Scripting requests

[cim]

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.

"Definitely" is something I like to wait a few days before being sure of in case people have better ideas (e.g. your boundingBox changes which Eric has suggested a few improvements to since my original implementation went into trunk). Agreed, though - I'll start putting summary posts in that thread every now and again for the new scripting stuff.

[cim]

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.

Would work nicely for runScreen, certainly. With addShip though system.addShip("trader") gives something pirates will attack, whereas system.addShip("[anaconda]") wouldn't, so adding a specific trader ship to the system would still need a separate role+name function.

Thinking about it Thargoids are a likely case for role/key collisions, as lots of things have roles = "... thargoid ...", and the basic warship also has dataKey 'thargoid', so even with role falling back to dataKey you can't get a guaranteed basic thargoid. Square brackets would fix that.

[JensAyton]

Would work nicely for runScreen, certainly. With addShip though system.addShip("trader") gives something pirates will attack, whereas system.addShip("[anaconda]") wouldn't, so adding a specific trader ship to the system would still need a separate role+name function.

You can fix that by setting the primaryRole (and, if necessary, AI) for the newly-created ship as necessary. This is fiddly, but can be rolled into a utility function. (This is the sort of thing I’d either leave to OXPers or put in the prefix script.)

[cim]

Would work nicely for runScreen, certainly. With addShip though system.addShip("trader") gives something pirates will attack, whereas system.addShip("[anaconda]") wouldn't, so adding a specific trader ship to the system would still need a separate role+name function.

You can fix that by setting the primaryRole (and, if necessary, AI) for the newly-created ship as necessary. This is fiddly, but can be rolled into a utility function. (This is the sort of thing I’d either leave to OXPers or put in the prefix script.)

Yes, of course. Obviously... Somehow I'd managed to miss that primaryRole was read-write for NPCs. Right, in that case square brackets seems to be the way to go, and gives a more general solution to the problem than putting in different solutions for each case a role-or-name might be used. I'll sort that out when I get a moment, then.

[Thargoid]

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.

As a throw-away thought, how about also having used cargo space for equipment perhaps increase the chance of damage? For example for every ton of space used, increase the chance by 0.1 or something? My thinking being that if you have a big complex bit of kit that's taking up half of your cargo bay and you get your iron ass handed to you, one of the first things that would likely get taken apart would be said piece of equipment...

[Switeck]

Would work nicely for runScreen, certainly. With addShip though system.addShip("trader") gives something pirates will attack, whereas system.addShip("[anaconda]") wouldn't, so adding a specific trader ship to the system would still need a separate role+name function.

You can fix that by setting the primaryRole (and, if necessary, AI) for the newly-created ship as necessary. This is fiddly, but can be rolled into a utility function. (This is the sort of thing I’d either leave to OXPers or put in the prefix script.)

Yes, it's quite fiddly.
I had to do this to add a random Pirate "Blackdog" to a system:

Code: Select all

this.shipExitedWitchspace = function()
{
// Sometimes adds 1 pirate "Blackdog" Python...10% chance in Anarchy systems, 3% chance at Corporate State systems.
	if(Math.random() < (0.1 - system.government*0.01) ) {
		var pirBD = system.addShipsToRoute("blackdog", 1, (Math.random()*0.7+0.1) )[0];
		pirBD.switchAI("pirateAI.plist");
		pirBD.AIState ="GLOBAL";
		pirBD.primaryRole = "pirate";
		if(pirBD.bounty < 39) pirBD.bounty = Math.round(Math.random() * 60) + 40; // 40-100 credits bounty?
	}
}

If I wanted to add a random Python, that's a problem because only the "Blackdog" one has a unique role.

In a mission/campaign I was working on, I actually did want to show an Anaconda as the model to spin in the "background" while you read the text. I know how to make that work, I just have to make a shipdata-overrides.plist entry to modify the Anaconda to have a unique role.

[JensAyton]

I had to do this to add a random Pirate "Blackdog" to a system:

Setting AIState is redundant, as it’s set to GLOBAL when switching AIs.

In order for this to be done in a general way, it would probably be good to expose ships’ autoAI property and the autoAIMap to JS so the AI switch can be inferred from the role.

[cim]

As a throw-away thought, how about also having used cargo space for equipment perhaps increase the chance of damage? For example for every ton of space used, increase the chance by 0.1 or something? My thinking being that if you have a big complex bit of kit that's taking up half of your cargo bay and you get your iron ass handed to you, one of the first things that would likely get taken apart would be said piece of equipment...

I'd rather leave that sort of decision up to the OXP writers - it's easy enough to set damage_probability at the same time as required_cargo_space, and both in their OXP-usable form are post-1.76 features so there's less worry about backward compatibility. (The only pieces of core equipment which affect cargo space are undamageable, of course)

[Thargoid]

An event-handler (well, two actually) that triggers when the player buys or sells cargo (passing commoditiy name, quantity, and price).

