What if there are two different towers that can upgrade to the same tower, and for trigger reasons it absolutely must be the same unit (not an identical clone)? The moment those two source towers have a different initial cost, the cost to upgrade will be different, and you can't compensate for that. Imagine this nested inside a long and tortuous but finely-balanced upgrade tree where those three towers are far away from being either the first tower(s) you build or the final upgrade(s), and it's easy to see (for me anyway) how the cost issue could be a problem.
Also, this assumes that the costs are static, so that you can manually calculate the different and account for it in the permanent values. It also assumes that you'll always buy this second tower exclusively by upgrading it from the first, which may not always be the case - maybe later on you unlock a new cost and time-saving builder that can directly build later tower versions and save you the difference?
If the name of Tercesje's map is any indication, this is intended for a tutorial rather than an actual published map. In this case, you want to keep in mind any of the above possibilities, because people following the tutorial just might want to do something that isn't exactly like the traditional TD model.
Other point worthy of note: OP is in EU, grenegg is in NA. I'm in NA too, and I also have never seen this sort of behavior despite having always been in Bronze since the beginning of time (i.e. I do play with Bronze-level skills have that's been my skill level since the early days of SC1 because I can't care enough to improve my melee skills). On the contrary, most people I've played against were either completely silent the entire game, said only a conservative "gl hf" and "gg" at the beginning and end of the match, or were very friendly and smart with verbal jabs sometimes being exchanged during the game.
Another possible factor is the time of day you pick to play. If you're playing around 16-17h, right when all the hyper kids come back from school in a hurry to play a game and "pwn sum n00bs" and when all the adults tired from a long day of work are stressed out and just want to let out the steam somewhere, then you're bound to have more chances of meeting troublesome players. If on the other hand you're playing around 4-5h, while there'll be a lot fewer players, most of them will be somewhat more dedicated gamers or people who live at their own pace, both of which are usually less belligerent to other players.
There *is* no such thing as a script you can just paste into a Custom Script block that will run. The reason why is that this way, the game has no way to know how or when to run that code. At the very least, you need to also type / paste a function name in the init box at the bottom of the Custom Script view so the game knows it has to run that function at map init.
Also, all the complaints and errors you've been getting I've already explained and given solutions for in my posts, so it would seem you're skipping stuff. At this point, considering that behavior, there's not much more I can do to help - I've already given you several examples and detailed explanations that contain exactly what you're asking for, as well as other examples for comparison, and so have FuzzYD and Avogatro. Simply re-reading over this thread would give you all the information you need regarding this.
It's also theoretically possible to convert Assembler into Common English. However, I believe the issue is that in both cases, it would require much more effort to create a program that does the conversion automatically than to simply manually recreate/convert specific code from galaxy to GUI (or assembler to english) whenever it's really needed.
Then again, a good AI program could solve the issue entirely. Hmm.
On-topic: It's not impossible, but definitely not practical, and for the reasons stated above will probably never be done.
I believed I'd already made clear in my explanations where goes what and what exactly you need in a custom script to have it working. However, here's an even more detailed explanation:
Yes, that's all it needs to work, and yes, I've tested that and it works exactly as intended.
The reason that code generates script errors is because of "playergroup players" in your first UIDisplayMessage() call. In vanilla Galaxy, you can't declare variables on-the-fly, only in the global scope and at the very top of a function. The would-be "players" variable here also doesn't even have a value, so even if it were valid code it still wouldn't work ingame. You need to tell the function to output to all players by passing it a player group that contains all players (or anyway, pass it a group that contains all players whom you want to see the message). The function PlayerGroupAll() returns such a group that contains all players. Most people use a global variable called PLAYERS_ALL or somesuch that is set to PlayerGroupAll() at map init, so as to reduce unnecessary function calls and thus optimize code a tiny bit.
Also, you send "hello world" as a parameter to the UIDisplayMessage function. "hello world" is a string. UIDisplayMessage needs a "text" variable, not a "string" variable. Thus, you need to use the StringToText() function (which transforms the string you give it into a text) to pass a text to the UIDisplayMessage() call in this case.
Anyway, if its one thing Im certain of, that being no one will ever possibly create an amazing Co-op Campaign. Not going to happen. Ever.
I assume here you're talking about Coop Campaigns in RTS games specifically. Otherwise, I will kindly point you towards:
Magicka
Half-Life (the entire campaign from HL1 to EP2, albeit slightly modified, can be played in coop seamlessly through mods, and it's tons of fun)
Neverwinter Nights (mostly the first, though the second still qualifies - throw in a good DM, and you just cranked up both replayability and immersion to epic levels beyond anything else mentioned in this post)
Magicka
System Shock 2
Did I mention Magicka? Seriously. I'd even be surprised if no one tries to remake Magicka in SC2.
Honorable Mentions: Tom Clancy's Splinter Cell series has coop mini-campaigns of various kinds and gamemodes in at least two of its titles. They might not be campaigns proper, and their story definitely could be a lot better, but hey, they're fun. Left 4 Dead and its sequel also deserve mention. The story is badly portrayed ingame, but I believe that's simply a design decision, because the actual backstory and the world events are rich and immersing when you really delve into them and look for them. They're just kept out of view of the players during gameplay. Finally, WH40k: Dawn of War II has some really good coop gameplay that lets you play through the whole campaign together. However, some of the content is fairly average, and replayability is almost non-existent.
So yeah, so far Co-op Campaigns are one of the gameplay types that require the most development time and effort, and usually are the least efficient application of this effort out of several other options. However, this is not because of the inherent properties of those campaigns, but merely because of different expectations both from the developers and from the players as to "how" a coop campaign should be, and if those issues are overtaken (or conveniently ignored and made self-invalidating, as in Magicka's case), a coop campaign can shine for twice its worth in developer effort.
I've only listed above whatever I could think up off the top of my head. I'm sure there's more that I either don't remember or don't know about.
TL;DR: There are quite a few good coop campaigns out there. It's not impossible to make one. If you want to make one, go ahead. Just keep in mind that it's hard to keep a playerbase on coop content alone, and the initial investment in time and energy to make something good is much steeper than other mediums, though later on the effort-vs-fun ratio cranks back up much higher once more and more polish and fleshing-out is done.
Import your script (e.g. the hacked Sotis galaxy script) as "importedScript.galaxy" in your map through the Import manager. The name doesn't really matter, I just used this so you can see what I do.
Now, open the target map where you want that script to be, create a Custom Script block. In this block, at the very bottom, type "customInit", and then create a function called customInit in your custom script block. This function should call all the initializers in the imported script. Finally, at the top of the Custom Script block (before the customInit function), place the line: include "importedScript"
Again, the names themselves don't matter, as long as you use the same at both places they're used. Note the lack of filetype suffix (".galaxy") in the include statement. This is normal and required - SC2 adds the .galaxy on its own, so if you put one it'll try to find importedScript.galaxy.galaxy and will obviously fail.
That's "include trickery". Best to go with other methods - or even better, not steal someone else's code - if the above is too complex for you (this is directed at anyone who will be concerned by this statement and no one in particular).
If you'd taken the time to look around (and read the OP), you'd have noticed that Hive Keeper's main project page was last updated just a few days ago, and there are no indications that he was leaving, abandoning or otherwise stopping the project. The Jan 28 update even indicates that recent progress has been made on units, portal summoning and room conquest.
If such a "list" existed, it would contain more words than the current size of the known Universe in cubic micrometers. That's the whole point of programming and scripting; the possibilities are practically infinite. Of course, most of those possibilities are of no interest whatsoever to any of us, but still, even 0.01% of "practical infinity" remains a gargantuan number.
The best place to start for learning galaxy is probably here, and then using the Script View (CTRL-F11 from the Trigger Editor) to look at code generated by triggers.
Galaxy scripting is mostly used either because the mapmaker is simply used to typing code, wants to have more control and flexibility over how the map/script works, wants to do more with less (often, a smart coder can make a small script in five minutes where doing the same thing with triggers would take half an hour), or wants to optimize his code for maximal performance (because you need better control over the code to achieve this than what is offered by triggers), or any combination of the previous points.
Fair warning though: Even galaxy, as simplistic a language as it is, is not for the faint of heart and will take a lot of time and effort to learn if you've never worked with programming or scripting languages before.
Actually, the two methods I stated above I've learned from Motive directly while I was attempting to help the Cortex project. I agree that working in external files is pretty good. At the moment I'm very partial to Andromeda, and developing in Andromeda has the huge advantage that I haven't even opened the map I'm currently working on in the SC2 editor in days, yet have been working on it constantly - the code of the map itself basically consists of a single include statement in a custom Action definition, which the Andromeda compiler detects when compiling the map. The rest of my code is 100% external, and the compiler does all the importing and other tidbits of data-mongering on its own (on top of compiling Andromeda code to Galaxy code, obviously). Looking forward to 0.2.0, too. Just wish I had Moonlite to go along with all this.
As for SoulCarver's difficulties (e.g. seeming like he doesn't know about constants), I'm assuming it's more because he isn't too familiar yet with the structural concepts and terminology associated with galaxy script. It's very easy to fully understand and use adequately the concept of "number or value that has a name and that doesn't change" without necessarily knowing that that's called a "constant" in mathematical or coding jargon, to take a generic primitive example.
The above will print "Hello World!" to the "debug area" (basically to the left of the screen, just above the minimap) three real seconds after the map starts.
Yes, that is a complete and functional MapScript.galaxy. It's not necessary to put your trigger "Actions" in a separate function call - if anything, keeping the entire trigger content in the same function helps with performance a tiny bit.
As for getting your custom script to run, the easiest way is to simply create a new "Custom Script" element in your trigger list view (RightClick -> New -> New Custom Script, when you right-click the panel that shows your list of triggers in the trigger editor). When you select this new element, you'll see a large window for typing your script, and at the very bottom a tiny little box called "Initialization Function (Optional)". Whatever you type in this box will be the function name of the function you want to run in this Custom Script block at map init.
So, if I make a Custom Script block with a "fooBar" function and I enter "fooBar" in the Init Function box at the bottom, my resulting MapScript.galaxy might look like this:
include"TriggerLibs/NativeLib"triggerfoo;voidInitLibs(){libNtve_InitLib();}voidfooBar(){Wait(5,c_timeReal);UIDisplayMessage(PlayerGroupAll(),c_messageAreaDebug,StringToText("I'm a test!"));}boolbar(booltestConds,boolrunActions){if(!runActions){returnfalse;}UIDisplayMessage(PlayerGroupAll(),c_messageAreaDebug,StringToText("Hello World!"));returntrue;}voidInitTriggers(){foo=TriggerCreate("bar");TriggerAddEventTimeElapsed(foo,3,c_timeReal);}voidInitCustomScript(){fooBar();}voidInitMap(){InitLibs();InitTriggers();InitCustomScript();}
Basically, you can use this Custom Script block itself to put all your code, one block could call functions and use globals from another Block (as long as it's positioned lower than the others in the trigger list, because that determines their position in the generated code and galaxy requires forward-definition), or this one block could have:
include"fileToInclude"
as its only statement, as long as you also import a file named "fileToInclude.galaxy" in your map through the import editor and it's located at the root "folder" of the map. This way you can work almost exclusively in external files. If you really want only external files, you can also import and override MapScript.galaxy with your own code (like I did to test the above examples), but that's a finnicky and tricky process and you'll bash your head on a wall trying to do it unless you know and perform the proper rituals to appease the gods of the Editor beforehand.
A straight implementation of that could lead to hidden and unexpected issues. For example, what if I attacked someone, waited 4.9 seconds, and attacked again? In the following 0.1 seconds, the wait time from the first instance would expire and the value would be set to false immediately, effectively counting me as out of combat even though I attacked someone again just 0.1 seconds earlier.
Since you're saving a global variable here anyway, a cleaner method would be to save the real time elapsed since the start of the game (or game time, but game time is affected by game speed) to a variable whenever the unit attacks or is attacked (overwriting the previous value each time so that only the latest attack time is kept), and when loading/saving/whatever you check the current game time versus the last attack time (the variable), and if the difference is greater than five seconds you proceed with the save/load, if it's smaller you warn the player or do whatever you want to do when not loading.
There is currently no means for us to dynamically modify the list of abilities (add/remove/replace abilities) for a unit at runtime (i.e. during gameplay through triggers or otherwise).
The best alternative is to pre-add abilities but disable and hide all of them by default and then enable the ones you want when you want to "add" them to the unit. There are several ways to do this, some of which allow abilities to only be enabled for a specific unit and others that can toggle abilities for all units of a certain type or even enable the ability globally for all units that have it. Whatever method you use is up to you - they're pretty much all as clumsy as the next when it comes to having a lot of abilities or a lot of different units that need access to many abilities.
This remains probably the single most cited engine limitation preventing the Cortex Roleplay Engine from reaching greater heights of mapping and modding innovation.
Heh, that sounds very much like me. Well, at least for the general ideas and the behavior part about never finishing a project, I mean. I won't be so bold as to claim pushing the boundaries and being amazing when I don't even have a single SC2 modding accomplishment to my name (well, that's not strictly true; I did contribute a feature or two, a bit of code, and some theory-crafting for the Cortex Roleplaying Engine project - but all things considered, I think that's not nearly on par with releasing a tech demo, let alone a complete map).
On another note, and I might be hijacking the thread a bit here (and if so I apologize, I'm just interested/curious), but I haven't seen anyone comment about races. Space games often involves multiple alien races duking it out (or talking it down) for supremacy, resources, or just because that's what they do. What do you all think would be the best way to handle races in a space game? Or is it better to avoid that issue entirely by postulating that there's only humans everywhere who have expanded and turned on eachother or somesuch? If the game allowed you to create/have your own race, what would you look for in it, expect, and think would be most fun or practical?
A drawing or a more elaborate explanation would be useless, since the system you describe happens to be exactly the staple feature of Gratuitous Space Battles (screenshot of the ship design screen). It's also been used in various forms in the Space Empires series (screenie!) and several other games.
It's basically a tried-and-true system that has a lot of merits and relatively few disadvantages, but the technical aspects of coding it are difficult for people not familiar with this type of game design philosophies and it makes balancing it out (both in the aspect of PvP balance and in the aspect of fun and options and choices and creating truly interesting/original components) rather complex.
Is trigger space some sort of hard limit on the amount of triggers you can use or something? I've heard about the 4MB limit, but I've also heard that Data Tables and at least one other thing were not counted in this memory limit. If you manage the data efficiently, you can probably have an active pool of up to (playercount) systems + generator + global variables + a few odd local variables, at any one time, supposing that all players all decided to explore new sectors at the exact same time. The rest (all the sectors generated but not currently active, for instance) stays in Data Tables until you need to do something with it.
0
@DrSuperEvil: Go
What if there are two different towers that can upgrade to the same tower, and for trigger reasons it absolutely must be the same unit (not an identical clone)? The moment those two source towers have a different initial cost, the cost to upgrade will be different, and you can't compensate for that. Imagine this nested inside a long and tortuous but finely-balanced upgrade tree where those three towers are far away from being either the first tower(s) you build or the final upgrade(s), and it's easy to see (for me anyway) how the cost issue could be a problem.
Also, this assumes that the costs are static, so that you can manually calculate the different and account for it in the permanent values. It also assumes that you'll always buy this second tower exclusively by upgrading it from the first, which may not always be the case - maybe later on you unlock a new cost and time-saving builder that can directly build later tower versions and save you the difference?
If the name of Tercesje's map is any indication, this is intended for a tutorial rather than an actual published map. In this case, you want to keep in mind any of the above possibilities, because people following the tutorial just might want to do something that isn't exactly like the traditional TD model.
0
@grenegg: Go
Other point worthy of note: OP is in EU, grenegg is in NA. I'm in NA too, and I also have never seen this sort of behavior despite having always been in Bronze since the beginning of time (i.e. I do play with Bronze-level skills have that's been my skill level since the early days of SC1 because I can't care enough to improve my melee skills). On the contrary, most people I've played against were either completely silent the entire game, said only a conservative "gl hf" and "gg" at the beginning and end of the match, or were very friendly and smart with verbal jabs sometimes being exchanged during the game.
Another possible factor is the time of day you pick to play. If you're playing around 16-17h, right when all the hyper kids come back from school in a hurry to play a game and "pwn sum n00bs" and when all the adults tired from a long day of work are stressed out and just want to let out the steam somewhere, then you're bound to have more chances of meeting troublesome players. If on the other hand you're playing around 4-5h, while there'll be a lot fewer players, most of them will be somewhat more dedicated gamers or people who live at their own pace, both of which are usually less belligerent to other players.
0
@SouLCarveRR: Go
There *is* no such thing as a script you can just paste into a Custom Script block that will run. The reason why is that this way, the game has no way to know how or when to run that code. At the very least, you need to also type / paste a function name in the init box at the bottom of the Custom Script view so the game knows it has to run that function at map init.
Also, all the complaints and errors you've been getting I've already explained and given solutions for in my posts, so it would seem you're skipping stuff. At this point, considering that behavior, there's not much more I can do to help - I've already given you several examples and detailed explanations that contain exactly what you're asking for, as well as other examples for comparison, and so have FuzzYD and Avogatro. Simply re-reading over this thread would give you all the information you need regarding this.
0
@MotiveMe: Go
It's also theoretically possible to convert Assembler into Common English. However, I believe the issue is that in both cases, it would require much more effort to create a program that does the conversion automatically than to simply manually recreate/convert specific code from galaxy to GUI (or assembler to english) whenever it's really needed.
Then again, a good AI program could solve the issue entirely. Hmm.
On-topic: It's not impossible, but definitely not practical, and for the reasons stated above will probably never be done.
0
@SouLCarveRR: Go
I believed I'd already made clear in my explanations where goes what and what exactly you need in a custom script to have it working. However, here's an even more detailed explanation:
The reason that code generates script errors is because of "playergroup players" in your first UIDisplayMessage() call. In vanilla Galaxy, you can't declare variables on-the-fly, only in the global scope and at the very top of a function. The would-be "players" variable here also doesn't even have a value, so even if it were valid code it still wouldn't work ingame. You need to tell the function to output to all players by passing it a player group that contains all players (or anyway, pass it a group that contains all players whom you want to see the message). The function PlayerGroupAll() returns such a group that contains all players. Most people use a global variable called PLAYERS_ALL or somesuch that is set to PlayerGroupAll() at map init, so as to reduce unnecessary function calls and thus optimize code a tiny bit.
Also, you send "hello world" as a parameter to the UIDisplayMessage function. "hello world" is a string. UIDisplayMessage needs a "text" variable, not a "string" variable. Thus, you need to use the StringToText() function (which transforms the string you give it into a text) to pass a text to the UIDisplayMessage() call in this case.
0
I assume here you're talking about Coop Campaigns in RTS games specifically. Otherwise, I will kindly point you towards:
Honorable Mentions: Tom Clancy's Splinter Cell series has coop mini-campaigns of various kinds and gamemodes in at least two of its titles. They might not be campaigns proper, and their story definitely could be a lot better, but hey, they're fun. Left 4 Dead and its sequel also deserve mention. The story is badly portrayed ingame, but I believe that's simply a design decision, because the actual backstory and the world events are rich and immersing when you really delve into them and look for them. They're just kept out of view of the players during gameplay. Finally, WH40k: Dawn of War II has some really good coop gameplay that lets you play through the whole campaign together. However, some of the content is fairly average, and replayability is almost non-existent.
So yeah, so far Co-op Campaigns are one of the gameplay types that require the most development time and effort, and usually are the least efficient application of this effort out of several other options. However, this is not because of the inherent properties of those campaigns, but merely because of different expectations both from the developers and from the players as to "how" a coop campaign should be, and if those issues are overtaken (or conveniently ignored and made self-invalidating, as in Magicka's case), a coop campaign can shine for twice its worth in developer effort.
I've only listed above whatever I could think up off the top of my head. I'm sure there's more that I either don't remember or don't know about.
TL;DR: There are quite a few good coop campaigns out there. It's not impossible to make one. If you want to make one, go ahead. Just keep in mind that it's hard to keep a playerbase on coop content alone, and the initial investment in time and energy to make something good is much steeper than other mediums, though later on the effort-vs-fun ratio cranks back up much higher once more and more polish and fleshing-out is done.
0
@Ezera: Go
Import your script (e.g. the hacked Sotis galaxy script) as "importedScript.galaxy" in your map through the Import manager. The name doesn't really matter, I just used this so you can see what I do.
Now, open the target map where you want that script to be, create a Custom Script block. In this block, at the very bottom, type "customInit", and then create a function called customInit in your custom script block. This function should call all the initializers in the imported script. Finally, at the top of the Custom Script block (before the customInit function), place the line: include "importedScript"
Again, the names themselves don't matter, as long as you use the same at both places they're used. Note the lack of filetype suffix (".galaxy") in the include statement. This is normal and required - SC2 adds the .galaxy on its own, so if you put one it'll try to find importedScript.galaxy.galaxy and will obviously fail.
That's "include trickery". Best to go with other methods - or even better, not steal someone else's code - if the above is too complex for you (this is directed at anyone who will be concerned by this statement and no one in particular).
0
@Seiga10: Go
If you'd taken the time to look around (and read the OP), you'd have noticed that Hive Keeper's main project page was last updated just a few days ago, and there are no indications that he was leaving, abandoning or otherwise stopping the project. The Jan 28 update even indicates that recent progress has been made on units, portal summoning and room conquest.
0
@Reaper872: Go
If such a "list" existed, it would contain more words than the current size of the known Universe in cubic micrometers. That's the whole point of programming and scripting; the possibilities are practically infinite. Of course, most of those possibilities are of no interest whatsoever to any of us, but still, even 0.01% of "practical infinity" remains a gargantuan number.
The best place to start for learning galaxy is probably here, and then using the Script View (CTRL-F11 from the Trigger Editor) to look at code generated by triggers.
Galaxy scripting is mostly used either because the mapmaker is simply used to typing code, wants to have more control and flexibility over how the map/script works, wants to do more with less (often, a smart coder can make a small script in five minutes where doing the same thing with triggers would take half an hour), or wants to optimize his code for maximal performance (because you need better control over the code to achieve this than what is offered by triggers), or any combination of the previous points.
Fair warning though: Even galaxy, as simplistic a language as it is, is not for the faint of heart and will take a lot of time and effort to learn if you've never worked with programming or scripting languages before.
0
@Vermore: Go
Actually, the two methods I stated above I've learned from Motive directly while I was attempting to help the Cortex project. I agree that working in external files is pretty good. At the moment I'm very partial to Andromeda, and developing in Andromeda has the huge advantage that I haven't even opened the map I'm currently working on in the SC2 editor in days, yet have been working on it constantly - the code of the map itself basically consists of a single include statement in a custom Action definition, which the Andromeda compiler detects when compiling the map. The rest of my code is 100% external, and the compiler does all the importing and other tidbits of data-mongering on its own (on top of compiling Andromeda code to Galaxy code, obviously). Looking forward to 0.2.0, too. Just wish I had Moonlite to go along with all this.
As for SoulCarver's difficulties (e.g. seeming like he doesn't know about constants), I'm assuming it's more because he isn't too familiar yet with the structural concepts and terminology associated with galaxy script. It's very easy to fully understand and use adequately the concept of "number or value that has a name and that doesn't change" without necessarily knowing that that's called a "constant" in mathematical or coding jargon, to take a generic primitive example.
0
Here's a very barebones Galaxy "Hello World" script:
The above will print "Hello World!" to the "debug area" (basically to the left of the screen, just above the minimap) three real seconds after the map starts.
Yes, that is a complete and functional MapScript.galaxy. It's not necessary to put your trigger "Actions" in a separate function call - if anything, keeping the entire trigger content in the same function helps with performance a tiny bit.
As for getting your custom script to run, the easiest way is to simply create a new "Custom Script" element in your trigger list view (RightClick -> New -> New Custom Script, when you right-click the panel that shows your list of triggers in the trigger editor). When you select this new element, you'll see a large window for typing your script, and at the very bottom a tiny little box called "Initialization Function (Optional)". Whatever you type in this box will be the function name of the function you want to run in this Custom Script block at map init.
So, if I make a Custom Script block with a "fooBar" function and I enter "fooBar" in the Init Function box at the bottom, my resulting MapScript.galaxy might look like this:
Basically, you can use this Custom Script block itself to put all your code, one block could call functions and use globals from another Block (as long as it's positioned lower than the others in the trigger list, because that determines their position in the generated code and galaxy requires forward-definition), or this one block could have:
as its only statement, as long as you also import a file named "fileToInclude.galaxy" in your map through the import editor and it's located at the root "folder" of the map. This way you can work almost exclusively in external files. If you really want only external files, you can also import and override MapScript.galaxy with your own code (like I did to test the above examples), but that's a finnicky and tricky process and you'll bash your head on a wall trying to do it unless you know and perform the proper rituals to appease the gods of the Editor beforehand.
0
@Abion47: Go
A straight implementation of that could lead to hidden and unexpected issues. For example, what if I attacked someone, waited 4.9 seconds, and attacked again? In the following 0.1 seconds, the wait time from the first instance would expire and the value would be set to false immediately, effectively counting me as out of combat even though I attacked someone again just 0.1 seconds earlier.
Since you're saving a global variable here anyway, a cleaner method would be to save the real time elapsed since the start of the game (or game time, but game time is affected by game speed) to a variable whenever the unit attacks or is attacked (overwriting the previous value each time so that only the latest attack time is kept), and when loading/saving/whatever you check the current game time versus the last attack time (the variable), and if the difference is greater than five seconds you proceed with the save/load, if it's smaller you warn the player or do whatever you want to do when not loading.
0
@Fullachain: Go
There is currently no means for us to dynamically modify the list of abilities (add/remove/replace abilities) for a unit at runtime (i.e. during gameplay through triggers or otherwise).
The best alternative is to pre-add abilities but disable and hide all of them by default and then enable the ones you want when you want to "add" them to the unit. There are several ways to do this, some of which allow abilities to only be enabled for a specific unit and others that can toggle abilities for all units of a certain type or even enable the ability globally for all units that have it. Whatever method you use is up to you - they're pretty much all as clumsy as the next when it comes to having a lot of abilities or a lot of different units that need access to many abilities.
This remains probably the single most cited engine limitation preventing the Cortex Roleplay Engine from reaching greater heights of mapping and modding innovation.
0
@scmapcritic: Go
Heh, that sounds very much like me. Well, at least for the general ideas and the behavior part about never finishing a project, I mean. I won't be so bold as to claim pushing the boundaries and being amazing when I don't even have a single SC2 modding accomplishment to my name (well, that's not strictly true; I did contribute a feature or two, a bit of code, and some theory-crafting for the Cortex Roleplaying Engine project - but all things considered, I think that's not nearly on par with releasing a tech demo, let alone a complete map).
On another note, and I might be hijacking the thread a bit here (and if so I apologize, I'm just interested/curious), but I haven't seen anyone comment about races. Space games often involves multiple alien races duking it out (or talking it down) for supremacy, resources, or just because that's what they do. What do you all think would be the best way to handle races in a space game? Or is it better to avoid that issue entirely by postulating that there's only humans everywhere who have expanded and turned on eachother or somesuch? If the game allowed you to create/have your own race, what would you look for in it, expect, and think would be most fun or practical?
@Mogranlocky: Go
A drawing or a more elaborate explanation would be useless, since the system you describe happens to be exactly the staple feature of Gratuitous Space Battles (screenshot of the ship design screen). It's also been used in various forms in the Space Empires series (screenie!) and several other games.
It's basically a tried-and-true system that has a lot of merits and relatively few disadvantages, but the technical aspects of coding it are difficult for people not familiar with this type of game design philosophies and it makes balancing it out (both in the aspect of PvP balance and in the aspect of fun and options and choices and creating truly interesting/original components) rather complex.
0
@Hookah604: Go
Is trigger space some sort of hard limit on the amount of triggers you can use or something? I've heard about the 4MB limit, but I've also heard that Data Tables and at least one other thing were not counted in this memory limit. If you manage the data efficiently, you can probably have an active pool of up to (playercount) systems + generator + global variables + a few odd local variables, at any one time, supposing that all players all decided to explore new sectors at the exact same time. The rest (all the sectors generated but not currently active, for instance) stays in Data Tables until you need to do something with it.