Save Any Where OXP Version 3.2 [RELEASE]

[lave]

I for one am looking forward to a release.
Thanks.

[Switeck]

line 884 if(guiScreen !== "GUI_SCREEN_STATUS")//CommonSenseOTB bug found deprecated !=

Just for the sake of writing OXPs, I don't fully understand the difference between != and !== or even == and === in an if statement.
You have a good link to explain what makes them tick?

[Dragonfire]

No link, but I know that for Python (so, similar syntax, I assume), "=" sets a variable, while "==" compares a variable. "!=" means "does not equal".

But, it could be different for openstep, so don't quote me.

[Lone_Wolf]

line 884 if(guiScreen !== "GUI_SCREEN_STATUS")//CommonSenseOTB bug found deprecated !=

Just for the sake of writing OXPs, I don't fully understand the difference between != and !== or even == and === in an if statement.
You have a good link to explain what makes them tick?

try this one :
JavaScript Comparison and Logical Operators

[CommonSenseOTB]

line 884 if(guiScreen !== "GUI_SCREEN_STATUS")//CommonSenseOTB bug found deprecated !=

Just for the sake of writing OXPs, I don't fully understand the difference between != and !== or even == and === in an if statement.
You have a good link to explain what makes them tick?

Hi Switek.

To find the bugs I needed to see what the changes were from 1.74.2 to 1.75.

I looked in the Changelog that comes with oolite and found under 1.75 under javascript changes the following:

Vector3D and Quaternion objects can no longer be compared using == and !=,
because the wart in the JavaScript engine we were previously exploiting no
longer exists. See https://bb.oolite.space/viewtopic.php?f=4&t=8847 for
more information.

In that post there is a link to this website that explains it.

http://www.webreference.com/js/tips/991205.html

Sometimes it is not required to understand the changes, but simply to know what they are and apply them. Basically we were using sloppy programming and that will no longer work as of 1.75. Best to use !==(not exactly equal) and ===(exactly equal) as "3" == 3 is true but "3" === 3 is false. See the difference? For a lot of comparisons == works just fine but for how long? and != can give the wrong answer so shouldn't be used and the "wart" that allowed us to be sloppy is no longer there so you might not get the same answer from the same equation as of 1.75.

I hope that helps Switek. It helped me understand what to look for in an oxp that became broken as of 1.75.

[JensAyton]

Erm, that link very explicitly applies only to Quaternion and Vector3D objects. == and != are not deprecated for strings, and === and !== are no use for Quaternions and Vector3Ds either.

For a lot of comparisons == works just fine but for how long?

Forever. The problem was highly specific.

[Switeck]

This did get me looking at my old OXP code again. In Misjump Inducer OXP, I could've accidentally done this:

Code: Select all

		if(player.ship.scriptedMisjump === "TRUE") {
			player.ship.scriptedMisjump = false;
			player.commsMessage("Misjumping Disabled.",6);
		} else {
			player.ship.scriptedMisjump = true;

Does true with no quotes exactly equal (both value and type) "TRUE" as a string? I'm not convinced it is...or should be. Fortunately, that's not what I used.

I also work with a lot of math in some of my unreleased OXPs...related to this:
https://bb.oolite.space/viewtopic.php?f=2&t=9729
(It's too complex and crash-happy to release ANY of it, not to mention it's currently only a hack-job cheat I use for testing. That it also mostly duplicates parts of Okti's LongRangeScanner OXP gives me even less incentive to release it.)
But in it, I alternate from dealing with probable integers to definite floating point numbers. It would be a pain if an integer 4 isn't exactly equal to a floating point 4.0000 and that's a minefield I was sure to run into had you not helped me out some here.

[JensAyton]

Does true with no quotes exactly equal (both value and type) "TRUE" as a string?

No. The boolean values, true and false, are distinct values of a particular type, boolean.

In any case, the proper test here is if (player.ship.scriptedMisjump). Comparing against either boolean value, but especially true, is almost never the right thing. It makes your code noisier and more fragile.

[Switeck]

Looks like both my Auto ECM OXP and Misjump Inducer OXP are in need of updates to make them less fragile then.
I'd previously mistaken a statement like this:
if (player.ship.scriptedMisjump)
to ONLY mean "if this exists" (is not null). Ah well, live and learn.

[JensAyton]

The actual rule is that the following values are treated as false:

• false
• 0
• -0
• NaN (“not a number”, a numerical value for certain invalid operations like Math.asin(2))
• The empty string
• null
• undefined

[CommonSenseOTB]

Edited: Irrelevant post as math discusion has ceased.


I'm glad I could help you Switek.

A little heads up to Save Anywhere users who used my bugfix to upgrade their copy. I found a very isolated behaviour in custom views when loading a saveanywhere savegame. This is specific to a method I'm using to keep huds synchronized with the correct zoom views in my Sniper Camera System.oxp and as no other oxp uses this method you need not worry about it and I have a workaround for it anyway.

Be on the lookout for any other strange behaviour as everything released in the last 6 months hasn't had to pass testing with this oxp installed. I don't anticipate any real problems but developers should test their stuff that it is ok after reloading a save anywhere saved game and anyone who finds some kind of weird behaviour after reloading a saved saveanywhere game should report it here.

We're six months behind so this is to be expected.

[Dragonfire]

Somehow not able to figure out...has this been released yet in the fixed version? The wiki still lists it as broken.

[maik]

Somehow not able to figure out...has this been released yet in the fixed version? The wiki still lists it as broken.

The fix hasn't been included in the released version. However, I added a link to this discussion to its wiki page and moved its entry from the broken to the normal section of the [wiki]OXP List[/wiki], marking it as N* (broken but fix exists). Does this make sense?

[DaddyHoggy]

Makes sense to me - and the link to the fix is good - because I lost it!

[maik]

Found it in CommonSenseOTB's User page on the wiki, escaped my attention before...