Scripting requests

[JensAyton]

The unique roles of the in-built ships have been removed somewhere around 1.73. I still haven't really understood why.

The notion of a role uniquely identifying a ship fell apart in the face of like_ship and copy & paste coding. (For the record, those roles were never in a stable release.)

[Commander McLane]

The unique roles of the in-built ships have been removed somewhere around 1.73. I still haven't really understood why.

The notion of a role uniquely identifying a ship fell apart in the face of like_ship and copy & paste coding. (For the record, those roles were never in a stable release.)

Sure, they would be inherited through like_shipping (or senseless c&p'ing), which would of course defeat their purpose.

However, I would expect the roles key to be included explicitly to a new ship, because generally I wouldn't expect a new ship to have the exact same role set as its model.

[Commander McLane]

And while I'm posting in this thread, may I put in a small reminder of this request?

[cim]

And while I'm posting in this thread, may I put in a small reminder of this request?

It's in r4937 and the current nightly builds - I just haven't got around to documenting it yet. (Vector ship.boundingBox is the short version)

[Commander McLane]

And while I'm posting in this thread, may I put in a small reminder of this request?

It's in r4937 and the current nightly builds - I just haven't got around to documenting it yet. (Vector ship.boundingBox is the short version)

Cool!

[JensAyton]

generally I wouldn't expect a new ship to have the exact same role set as its model.

The observed reality was that they often did.

[Commander McLane]

generally I wouldn't expect a new ship to have the exact same role set as its model.

The observed reality was that they often did.

Well, there's little to do against observed reality, I guess. (Except you're an ostrich, of course. )

[Eric Walch]

It's in r4937 and the current nightly builds - I just haven't got around to documenting it yet. (Vector ship.boundingBox is the short version)

I just realised that it probably needs some polishing. totalBoundingBox is only calculated on the first update. I had the same problem with the size detection of launching ships. Originally I used boundingBox until I noticed that small ships with big subents still could launch. But after replacing it with totalBoundingBox I forgot to test until I noticed in a release version that all ships could launch again.
I think same will happen here if the JS script evaluates the boundingBox of a just created ship Should be easy to fix if it really happens.

[cim]

It's in r4937 and the current nightly builds - I just haven't got around to documenting it yet. (Vector ship.boundingBox is the short version)

I just realised that it probably needs some polishing. totalBoundingBox is only calculated on the first update. I had the same problem with the size detection of launching ships. Originally I used boundingBox until I noticed that small ships with big subents still could launch. But after replacing it with totalBoundingBox I forgot to test until I noticed in a release version that all ships could launch again.
I think same will happen here if the JS script evaluates the boundingBox of a just created ship Should be easy to fix if it really happens.

Right. I'll test and have a look at it. Might be easier to just push the calculation of totalBoundingBox earlier.

[Capt. Murphy]

Can we make the model parameter of mission.runScreen accept both a role string or a dataKey string as valid inputs?

So try to interpret it as a role, and if that fails try to interpret it as a shipdata key? (and the same for addShips, etc.)

Alternatively there could be separate parameters and functions in the same way that escort_role and escort_ship are separated. Which is less likely to be confusing?

Mmm, to my mind the first option is the least confusing (certainly in the context of mission.runScreen), and with the introduction of dataKey to JS is a guaranteed unique parameter (unlike role or ship.name), it just makes sense to me that it would be used to define a model in this context. The specific use I'm thinking of is to display a specific player flyable ship on the missionScreen and obviously role "player" doesn't cut it.

