Oolite Bulletins

dajt wrote:

Ahruman wrote:

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.

Pretty much… but is there a ternary add? Allowing a = b + c to be transformed into “add: a b c” (and so on for other operations) would be nice. I’m a tad unfamiliar with the scripting engine, though.

Allowing a = b + c * d, to be converted to, say (“multiply: local_ooc_temp0 c d”, “add_ a b local_ooc_temp0”) would be even nicer, of course, but that’s approaching real compilerhood. :-)

Well, the good thing is that sort of transformation can be implemented later without breaking too much existing stuff, except that you'd want () as grouping/ordering operators which might stuff up people that use them, assuming '=' could be applied to string values in which they might have been used.

But right now I just want to get useful and consistent substitution going.

I could implement an entirely new scripting engine that didn't use the existing stuff and had a normal programming language symtax, but that is for another day. If I went that way I'd want to review how and when scripts are run, and possibly add threading so they could run in the background, and then I'd have X2!

I'd just like to say that I'm actually really pleased at the way this is developing. You're doing a great job with this.

You'll just have to forgive my nitpicks sounding curmudgeonly - feeling sub-par is emphasising my grumpier aspects!

dajt wrote:

I could implement an entirely new scripting engine that didn't use the existing stuff and had a normal programming language symtax, but that is for another day.

The words “reinventing” and “wheel” spring to mind. I’ve vaguely suggested Lua¹ in the past; it’d require significant fiddling with the script system, but so would a custom language.

¹ There are other options, of course; I don’t have a dogmatic preference. One with existing Objective-C bindings would be preferable, of course, especially if they already work with both Cocoa and GNUStep.

You ever read lisp ?

Looks like a new variant called plisp

1. Script-local variables

That'd be awesome!
No more headscratching where AddOns clash, yay!

Ahruman wrote:

The words “reinventing” and “wheel” spring to mind. I’ve vaguely suggested Lua¹ in the past; it’d require significant fiddling with the script system, but so would a custom language.

Fair enough. I didn't go for lua because I didn't immediately feel an affinity for it when I looked at it last time. But then I feel the same about most languages ;)

I'll have another look at it if I ever decide to do a new script engine.

And sure, implemeting an interpreter when there is no need to is a waste of work.

I've checked in some changes to the script-compiler branch.

I have added an action for scripts to set the planet info entries for any galaxy/planet rather than the current one. I found this useful when I wanted to change the state of a different planet in a script based on actions in the current one.

Universe::expandDescription now expands _string, _number, and _bool functions if they are enclosed in []. You can optionally pass a script local variable dictionary in and have script local variables expanded if they are enclosed in []. I have done this so that the original signature of the method is maintained to existing code sees no difference in regards to locals, although the functions will now get expanded if enclosed in []. Note that given the behaviour of expandDescription, anything that looks like a function or local var passed in now would have to be a mistake because the only valid expansion expressions in the current code are mission variables, commander variables, and numbers.

Script local variables can be checked in conditions.

scriptAction now calls expandDescription before calling the action. The action word itself isn't pased in but all action arguments are. Yes, even the target of an assignment. So if you are determined to do:
and local_x has a value of "mission_y", then the action that gets executed is:
So you can do things like:
In the add action, local_x isn't enclosed in square brackets because that would make it be expanded, which you don't want.

Now, script and local vars, and functions, are ALWAYS expanded in conditions, and must not be surrounded by []. This is a bit inconsistent, but having to put them in [] in conditions would make scripts less readable (and I'm trying to improve that aspect!) and also annoying to type. So I'm happy to live with that one.

I'll post the oolite.exe on the Oolite-PC site for anyone that wants to try it. Just back up your current .exe and replace it with this one to try it, then go the other way to put the original back.

Galileo wrote:

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
				);
			},

Given the new executable I just posted, and using the oos syntax, your example becomes:
Of course, you can still use your current plist script too. Just replace the "1" in addSystemShips with "[mission_ionics_government_fleet_size]".

Great work! Thanks for that. BTW, how long do you think it will be before your script-compiler branch is merged into the main branch?

Not long - I'm happy with the work and I have a couple more things to do on the main branch - then it can be merged.