Oolite Bulletins

I think scripters want to be able to get a Systemname for a number. UPS is the first that used random locations in his missions. Now RandomHits and GalacticNavy also use random locations. The last two use a lot of code and a database with names to link a name to a number. a waste of time when Oolite has the code internally ready.

It is in "universe.m": systemSeedForSystemNumber: and generateSystemName:. The first generates a system seed from a interger (=system.ID), the second uses that seed to generate a system name. I think it will be no great problem to add a scriptfunction that calls those functions. i tried it from within JS but the functions in "universe.m" are not accessible with a xxx.call()

e.g.
mySeed = xxx.call("systemSeedForSystemNumber:", 7)
myName = xxx.call("generateSystemName:", mySeed)
is not working.

That would be handy! I knew I could just use a set: mission_random_hits_planetnumber [d256] to get a random system, but could not think of a way to change this into a name. Hence the rather unweildy script of systemname oneof: long list of system names C&Ped from the wiki planet list! do set mission_random_hits_planetnumber 0 and so on!

Please use appropriate sticky threads when they exist. A scripting request that’s not in the scripting requests thread and isn’t followed up on immediately is likely to get lost.

Regarding the call() thing: Universe methods are not callable with call(), and never will be. call() exists to enable the use of legacy scripting methods which don’t have a JavaScript equivalent, not to allow you to dig around and find interesting new methods. Methods that have not previously been documented as intended for scripts, or used in scripts released by Giles, are internal and may change at any time. Using it for prototyping is OKish, but don’t even consider shipping OXPs which abuse call() this way.

Beyond that, call() is dangerous. It can trivially be used to crash Oolite. It can almost certainly be used to do worse things. I wouldn’t have even considered implementing it, if it wasn’t for the fact that the legacy scripting system has the same problem. Ideally, all OXPs would be ported to JS and we could throw out the old system. More practically, it may be possible to auto-translate legacy scripts into call()-free JS (but not for the MNSR).

The AI system has similar problems, but because its scope is more restricted it can probably be sandboxed. The shader binding system also calls methods directly, but is more restricted and typesafe; even so, I intend to add a whitelist to it so only safe methods can be called.

This has been nagging at me for some time. The way OXPs work makes Oolite a security risk. As it stands, the MNSR will probably not include call().