For spawning ships I guess there are issues to consider in allowing dataKey or ship.name as an alternative input to role, in deciding what role will be assigned to the resulting ship if it has several available (and AI if the autoAIkey isn't set. But I guess that can be handled as normal with role probabilities. Alternatively perhaps the command syntax could be expanded to...
addShips(role : String[, dataKey: String], count : Number [, position: vectorExpression] [, radius: Number]) : Array

with dataKey as an optional parameter in addition to role. Perhaps something similar formission.runScreen?

[cim]

Mmm, to my mind the first option is the least confusing (certainly in the context of mission.runScreen), and with the introduction of dataKey to JS is a guaranteed unique parameter (unlike role or ship.name), it just makes sense to me that it would be used to define a model in this context. The specific use I'm thinking of is to display a specific player flyable ship on the missionScreen and obviously role "player" doesn't cut it.

I thought that might be what you needed it for. Role with fallback to dataKey makes sense, I think, for that. Of course, you might have a ship whose dataKey is the role for a different ship, but that seems unlikely to be a major problem.

For spawning ships I guess there are issues to consider in allowing dataKey or ship.name as an alternative input to role, in deciding what role will be assigned to the resulting ship if it has several available (and AI if the autoAIkey isn't set. But I guess that can be handled as normal with role probabilities. Alternatively perhaps the command syntax could be expanded to...
addShips(role : String[, dataKey: String], count : Number [, position: vectorExpression] [, radius: Number]) : Array

with dataKey as an optional parameter in addition to role. Perhaps something similar formission.runScreen?

I'm not sure adding an optional parameter to the middle of a function list is really a good idea, even if it is technically possible in that case. I think there might have to be a separate function for that, where both role and dataKey are required. (Certainly adding a ship with a dataKey and no specified primaryRole would get very messy, as you say)

[cim]

It's in r4937 and the current nightly builds - I just haven't got around to documenting it yet. (Vector ship.boundingBox is the short version)

I just realised that it probably needs some polishing. totalBoundingBox is only calculated on the first update. I had the same problem with the size detection of launching ships. Originally I used boundingBox until I noticed that small ships with big subents still could launch. But after replacing it with totalBoundingBox I forgot to test until I noticed in a release version that all ships could launch again.
I think same will happen here if the JS script evaluates the boundingBox of a just created ship Should be easy to fix if it really happens.

Right. I'll test and have a look at it. Might be easier to just push the calculation of totalBoundingBox earlier.

Fixed in r4939 - totalBoundingBox is now also calculated on entity initialisation. There may be some code in launching that can now be simplified - I haven't looked.

[JensAyton]

Mmm, to my mind the first option is the least confusing (certainly in the context of mission.runScreen), and with the introduction of dataKey to JS is a guaranteed unique parameter (unlike role or ship.name), it just makes sense to me that it would be used to define a model in this context. The specific use I'm thinking of is to display a specific player flyable ship on the missionScreen and obviously role "player" doesn't cut it.

I thought that might be what you needed it for. Role with fallback to dataKey makes sense, I think, for that. Of course, you might have a ship whose dataKey is the role for a different ship, but that seems unlikely to be a major problem.

An approach I was toying in for 2.0 was to implicitly add [dataKey] as a role to every ship, so you could use system.addShip("[anaconda]"). Explicit roles with brackets in the plist would be rejected.

[cim]

Whilst your messing with equipment related code could some consideration be given to the code that selects equipment for damage in combat.

equipment.plist now has a damage_probability key (readable with JS EquipmentInfo.damageProbability)
This is ignored for missiles and mines (and is effectively 0), and defaults to 1 for everything else.
It's a relative probability that works in the same way as ship role selection - so if you have one piece of equipment with damage_probability = 1.5, and two with damage_probability = 0.5, then the one with damage_probability = 1.5 will be damaged 60% of the time. (If it isn't the first item to take damage, it will then have an 80% chance of being the second item to take damage)

I haven't changed the default values for non-visible items.

[Commander McLane]

Whilst your messing with equipment related code could some consideration be given to the code that selects equipment for damage in combat.

equipment.plist now has a damage_probability key (readable with JS EquipmentInfo.damageProbability)
This is ignored for missiles and mines (and is effectively 0), and defaults to 1 for everything else.
It's a relative probability that works in the same way as ship role selection - so if you have one piece of equipment with damage_probability = 1.5, and two with damage_probability = 0.5, then the one with damage_probability = 1.5 will be damaged 60% of the time. (If it isn't the first item to take damage, it will then have an 80% chance of being the second item to take damage)

I haven't changed the default values for non-visible items.

Whenever a change has definitely been made, it would be nice to post it in the Progress thread rather than here. For more clarity a link to the relevant part of the debate here (or elsewhere) can be made there.