Scripting requests

[cim]

Looking at what's tied to scanClass, it's probably safe to make it read-write, though not all transitions will make much sense...

I’m leery of doing that since it has traditionally been an invariant, but I can’t point at anything in particular as a reason for keeping it that way.

I can't think of anything yet that could result from making it read/write that would be worse than the possible consequences of letting it be set at all from shipdata. I'll think about it for a bit longer before doing it, though.

[Eric Walch]

I can't think of anything yet that could result from making it read/write that would be worse than the possible consequences of letting it be set at all from shipdata. I'll think about it for a bit longer before doing it, though.

One thing would have been to mis-use it to deceive the player, but as you already can set the colour of any ship by script, that seems no good reason against it. Just make sure it is not misused as a cheap cloak by not allowing it to set to "CLASS_NO_DRAW". (scanClass must be > 0)

[Capt. Murphy]

Griff's ships when spawned (or displayed on a missionScreen) have a random paint job as defined by uniforms in the Shader's dictionary.

e.g.

uniforms =
{
uColorMap = { type = texture; value = 0; };
uNormalMap = { type = texture; value = 1; };
uEffectsMap = { type = texture; value = 2; };
uDecalMap = { type = texture; value = 3; };
uTime = "universalTime";
damage_amount = "damage";
alertlevel = "alertCondition";
hull_heat_level = "hullHeatLevel";
laser_heat_level = "laserHeatLevel";
engine_power = "speedFactor";
PaintColor1 = {type = "randomUnitVector"; scale = 0.25;};
Decal1_Scale_and_Position = { type = vector; value = "0.396 0.39 8.5"; };
Decal1_Rotation = { type = "float"; value = 0.0; };
};

If a ship's Shader dictionary was visible to JS as a read only object would PaintColor1 be reported as the actual value for that ship? If so it could be handy in several contexts to be able to store the Shader dictionary and use the stored object and setShaders to maintain a consistent paint colour. Same goes for making the Materials dictionary visible to JS.

[JensAyton]

If a ship's Shader dictionary was visible to JS as a read only object would PaintColor1 be reported as the actual value for that ship?

Nope.

The value is derived from the ship’s entityPersonality. If you want to serialize and restore ships, you should probably be requesting a way to create a ship with a specified personality, or just a game-provided way to serialize and restore (which would probably be based on the method used for wormholes).

[Capt. Murphy]

Thanks Ahruman.

There are two specific scenarios I'm looking at (albeit used in the same WIP OXP).

First is displaying the model of a ship just bought from the shipyard on a subsequent missionScreen. Since cim has implemented the automatic inclusion of [dataKey] as a role, the model can be got, but looking at how it's created I see it effectively creates a new entity with a new random entityPersonality, so Griff's paint job will be different.

Second is as you surmise is serialising and restoring player.ship attributes. Again pretty much all of this can be now be done via JS, given that weapons are read/write and with the player.replaceShip(dataKey) method. Again cim has coded this to piggyback on the normal shipyard code, so the ship 'given' to the player will always have a new random entityPersonality when it's added on the fly to the shipyard.

The paint job/entityPersonality is the only remaining bugbear that I can think of that's a barrier to doing this seamlessly via script.

I'm guessing that making entityPersonality read/write is a no-no? For these purposes it would only have to be read/write for the player.ship, and for NPC ships that are demoShip entities. Would two entities in existence with the same entityPersonality cause big problems?

Another option might be to expand player.replaceShip(dataKey) so it accepts an integer as an optional second parameter and uses that to set the entityPersonality. But again would this cause problems if that particular entityPersonality had been recycled and was is use?

As far as the random colours go is visible paint colour very similar for entityPersonality's that are only one digit different? If so one possibility would be limited write access to entityPersonality, and if a non unique value was selected it could be retried after incrementing it by 1.

Re core game serialisation of the player.ship that would be good, but it's going to need some extra help from script to deal with OXP equipment, which often has missionVariables etc that would need to be associated with the serialised data. If it were implemented then perhaps player.replaceShip(dataKey) could be amended to accept either just dataKey, or the core game created serialised data.

