Oolite Bulletins

OK, my journey to this question started with an error logged for the In System Trader OXP by Dr.Tripsa
http://wiki.alioth.net/index.php/In_System_Trader

[script.javaScript.exception.ooliteDefined]: ***** JavaScript exception (In_System_Trader 1.4): Error:
Station.setMarketPrice: Invalid arguments ("Alien Items", NaN) -- expected Unrecognised commodity type.

I figured out the error easily enough (old code for price adjustments, based on the pre-1.81 Commodities structure) but I'm having less success finding a solution.

I've read the Market Scripts page
http://wiki.alioth.net/index.php/Oolite ... et_Scripts
and followed the link at the bottom of that page
viewtopic.php?f=4&t=17621#p239979
I've also looked at the ...market.js code in about a dozen OXPs that have been updated for v1.8+ but these all work by recreating the function of the old <= v1.7 code.

This seems like an unsatisfactory solution, not only because it effectively rolls Oolite back the old days, but also because it will not work for non-legacy commodities added by other OXPs.

So here's my question:
Is there an example of the New updateLocalCommodityDefinition code, i.e. using the New trade-goods.plist values: price_average, price_economic and price_random?

I've read the trade-goods.plist page
http://wiki.alioth.net/index.php/Trade-goods.plist
and I understand the use of price_average and price_random values, but the documentation for price_economic is less clear:

price_economic

• The proportion of the price affected by the system economy.
  0 means that this good does not change in price depending on system economy.
  0.3 means that the good would be 0.7 times price_average in an ideal exporting system,
  and 1.3 times price_average in an ideal importing system.

Specifically, what is an 'ideal exporting system' and 'ideal exporting system' in the context of the calculation - how would you arrive at a multiplier to apply to price_economic based on the commodity/system/...?

I'm assuming this is all dealt with somewhere in the Oolite source code, and I'd be happy just to lift that bit of code, but I don't know how to get my hands on it.

This is my first post, so apologies if it's in the wrong place, or has already been dealt with - I've searched this forum for similar posts but I can only find this one:
viewtopic.php?f=4&t=3243&p=258017&hilit ... ic#p258017
which includes a question about how prices are calculated but that doesn't seem to have been answered.

Welcome aboard commander!

[edit]
OK, the Darkside Moonshine Distillery creates a brand new commodity and implements the updateGeneralCommodityDefinition at the station, so it might be worth a look. It's also a great station model.

 Fuel Tweaks OXP does a similar thing, in creating a new commodity. These might not answer your specific questions, but they might be a good starting point.

Hi Nick , thanks for the response.

It looks like your Fuel Tweaks code is the closest to a solution, certainly good enough to patch the In System Trader bug.

Trying to change the players lasers by script.

Lasers are an odd case for equipment in that they have a facing and so
player.ship.awardEquipment ("EQ_WEAPON_PULSE_LASER");
does not provide sufficient information (i.e. facing not specified).

So I tried to use
if (player.ship.aftWeapon === "EQ_WEAPON_PULSE_LASER") {player.ship.aftWeapon = "EQ_WEAPON_WLPULSE_LASER";}
but no luck.

Can anyone see what I 'm doing wrong?

Thanks in advance.


