I'd like to SEE this script run

[ScrubMuncher]

Hi All,
Been thinking this would solve some other ppl's problems, wanted to post months earlier, but didn't know if it was worth it.. so here it is, cut and pasted.
I need major programming help.  I'm lost in the details, but the logic is do-able. If this would help OFP in any way, I'd appreciate any help (or better yet. if someone wanted to TAKE the project..)
In my attempt to design a Twilight 2000 style environment (warring AI factions, scrounging for weapons and ammo, and few vehicles), it was necessary to have conditional as well as random script events occur.  The rate and quantity of random elements (small stories in themselves, really), needed to be controlled. Also, I wanted to have it scalable, so anyone may add scripted events to the list and further make an interesting time for all.  The result is the Story Event Engine.  Very simple idea, just takes some planning and standardization of scripts, and any police or continuous play type game can have any number of elements added to it.
This really needs some evolving. But here it is in a nutshell:

1. A main script, handles the rate and quantity of story events run. it INIT's and counts available scripts (sequentially labeled story1.sqs, story2.sqs...), tracks timing in between the starting of scripts, and the total allowed to run at once. Also, it  possibly hands off variables (player / playable unit, units, groups, elements in play that may be conditional for a script to run-like the establishment of a base, wether a stalk script is running.. etc)

2. The scripts, you all know them (much better than me I'd wager) you know you can pre-select a few applicable zones, check for the presence of ANYBODY, AI or not.  And then, off a single XY coord, spawn an entire base, setup patrols, change objectives or alert the player(s) in some other fashion.  Using Dr. Strangelove's methods, there could be factions warring, or coming after the players.  Using some waypoints and text, a couple of robbers could start at any preselected town, and head off to their hideout, wait a few and then go off to another heist, or kidnapping.  The main point is that more scripts can be added to enrich the experience.  There just needs to be some thought done up-front.

   2a. Basically the scripts need:
       - To be countable
       - To be able to see if some (standardized) events are running, or set up.
       - To register what type of script is running, like resupply, patrol, stalk or    
          robbery. A gametype-specific list would have to be hashed out.  (This is a future
          issue that would give better continuity to the events able to be called)
       - To monitor itself, end, and register with the main loop when it does so.

I believe the real work is to envision the range of events, get them into a meaningful catagory, and then set up the way scripts need to be done to integrate with this.  I have two examples to explain.. not entirely functional, but should be enough to get the point across.

Hope this is spurring some good thoughts, I see a lot of use for the concept..  Just beyond me to make it happen,  please let me know it is of use.

Thanks,
Scrub

[ScrubMuncher]

Here's the second file,  a potential script for use.  (Don't know how to post two files at the same time... what a noob) ;-)

[PsyWarrior]

Greetings,

Some very interesting ideas here. I would love to take on this project, but I just can't. I'm already working on/ with a couple of equally massive projects.

However, perhaps I can be some help still:

The essence of OFP randomness is the generating of randomised numbers. When you want, for instance, one of 5 messages to appear at the start of a mission (with the chance of a different message each time, and one very improbable message), you would write something like this:

;Beggining of random sequence
_RNum = Random 4
? _RNum >=0 && <1:Hint "Message 1"
? _RNum >=1 && <2:Hint "Message 2"
? _RNum >=2 && <3:Hint "Message 3"
? _RNum >=3 && <4:Hint "Message 4"
? _RNum == 4: Hint "Special Improbable Message!"
;end.

Hopefully the above is right... been a couple of months since I wrote one of these...

So, here's some ideas for the master script:
-Contains the Random number "improbability engine" (spot the Hitchhikers Guide to the Galaxy reference there)
-All possible scripts stored in one of two arrays: Story scripts, and story scripts running. When a story script is executed, it is moved from one to the other. I.E:
_stories = ["story1.sqs", "story2.sqs", "gangsters.sqs", "nuclear Death.sqs"...]
_storiesRunning = ["Story4.sqs", "kidnapping.sqs"]

You could keep track of which scripts are in operation by referencing the array, and using 'count' to check how many are in operation.

The story scripts:
Each script will spawn a certain number of AI's. This is what you need to keep track of, more than any other factor. You could impose a limit on how many subscripts are running, to prevent the player being confused (i.e. jewel robbery, kidnapping, terrorist attack, and enemy faction base being uncovered at the same time), but you need to make sure that you don't spawn too many people.

The OFP limits for spawning are: 52 groups per side, 12 units in every group. 4 sides (West, East, Res, Civ) (not including Game Logic side). One of those sides has no combat AI (civ).
Therefore, you need to set 4 global variables:
groupsW
groupsE
groupsR
groupsC
4 triggers covering the whole map, set to west present, east present etc. will se the initial value, by counting how many groups there are for that side. Something like:
groupsW = count groups thislist
(I have no idea if the above will work. Untested at the moment).
At the beginning of every story script, the number of new AI's spawned is added to this variable. For instance, if 4 new Resistance side AI groups are spawned (that could be between 4 and 48 AIs) by the script:
groupsR = groupsR + 4.
At the end of the script, you would do the same, but removing those 4 groups.

The master script keeps track of how many groups are in operation, and stops the execution of any more story scripts when the amount of groups for a side reaches 40 (a safe limit, that allows script already in operation to spawn a few more groups if needed). When the number of groups drops below 40, story scripts will be re-enabled.

I'm running out of time to type right now, so a few closing notes:
Uploading multiple scripts: Put them all into a .zip file and upload them all at once...
I may also be able to come up a couple of events, give me some time...
It should be possible to construct a script such as this, but it will take a significant amount of time.

