Before creating the magnificient Spring engine, the Swedish Yankspankers were well known for having made the TA demo recorder, an impressive piece of code which added many functionnality to the TA engine, such as recording and replaying game, interface upgrades with line building, multiplayer markers, whiteboard, new codes, etc..
As the Swedish Yankspankers quitted developping the TA demo recorder to instead concentrate on the much more ambitious Spring engine, they released the source code of demo recorder, and now it is Xon, formerly known as ggs, from Central Consciousness, who has taken up the task of pursuing the improvment of the TA demo recorder. He closed memory leaks an hunted bugs, gave use complete los sharing between allies (instead of seeing units through fogs), allowed more than one AI per player in multi, and added new get/set commands for scripters.
Meanwhile, the Spring engine, still heavily based on TA data, also saw the addition of new get/set commands for scripters.
Sure, you could say that these are two different projects, and that anyway Spring should strive to depart from the TA world, but truth is, Spring and TA scripts are still nearly the same. And many modders are developping mods for both engine.
So, anyway, what I'm slowing going at, is that yesterday, Xon added a new command, get UNIT_IS_OWNED_BY_THIS_COMPUTER(unit_id), returning 1 if the unit is from a player or an AI owned by this computer, or 0 if the unit is from a player or an AI owned by another computer in a multiplayerl game. This information would have absolutly no relevance in the Spring engine, which has a competly different approach to multiplayer synching. However, to avoid lots of confusion, it would be good if the value we associated to "UNIT_IS_OWNED_BY_THIS_COMPUTER" was never used for any new get/set in Spring.
So, yeah, the question is, could we agree on some get/set value to leave free for Xon? There's 65536 possible value to choose from, right? There's got to be a way for Spring and Xon new recorder to not fall on the sames!
Cross-posted with:
http://www.tauniverse.com/forum/showthread.php?t=35116
Xon new recorder new get/set script command.
Moderator: Moderators
One comment i think is all it woudl take 
Quesiton: Would Spring simply ignore an invalid get/set command? or woudl it crash horribly?
Code: Select all
/***DO NOT USE THESE VALUES AS NAMES FOR GET/SET COMMANDS:
****
****UNIT_IS_OWNED_BY_THIS_COMPUTER
***/
Quesiton: Would Spring simply ignore an invalid get/set command? or woudl it crash horribly?
We don't need to keep anything free for that, we'll only see a conflict if someone is trying to get/set that in a script, knows the value it needs (of course there is no matching value so he couldn't add it in first place) and has defined that in his own .h file.
No idea what happens with invalid get/sets, why don't you try it out? set 60 to 11? I think it's ignored, the relevant code treats a set on a read-only option the same as a set on an option that doesn't exist at all.
No idea what happens with invalid get/sets, why don't you try it out? set 60 to 11? I think it's ignored, the relevant code treats a set on a read-only option the same as a set on an option that doesn't exist at all.