chrisk123999
April 26th, 2011, 08:15 PM
Found this while browsing halomaps forums...
--- Original message by: The Cereal Killer
I'm sure that most scripters in the community know of, and subscribe to (as I did), the commonly held belief that stub scripts accomplish nothing. Well, that is true for most people. However, under specific conditions (which I myself happened to get into recently) they may become useful, and actually quite necessary.
Allow me to communicate, before you continue reading, just exactly the reason no one has ever seen this before. I am one of the few people in the community who uses child scenarios. Even further, I use specific scripting methods and organization within those separate scenarios, and I have many times faced difficulty in redirecting an active script to the parent scenario. A while back, when frustrated by the scripts' repeated inability to submit to authority, and frankly out of curiosity as well, I happened to discover the use of these wonderful things.
Although it involved quite a lot more, the situation is best summed up as this:
I have a separate scenario for each location (bsp) in Red Skulls, which assists in organization. In turn, each of these scenarios has its own script. Now, scripts in the child scenario(s) are able to be recognized by scripts in the parent scenarios, but not vice-versa. So, in my case, I had this script in the parent scenario's scripts to make it easier to refer to the player:
(script static "unit" player
(unit (list_get (players) 0))
)
But scripts in the child scenario cannot recognize that. So now, I just copy it from the parent script to the child script, correct? No, because the parent script can see the child script, so it will not allow a script in the child scenario to have the same name as one in the parent scenario. The odd thing of it is that both scripts compile correctly in their respective scenarios in Sapien, however when I attempt to compile the map by referencing the main scenario in tool, it returns this:
04.26.11 02:56:09 tool pc 01.00.00.0609 ----------------------------------------------
04.26.11 02:56:09 reference function: _write_to_error_file
04.26.11 02:56:09 reference address: 42ca20
04.26.11 02:56:09 Couldn't read map file './toolbeta.map'
04.26.11 02:56:10 invalid detail object data in structure levels\red_skulls\quarry
04.26.11 02:56:10 recompiling scripts after scenarios were merged.
04.26.11 02:56:10 [island_script line 1] only static scripts of the same type can override stub scripts.: (script static "unit" player
Obviously this intrigued me, so out of sheer curiosity I replaced the static player script in the child scenario with a stub script of the same name and command:
(script stub "unit" player
(unit (list_get (players) 0))
)
And then the most wonderful thing happened - tool compiled flawlessly; and then an even better thing happened - the reference to (player) in the child script worked the same way.
So, in conclusion, stub scripts are in fact not at all useless. They are used to override scripts (just like it says in the scripting bible) from the parent scenario but only in the child scenario. This means you can bring in some scripts into the child and you don't need to unnecessarily change your system for naming globals/units/formulas/etc. I'm sure many of you will not be affected in the least by this; as I said, I may be the only person in this community to use child scenarios. But on the off chance that some of you do or are considering doing so, I hope this helped you. Thank you and good day :)
http://forum.halomaps.org/index.cfm?page=topic&topicID=37400
--- Original message by: The Cereal Killer
I'm sure that most scripters in the community know of, and subscribe to (as I did), the commonly held belief that stub scripts accomplish nothing. Well, that is true for most people. However, under specific conditions (which I myself happened to get into recently) they may become useful, and actually quite necessary.
Allow me to communicate, before you continue reading, just exactly the reason no one has ever seen this before. I am one of the few people in the community who uses child scenarios. Even further, I use specific scripting methods and organization within those separate scenarios, and I have many times faced difficulty in redirecting an active script to the parent scenario. A while back, when frustrated by the scripts' repeated inability to submit to authority, and frankly out of curiosity as well, I happened to discover the use of these wonderful things.
Although it involved quite a lot more, the situation is best summed up as this:
I have a separate scenario for each location (bsp) in Red Skulls, which assists in organization. In turn, each of these scenarios has its own script. Now, scripts in the child scenario(s) are able to be recognized by scripts in the parent scenarios, but not vice-versa. So, in my case, I had this script in the parent scenario's scripts to make it easier to refer to the player:
(script static "unit" player
(unit (list_get (players) 0))
)
But scripts in the child scenario cannot recognize that. So now, I just copy it from the parent script to the child script, correct? No, because the parent script can see the child script, so it will not allow a script in the child scenario to have the same name as one in the parent scenario. The odd thing of it is that both scripts compile correctly in their respective scenarios in Sapien, however when I attempt to compile the map by referencing the main scenario in tool, it returns this:
04.26.11 02:56:09 tool pc 01.00.00.0609 ----------------------------------------------
04.26.11 02:56:09 reference function: _write_to_error_file
04.26.11 02:56:09 reference address: 42ca20
04.26.11 02:56:09 Couldn't read map file './toolbeta.map'
04.26.11 02:56:10 invalid detail object data in structure levels\red_skulls\quarry
04.26.11 02:56:10 recompiling scripts after scenarios were merged.
04.26.11 02:56:10 [island_script line 1] only static scripts of the same type can override stub scripts.: (script static "unit" player
Obviously this intrigued me, so out of sheer curiosity I replaced the static player script in the child scenario with a stub script of the same name and command:
(script stub "unit" player
(unit (list_get (players) 0))
)
And then the most wonderful thing happened - tool compiled flawlessly; and then an even better thing happened - the reference to (player) in the child script worked the same way.
So, in conclusion, stub scripts are in fact not at all useless. They are used to override scripts (just like it says in the scripting bible) from the parent scenario but only in the child scenario. This means you can bring in some scripts into the child and you don't need to unnecessarily change your system for naming globals/units/formulas/etc. I'm sure many of you will not be affected in the least by this; as I said, I may be the only person in this community to use child scenarios. But on the off chance that some of you do or are considering doing so, I hope this helped you. Thank you and good day :)
http://forum.halomaps.org/index.cfm?page=topic&topicID=37400