Oolite Bulletins

Posted: **Mon Mar 10, 2008 4:47 pm**

Great job on squashing the killer edible asteroids, Kaks.

New version available here:

Ore Processor 1.51

Ore Processor equipment for Giles William's Oolite

The Ore Processor costs 1500 Cr and can be found at shipyards of tech level 12 or higher.

It attaches to the fuel scoop and instantly extracts valuable materials from mined asteroid splinters.

Thanks to Little Bear, Cmdr Wyvern, Griff and DaddyHoggy for creative input and bugsquashing.

Special Thanks to Ark for updating this OXP to v.1.5 and to Kaks for finally ironing out the terrible edible killer asteroid bug by making the Ore Processor work differently in different versions of Oolite

v.1.51

Update by Kaks:
- The Ore Processer now works differently with Oolite 1.65 and Oolite 1.70 up. Gem stones only available in 1.70 up to stop splinters from awarding food.

v.1.5

- Price has been increased

update by Ark:
- Scripted messages tell the player what material has been extracted.
- The Ore Processor can now extract gem stones
- code has been optimized

v.1.03

No more rock candy. Seriously

v.1.02

Edible asteroids have been removed )

Posted: **Mon Mar 10, 2008 10:11 pm**

Downloaded version 1.51 of ore-processor. From the file I learn there is a bugs in awarding gems on windows. it's the first time I hear of a difference between the operating systems on scripting level.

In UPS I used a lot of award gems to pay for missions. It always worked on my mac. In 1.55 and up to 1.70 I had never problems with it. Yesterday I heard from Ark that on windows you always get food in this case. Strange bug, that is fixed in 1.70 I understood.

I double checked with ore processor 1.50. I gave the gem splinters a scanclass "class_cargo" and a role "gemsplinter". This way I could add them with a script and scoop them. I did get gems. (not food)

However there is a syntactic bug in the plist script that was added. The legacy one is not opened with my plist editor, meaning that Mac-Oolite is also not opening it. It would be genius when you could make the oxp so that this resulted in that the gems were still added on mac systems.

Now it is for Mac users better to use the 1.50 version were the gems are also added in pre 1.70 versions.

Posted: **Mon Mar 10, 2008 11:13 pm**

Thank you Eric!
Obviously, I didn't check it as thoroughly as I thought.... It didn't give me any errors with -verify-oxp, & I stupidly assumed everything would be ok...

This is what script.plist should have been:

Code: Select all

{
	OreProcessorGems = (
		{
			conditions=("mission_ore_processor_extractgems greaterthan 0"); 
			do = ("set: mission_ore_processor_extractgems 0"); 
		}
	);
}

Luckily that plist script was intended only as an insurance policy. Its only function was to make sure a save game from 1.70 won't create edible asteroids on pre-1.70 pc Oolite.

If you weren't importing 1.70 save games on older versions of Oolite, 1.51 would do the right thing anyway.

Intriguing about that mac-pc difference. It's even more amazing that there's just a handful of differences between such different platforms!

Posted: **Tue Mar 11, 2008 8:00 am**

To make myself clear it was only an assumption that this bug occurs only in windows.
An assumption I cannot 100% confirm, since I do not have a Mac. If anybody from the community has a PC and also a Mac (and the time and will to dig deeper in this exotic bug) it is easy to confirm that.
Just end the build-in nova mission or try ore processor 1.5 in both platforms. In the PC version of 1.65 I get food instead of gems!

Posted: **Tue Mar 11, 2008 10:54 am**

Ark wrote:
To make myself clear it was only an assumption that this bug occurs only in windows.
An assumption I cannot 100% confirm, since I do not have a Mac. .....

The nova mission was developed on a mac. Giles who made it would have noticed it then. He didn't so I am sure it always worked on a mac. For linux I don't know. Gemstones have a hyphen in their name. For some reason this must be the course of the difference. Maybe in the windows version this character is compiled with an other ascii symbol. Just guessing.

Kaks wrote:
Luckily that plist script was intended only as an insurance policy. Its only function was to make sure a save game from 1.70 won't create edible asteroids on pre-1.70 pc Oolite.

This bug won't be a trouble on a mac as you say because the gemstones never bugged on a mac. And when you one run the oxp under 1.70, you will get the splinters on a mac because a mac is not loading the script to undo this under 1.65

Posted: **Tue Mar 11, 2008 1:46 pm**

I am pretty sure that I did get the Nova-gems at the time on my Mac. So it may indeed be platform-specific.

Posted: **Tue Mar 11, 2008 3:43 pm**

Does anybody with a pc (apart from me) can confirm that by finishing the nova mission in 1.65 you get food instead of gems?