playerBoughtCargo(commodity,units,price) and playerSoldCargo(commodity,units,price) are available as of r4851.

Thank you, kindly.


While I'm at it...

Would it be possible to give each station entity its own market object (along the same lines as the player's manifest object), allowing the harried, overworked OXP-writer direct access to prices and quantities without the need to horse around with that @#&%$ commodities.plist?

Can I second this request for 1.77 please? Just updated HyperCargo ready for 1.77 use of cargo space by equipment, but having the price available would be better for the work-around needed instead.

[JensAyton]

You can fix that by setting the primaryRole (and, if necessary, AI) for the newly-created ship as necessary. This is fiddly, but can be rolled into a utility function. (This is the sort of thing I’d either leave to OXPers or put in the prefix script.)

On further consideration, the full behaviour of newShipWithRole: and auto_ai can’t be implemented in JS without making scanClass read-write. The full logic, translated to JS, is:

Code: Select all

if (ship.autoAI)
{
    let defaultAI = autoAIMap[role];
    if (defaultAI)
    {
        ship.setAI(defaultAI); // Not switchAI; this is probably a bug.
        
        // Nikos 20090604
        // Pirate, trader or police with auto_ai? Follow populator rules for them.
        if (role == "pirate")  ship.setBounty(20 + Math.random() * 50, "setup actions");
        if (role == "trader")  ship.setBounty(0, "setup actions");
        if (role == "police")  ship.scanClass = "CLASS_POLICE";
        if (role == "interceptor")
        {
            ship.scanClass = "CLASS_POLICE";
            ship.primaryRole = "police"; // to make sure interceptors get the correct pilot later on.
        }
    }
    if (role == "thargoid")  ship.scanClass = "CLASS_THARGOID"; // thargoids are not on the autoAIMap
}

[Switeck]

I'm not sure this handles the escort scanClass.

Escorts have weird properties:
https://bb.oolite.space/viewtopic.php?p=123225#p123225
"Yes, it is hardcoded that only the main-station and ships with role "police" and "hunter" accept distress messages. That are the roles that are supposed to watch the system for criminals. Even escorts that turn into a hunting role will not react to this. All other ships using the route1patrolAI.plist, can only react on the scanning for offenders."

https://bb.oolite.space/viewtopic.php?p=140702#p140702
"would it be possible to turn the NPC hitch-hikers into escorts of the NPC that created the wormhole? Can escorts be created on the fly, as it were, and then (if necessary) de-escortified later?"
...later reply:
"I don't think that you can create escorts in JS. It is however possible to combine ships into a group."

Viper types with "wingman" roles that are added by JS probably also cannot be made to follow other police Vipers as escorts, only combined into a group.

[Eric Walch]

...later reply:
"I don't think that you can create escorts in JS. It is however possible to combine ships into a group."

Viper types with "wingman" roles that are added by JS probably also cannot be made to follow other police Vipers as escorts, only combined into a group.

You can add escorts with JS but very limited. You can add replacement escorts for killed ones. The ship will accept them. max escort is lowered on ship creation, so the maximum could be lower that shipdata shows.
police and hunters are different. Their max escort overwrites shipdata and is always 16. Specially for vipers it is easy to add additional wingmen. A ship added in that role will look for ships in role police and follow them it the police has less than 16 escorts. If not found, it turns himself into a police. This process assures that, if a leading viper was killed in a battle, the remaining wingmen don't fly off individually after the battle, but they choose a new lead-ship and the rest is following it. (This all happens outside the AI, at a lower code level)
That is one of the differences between wingman and escort.

[Thargoid]

A new request (and hopefully a simple one) - can we have a read/write new ship function currentWeapon to be used interchangably with forwardWeapon/aftWeapon/portWeapon/starboardWeapon, but acting on the currently active weapon (ie the one corresponding to the currently selected view).

The reasoning is so we don't have to go through the faff of using currentView to find out which way the viewscreen is currently looking, and then going to the appropriate of the four weapon mounts above. It would help to streamline code where we just want to reference/check/adjust the current weapon that is firing.

So basically when in forward view, player.ship.currentWeapon = "EQ_WEAPON_MILITARY_LASER" would set the forward laser to a military laser (same as player.ship.forwardWeapon = "EQ_WEAPON_MILITARY_LASER"), but if the same command was done in aft view then it would act as player.ship.aftWeapon = "EQ_WEAPON_MILITARY_LASER"

Also if the view is VIEW_CUSTOM, then currentWeapon should point to whichever weapon is assigned to that view in the shipdata.plist definition (defaulting to forward if undefined).

Could that be dropped into 1.77 please?

[cim]

On further consideration, the full behaviour of newShipWithRole: and auto_ai can’t be implemented in JS without making scanClass read-write.

That would certainly have other uses for scripters, too. Looking at what's tied to scanClass, it's probably safe to make it read-write, though not all transitions will make much sense...

[JensAyton]

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.