The Oolite Extended Project - Fork, no oxp

[Screet]

OK, let's use the following-to-download Scripts folder as the new template on which to work on?!:

2 days wasted. !@%$#%@۞

i would not trash what you did...simply try to use a program for highlighting the changes between these versions and look what you should add to your current WIP?

Screet

[pmw57]

OK, let's use the following-to-download Scripts folder as the new template on which to work on?!:

2 days wasted. !@%$#%@۞

i would not trash what you did...simply try to use a program for highlighting the changes between these versions and look what you should add to your current WIP?

Would that it were so simple.

Notepad++ has a very good diff plugin, but there's nothing that can be done when comparing script-wide changes.

Compare and contrast these two pieces of code:

Code: Select all

this.addBuoys = function()
{
    if(player.ship.hasEquipment("EQ_ROCKHERMIT_SCANNER")) this.buoy = "rockbeacon"; else this.buoy = "rockbeacof"
    var rockHermits = system.shipsWithPrimaryRole("rockhermit");
    var pirateCoves = system.shipsWithPrimaryRole("pirate-cove");
    {
        for (var i=0; i<rockHermits.length;i++)
        {
            if(rockHermits[i].name == "Rock Hermit")
            system.legacy_addShipsAtPrecisely(this.buoy, 1, "abs", rockHermits[i].position.add(rockHermits[i].heading.multiply(10E3)))
        }
        for (var i=0; i<pirateCoves.length;i++)
        {
            if(pirateCoves[i].name == "Rock Hermit")
            system.legacy_addShipsAtPrecisely(this.buoy, 1, "abs", pirateCoves[i].position.add(pirateCoves[i].heading.multiply(10E3)))
        }
    }
    this.buoysAdded = true
}

Code: Select all

this.addBuoys = function () {
	this.buoy = player.ship.hasEquipment("EQ_ROCKHERMIT_SCANNER") ? "rockbeacon" : "rockbeacof";
	function addIfRockHermit(ships) {
		var i;
		for (i = 0; i < ships.length; i += 1) {
			if (ships[i].name === "Rock Hermit") {
				system.legacy_addShipsAtPrecisely(this.buoy, 1, "abs", ships[i].position.add(ships[i].heading.multiply(10E3)));
			}
		}
	}
	addIfRockHermit(system.shipsWithPrimaryRole("rockhermit"));
	addIfRockHermit(system.shipsWithPrimaryRole("pirate-cove"));
	this.buoysAdded = true;
};

One of these has a wide variety of problems due to how they have bee coded, and makes a large number of unproven assumptions.

Thankfully, using something like JSLint.com and having Douglas Crockford hovering over yours shoulder, helps to ensure that best practices are met.

At best I could compare the upadated code from Lestradae with the official release, and based on those differences go back to WIP and double check things from there.

[Commander McLane]

Hi pmw57,

the new scripts give me quite some of these here, multiple of them:

[script.javaScript.warning.undefinedProp]: ----- JavaScript warning ("PlanetFall" 1.2): reference to undefined property this.rangeCheckTimer
[script.javaScript.warning.undefinedProp]: ../AddOns/A - OSE Main Data WiP V0.70.14.oxp/Scripts/PlanetFall.js, line 496.
[script.javaScript.exception.noProperties]: ***** JavaScript exception ("PlanetFall" 1.2): TypeError: this.rangeCheckTimer has no properties
[script.javaScript.exception.noProperties]: ../AddOns/A - OSE Main Data WiP V0.70.14.oxp/Scripts/PlanetFall.js, line 496.

