Using variables in addShip methods

[Galileo]

I don't know how often an ability like this would be used but it would be useful to me so I thought I'd mention it anyway..

I currently use a variable to keep track of the number of ships in a fleet and add them 5 at a time when there are none on the battlefield. When the fleet size gets to below 6 I have to add them 1 at a time with code like this:

Code: Select all

"checkForShips: ramazan_government_vessel",
			{
				conditions = (
					"shipsFound_number equal 0",
					"mission_ionics_government_fleet_size greaterthan 0",
					"mission_ionics_government_fleet_size lessthan 6"
				);
				do = (
					debugOn,
					"addSystemShips: ramazan_government_vessel 1 0.95",
					debugOff
				);
			},

It would be nice if I could use something like this to add all of the remaining ships at the same time:

Code: Select all

"addSystemShips: ramazan_government_vessel mission_ionics_government_fleet_size 0.95"

Of course if I really wanted all the remaining ships to be added at the same time I could write 5 different sections (if 5 ships left - add 5, if 4 left- add 4, etc.) but it's something to think about.

[dajt]

I'm reviewing the scripting code at present so I'll have a look at this.

[Cmdr. Wombat]

Using variables in scripts where currently you have to use a number could turn out to be very useful for writing missions.

[aegidian]

It's on my to-do list.

[Rxke]

It's on my to-do list.

Giles, I think it would be less paperwork to make a list of things that are NOT on your todo list.

(wait one... that's wrong logic, no? Need...sleep...brain...fuses...)


I'm constantly amazed where you keep getting the inspiration, Giles. (bows in awe)

I sure hope one day I'll make it to the annual pub-meet.

[Evil Juice]

Yeah, giles should just publish his NOT TO DO LIST...

[stevesims]

Maybe he should have a "screw that idea, somebody else can do it" list?

[dajt]

Here is what I plan to implement in the script-compiler branch. Note these changes will be to the script interpreter so they will work for the normal script.plist scripts too.

1. Script-local variables

Anywhere you can use mission_XXX at present, you will be able to use local_XXX. Each script has its own collection of local variables which is empty before the script starts executing. Script-locals are not saved in the game file, they are just temporary value holders.


2. mission_, local_, and commander_ always expanded on RHS of actions

Before an action is executed all instances of mission_XXX, local_XXX, and commander_XXX will be expanded. This will not be recursive.

So you can do something like:
addShipsAt: station 1 pwu local_x local_y local_z

and instead of [commander_name] you can use commander_name and always have it expanded.


3. Functions on the RHS of actions

The script interpreter will assume tokens ending in _string, _number, and _bool are functions that should be called, with the token being replaced with the function's return value. If there is no such function then the token will be left as-is.


All this processing will be done in the scriptAction method, before the action selector is called.

Locals will keep their values between different invocations of the script as long as the game is running. I guess they should be reset when the player loads a game or is killed too.

Update: I have done a quick implementation and found an obvious problem: "set: local_X d100_number". The first time this runs you give local_X a value, say 17. The next time it runs the statement is transformed into "set: 17 46". Bugger. I might change it so anything to be expanded has to be in square brackets, so it would instead look like: "set: local_X [d100_number]". The other option is to introduce special processing for different actions which I don't think is a good idea.

[aegidian]

Mmm... nitpick...

I feel anything in brackets ([mission_XXXX] or [XXX_string]) should be recursively expanded (a la descriptions.plist).

set: variable_name value (and add: subtract: increment: and decrement:) should simply take a local_ or mission_ as their first value, this should be checked for and not expanded at all.

[dajt]

If there is already recursive processing of stuff in brackets then the thing to do is probably just extend the range of things it understands and use that.

I don't like the idea of having each action figure out what is expandable and what isn't, I think the code will be much cleaner if it all happens in scriptAction, and stuff in brakcets gets expanded. Then there are no questions as to what is expandable or not and no special code in only certain actions.

[JensAyton]

Maybe he should have a "screw that idea, somebody else can do it" list?

#1: be more like Frontier…

[aegidian]

I don't like the idea of having each action figure out what is expandable and what isn't, I think the code will be much cleaner if it all happens in scriptAction, and stuff in brakcets gets expanded. Then there are no questions as to what is expandable or not and no special code in only certain actions.

Having everything work in one repeatable way is a great ideal but it's just not how assignment should work.

However assignment actions should be the only exception to the expand anything in brackets and substitute for mission_xxx and local_xxx routine.

I'd oppose anything that broke backwards compatibility (old OXPs must keep working without needing adapting).

[JensAyton]

The first operand to set: or add: can be considered the LHS of an assignment operation (and should probably be representable as such in oos)…

[dajt]

I'd expect old OXPs will keep working unless they did something like:

set: [do_not_replace] why did I put square brackets there when it has to be a mission_variable?

or:

set: mission_xxx I do not want [this] replaced with anything

I doubt either case exists.

Anyway, I have some of it working now so will play around with it for a bit. It's all going in the script-compiler branch anyway so there is no danger of breaking the main dev code.

I've moved the bulk of the code from Universe expandDescription into a new method that also takes the local variables dictionary as a parameter. Then regular old expandDescription calls this new method with nil so existing code knows no difference. The new method doesn't do anything with locals if the locals dictionary passed in is nil.

[dajt]

The first operand to set: or add: can be considered the LHS of an assignment operation (and should probably be representable as such in oos)…

In which case I'd change the syntax in oos to be local_x = everything on the rest of this line.

It seems a simple and safe enough compromise to me that everything in [] gets expanded, and you never put anything in [] as the first word after set: etc. They are not valid there at present anyway. And if you do, you get a self-modifying script ;)