Strictly speaking, the answer is no. The GUI -> Galaxy conversion is one-way. For example, comments will not appear in the Galaxy code and therefore can not be restored. Same goes for presets, macros etc.
However, a majority of the code could in theory be recovered. There is no such tool though, so you are probably better of reading and understanding Galaxy itself.
Variable access in general is faster than function calls, because each function call introduces some additional overhead. The overhead typically increases with the amount of parameters, because each of them needs to be copied to the functions local stack.
However, in practice, these differences rarely matter. As a beginner, make sure to focus on correctness instead of performance.
The descriptions are saved in a seperate folder and file because they can be localized. They are not directly related to the XML data. The XML data is connected to the localized text via a unique ID.
Try to find the enUs folder in your mpq archive and copy its contents. There should be a bunch of text files (GameStrings.txt etc.)
Over five years ago, myself, a creative developer, and Philipp Meyer, a brilliant programmer, began developing a ‘World of StarCraft’ prototype using the StarCraft II Engine. Neither of us knew of each other’s projects, until one day we discovered one another and joined forces to build a small team, beginning work on what we wanted to be the biggest mod ever made… Not just a mod. A game. A complete transformation of the way StarCraft was played; Something the entire Blizzard community dreamed of for years.
We wanted to combine the third person action RPG elements of World of WarCraft, the combat mechanics of Diablo, and the starship mechanics of FTL with the StarCraft setting. We wanted the game to be completely voice acted with a unique story, custom art assets, and a fresh musical score. We wanted it to open with a breathtaking CG cinematic, inspired by Blizzard Entertainment’s dedication to high production values.
And so our small group set out to do what many said we were crazy to do, what others said we would never finish, and what some said we would completely fail at… But there were those throughout the globe who believed in us, backed us, and bought us the time we needed to deliver on our promises.
Today we announce the Open Beta of StarCraft Universe: Beyond Koprulu, and the full launch slated to release one month from now! We don’t own the intellectual property on StarCraft, so we cannot sell SCU, but we ask those who are able and enjoy what we’ve done, to back us on Indiegogo, a platform endorsed by Blizzard for community developers to receive donations.
To all those who believed in us and helped us along the way, we say thank you. SCU would not have been possible without you. We look forward to seeing you all… in the worlds… of StarCraft.
Its important to understand that events are not dynamic, in other words, the events get defined at map initialization, once. Therefore, if you variable is not set before the event gets initialized, it wont work properly or yield unexpected results. For example, a unit variable which defaults to a NULL value will count as ANY UNIT for some events, causing it to fire more often than necessary.
You can also use the data table feature. Simply get the unit ID, convert it to a string and use it as key. Then, add the attached actor as value.
Later you can simply look up the actor in the data table and send the destroy event.
Bank files should be able to store unicode strings. You could create a bank file mapping unicode commands to trigger function names and look up the trigger function by name to execute a specific trigger upon receving a chat cmd.
its quite hacky, too, but maybe a valid alternative to the escape sequence stuff.
Not sure if known because this thread is so long...
Pitfall: Removing a unit does not instantly remove it from unit groups anymore
Solution: remove it manually, else maybe a check for it being alive works. It basically means that you now need to actively prevent this... same for inventory items, though.
Pitfall: I get the trigger error "TextError: Text [0] is too tall for a single line. Exceeds by [4]". I get this during editor play testing and the odd thing is it doesn't happen all the time. When it does, it's at map start.
Solution: I don't have a solution for this yet.
Increase the labels height by 4 to fix the problem. Its a new warnign added for labels that are too small to store their text value properly. You need to figure out which label it is by yourself though. :) In your case, it has something to do with the text "0".
0
Strictly speaking, the answer is no. The GUI -> Galaxy conversion is one-way. For example, comments will not appear in the Galaxy code and therefore can not be restored. Same goes for presets, macros etc.
However, a majority of the code could in theory be recovered. There is no such tool though, so you are probably better of reading and understanding Galaxy itself.
0
Variable access in general is faster than function calls, because each function call introduces some additional overhead. The overhead typically increases with the amount of parameters, because each of them needs to be copied to the functions local stack.
However, in practice, these differences rarely matter. As a beginner, make sure to focus on correctness instead of performance.
0
I'm sure you can refactor your code, so that you can fit all the stuff in.
Try to avoid duplicate code, use actions and functions, use user data XML for constant data.
0
The descriptions are saved in a seperate folder and file because they can be localized. They are not directly related to the XML data. The XML data is connected to the localized text via a unique ID.
Try to find the enUs folder in your mpq archive and copy its contents. There should be a bunch of text files (GameStrings.txt etc.)
0
Try tga instead of dds. Sounds like a MAC bug.
0
Upheaval Arts is Proud to commence the launch of StarCraft Universe!
Cinematic Trailer -
Gameplay Trailer -
Indiegogo - https://igg.me/at/SCU
OPEN BETA ZONES CURRENTLY ON BATTLE.NET
SC Universe: Prologue 1 (Singleplayer Basic Tutorial)
SC Universe: Prologue 2 (Multiplayer Basic Raid)
SC Universe: Prologue 3 (Singleplayer Ship Tutorial)
SC Universe: Beyond Koprulu (Limited Open Beta)
Over five years ago, myself, a creative developer, and Philipp Meyer, a brilliant programmer, began developing a ‘World of StarCraft’ prototype using the StarCraft II Engine. Neither of us knew of each other’s projects, until one day we discovered one another and joined forces to build a small team, beginning work on what we wanted to be the biggest mod ever made… Not just a mod. A game. A complete transformation of the way StarCraft was played; Something the entire Blizzard community dreamed of for years.
We wanted to combine the third person action RPG elements of World of WarCraft, the combat mechanics of Diablo, and the starship mechanics of FTL with the StarCraft setting. We wanted the game to be completely voice acted with a unique story, custom art assets, and a fresh musical score. We wanted it to open with a breathtaking CG cinematic, inspired by Blizzard Entertainment’s dedication to high production values.
And so our small group set out to do what many said we were crazy to do, what others said we would never finish, and what some said we would completely fail at… But there were those throughout the globe who believed in us, backed us, and bought us the time we needed to deliver on our promises.
Today we announce the Open Beta of StarCraft Universe: Beyond Koprulu, and the full launch slated to release one month from now! We don’t own the intellectual property on StarCraft, so we cannot sell SCU, but we ask those who are able and enjoy what we’ve done, to back us on Indiegogo, a platform endorsed by Blizzard for community developers to receive donations.
To all those who believed in us and helped us along the way, we say thank you. SCU would not have been possible without you. We look forward to seeing you all… in the worlds… of StarCraft.
0
Its important to understand that events are not dynamic, in other words, the events get defined at map initialization, once. Therefore, if you variable is not set before the event gets initialized, it wont work properly or yield unexpected results. For example, a unit variable which defaults to a NULL value will count as ANY UNIT for some events, causing it to fire more often than necessary.
0
If anything we would need access to the current database and a redirect mechanism, which wont happen. :(
0
Looks sick! :D
0
@sandround: Go
You can also use the data table feature. Simply get the unit ID, convert it to a string and use it as key. Then, add the attached actor as value. Later you can simply look up the actor in the data table and send the destroy event.
No need for complex array management.
0
Bank files should be able to store unicode strings. You could create a bank file mapping unicode commands to trigger function names and look up the trigger function by name to execute a specific trigger upon receving a chat cmd.
its quite hacky, too, but maybe a valid alternative to the escape sequence stuff.
0
Sadly doesnt seem to be possible right now.
0
The Bank Preload action only accepts literal values (No variables allowed).
0
What? Really? Wow thats weird...
0
Increase the labels height by 4 to fix the problem. Its a new warnign added for labels that are too small to store their text value properly. You need to figure out which label it is by yourself though. :) In your case, it has something to do with the text "0".