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 :)
Edited by The Cereal Killer on Apr 26, 2011 at 05:32 PM

Glad I could help.

Very nice. Also, you almost never need to quote the return type.
Edited by chrisk123999 on Apr 26, 2011 at 08:41 PM

I don't do that unless it is a static script to call a unit, object, or value; and it's mostly so that I can remember what it does at a glance.

For some reason everyone seems to have a bad habit of quoting the return type when it doesn't need it. It's technically bad formatting.
Edited by chrisk123999 on Apr 27, 2011 at 12:10 AM

Mm, well I normally don't put a return type, the only reason I quote it when I do put one is so that it will be more readily visible to spot from the rest of the text. LISP uses quotes to contain phrases in general, so nothing too wrong with it :P

Interesting, I always thought stub scripts didn't have much application since they're hardly utilized in the original campaign scripts. So in a sense stubs are only referenced in a child scenario so as to override another script name used in the parent?

tbh they were probably used, but once the things merge the stub part is removed because there only needs to be 1 script of that type.

It would be impossible to tell because when it's compiled there are no longer separate files.
Edited by chrisk123999 on Apr 27, 2011 at 04:10 PM

Think of it as a way to import scripts from the parent to the child scenario without running into a "conflicting names" error, so that you don't need to come up with new names for the same script over and over.

I suppose so, they are quite vague if you don't have a good impression of what to do with them already. I'll write one up soon.