Other than that, the V0.7 with that (pmw57's) script patch has reduced the crashes massively. Had one, while docked at the main station and saving

/report

L

Thanks, that looks to be legacy code at work. Here is the code that is related to rangeCheckTimer. Unrelated code has been stripped out, for the sake of simplification.

Code: Select all

this.shipExitedWitchspace = function () {
	this.rangeCheckTimer.start();
};
this.shipLaunchedFromStation = function () {
	if (this.rangeCheckTimer) {
		this.rangeCheckTimer.start();
	} else {
		this.rangeCheckTimer = new Timer(this, this.planetScan, 0, 15);
	}
};
this.shipExitedPlanetaryVicinity = function () {
	this.planetScan();
	this.rangeCheckTimer.start();
};
this.shipWillDockWithStation = function (station) {
	this.rangeCheckTimer.stop();         // Line 496
};
// My added code is here
this.playerWillEnterWitchspace = function () {
	if (this.landingTimer) {
		this.landingTimer.stop();
		delete this.landingTimer;
	}
	if (this.rangeCheckTimer) {
		this.rangeCheckTimer.stop();
		delete this.rangeCheckTimer;
	}
};

Does anyone else see the problem? How about when you hyperspace in to a system and then dock - a timer no longer exists.

I reckon that the following needs to be added to the shipExitedWitchspace event, so that if a timer doesn't exist, one is created at that time.

Code: Select all

	if (this.rangeCheckTimer) {
		this.rangeCheckTimer.start();
	} else {
		this.rangeCheckTimer = new Timer(this, this.planetScan, 0, 15);
	}

I don't know if you're still interested in knowing what's going on here? I just reply in case you are.

(1) There is no legacy code at work here at all. Everything is JavaScript.

(2) Your code is explicitely deleting rangeCheckTimer whenever the player enters witchspace. Therefore, after arriving in the next system, the timer doesn't exist anymore. And of course you will get an error message about the timer not existing. You have deleted it.

(3) The code doesn't make sense anyway, and I am surprised that it actually works. this.playerWillEnterWitchspace is an event handler exclusively for ship scripts. It doesn't make any sense in a world script. And the only case in which you need to delete a timer, if the player leaves the system, is for timers inside ship scripts. However, Planetfall.js is not a ship script. It is a world script. So you just have to completely delete your addition, and everything will be fine.

[Screet]

I think this fixes the problem with drones_Pickup.js:

Code: Select all

	var master = this.ship.master;
    function isHostileToMaster(entity) 
    { 
        return (entity.isShip && entity.target && entity.target == master && entity.hasHostileTarget);
    }

Previously it was using this.ship.master inside of isHostileToMaster which is not accessible there and flooding the log with error messages. I did not get the message afterwards, yet I'm not experienced enough to actually know if this is the way it should be fixed. Can anyone confirm this?

Screet

[Thargoid]

(3) The code doesn't make sense anyway, and I am surprised that it actually works. this.playerWillEnterWitchspace is an event handler exclusively for ship scripts. It doesn't make any sense in a world script. And the only case in which you need to delete a timer, if the player leaves the system, is for timers inside ship scripts. However, Planetfall.js is not a ship script. It is a world script. So you just have to completely delete your addition, and everything will be fine.

I think you're mixing up this.shipWillEnterWitchspace (which is a ship script event) with this.playerWillEnterWitchspace, which is a worldscript one (and useful for stopping timers and such, or other stuff that may no longer be needed). They are two distinct commands.

That said I would agree that having everything listed on the wiki page for world script events doesn't make the ship/world script distinction any clearer.

And if it's not an out-of-place question, why is Planetfall being included in OSE anyway? I thought OSE was about ships and equipment, not such functionality?

[Thargoid]

I think this fixes the problem with drones_Pickup.js:

Code: Select all

	var master = this.ship.master;
    function isHostileToMaster(entity) 
    { 
        return (entity.isShip && entity.target && entity.target == master && entity.hasHostileTarget);
    }

Previously it was using this.ship.master inside of isHostileToMaster which is not accessible there and flooding the log with error messages. I did not get the message afterwards, yet I'm not experienced enough to actually know if this is the way it should be fixed. Can anyone confirm this?

Screet

Let me first double-check if the original version still works, or if the oolite updates since I wrote it have broken something inside it. I did notice last night a log error or two relating to that script, so it might be that the code needs an update overall.

[Lestradae]

And if it's not an out-of-place question, why is Planetfall being included in OSE anyway? I thought OSE was about ships and equipment, not such functionality?

As you said, OSE is about ships and equipment. And while there are sorts of equipment I do not make generally buyable in OSE (like a certain UPS scanner, or the mission rewards of Aquatics, the damage control node of the Caduceus etc.) because they are atmospheric quite the way they are, it irked me a bit that two equipment oxps were not yet in OSE - the salvage option from Dredgers and the planetfall equipment from, well, planetfall.

While on holiday, on a boring afternoon, I took the time, dared the heightened complexity of the task and included these two options with all their dependent stuff from third-party oxps. I hope no toes were being tread on, especially as you, when creating planetfall, suggested I include it into then-fledgling OSE

In the meantime, Screet and pmw57 are reworking all the java scripts due to a recently discovered problem with timers on windows systems. They can, for various reasons as far as I am told, including one caused by a "security feature" of Microshaft, crash the game without a trace in the log. I am told one of these scripts is planetfall.

Feel free to have a look at their work, downloads leading up to the most recent are strewn all over this thread. If you think something or all of what they have done to your script(s) is useful to you, obviously use it for the originals too! (what with all of this being creative commons plus you are cordially invited anyways )

My game has become massively more stable with these new scripts, and this is not "another RS/OSE problem", I might add. These are game-crashing problems originating in the original oxps! It simply happens more often in OSE because there is much more stuff assembled in there, and the statistical chance something goes wrong is much higher ...

Cheers

L

PS: @pmw57:

OK, let's use the following-to-download Scripts folder as the new template on which to work on?!:

2 days wasted. !@%$#%@۞

Huh I hope not?

That's why I asked Screet and yourself to somewhat synchronise, when I started to get updates from both of you for tens of scripts at a time, them altered in different ways.

I think it's really important that that happens still, I don't have the kind of java script capacity to do it myself (and, sorry everyone, not investing six months of my life to learn them ), in other words, before someone gives up on this due to frustration we better find a way to include both of your excellent inputs into this.

[Thargoid]

While on holiday, on a boring afternoon, I took the time, dared the heightened complexity of the task and included these two options with all their dependent stuff from third-party oxps. I hope no toes were being tread on, especially as you, when creating planetfall, suggested I include it into then-fledgling OSE

In the meantime, Screet and pmw57 are reworking all the java scripts due to a recently discovered problem with timers on windows systems. They can, for various reasons as far as I am told, including one caused by a "security feature" of Microshaft, crash the game without a trace in the log. I am told one of these scripts is planetfall.

I don't have a problem with it, I was just surprised as you told me you weren't going to include it when we discussed it before.

It would also be nice to be informed about re-worked scripts (both PF and Drones, from the above posts) so I can give input and clarify things, or at the very least identify and replicate the problems and solutions into the stand-alone original OXPs. I don't want to end up with different script versions in OSE and OXP, or else we're going to get in a huge muddle of bug reports etc.

[Screet]

It would also be nice to be informed about re-worked scripts (both PF and Drones, from the above posts) so I can give input and clarify things, or at the very least identify and replicate the problems and solutions into the stand-alone original OXPs. I don't want to end up with different script versions in OSE and OXP, or else we're going to get in a huge muddle of bug reports etc.

I also do not want some chaos there...I just did write the message to ask for further insight into the problem and as it's more likely to appear with OSE in, I asked here (wouldn't even know another appropriate thread).

