Missile Countermeasures OXP (v 0.2)

[Screet]

Hi,

if anyone is tired of missiles and doesn't like to use the MASC or wants more security for moments when the MASC won't help, try this toy! It's also much more fun than using the MASC

It's basically an advancement to the Chaff Launcher by Ramirez and the Anti Missile System by Thargoid. As a result, it's not compatible with existing AMS on your ship as both would activate together, but the oxp itself is compatible to AMS.

Please test it and let me know of any problems!

http://www.box.net/shared/91dchnlecf
EDIT: updated link to v.0.2

It's a first test version, but the testers so far have reported no problems.

Version 0.2 now should access equipment price factor on oolite nightly builds. There was accidentally still some dependency on another oxp and I also did add auto-ECM for standard missiles and slightly reduced the dart price.

Screet

[Screet]

Since editing the entry didn't push the thread up, I'm doing it this way now. Most of the initial downloaders haven't switched to the new version and I guess it's simply been missed.

You really should update to version 0.2! Otherwise you may suffer massively reduced efficiency of the MCM system...

Screet

[Greyman]

Well, thank you.

Sounds interesting and so I'm already downloading to try this baby

[Greyman]

I guess I found a small bug. So here's the feedback:

When buying a Chaff refill at a station I end up with a huge number of credits.

I have 71.700Cr and buy Chaff refill for 3.000Cr and end up with 4.294.966.729Cr!

Otherwise, I like the idea of this piece of equipment. I also think the pricing is adequate (as long as your Credits aren't multiplied by refilling).

[Screet]

Otherwise, I like the idea of this piece of equipment. I also think the pricing is adequate (as long as your Credits aren't multiplied by refilling).

Uhh...sounds like trouble with an older version of oolite delivering a wrong value - I wrote code to check for a proper oolite version in order to apply equipment price factor, but it seems it's not working as intended.

In mcm_system.js there are two lines like this:

Code: Select all

			priceFactor = player.ship.dockedStation.equipmentPriceFactor;

If you comment them out or cut them, it should always use a price factor of 1 - that might still charge you a slightly wrong amount for stations with non-standard price factor, but not do such harm to your balance.

Which version of oolite are you running?

Hmmm. Just thinking...I didn't check for values of

Code: Select all

	<key>mission_mcm_chaff_count</key>
	<key>mission_mcm_dart_count</key>

in the save file as buying the equipment would initialize them. Maybe you also want to verify that they are greater or equal to 0 - guess I'll simply add that to the next version in case someone has faulty variables due to editing or something like that.

Screet

[Greyman]

Hello,

thanks for the advice! I changed the script as proposed and it works like a charm.

I'm using Oolite version 1.73.4 and while checking the save file i found the following:

Code: Select all

<key>mission_mcm_chaff_count</key>
<string>23</string>
<key>mission_mcm_dart_count</key>
<string>6</string>

So both keys seem to be of positive value. Even though I don't understand why they are strings and not integers.


Greyman

[Eric Walch]

So both keys seem to be of positive value. Even though I don't understand why they are strings and not integers.

They must be correct as the code is:

Code: Select all

	player.credits += (priceFactor * 12000/6)*missionVariables.mcm_dart_count;
	missionVariables.mcm_dart_count = 6;

It must have been undefined when increasing the credits, but was defined in the next line.

On the second question: missionVariable are always stored as strings. That way it can contain everything.

[Greyman]

Thank you for the explanation. I am not much of a programmer but it seemed odd to me to have number values stored as strings and then used as a multiplication factor without any conversion.

[JensAyton]

Mission variables are always stored as strings because the legacy scripting mechanism only supports string variables (although it can do arithmetic on strings containing numerical values). This isn’t especially unusual for high-level scripting languages.

For JavaScript, mission variables with a purely numeric values are converted to numbers when retrieved, and setting a mission variable to a number converts it to a string behind the scenes; in other words, mission variables can be numbers or strings in the JavaScript programming interface but are always strings internally and in saved games. Changing this (at least in the saved games) would break backwards-compatibility.

[Greyman]

And I guess I could have learned this by reading the wiki (which I'm actually too lazy to do ).

Thanks for the patience and the explanations!