Mod scripts!

[PauloMorfeo]

Since you guys are working on adding scripting, i may idealize a way for mods to work.

Have each mod have it's own mod script file. In it, it is defined:

- What the victory conditions are!
(i don't know how it works now but i've wondered how the engine will behave if we, for example, do not start with a comander, in some mod)

- Mutators!
Supose the mod's lose condition is losing it's comander. One of the mutators in the script could be changing that.
Then, when hosting, it would read what the various mutators were, as well as it's possible values, and the host could add them to the list of mutators.

- Something else someone will probably think of!

####
This way, the mods/mutators would work in a more flexible way than they seem to work now, both engine-wise as well as GUI wise.

[PauloMorfeo]

Example:

xta_se_v065.scr

Code: Select all

//Victory Conditions
bool VictoryConditions ()
{
  if (PlayerOwns (thisPlayer, StarGate) > 0) return true;
}

//Losing Conditions
global List LosingUnits
bool LosingConditions ()
{
  if (PlayerOwns (thisPlayer, LosingUnits) < 1) return true;
}

//Mutators
global List LosingUnits= {CoreCommander, ArmCommander};
Mutator
[
  name= "Destroyed Commander?";
  option
  [
    description= "Game Continues!";
    action= SetGameContinue ();
  ]
  option
  [
    description= "Game Ends!";
    action= null;
  ]
]

SetGameContinue ()
{
  LosingUnits= { };
}

A general idea of how it would look in a mix of C/C++/C# and Python and whatever :p.

[FLOZi]

This could probably be done with the LUA scripts anyway.

It'd be REALLY cool if the lobby supported running mod-specific LUA scripts for multiplayer

[Pxtl]

Many scripts will need to be tied to a specific map (or a map will be tied to a script) - consider scripts that include specific starting positions for equipment. Such things would have to be done on a map-by-map basis.

[FLOZi]

And, just as obviously, a mod-by-mod basis, unless they are some submod of OTA or whatever.

[AF]

Lets say we have XTA.lua and WD.lua along with mission.lua

lets say mission.lua always calls mod(); when it starts which does whatever mod processing is needed.

In XTA.lua and WD.lua we have our definitions for mod().

If the engine loads XTA.lua then mission.lua then the XTA version of mod() is in the VM stack already so it will be called even if ti isnt defined anywhere in misison.lua. The same is true of WD.lua. It could also be noted that you could add other functions to XTA.lua or WD.lua that where mod specific and any lua script ran after those files are laoded has access to those functions.

I suggest each mapfile ahs a lua script with an identical name such as metalheck.smd metalheck.lua which is called when the map is laodd, then the modname.lua is called then mission.lua is called.

As long as they are all using the same VM instance of lua they should be able to crosscommunicate and do any trickery one wants performed.

This could be manually calling a function in a units script once lua unti scripts are implemented, changing a map statistic based on a mod or interface value on loading so that a map never plays the same, or if unti fbi's are converted it could be making a unit behave in different ways depending on the type of map, eg unit generating energy using wind rather than using solar on windy maps.

[mongus]

not me but someone think of security... you know.. malintentioned code.. and such.

[SwiftSpear]

Lets say we have XTA.lua and WD.lua along with mission.lua

lets say mission.lua always calls mod(); when it starts which does whatever mod processing is needed.

In XTA.lua and WD.lua we have our definitions for mod().

If the engine loads XTA.lua then mission.lua then the XTA version of mod() is in the VM stack already so it will be called even if ti isnt defined anywhere in misison.lua. The same is true of WD.lua. It could also be noted that you could add other functions to XTA.lua or WD.lua that where mod specific and any lua script ran after those files are laoded has access to those functions.

I suggest each mapfile ahs a lua script with an identical name such as metalheck.smd metalheck.lua which is called when the map is laodd, then the modname.lua is called then mission.lua is called.

As long as they are all using the same VM instance of lua they should be able to crosscommunicate and do any trickery one wants performed.

This could be manually calling a function in a units script once lua unti scripts are implemented, changing a map statistic based on a mod or interface value on loading so that a map never plays the same, or if unti fbi's are converted it could be making a unit behave in different ways depending on the type of map, eg unit generating energy using wind rather than using solar on windy maps.

That would make it EXTREAMLY difficult to build mission.lua's. How would you define what unit is called to be generated and spawned? Unit catagories? Different mods call the different units totally different things, and have absolutly no coordination between unit IDs as to what unit ID fills what roles. With unit catagories you might be able to find units that fit into the same spawn group, but it would be extreamly uncontrolable and there is no guarentee a certain mod even uses the catagories used in XTA for example.

For standards sake I think we are limited to mod specific mission.lua's for the time being. Maby in the future we can standardize a new unit format that would allow for that, but I doubt the SY's will jump for that because then someone has to rewrite all the XTA FBIs and TDFs.

[Pxtl]

Lets say we have XTA.lua and WD.lua along with mission.lua

lets say mission.lua always calls mod(); when it starts which does whatever mod processing is needed.

In XTA.lua and WD.lua we have our definitions for mod().

If the engine loads XTA.lua then mission.lua then the XTA version of mod() is in the VM stack already so it will be called even if ti isnt defined anywhere in misison.lua. The same is true of WD.lua. It could also be noted that you could add other functions to XTA.lua or WD.lua that where mod specific and any lua script ran after those files are laoded has access to those functions.