Concerning "CombatComputers5.js" I've got a suggestion:

Code: Select all

    if(player.ship.hasEquipment("EQ_COMBAT_COMP") && player.ship.hasEquipment("EQ_ECM"))

Previously it did not check for a working ECM system, thus it could cause log errors about trying to enable ECM while it's gone or damaged. Furthermore it's not making any sense to write a screen message that ECM has been enabled when it was not

Screet

[Kaks]

Hmm, hasEquipment('EQ_ECM') should still return true even if the ECM is damaged...

[Lestradae]

@Thargoid:

It would also be nice to be informed about re-worked scripts (both PF and Drones, from the above posts) so I can give input and clarify things, or at the very least identify and replicate the problems and solutions into the stand-alone original OXPs. I don't want to end up with different script versions in OSE and OXP, or else we're going to get in a huge muddle of bug reports etc.

You got quite a big point there. Maybe I still have to get my head around OSE becoming more of a team effort, not exclusively "my baby", and comparing script versions might be part of that. I will think about it, at the moment I suggest everyone compare their script versions, the original, pmw57's and Screet's?

This thread here would be the logical place to do it imo.

@Screet:

Please, really you and pmw57 should exchange versions. Perhaps you can compare them if pmw57's editor is not so well suited for that task? We can find out which scripts we have altered, and I would inform the original oxp'ers about the changes.

@pmw57:

Perhaps you could post your two day's work here for download? Then everything can be compared and your work need not be lost!



L

[Screet]

Hmm, hasEquipment('EQ_ECM') should still return true even if the ECM is damaged...

IEK...then I know quite some scripts which will (attempt to) work with damaged eq.

Thus it's necessary to also make a call for equipment status? If so...how about some oolite method for JS to call for WORKING equipment in one call?

I did not really expect that EQ_ECM_DAMAGED would qualify as EQ_ECM as I've seen other equipment simply being removed from my ship after loading, apparantly because a required part of eq was damaged. That would even indicate that this is not handled consistently within oolite itself...or I might have overlooked something else?

Anyway, I think that eq loss because of a damaged part in the requirements list is a bad choice. It simply should stop working until that part is repaired, not be lost.

Screet

[Eric Walch]

Hmm, hasEquipment('EQ_ECM') should still return true even if the ECM is damaged...

That would be very non practical and break all released scripts. And you can argue of cause if broken equipment is still that equipment. Because, when my coffee machine is broken it has the same functionality as a broken cd-player. Both do nothing.

But I just tested with the console: broken equipment returns false.

Code: Select all

> player.ship.hasEquipment('EQ_ECM')
true
> player.ship.setEquipmentStatus('EQ_ECM', "EQUIPMENT_DAMAGED")
Damaged: EQ_ECM With name: E.C.M. System
true
> player.ship.hasEquipment('EQ_ECM')
false
> player.ship.hasEquipment('EQ_ECM_DAMAGED')
true

[pmw57]

@pmw57:
Perhaps you could post your two day's work here for download? Then everything can be compared and your work need not be lost!

12 hours ago I was moving forward from Screets work.

What I will do tomorrow is to compare Lestradae's recently uploaded code with Screets. Any differences between them will be incorporated/ignored/queried/thrown to the winds, and I will upload the updated timer-related scripts tomorrow, before continuing on with the rest of the scripts.

The aim - solid coding practices using proven techniques.
The method - to bring scripts up to a minimum standard using www.jslint.com The parameters, enable "The Good Parts" and disable the "use strict" header.

I am also aware of other sites like javascriptlint.com as well, but that lets anything pass and what's the point of that! jslint.com provides a much stronger improvement to your code, but it will hurt your feelings, so toughen up coders!

[Thargoid]

Agreed. Having EQ_<whatever> and EQ_<whatever>_DAMAGED works fine.

I would have to slightly ironically here request that something that isn't broken doesn't get fixed...