HTC! : A suggestion for a tool for the scenario makers

[Naso]

I have an idea for a tool useful for scenarios.

A tool to implement airplanes numbers limitations and spawn rules.

Our scenarios are usually based on an honor system, enforced with closing field and penalty in scores.

I've elaborated a suggestion, maybe is a dumb idea, but i'll like HTC and CMs to look at it and say if it is feasible.

I am posting here in scenario forum, hoping is a good place to do it, but i'll post pointers in other forums aswell.

Premise

I assume that the server part of the game is a different application than the FE, dunno in wich language is written, but I guess there are databases, variables, and maybe an object/event oriented style of programming.

Looking at how arena setup works, i assume that there's a database linking the avalaibility of the plane types to the field, something like:

Field x + Kite model y = Active/Inactive (boolean, I guess)

everytime the FE ask for a Spawn event the DB is checked by the server for this variable, and if false the FE respond in "you cannot fly this plane... etc.", if true the FE spawn the plane and the server create the instance (or equivalent) of it.

Suggestion

In an horrible pseudo code

Add a numeric variable to the above (imagined) Table/Array/whatever you call it, we can call it:

Field_Model_Number_Avail (x,y) = z

The 2 simple integration to the landing and spawn event/subroutines:

x = starting field
y = plane type
z = plane type number variable value
w = Landing field

Spawn

If Field_Model_Active(x,y)=False
     No_soup_for_You_Message : Exit
Else if
     Sub 1 to Field_Model_Number_Avail(x,y)
     If Field_Model_Number_Avail(x,y)<=0
          Set Field_Model_Active(x,y)=False
          Set Field_Model_Number_Avail(x,y)=0 ' To avoid negative numbers bug ;)
     End If
End If

Succesful Landing

Add 1 to Field_Model_Number_Avail(w,y)
If Field_Model_Active(w,y)=False
     Set Field_Model_Active(w,y)=True
End If

With a modification to the FE (eventually) to show the numbers of planes available in the hangar interface.
And the possibility in the setup interface to activate (as already is) and indicate the number of planes to be Available in the field.

This tool can be useful to ease the work of the CMs during and after the frames, since is the server itself that control the spawning.

Plus can be used to field transfers, Kite lifes, forces distribution, and many other things, expecially in Niemen and Kurland type of scenarios.

Ah, I almost forget.

The function can be activated for the map like the Strat On/Off we already have, and as a plus:

Be set On/Off for ride type.
Be set On/Off for field or event.

Example:

In a Scenario we have Unlimited Vehicle life and 1 life for planes (Landing and exiting is similar as to die or disco).

Settings:
Arena

Plane counter = On

Field X settings
Ride (1.2.3 GV planeset) Counter off
Ride (5.7.9 Planes planeset) Counter On / Landing Off / Number=planeset

Another example:

A Scenario where you have 1 life in planes ..... ok, Niemen, or Kurland.

Arena

Plane counter = On

Field X settings
Ride (Planeset) Counter on / Number = Planeset


Make sense?

Opinions?

[BlckMgk]

Ok, makes sense. Its efficient enough not to bogg the server, except maybe on launch.

And if a plane lands at another field, do we add +1 to inventory of that field? or do we add +1 to the field of orgin, would be better to modify the +1 to be field of successfull landing.

Looks decent enough to add, the support code for interface and setup would take a bit longer, just make calls to a Procedure thats setup with "PlaneAvailable"

Looks good..

[Naso]

Originally posted by BlckMgk
And if a plane lands at another field, do we add +1 to inventory of that field?

That was the idea, editing the post to clarify.

[BlckMgk]

Ok what I see now is, that every field will need an array with plane type, and num available.

What keeps happening is that I associate the variable to a player and plane, and not to the Field itself. This clarifies because, the "check" is only run on launches and landings. Which is independent of the pilot of the plane. Because if he doesn't return he's dead.. which means inventory was already modified. The problem I'd see is if they crash on takeoffs , or discos.. you could account for that by making a new rule you get up to 4 disco's per squad (you account for that by adding the extra inv.)

