From a more practical/technical side of things, am I the only one here who somehow believes dynamic map generation and huge universes are still possible within the SC2 engine?
Eiviyn, you say there's only so much joy in exploring one tiny SC2 map. I agree. What if you could pack several hundreds, or even thousands, or smaller blocks within the same space?
See, this is the advantage of space games. They're modular (or easy to make so) by nature. All you need is one big "empty" area made of just that, space, and then place objects within it (stars, stations, asteroids, planets, ships, nebulae, etc.). What I'm thinking is that you could just divide one giant map into subsections, and have the contents of those subsections and their relative positions saved somewhere until you actually need to display or access that section, where you just load it and place its contents on a pre-arranged visualizing area. Thus, you still have a map that is technically 256x256 or even smaller in SC2's terms, but can have the game take place over a virtual playing field that would be the equivalent of a map exponentially larger without losing any control over scale.
Has this already been thoroughly studied and dismissed as unfeasible before? Has no one ever really thought about doing things this way? My current tests leave me fairly optimistic about this, so if there's some issue I don't see I'd appreciate it being brought up, considering that any future mapping projects I might have will most likely depend on this kind of systems.
I doubt that that's what he meant. He specifically stated that this should be "just like changing the game speed from 'normal' to 'faster'". This implies that the entire game is sped up. I believe the best technical method to accomplish this would be to simply accelerate the game clock further. The problem is that it's probably impossible with the current tools to directly do exactly that. Game speed is set internally depending on one of five native values (c_gameSpeedSlower to c_gameSpeedFaster, with respective integer values being 0 to 4), and we have no direct control over the actual rate of game time as far as I can tell.
Thus, either someone finds a workaround to trick the SC2 engine into going faster, or manually edits every single entry in the entire melee catalog (i.e. all the data available in the data editor when the melee dependency is activated) to make their duration shorter.
The "Param/Value/342708EE" text you see is actually the content of your "Text" variable. Text variables are only references, and usually they point to a certain position in another file within the map archive that contains the actual text for all the Text constants use in your map. If you try to do something with a string variable instead, this should not happen.
The thing about logging in in one disconnecting you from the other is entirely normal. You can't be connected to Battle.net from two "clients" at the same time, and Galaxy Editor and StarCraft II are both considered as "clients". Sure, it might be annoying, but it's normal and works the way they intended it to as far as we know.
As for your problem with testing maps, I don't know why it would do that, since it always lets me test maps offline. It may be a registry and/or user cache issue. If that's the case, and I would like to insist that I'm really not sure it is, it may be best to completely uninstall the game and manually remove leftover folders before installing again.
The reason for this is simple, if it's what I think it is: You need to first publish the mod by itself, then, in your map, add the published version of the mod as a dependency. Only that will work. Publishing the map with a local dependency and playing it on bnet, even if all players have the mod locally, has caused problems in all my tests.
There seems to be a major issue with the internal "Player () selects Quit Button" event where that event, while successfully disconnecting the player from the game, fails to call/notify the internal "GameOver()" function, which is what the "Player Leaves Game" event seems to fire on.
If anyone can find a proper solution, that's good, but I doubt there's anything we can do without a Blizzard fix or an large ugly .5 second loop.
Some people have reported that putting the Campaign files first in the Dependencies list instead of leaving them at the bottom fixes this issue for them. This is the solution that worked for me, too.
For the saving of data, I believe a little exploration in the "Bank" label of the trigger actions will be enlightening. From what I see, they seem to be exactly what you're looking for.
As for the part about heroes, that will take a bit more exploration in the data editor. I believe you can make a hero entirely there without touching the trigger editor. Stuff within the trigger editor pertaining to heroes would, I think, be more useful in case you want to dynamically create or modify heroes or their properties ingame. Most of the stuff within the data editor seems to be possible to actively modify during runtime through galaxy scripting if not already handled by the GUI Trigger Editor.
0
From a more practical/technical side of things, am I the only one here who somehow believes dynamic map generation and huge universes are still possible within the SC2 engine?
Eiviyn, you say there's only so much joy in exploring one tiny SC2 map. I agree. What if you could pack several hundreds, or even thousands, or smaller blocks within the same space?
See, this is the advantage of space games. They're modular (or easy to make so) by nature. All you need is one big "empty" area made of just that, space, and then place objects within it (stars, stations, asteroids, planets, ships, nebulae, etc.). What I'm thinking is that you could just divide one giant map into subsections, and have the contents of those subsections and their relative positions saved somewhere until you actually need to display or access that section, where you just load it and place its contents on a pre-arranged visualizing area. Thus, you still have a map that is technically 256x256 or even smaller in SC2's terms, but can have the game take place over a virtual playing field that would be the equivalent of a map exponentially larger without losing any control over scale.
Has this already been thoroughly studied and dismissed as unfeasible before? Has no one ever really thought about doing things this way? My current tests leave me fairly optimistic about this, so if there's some issue I don't see I'd appreciate it being brought up, considering that any future mapping projects I might have will most likely depend on this kind of systems.
0
@Jooon: Go
I doubt that that's what he meant. He specifically stated that this should be "just like changing the game speed from 'normal' to 'faster'". This implies that the entire game is sped up. I believe the best technical method to accomplish this would be to simply accelerate the game clock further. The problem is that it's probably impossible with the current tools to directly do exactly that. Game speed is set internally depending on one of five native values (c_gameSpeedSlower to c_gameSpeedFaster, with respective integer values being 0 to 4), and we have no direct control over the actual rate of game time as far as I can tell.
Thus, either someone finds a workaround to trick the SC2 engine into going faster, or manually edits every single entry in the entire melee catalog (i.e. all the data available in the data editor when the melee dependency is activated) to make their duration shorter.
0
@Dystisis: Go
The "Param/Value/342708EE" text you see is actually the content of your "Text" variable. Text variables are only references, and usually they point to a certain position in another file within the map archive that contains the actual text for all the Text constants use in your map. If you try to do something with a string variable instead, this should not happen.
The thing about logging in in one disconnecting you from the other is entirely normal. You can't be connected to Battle.net from two "clients" at the same time, and Galaxy Editor and StarCraft II are both considered as "clients". Sure, it might be annoying, but it's normal and works the way they intended it to as far as we know.
As for your problem with testing maps, I don't know why it would do that, since it always lets me test maps offline. It may be a registry and/or user cache issue. If that's the case, and I would like to insist that I'm really not sure it is, it may be best to completely uninstall the game and manually remove leftover folders before installing again.
0
The reason for this is simple, if it's what I think it is: You need to first publish the mod by itself, then, in your map, add the published version of the mod as a dependency. Only that will work. Publishing the map with a local dependency and playing it on bnet, even if all players have the mod locally, has caused problems in all my tests.
0
There seems to be a major issue with the internal "Player () selects Quit Button" event where that event, while successfully disconnecting the player from the game, fails to call/notify the internal "GameOver()" function, which is what the "Player Leaves Game" event seems to fire on.
If anyone can find a proper solution, that's good, but I doubt there's anything we can do without a Blizzard fix or an large ugly .5 second loop.
0
Some people have reported that putting the Campaign files first in the Dependencies list instead of leaving them at the bottom fixes this issue for them. This is the solution that worked for me, too.
0
For the saving of data, I believe a little exploration in the "Bank" label of the trigger actions will be enlightening. From what I see, they seem to be exactly what you're looking for.
As for the part about heroes, that will take a bit more exploration in the data editor. I believe you can make a hero entirely there without touching the trigger editor. Stuff within the trigger editor pertaining to heroes would, I think, be more useful in case you want to dynamically create or modify heroes or their properties ingame. Most of the stuff within the data editor seems to be possible to actively modify during runtime through galaxy scripting if not already handled by the GUI Trigger Editor.