Posted: **Tue Mar 11, 2008 3:49 pm**

I think it happened to me also when playing on 1.65. But I never paid any particular attention to it, I thought it was like this by design. Will test again at first opportunity just to be sure.

Edit: Yep, confirmed. 35t of food in the cargo hold after completion of the Nova mission on 1.65 Windows.

Posted: **Tue Mar 11, 2008 4:20 pm**

on the pc playing 1.691 (I think) I'm pretty sure i got gems.

Posted: **Tue Mar 11, 2008 10:44 pm**

Eric Walch wrote:
For some reason this must be the course of the difference. Maybe in the windows version this character is compiled with an other ascii symbol. Just guessing.

The way I understand it, it seems to be a difference in the way the '-' character is handled. The GNUstep libraries would treat '-' as a word separator - like commas and spaces - while the original mac libraries consider it part of the word itself.

I'm fairly sure linux players would get food instead of gems at the end of the nova mission in 1.65...

Posted: **Sat Mar 15, 2008 12:31 pm**

Finally got around to upload v.1.52

v.1.52

Update by Kaks:
- A problem with the script spotted by Eric Walch has been fixed

Posted: **Sun Mar 29, 2009 6:11 pm**

Hi Dr. Nil,

The 1.52 version of Ore Processor still identifies itself as 1.51?

Also, under trunk (1.73 WiP) the Ore Processor no longer works. This is probably a bug which got introduced somewhere in the codebase since the 1.72 test release since it does work there.

However, while looking into it I got rather curious about your script, in particular why it performs what appears to me to be a rather involved no-op.

May I ask what this code section in the script is good for?

Code: Select all

<array>
  <string>set: mission_ore_difference [credits_number]</string>
  <string>awardCredits: 1</string>
  <string>subtract: mission_ore_difference [credits_number]</string>
  <dict>  
    <key>conditions</key>
    <array>
      <string> mission_ore_difference lessthan 0</string>
    </array>
    <key>do</key>
    <array>
      <string>awardCredits: -1</string>
      <string>awardCargo: 1 Alloys</string>
      <string>consoleMessage3s: 1 ton of Alloys extracted</string>
    </array>
  </dict>
</array>

I must admit complete ignorance with legacy scripting, but it -looks- to me as if its doing (in some weird sort of pseudo-code):

Code: Select all

mission_ore_difference = player.credits;
player.credits += 1;
mission_ore_difference -= player.credits;

if( mission_ore_difference < 0 ) // This is always true
  player.credits -= 1;
  player.awardCargo("xxx");
endif

Under 1.73, it looks like either the subtract or the lessthan isn't working properly, hence the player is never awarded cargo after scooping one of your splinters.

Looking at the code it looks as if the lessthan test and the whole awarding of credits then removing them again when awarding cargo is a no-op. After removing the credit-awarding-removing-and-testing stuff from your script the Ore Processor (appeared to) work properly in 1.73 again.

Perhaps one of the more script-savvy guys can comment as well..

Cheers,
- Micha.

Posted: **Sun Mar 29, 2009 7:32 pm**

Ok, I think I found it.

In changelist 1129, the code for CARGO_SCRIPTED_ITEM was changed such that the script runs in the context of the scooped object and not the player object and awardCredits now silently fails. Hence the lessthan check in the script fails since mission_ore_difference is now always 0 instead of always negative.

This also means that any scripted cargo which awards credits is currently broken in the trunk.

However, my question as to why the code is required at all still stands

Posted: **Sun Mar 29, 2009 7:48 pm**

Micha wrote:
However, my question as to why the code is required at all still stands :)

It was a workaround to identify the scooper. awardCredits was only working for the player. So this was the only way to check if the player has scooped the cargopod.

But then it would be a lot easier to use

Code: Select all

this.shipWasScooped = function(scooper)
{ 
  if (scooper.isPlayer) { ...your code, award cargo, credits, or do other stuff }
}

Posted: **Mon Mar 30, 2009 12:41 pm**

elite wrote:
Whenever I extract gem stones I end up with food in the cargo bay?

Maybe that "feature" should be re-enabled for shooting down Rock Hermits and the food could be Luxury goods (food)?

Depending upon the hermits alcoholic preferences, the meat would surely always taste different!

Screet, thinking that Rebecca might subconsciously have read this thread before opening fire on that hermit...
P.S.: GRRR...Annyoing typo...edit and submit only did lead to "preview"...did delete the message, used copy & paste and now I get the same behaviour (preview instead of submit) for the new message?!?

Oolite Bulletins

Ore Processor (v.1.52)