Oolite Bulletins

Commander McLane wrote:

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.

Ahruman wrote:

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 wrote:

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.

Ahruman wrote:

cim wrote:

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 wrote:

Capt. Murphy wrote:

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.

Ahruman wrote:

cim wrote:

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.)

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?
	}
}

Switeck wrote:

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

Thargoid wrote:

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...

Phasted wrote:

cim wrote:

Phasted wrote:

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?

Ahruman wrote:

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.)

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 wrote:

...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.

Ahruman wrote:

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

cim wrote:

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