Can you elaborate on splitting the map up by the visible/invisible portions? As in each module will be sent the data from their related sections?
Nono, this is a stand alone program. It's for grafting portions of maps together. It won't interact with the other modules.
I honestly think that doing it the COM way would be better....
And its going to be hectic unless you define a standard you should all follow and by standard I mean a set way of how your 'module' (I still think COM would be better) should be structured, kind of like CSS defines tags in HTML, you should have a standard your programmers follow.... For portability ease and speed of the program.
The primary problem with this is that then I would have no programmers. People aren't going to want to help if they have to learn a new standard a new language etc.
None.
And its going to be hectic unless you define a standard you should all follow and by standard I mean a set way of how your 'module' (I still think COM would be better) should be structured, kind of like CSS defines tags in HTML, you should have a standard your programmers follow.... For portability ease and speed of the program.
The way he wants it done means its not necessary to make a "standard."
Then I guess if he wants to take the time to go through source code to optimize it so it runs quick then cewl. Cause I bet the people he's working with probably wont (if they do, sweetness less work for the guy wanting to do this). Creating that 'standard' would create the basic 'rules' used in the production.
Sall good though, just giving ideas.
None.
Then I guess if he wants to take the time to go through source code to optimize it so it runs quick then cewl. Cause I bet the people he's working with probably wont (if they do, sweetness less work for the guy wanting to do this). Creating that 'standard' would create the basic 'rules' used in the production.
Sall good though, just giving ideas.
This whole paragraph makes little sense? Was your suggestion motivated by performance worries? What made you think that any type of map editor would have performance problems?
Anyways I get the impression that you really don't know your stuff...
None.
i have no knowledge is programming this is WAY out of my lead! the best I can do is suggest ideas for the editor
I wish the project workers the best of luck.
None.
This works flawlessly:
void* data = new char[985];
SFileReadFile(ArchiveFile, data, 4, NULL, NULL);
This segfaults:
void* data = new char[984];
SFileReadFile(ArchiveFile, data, 4, NULL, NULL);
Needless to say, I'm not very satisfied with sfmpqapi at the moment.
EDIT:
Plan BEDIT2: Plan B works flawlessly. I have successfully recreated DecompileMap.exe in 2 or 3 days and 100 lines of code. Now however I am at my second roadblock, one which isn't an immediate problem, but presents a challenge for the long term sustainability of the project. Wish me luck.
Post has been edited 3 time(s), last time on Dec 26 2008, 8:29 am by scwizard.
None.
This works flawlessly:
void* data = new char[985];
SFileReadFile(ArchiveFile, data, 4, NULL, NULL);
This segfaults:
void* data = new char[984];
SFileReadFile(ArchiveFile, data, 4, NULL, NULL);
Needless to say, I'm not very satisfied with sfmpqapi at the moment.
Strange, the threshold value SFileReadFile will start segfaulting on is somewhere between 3072 and 4096 bytes on my computer. Does this mean that if I were to run your program it'd segfault on me since you used only 985 bytes?
None.
Strange, the threshold value SFileReadFile will start segfaulting on is somewhere between 3072 and 4096 bytes on my computer. Does this mean that if I were to run your program it'd segfault on me since you used only 985 bytes?
I have no idea. Doodle says that this is fixed in the new version. However I'll continue to use storm for reading purposes.
Also this might be useful to some people:
EDIT: .-.
Post has been edited 3 time(s), last time on Jan 4 2009, 4:36 pm by scwizard.
None.
Hey, I'd love to help, but I no little a bout coding. If there's any grunt work to be done, I'm here. (I can do icons and such too, I'm quite skilled with paint-like programs)
Is this going to be Mac-Patible? (Please say it will be Mac-patible)
None.
Hey, I'd love to help, but I no little a bout coding. If there's any grunt work to be done, I'm here. (I can do icons and such too, I'm quite skilled with paint-like programs)
Is this going to be Mac-Patible? (Please say it will be Mac-patible)
My program? I'd like to, but I'd have to figure out Cocoa in order to do that. I really don't want to have to figure out Cocoa.
Other people's programs? I have no idea.
Post has been edited 1 time(s), last time on Dec 28 2008, 12:02 am by scwizard.
None.
Then I guess if he wants to take the time to go through source code to optimize it so it runs quick then cewl. Cause I bet the people he's working with probably wont (if they do, sweetness less work for the guy wanting to do this). Creating that 'standard' would create the basic 'rules' used in the production.
Sall good though, just giving ideas.
This whole paragraph makes little sense? Was your suggestion motivated by performance worries? What made you think that any type of map editor would have performance problems?
Anyways I get the impression that you really don't know your stuff...
People do code differently. Some code it so it works but works slowly, some code it so it performs faster.
And you're right. I don't know anything about Starcraft editing cause I gave up on that stuff a long time ago to venture into more complex things such as high/low-level coding, Web Design and Music Composition.
Just trying to help out anyways, sheesh.
None.
People do code differently. Some code it so it works but works slowly, some code it so it performs faster.
And you're right. I don't know anything about Starcraft editing cause I gave up on that stuff a long time ago to venture into more complex things such as high/low-level coding, Web Design and Music Composition.
Just trying to help out anyways, sheesh.
Sorry about that, I got the wrong impression because I didn't really understand exactly what you were talking about. Now I have a better idea of what you're talking about. You weren't suggesting good design for the sake of speed, just good design for the sake of good design (and to speed up development times by removing redundancy).
It would be a good idea under normal circumstances, but in this particular case I'm paranoid about over centralizing this thing. Also I kind of would like to see the project participants learn stuff themselves instead of relying on other people's code to help, kind of to force them to walk before they can run.
None.
Is this going to be Mac-Patible? (Please say it will be Mac-patible)
My program? I'd like to, but I'd have to figure out Cocoa in order to do that. I really don't want to have to figure out Cocoa.
Other people's programs? I have no idea.
Sfmpqapi includes windows.h and I don't think Storm has mpq writing functions that we can use. Theres a linux folder with a custom windows.h/.cpp though, so cross compatibility is probably possible if the programmer uses a API like wxWidgets or Qt to develop the gui.
Strange, the threshold value SFileReadFile will start segfaulting on is somewhere between 3072 and 4096 bytes on my computer. Does this mean that if I were to run your program it'd segfault on me since you used only 985 bytes?
I have no idea. Doodle says that this is fixed in the new version. However I'll continue to use storm for reading purposes.
Just downloaded the latest version, doesn't segfault even when I pass it a pointer to a buffer 1 byte long and read it a byte at a time xD . Didn't check before, but the SFmpqapi listed on the
downloads page was last updated in 2002, the latest can be found
here.
BTW: Is
Inside MoPaQ still being updated or has that been abandoned by the original author? Copyright is listed as 2002
.
Should modules allow mappers to input any value for each setting, perhaps after setting an 'expert' option? IE: In the
OWNR section there are 9 valid values for each player, however a byte can store any number from 0-255. Won't be useful to most people for this section, but should someone want to set it to that value for some desired effect they'd be able to easily.
Post has been edited 1 time(s), last time on Dec 30 2008, 9:49 am by Elvang. Reason: Forgot original reason for posting
Ohhh, that helps out a ton. Thanks.
Should modules allow mappers to input any value for each setting, perhaps after setting an 'expert' option? IE: In the
OWNR section there are 9 valid values for each player, however a byte can store any number from 0-255. Won't be useful to most people for this section, but should someone want to set it to that value for some desired effect they'd be able to easily.
My opinion on the matter is yes, but it's up to the person witting the program.
None.
i have a few ideas in mind. i really dont know if its possible to do them.
(some (maybe all) ideas are very generic and/or very hard to do)
Collapsable Box
Offset Calculator
EUD trigger list
Auto update with new SCBW B.net patch (works with 1st 2 ideas)
Text trigger Find function
Sprite filters (includes filters for Crashing sprites,non crashing sprites, pure sprites, and a customizable filter)
Clipboards for Terrain, Units, and Sprites
This one would be really sweet and would proabably be very hard to do.
An action viewer mode:
a button that displays a timeline for triggers and scripts carried out
hilight the timeline to select a certain period for viewing
displays locations, states triggers being carried out, and colors for each player.
when crashed, instantly opens up the map editor to prevent lost data
None.
A couple of those I'd like as features in an editor as well, though the action viewer mode I don't think is possible unless I'm misunderstanding exactly what it would do.
Quote from Other features that would be cool
Place multiple copies of a unit at once
Change default settings for a unit when being preplaced (IE turn on invincibility and burrowed for zergling)
Text overlapper(
possible)
Built in mass trigger creator for triggers where only a few variables change
its just basically what farty did i think just a shortcut in the map editor
None.
Switched back to sfmpqapi. The storm lib I was using had a weird bug.
Awesomely, the current version of sfmpqapi comes with the source code. There's already one bug I know I want to fix.
None.
I did not read eevrything so I'm not sure if all those features will be avaible...
but here is what I have a mind:
- Grid
- Perma Location
- Perma "can be placed here?" [just the grey spots when you select a ground unit and want to place it]
- Display TERRAIN only
- Display DOODADS only
- Display UNITS only
- A windows where the exact unit sizes are displayed (for inverted locations)
- Just for terrain-check, so you can check if a unit can past "there". maybe you place a unit, and then you can select it, and "order" it somewhere. So you can check if the unit can get past small terrain parts or not. that would stop all the ingame tests
- string editor like in SCMdraft
- WAV Editor with all stardat.mpq wavs ofc. and high/med/low/no compression for self-imported ones
- That you can click on the editor-screen while the trigger-editor is opend, so you can add units/locations while it is opend
- display all parametres in triggers in a costum color
- trigger count
- string count
- locaiton count
- location editor (just displays a "minimap" and a block for each location. there is a list next to the minimap with all placed location listed. click on one of them and that block will be markes as green
- a compress-editor so you can erase unused unit-names (if they are set, but not needed in triggers/ingame), unused location, "never" triggers, comments, and location names
- Map-Protector with password-protection
- allow illegal doodad placement
- ofc the copy/cut/paste function shouldn't be missed
- a function which always deletes flags, which would crash if you click on it
- a function which erases each unit, which cause crashes when game starts
- Maybe an "addon" for the trigger editor: just an input field named "hyper triggers" if you tick it hyper triggers automatly will be added, if not, they'll be removed
- a string-color-codes addon, which shows which color IS what color in what section (like "green" in map-title is red etc.)
- Map-Zoom (best: costum)
- a Tech/upgrades extra button: Make all Techs researched/ all upgrades max, and would be cool if there are buttons like these for each single race
- an "ingame-screen" so you can look how it would look like ingame (console etc.)
- maybe jsut some extended terrains which are pre-done (like a high cliff x2 [from falko ]) so you can place it as a "doodad"
- doodad: convert to terrian function would be cool
- In the tileset editor there should be a extra slot where a/the walkable-null-terrain is.
- This may is hard to make, but maybe a "balance checker" it compares each dmg/armor/hp of the selected units and they will tell you if all are blanaced or if there is a unit which would be to good
That's all I have in mind at the moment. I hope there are things in it which you gonna add.
Thanks for reading, hope that helps.
Please report errors in the Staredit.Network forum.
i have a few ideas in mind. i really dont know if its possible to do them.
(some (maybe all) ideas are very generic and/or very hard to do)
Collapsable Box
Offset Calculator
EUD trigger list
Auto update with new SCBW B.net patch (works with 1st 2 ideas)
Text trigger Find function
Sprite filters (includes filters for Crashing sprites,non crashing sprites, pure sprites, and a customizable filter)
Clipboards for Terrain, Units, and Sprites
This one would be really sweet and would proabably be very hard to do.
An action viewer mode:
a button that displays a timeline for triggers and scripts carried out
hilight the timeline to select a certain period for viewing
displays locations, states triggers being carried out, and colors for each player.
when crashed, instantly opens up the map editor to prevent lost data
i forgot to add something...
a location editor that allows you to "punch out" unwanted squares on locations
None.