if(!worldScripts["new_lasers"])
{
var HiradLaser = EquipmentInfo.infoForKey("EQ_WEAPON_HIRAD_LASER");
var StarLaser = EquipmentInfo.infoForKey("EQ_WEAPON_STAR_LASER");
var EmilitaryLaser = EquipmentInfo.infoForKey("EQ_WEAPON_EMILITARY_LASER");
var AssaultLaser = EquipmentInfo.infoForKey("EQ_WEAPON_ASSAULT_LASER");
var BlastLaser = EquipmentInfo.infoForKey("EQ_WEAPON_BLAST_LASER");
log(this.name, "WEAPON-TEST-1a", this.ship.displayName, this.ship.forwardWeapon);

switch (this.ship.forwardWeapon)
{
case BlastLaser:
{
this.ship.forwardWeapon = "EQ_WEAPON_PULSE_LASER";
break;
}

....

This version is tested and works, I just pasted parts of the code so you can see how I solved this problem.

I'd check the condition script for the laser (if one is specified). My guess is that you've included rules that prohibit the laser from being installed in certain conditions. To ensure you can always install a piece of equipment via script, put this line at the beginning of the condition script, like this:

montana05 wrote: ↑Sun Jun 16, 2019 11:23 pm

This version is tested and works, I just pasted parts of the code so you can see how I solved this problem.

Thanks montana 05, I'll give that a try...

phkb wrote: ↑Sun Jun 16, 2019 11:43 pm

I'd check the condition script for the laser (if one is specified). My guess is that you've included rules that prohibit the laser from being installed in certain conditions.

Ah, you know me well
It shouldn't be that however as I did specify that the conditions only apply within the context of purchase and so scripting should be fine...
Nevertheless, I shall also give your suggestion a try and see if it makes any difference.
Thanks.

Redspear wrote: ↑Tue Jun 18, 2019 9:50 pm

montana05 wrote: ↑Sun Jun 16, 2019 11:23 pm

This version is tested and works, I just pasted parts of the code so you can see how I solved this problem.

Thanks montana 05, I'll give that a try...

I just recognized that my code could be a bit confusing. I am sure you figured it out yourself, the basic idea is that EquipmentInfo.infoForKey("your_weapon") could be compared with this.ship.forwardWeapon while (as I found out myself) your simple solution didn't work.

montana05 wrote: ↑Tue Jun 25, 2019 12:54 pm

I am sure you figured it out yourself...

Still not tried it TBH, just too busy lately.
Thanks for the clarification though.

Just out of curiosity...

When looking at the code of people who are smarter than I am, every now and then I see little things I don't quite understand.

For instance: [from oolite-trumbles-mission.js]

this.startUp = function startUp()

Why is it a good idea to name the function? Is it somehow necessary because the code is enclosed in a self-executing function?

Phasted wrote: ↑Thu Aug 08, 2019 1:03 pm

Why is it a good idea to name the function?

It helps with debugging, particularly if the function is a target for a timer. Without naming the function, if the timer is recycled while it's running, the only info you get in the log is "Anonymous function", and there's no way to know where the problem is. If the function is named, it becomes much clearer.

Does anyone know of a way to disable a turret on a ship? Other than removing it, I mean.

phkb wrote: ↑Mon Aug 12, 2019 7:45 am

Does anyone know of a way to disable a turret on a ship? Other than removing it, I mean.

Not sure if this help but I could remember that there was a Turret Toggler:

http://wiki.alioth.net/index.php/Turret_Toggler

http://bb.aegidian.org/viewtopic.php?f=4&t=13112

Yeah, those examples are of the "remove it then restore it" type. Removing it would make it actually disappear from the ship. I'm trying to find a simple way of keeping the subentity visible, but neutering it's firing mechanism. Thanks for point that OXP out though - I'd missed it in my searches.

phkb wrote: ↑Wed Aug 14, 2019 3:48 am

Yeah, those examples are of the "remove it then restore it" type. Removing it would make it actually disappear from the ship. I'm trying to find a simple way of keeping the subentity visible, but neutering it's firing mechanism. Thanks for point that OXP out though - I'd missed it in my searches.

I never tried before but I did some scripted texture changes. However, if there is a possibility to change

{
type = "ball_turret";
subentity_key = "GNSS-navy_adder_turret";
position = ( -6.0, 1.25, -20.5 );
orientation = ( 0, 0, 1, 0 );
}

to

{
type = "standard";
subentity_key = "GNSS-navy_adder_turret";
position = ( -6.0, 1.25, -20.5 );
orientation = ( 0, 0, 1, 0 );
}

the turret would be visible but not functioning