[cim]

I'm guessing that making entityPersonality read/write is a no-no?

I'd have to check a little more carefully, but I can't see any reason why not.
- it's selected randomly on creation, with no attempt to avoid collisions. There doesn't appear to be any reason it has to be unique.
- it doesn't do that much except being a pseudo-random number
- there is already a method in ShipEntity for changing it

So it should be easy and safe to make read/write, though I shall check more thoroughly first.

[Capt. Murphy]

Thanks cim,

I guess it would need to be a method ship.setPersonality() or similar so the existing function in ShipEntity can be called which looks like it resets the textures? Anyway that would be an ideal solution for both contexts, and also would allow for a 'Get a new paint job for your Griff Ship'.oxp.....

[cim]

I guess it would need to be a method ship.setPersonality() or similar so the existing function in ShipEntity can be called which looks like it resets the textures? Anyway that would be an ideal solution for both contexts...

Because of the way the interface with JS works it's possible to just make the property read/write. ShipSetProperty in OOJSShip.m handles writing by JS to a native Oolite ShipEntity object - it's all indirect, calling functions in ShipEntity to do the setting. You only need separate JS methods for setting when the property isn't a scalar.

[Wildeblood]

Can we have the player ship cross-hairs dictionary/file changeable, the same way the HUD file is, please? Currently, to alter the cross-hairs on the fly, one has to embed the cross-hairs dictionary in a HUD file and switch the whole HUD file. It's easily done, but can cause a rapid proliferation of HUD files.

[JensAyton]

As far as the random colours go is visible paint colour very similar for entityPersonality's that are only one digit different?

No, they’d be as different as any other two personalities.

I'm guessing that making entityPersonality read/write is a no-no?

I'd have to check a little more carefully, but I can't see any reason why not.

The entity personality is very definitely intended to be an invariant so that any values derived from it stay stable, in the same way as system.pseudoRandomNumber. For example, if you change it, and the ship has shader quasi-random properties, the entity’s appearance will change if the player changes shader modes or there is a graphics reset for any reason.

It’s read-write internally because it needs to be set when deserializing and buying ships, but those only apply during setup; it shouldn’t be script-writeable “in-flight”.

[cim]

The entity personality is very definitely intended to be an invariant so that any values derived from it stay stable, in the same way as system.pseudoRandomNumber. For example, if you change it, and the ship has shader quasi-random properties, the entity’s appearance will change if the player changes shader modes or there is a graphics reset for any reason.

Agreed. On closer looking I found some non-shader components tied to entityPersonality in the same way, too.

However, it should be easy enough to get the mission screen model creation, and player ship creation, to allow a particular entityPersonality to be defined on ship setup. Would that be sufficient?

[Capt. Murphy]

However, it should be easy enough to get the mission screen model creation, and player ship creation, to allow a particular entityPersonality to be defined on ship setup. Would that be sufficient?

That would be ideal.

[CommonSenseOTB]

I wonder if it would be possible to implement this:

https://bb.oolite.space/viewtopic.php?f= ... 80#p148595

I've thought of a whole host of possible uses for this including cinematic flybys of your ship, a camera view that shows your ship as you land or dock, and of course a zoomable camera that works smoothly and automatically. I'm currently looking at doing a sniper laser for custom lasers that works much better than the sniper camera system and being able to both read/write the specific custom view name or string means alot of different ideas could work well and be on the ship at the same time. Combine this with frame callbacks and we'll put some real "wow" factor and immersion "punch" into this game.

[Cody]

... and we'll put some real "wow" factor and immersion "punch" into this game.

I've got plenty of real "wow" factor and immersion "punch" in my game already, thank you kindly.

[CommonSenseOTB]

... and we'll put some real "wow" factor and immersion "punch" into this game.

I've got plenty of real "wow" factor and immersion "punch" in my game already, thank you kindly.

What's that supposed to mean?