I suggest each mapfile ahs a lua script with an identical name such as metalheck.smd metalheck.lua which is called when the map is laodd, then the modname.lua is called then mission.lua is called.

As long as they are all using the same VM instance of lua they should be able to crosscommunicate and do any trickery one wants performed.

This could be manually calling a function in a units script once lua unti scripts are implemented, changing a map statistic based on a mod or interface value on loading so that a map never plays the same, or if unti fbi's are converted it could be making a unit behave in different ways depending on the type of map, eg unit generating energy using wind rather than using solar on windy maps.

That would make it EXTREAMLY difficult to build mission.lua's. How would you define what unit is called to be generated and spawned? Unit catagories? Different mods call the different units totally different things, and have absolutly no coordination between unit IDs as to what unit ID fills what roles. With unit catagories you might be able to find units that fit into the same spawn group, but it would be extreamly uncontrolable and there is no guarentee a certain mod even uses the catagories used in XTA for example.

For standards sake I think we are limited to mod specific mission.lua's for the time being. Maby in the future we can standardize a new unit format that would allow for that, but I doubt the SY's will jump for that because then someone has to rewrite all the XTA FBIs and TDFs.

Well, you can take both approaches. Some gameplay-mods will be unit-specific (say, a complex RPG-mod), but some mods will not require any checking more complex than "is X an air unit or not" (like King Of The Crater).

Plus there's the question of creating factions external to the mods. Let's say that a mod includes 3rd-party monsters - critters you can hunt for resources, monsters that spawn in and invade randomly, etc. Could it be possible to have a faction external to the mod for those critters? Or would you have to work within the existing unit list. This is relevant if a mission has special buildings and the like.

[SinbadEV]

In theory you could put a custom unit in a map... and then .cheat it onto the map (I'll have to try to be sure), so in that case you could have that kind of unit scripted into a map.

[AF]

AHEM.

You're problem si irrelevant. Add a usemod(modname); function to the lua interface and if it returns false then simply say so in the console and exit the script.

Otherwise there's a function to retrieve the modname isnt there? If not there should be, the lua itnerface should have all the abilities that AICallback interface gives GlobalAI's.


As for malicious lua code, other than messing other scripts I doubt there'll be any problems, lua is completely contained in its virtual stack and heap, the only bad thign ti can do to th engien is crash it or do silly things like send units to the wrong place by accident.

Odd though that nobody has noted security with the GroupAI dll itnerface, now that's where you could get your nasty computer hungry code being distributed.

[SwiftSpear]

AHEM.

You're problem si irrelevant. Add a usemod(modname); function to the lua interface and if it returns false then simply say so in the console and exit the script.

Otherwise there's a function to retrieve the modname isnt there? If not there should be, the lua itnerface should have all the abilities that AICallback interface gives GlobalAI's.


As for malicious lua code, other than messing other scripts I doubt there'll be any problems, lua is completely contained in its virtual stack and heap, the only bad thign ti can do to th engien is crash it or do silly things like send units to the wrong place by accident.

Odd though that nobody has noted security with the GroupAI dll itnerface, now that's where you could get your nasty computer hungry code being distributed.

True, it probably is better off being optional anyways, still, the ammount of extra work to make a script work for all mods would be intense. Quite likely altogether impossible for some mods... I doubt TAFF uses the "TANK" catagory anywhere in it's FBI's.

[AF]

tank category? I dont think we'd need to use those types of unit category, if you've got a mission you pretty much knwo what units you're going to use, and there's a storyline behind it. Simply switching the mission between mods sorta breaks that storyline.

Besides there isnt a TANK category as such, or a KBOT category. If I call GetUnitDef(unit) in an AI dll which gives me the same untidef structure the engien uses.

In that there's the type string and a longwinded string that resembles what OTA had, "ARM NOSUB TANK LVL1" etc, the type string has the values of either, MetalExtractor, Building, GroundUnit, Builder,Fighter, Bomber, or Factory.

You wont get any extra functions to determine that without writting them from scratch in lua or adding engine functionality.

But I really dont see why you would need it?!

And if you go back to the original mod scripts thing, I'm sure you could easily call units by name, afterrall you or a friend where the one who made them......

[SwiftSpear]

tank category? I dont think we'd need to use those types of unit category, if you've got a mission you pretty much knwo what units you're going to use, and there's a storyline behind it. Simply switching the mission between mods sorta breaks that storyline.

Besides there isnt a TANK category as such, or a KBOT category. If I call GetUnitDef(unit) in an AI dll which gives me the same untidef structure the engien uses.

In that there's the type string and a longwinded string that resembles what OTA had, "ARM NOSUB TANK LVL1" etc, the type string has the values of either, MetalExtractor, Building, GroundUnit, Builder,Fighter, Bomber, or Factory.

You wont get any extra functions to determine that without writting them from scratch in lua or adding engine functionality.

But I really dont see why you would need it?!

And if you go back to the original mod scripts thing, I'm sure you could easily call units by name, afterrall you or a friend where the one who made them......

mmm, you mean loading up a mod based on what the mission called for... I thought you meant loading up a mission, and then having it automatically generate it's units to properly work with whatever mod you were currently using... It would be difficult to impossible to properly write a mission script that worked for all, or even most mods.