Oolite Bulletins

I would like to know how I would be able to query the energylevel of a certain subentity and store this value in a variable.

Can someone point me in the right direction ?

variable = subentity.energy, assuming "subentity" is a variable holding the subentity you're interested in.

There are three (ish) different options for what "variable" is.

If you only need it until the end of the current function call, then a normal variable will do If you need it for longer than that, but don't need to worry about keeping it over save/load, then store it on the script itself If you need to keep it over save/load, then the easiest way to do that is to have it as a mission variable Obviously the longer you keep it for, the more effort you have to put in to making sure that you don't have any other variables with the same name - whether it has to be unique to the function, unique to the script, or unique to the whole game.

If you need to store multiple subentity energies, then you probably want something more manageable than giving each of them a differently named variable and hoping you can keep them all sorted in your head.

Thank you again Cim, I will (try to) put this to good use.

Ok, I solved it, thx to Wildebloods suggestion.

Cim,

I was experimenting with the code you wrote for engine trails. The one that Zirael used for his enginetrail oxp. It works well for the player ship, but is there any way to have it for NPC's as well. I like this one, since it gives you absolute freedom regarding length and dimentions of the trail, unlike the one you can define in the shipdata.plist

tried changing player.ship to this.ship, and adding a shipSpawned funtion to call it but just doesn't seem to work.

I added your quote from the other forum.

Could you have a quick peek at that please ?

cim wrote:

[wiki]Effectdata.plist[/wiki] lets you define a visual effect.

system.addVisualEffect(...) lets you add defined effects to the system.

Visual effects have a javascript representation which can be used to modify them.

I was experimenting with this myself a bit before 1.77 was released, to see if there was a better way to get engine flares - here's the not very far I got with it. It works okay - though it's a bit system-intensive - for one ship at low speeds, but it falls apart entirely at injector or torus speeds. Still, it gives an example of how you might add visual effects in about the right place to be an engine trail, though I wouldn't say it was an example of good code.

dertien wrote:

is there any way to have it for NPC's as well

Not really. There's a hard limit of 2,048 entities per system, and to get a decent engine trail - even a short one - requires a lot of separate entities with that method. There's usually about 100 ships per system, with an average of two engines each, so you'd be limited to maybe 5 or 6 entities per trail, which would look terrible at most speeds.

If it had worked out as a visual look, I'd have had to build a new entity type within Oolite - an option not available to OXPs [1] - to make them actually work: the engine trail code there is a quick "does this look plausible" hack.

[1] Actually, I think it's theoretically possible to make that style of engine trail without exceeding the entity limit by using nested subentities and a frame callback, though it'd not be at all good for your frame rate, and would be very complex to program.

Okido,

It looked so very good on the player ship. Ah, well, we'll just settle for the straightforward method then.

Thanks for the quick reply.

Since it is impossible to damage passenger berths, how can one query if one is installed or not ?

since this is not possible
what is the alternative ?

Passenger berths are not exactly equipment, in Oolite, so there are some oddities there. The equivalent test is

thank you Cim, will try that out.

Edit: works well thx.

According to this:
http://wiki.alioth.net/index.php/Oolite ... markSystem
"Multiple systems may be marked at once, as in mission.markSystem(4, 54, 222)"

So I tried this:...Which obviously doesn't work.

I couldn't get this to work either: What am I doing wrong?

So lots of repeated stuff. Well, at least I can copy-and-paste!

Repeated code is not good to the performance and a headache when you decide to modify something. Even better if you store the system numbers in an array and set the markers in a cycle.

I've some queries regarding station interfaces. Generally these are set by a world script using shipDockedWithStation, startUpComplete or missionScreenOpportunity, and OXPs tend to set them fairly promiscuously, either on every station or every main station.

I want an unfriendly station, where dockside services are not available. How do I prevent or undo your OXP setting an interface on my station? Is there an array I can loop through and null them all? If not, why not? Is there a way to prevent them being set in the first place? Basically, the problem is this: you've installed the It's Not For Everyone OXP, when you dock at INFE Station, you should see only the interfaces set by the INFE OXP, and no others.

Do interfaces have to be set from a world script - can a station set them up from its own ship script? E.g. of a ship system unique to a particular class of ship, would it not make more sense for a ship script on the player's ship to set the interface, rather than a world script?

Are there any restrictions on the callback function of an interface? So far I've only seen them used to run mission screens, which is fairly unimaginative. If I want to "Re-stock this station's market" I can do that directly from the interface callback without the unnecessary step of looking at an "Are you sure?" mission screen. Could I "Witchspace jump this carrier to another system", or would that be beyond the pale?

Lastly, if I have a reference to a station object, can I execute the callback function of an interface on that station while player.ship.docked === false or while docked at another station? The bottom line: could I create a prime-able equipment to take remote control of a station through its interfaces, or remotely control one station (through its interfaces, not by brute force) while docked at another?