-Supreme Commander PsyWarrior
-Psychic Productions Studios

[ScrubMuncher]

Wow, thanks for the diligent thoughts  .  That's adding functionality to what was a mere environmental moderator / monitor.   Keep in mind that the main script should be very low overhead, as it is not certain what load the events themselves will put on th CPU.  That is why (thanks to your wonderful idea) I'm now looking at the staggering of multiple script delays by use of the array, as well as staggering the use of functions inside each script.. rough example:

Say I have 3 scripts, all spawing and monitoring the 'damage' value of 100 objects apiece.  In this example, lets allow that the objects are expected to spawn out of sight of the player.  The three scripts have independant reasons for existing, so each must operate at about the same capacity.  
When the scripts start up, they register with the main program as stated before.  But, now included in Psy's array, a value that is at least the number of scripts run plus the order number of the script run, minus one (in this example 3, 4, and 5, could be higher of course, but this is just an example).  This value is built and passed from the array to each of the script's delay variable, allowing 3 independant seconds for the 3 scripts to run in, before the first repeats again.  This would be done in the startup of each script as it is called.  It would lower CPU load, and the lag that results (Nogova Virus ring a bell?)

Now, this may be of more common use, especially in large scripts that don't need real-time scanning.  But would really help in this event-ridden situation.
I'll give this to you up front and then explain my madness.  

------------------------------------------------------------------------------------------------------
_TotalNumOfObjects
;self-explanitory

_NoLagNumber
;a number of evals per scan, witnessed to give reasonable effect and no script lag

_PerScanCounter
;counts per scan up to the _NoLagNumber, It's all relative.

_TotalCounter
;counts up to _TotalNumOfObjects

#evaluate
? _PerScanCounter > _NoLagNumber : goto "delay"
? _TotalCounter > _TotalNumOfObjects : _TotalCounter = 0 ; goto "delay"

(Evaluation code, the number in the array or list to be evaluated is found by _TotalCounter)
? _EndCondition == true : (remove registered vars with main pgm); exit

_PerScanCounter = _PerScanCounter + 1
_TotalCounter = _TotalCounter + 1
goto "evaluate"

#delay
~_PassedValue
_PerScanCounter = 0
goto "evaluate"
------------------------------------------------------------------------------------------------------

  A simple math function to break-up evaluations of large amounts of data.  Inside the scripts, the number of objects to be spawned or monitored is often done by groups.  However in this example, lets say the objects are seperately evaluated (numbers of groups could be broken up).  The number of objects (100) is divided by an experienced number (a number that causes no script-lag), and limits the number of items to be evaluated in a single scan, spreading the work across several, again decreasing CPU load.

Thanks Psy, this is really helping me to understand what needs to be done.

Scrub

[PsyWarrior]

Thanks Psy

No probs

CPU load is going to be vitally important in this system, especially if it's going to run on lower-end systems. Optimisation is going to take up a lot of your time .

The Random function could be used to delay simutanious execution as well, again staggering the CPU load. putting something like
~Random 2
At the beggining of your scripts will prevent 3 subscripts kicking in at once (Suddenly stopping OFP dead while they spawn about 200 units). It's also useful for general CPU load staggering.

Like the evaluation splitter concept. It could be developed for many different scripting systems, especially in other types of event-ridden scripts (Like the master scripts controlling RTS mods, and AI command scripts).

Another note: There isn't really any 'real-time' scanning in OFP. All scanning is delayed by how quickly the scripter needs to know something against how much of a strain the scripter can afford to put on the CPU. For instance, if you need to know pretty much the instant a unit is dead, you could set up a 0.01s loop. If you needed to know, say, within about a second, you could set up a 1.0s loop.

Remember those group limits. OFP will not forgive you if you go over the limit, it will just stop spawning units and probably give out an error. Here's another idea to control this:
At the start of a particular subscript, there are local variables containing the maximum number of groups on every side that can be spawned by a script (you would have to have this anyway, for the previous method). Before the main script execution, this number is added to the current number of groups (global variable, see previously). If this final number exceeds 56, the script is terminated, and removed from the executed scripts array. It will not run untill there are enough groups to allow it.

This would be the better way, I believe.

Some more random thoughts for you... ;D

-Supr. Cmdr. PsyWarrior
-Psychic Productions

[ScrubMuncher]

Excellent, keep'em coming at your leisure..  I'll be away for a day or so and might not get a chance to update my progress.   I'm trying to see the shape and limitations of the event handler.  There definately needs to be catagories for the types of scripts.  Some may be long term, like tracking the holdings of AI factions, and triggering responses.  Some may be quick random events to keep the players on their collective toes.  And the remainder are results of the players actions.  So now there are a few variables that need to be held during the init of the main loop (really the searching of the script library).  There are compulsory scripts that need to be run (i.e. AI monitors), there are random events, and there are logical responses.   Sounds like there needs to be different series of filenames to organize with.  Maybe something Like 'StartUp', 'RandEvent',
 'AggressiveEvent', and 'ExpandEvent'.  This covers a broad range of topics.  Another thing to keep in mind is that the origional script events have the opportunity to start their own script for dedicated services, the Main is only concerned with the quantity, rate, and type of script originally run.  This layering is my main concern for the spreading out of the load.  As a mission maker fills out the script library with the events that create the custom environment and tunes the rate of their execution, continuity is going to be more and more an issue.  That is where I need to go next.. The catagories, and methods of tracking them will make themselves known after the matter of continuity is taken care of.

Thanks again,

Scrub