Oolite Bulletins

Oolite Shipyards Extension V0.7 is ready for download & testing.

Changes since V0.69 include:

Buggy behaviours fixed:
* Repaired nukeSubMunition.js, line 16.
* Fixed a double typo for buzzer-base shipdata entry
* Added a "traderAI" for the Griffin2
* Removed an OSE-deprecated player Condor version
* Applied Ramirez' suggested fixes to OSE's law and override missiles
* Removed yet another potential NEU bug from OSE equipment.plist
* Altered a potentially buggy line in the fuel collector script according to suggestions of Cmd. Cheyd & Kaks
* Exchanged an old behemoth java script with the new one created by Eric
* Fixed a bug by creating a shuttleAI for the Lambda Shuttle
* Repaired a bug concerning OSE's player escorts that allowed them being offered again after they were already hired
* Fixed a bug-creating typo in OSEhiredGuns_escort.js
* Removed the option to sell the Large Cargo Bay
* Upgraded aegidian's Asp Mk II Special with Kaks' new model and texture
* Applied Screet's stack overflow fixed to the law missile and override scripts and another fix to the fuel collector script
* Removed doubled Eric's Harpoon Torpedoes, now only new versions available
* Upgraded the OSE-merged neocaduceus oxp to version 11-10-2009
* Corrected a stupid infinite-money cheat bug when selling the Misjump Analyser
* Big shipyard bug found by Screet that made some ships appear as "0 Cr" and selling of equipment impossible repaired

Additional materials included:
* Included the griff_python_normalmapped ship
* Included Griff's Coriolis (now Griff's normalmapped ship's oxp is completely merged)
* Updated the Ore Processor to the newest version available on 11-10-2009
* Included the following eight oxps (which contain the last two equipment oxps not merged - dredgers and planetfall - and the oxps they are dependent upon): Dredgers 2.2.5, Oo-Haul, PlanetFall 1.23, PlanetFall Link - Black Monks 1.0, PlanetFall Mission - Oo-Haul 1.0.0, Planetfall Mission - Taxi 1.0.1, PlanetFall Link - hOopy Casino 1.0 & Shady_blackmonks
* Updated the Orisis oxp to version 1.2

New features:
* Added the special OSE equipment to the repair options of the repair bots script
* Changed the SIRFYards half-docked "repaired ships" into Griff and Simon versions
* Landing on planets
* Salvage wrecked ships
* Replaced the older version with Screet's more agressive take on the pirateCoveAI

Miscallenous:
* Took out the wreck-creation for Dredgers 2.2.2 as Oolite 1.73+ does that on its own
* Partially replaced the legacy OSE-XML.plist script with pmw57's OSE.js java script translation
* Did a missiles rework - specific missiles-per-ship are used much more sparingly

There follows a list of new oxps that were merged into OSE since V0.69. I am quite sorry to say that these oxps are incompatible with OSE and it is an either-or decision: Either you use the original oxps without OSE or OSE without these oxps. I want to add that there is no 'ideological' reason for that but simply the technical fact that the old "overwrite" strategy of the XML/OpenStep past no longer works with java scripts as far as I know/have experienced - so sadly, what I originally had in mind (total combinability) won't work

Dredgers 2.2.2, Oo-Haul, PlanetFall 1.23, PlanetFall Link - Black Monks 1.0, PlanetFall Link - hOopy Casino 1.0, PlanetFall Mission - Oo-Haul 1.0.0, Planetfall Mission - Taxi 1.0.1 & shady_black_monks

New OSE WiP V0.7 download:

Oolite version "1.73.4" is nescessary for playtesting this WiP, it simply won't run correctly with any lower versions!

Oolite Shipyards Extension WiP V0.7: http://www.box.net/shared/static/306vnoxkt8.zip
(The actual Test WiP - warning, download size is ~ 383 MB)
Open the folder. Put all three oxps inside into your AddOns folder together. They are three oxps because they are parcelled into pieces I am working upon. Together, they form the OSE WiP meta-oxp.

Hope to get the sort of feedback I am asking for, it is of interest to anyone who likes this meta-oxp and wants to play a finished version one day that I do.

Cheers

L

PS: IMPORTANT INFO FOR WINDOWS USERS (NOT ONLY OSE USERS, THIS IS A GENERAL VISTA PROBLEM!):

Computer>Properties> new window called
System Properties
Advanced>Performance settings>new window called
Performance Options
data execution prevention

tick oolite.exe

No other oolite files need to be ticked.

... DO THE ABOVE TO PREVENT REGULAR CRASHES DUE TO WINDOWS 'SECURITY FEATURES'

downloading and will test it out,

matthewfarmery wrote:

downloading and will test it out,

IMPORTANT:
If you are using Windows, please ensure that Data Execution Prevention is turned OFF for Oolite (or in general).

This is not an issue of OSE, but of several OXPs - it can arise with all shipscripts that use timers.

Screet

Screet wrote:

matthewfarmery wrote:

downloading and will test it out,

IMPORTANT:
If you are using Windows, please ensure that Data Execution Prevention is turned OFF for Oolite (or in general).

This is not an issue of OSE, but of several OXPs - it can arise with all shipscripts that use timers.

Screet[/b]

Dur... is that a Control panel setting, or in the BIOS?

pmw57 wrote:

Screet wrote:

IMPORTANT:
If you are using Windows, please ensure that Data Execution Prevention is turned OFF for Oolite (or in general).

This is not an issue of OSE, but of several OXPs - it can arise with all shipscripts that use timers.

Dur... is that a Control panel setting, or in the BIOS?

L just did update the message while I was adding mine

It's a bit hidden...please follow the steps that L did add to the message with the download link.

Would I have known this a year ago, it would have spared me from oh-so-much frustration including playing without RS/OSE for quite some time and spending hours of bughunting...

Screet

turned it off for Oolite, thanks for the warning,

Screet wrote:

It's a bit hidden...please follow the steps that L did add to the message with the download link.

Would I have known this a year ago, it would have spared me from oh-so-much frustration including playing without RS/OSE for quite some time and spending hours of bughunting...

Cheers.

Is it not normally a bad thing for executable code to be stored in a data area?

Perchance, would this be a bug, that doesn't exist yet because a bug report for it has not been written?

pmw57 wrote:

Is it not normally a bad thing for executable code to be stored in a data area?

Perchance, would this be a bug, that doesn't exist yet because a bug report for it has not been written?

As of today, there's a bug report in the test part of the forum.

It's a problem since a ship that has a scripted timer may be destroyed or removed once the player jumps or reloads. The js timer still is active then and will operate on parts of code that are no longer valid. Somehow it's not causing a crash if DEP turned off, but as the bug seems to come from some underlying lib and not oolite itself, windows does not even notice. Oolite would simply close without any hint at what went wrong (typically windows would open an alert box that the program tried to execute data and offer to disable DEP). It may result in logged messages hinting at the problem IF DEP is switched off, but with DEP on, the crash occurs too early to log that info.

Screet

also this post here will tell you

http://www.tech-recipes.com/rx/566/xp-s ... ature-dep/

then again, I did have problems with DEP when I was using a processor that didn't support hardware DEP, so it was running in software mode, and that gave me loads of DEP related crashes, since I upgraded to a CPU (Intel Q6600) which supports hardware DEP, I generally haven't had an issue what so ever, but I have turned it off as I said for Oolite, just need to reboot, however I will test OSE later, for now Im helping another company beta test one of their new products, but later on today I will be back and will test out OSE

I suggest filing a bug report on BERLIOS, or is that what you did anyways?

Screet wrote:

As of today, there's a bug report in the test part of the forum.

It's a problem since a ship that has a scripted timer may be destroyed or removed once the player jumps or reloads. The js timer still is active then and will operate on parts of code that are no longer valid. Somehow it's not causing a crash if DEP turned off, but as the bug seems to come from some underlying lib and not oolite itself, windows does not even notice. Oolite would simply close without any hint at what went wrong (typically windows would open an alert box that the program tried to execute data and offer to disable DEP). It may result in logged messages hinting at the problem IF DEP is switched off, but with DEP on, the crash occurs too early to log that info.

I know that I'm preaching to the choir here, but this issue is something that is a potential showstopper. This may be due to my support of computer users in general, but 80% of the potential Windows audience wouldn't know the first thing about changing data execution settings for their computer, and a few more just simply won't out of security concerns.

Let's do what we can to help this get fixed as quickly as possible.

Well, the only thing we could do would be to take the offending timer out of the two scripts in OSE Screet found - the buzzer and the behemoth one.

Screet, are you sure these two are the only ones that can - unintendedly use this Windows §"%$§&§& feature?

Lestradae wrote:

Well, the only thing we could do would be to take the offending timer out of the two scripts in OSE Screet found - the buzzer and the behemoth one.

Screet, are you sure these two are the only ones that can - unintendedly use this Windows §"%$§&§& feature?

I did make a find in files for timer and then tried to locate all scripts which were used as ship script instead of global script. Those are the ones I came up with.

An additional instance (probably harmless due to a slightly different timer usage) is in military fiasco when shooting-off the subentities of certain ships.

As for know, I suggest to leave the timers in, but try to make them as safe as possible (eric had some idea, but it looks like it's impossible for ship scripts to cover all situations that could cause a problem).

Screet

Lestradae wrote:

Well, the only thing we could do would be to take the offending timer out of the two scripts in OSE Screet found - the buzzer and the behemoth one.

When the player exits the system, does the shipDied event get called for the NPC ships? If so then that is the perfect place to stop the timer and prevent further issues.

pmw57 wrote:

When the player exits the system, does the shipDied event get called for the NPC ships? If so then that is the perfect place to stop the timer and prevent further issues.

If not, then perhaps a shipCleanup method or some-such similar method is justified.