[Pyro]

There's not actually anything to mod in that regard.  It would have to take a design of a new system.  There may be some development down that road for ToD that the CM's will be able to make use of.

[Naso]

Originally posted by Pyro
There's not actually anything to mod in that regard.  It would have to take a design of a new system.  There may be some development down that road for ToD that the CM's will be able to make use of.

One bad new and one good new, then.

Anyway thank you very much for your answer, this is what I call customer service.


BTW, do you like the idea?

Because, if you like it... maybe... soon or later....

One day...

In MLK voice: "I have a dream!!"

[brady]

Naso you get my E mails? The CO/CM forum is up and you nead to check in bud:)

[Tilt]

A request made previously was to be able to set the number of AC of each type available from each field..................

This would have been an addition to the field set up table............

It was clear however that such a system could not make use of any  counter already within the AH software............

Further if a terrain had 120 fields and  a plane set of 60 AC then a running count would be added to the server that cyles thru 7200 options at what ever frequency  deemed appropriate..............   1Hz?

Further this count would have to have the ability to be reset so it ends up being a  function of AC/Type/time

The alternative would be to approach field set up totally differently............... we await HTC's eventual implimentation of TOD with interest.............

[Naso]

Yes Tilt, I see i'm not the first to make this request.

The part I dont understand is the cycle part.

I guessed that the check would have been started by the client request of take off (.fly) in the same way is done now (I guess) to check If Airplane is enabled/disabled, Proper Hangar is Up/Down.

Adding there the counter operations.

The above suggested subroutines would have been triggered by the client request, not cyclic started by the server on his own.

I guessed that, being present a "setup" table with the Enabled/Disabled plane for each type and each field, this table could have been accessed when the client request were received by the server.

But looking at Pyro's answer, I guessed wrong about the architecture of the system.

Let's see what they bring on out of TOD's hat.

P.S.
I did'nt meant the request tyied to AH1 arena server, just generic.
If is coming with AH2 it's anyway a great tool.

[artik]

I think more powerfull tool could be done for scenario control.
Probably you want to enable 2-3 lifes for one side or sertain squadron etc.
Also what heppen if there are less players then defined? So someone will be able to take 2nd plane.
I think we need kind of script that CM can write and upload to server that will describe the behavior of life rules per player
Example

int glb_Max262Lives=8;

class PlayerLifes: public CPlayer {
    int m_LivesPerVeicle;
    int m_LivesPerFighter;

OnInit()
{
    if(Squadron==Pyro || Squadron==HiTech)
    {
        m_LivesPerVeicle=3;
        m_LivesPerFighter=1;
    }
    else if(country==0)
   {
        m_LivesPerVeicle=0;
        m_LivesPerFighter=1;
   }
   else if(country==1)
   {
        m_LivesPerVeicle=0;
        m_LivesPerFighter=2;
   }
   else
   {
        m_LivesPerVeicle=0;
        m_LivesPerFighter=0;
   }
};

bool OnEvent()
{
    switch(Event){
    case FLY:
        if(VType==Viecle && m_LivesPerViecle){
            return TRUE;
        }
        break;
    ............
    case DEAD:
       if(VType==Viecle){
           m_LivesPerViecle--;
       }
       if(Aircraft=P_262){
           glb_Max262Lives--;
       }

 
    .............
};
};

Of course scpirt I have written - is qute complex but the language itself can be simpler (not C like).
So CM upload scrpits that describe lifes behavior - in all cases.
Probably he can also describe much more things for viecles, and other rules.

Anyway - you have a class with data per player and per other fewchers. The procedures are interpreted each time any kind of event heppens and they describe the rules behavior.
Probably it is quite complex implementation but it can be extreemly powerfull tool.

EDIT:
I thought it could be actually little C++ file that can be compliled by HTC as .dll  and loaded each time scenario begins like - terrains.