Ore Processor (v.1.52)

Screet · Post by **Screet** » Mon Mar 30, 2009 10:22 pm

Seems like I found a bug within this nice tool!

I just had an astromine on my course...and there was an immense amount of boulders, very close together there. I just did go to full speed and tried to ram as many as possible on my way through...turned and went in again. Did this a very few times until my cargo hold (previously empty) was reported full with 50 tons.

Upon docking, my cargo hold was only full to 43 tons.

I have seen this discrepancy sometimes before, but never knew wether it came from using the ore processor or from scooping up platinum, gold and gems. This time, I did not use anything beside the Ore Processor...

Thus, it appears that some of those goods which should not affect cargo space do when they come aboard via the Ore Processor!

Screet

Post by **Micha** » Mon Mar 30, 2009 11:57 pm

It's a known 'feature' of the Ore Processor that converting ore into gems, gold, or platinum still takes 1T of cargo space until you dock. Apparently it can't automatically eject the leftovers.

Post by **Eric Walch** » Tue Mar 31, 2009 8:35 am

Micha wrote:
It's a known 'feature' of the Ore Processor that converting ore into gems, gold, or platinum still takes 1T of cargo space until you dock. Apparently it can't automatically eject the leftovers.

It happens not only with ore processor, but with any container. A container with 4 grams gems always weights 1 ton. Only upon docking the gems are reallocated in the ships vault and the large container that was wasting storage room is dumped at the station.

Call it a feature as a container that would be just large enough to contain 4 grams of gems probably would not be spotted by the player not would be visible on radar.

Post by **Eric Walch** » Thu Apr 09, 2009 11:02 am

Micha wrote:
......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

Svengali already wrote why the credits are used. Player can have credits, a NPC not. With old 1.65 this was the only way to determine if the player had scooped the barrels that triggered some events and not a NPC ship.

Since 1.70 we have ship scripts and since 1.71 they also work quite good.
In my previous UPS upload I already replaced these script_actions with a barrel-script.

Yesterday I did the same with OreProcessor and Cargo_Wreck_Teaser. For OreProcessor one single barrel-script in combination with script_info was enough. For Cargo_Wreck_Teaser I used 4 different barrel scripts. It's working well on my computer, so for 1.73 these new versions can be used when the old method by awarding credits is a problem. Advantage of a barrel-script is that there will even be more freedom with scripting. e.g. generate random values and use gr/grs in the display message depending on the quantity.

Will upload both soon when I don't encounter any bugs.

Code: Select all

this.shipWasScooped = function (scooper)
{
    var cargotype = this.ship.scriptInfo.cargotype
    var message = this.ship.scriptInfo.message
    var quantity = this.ship.scriptInfo.quantity

	if (scooper.isPlayer)
	{
		if(quantity < 0) quantity= Math.ceil(Math.random()*(-quantity)); // only negative values are randomised.
		if(quantity > 1) {message = message.replace("gr ", "grs "); message = message.replace("kilogram ", "kilograms ")};

		if(scooper.hasEquipment("EQ_ORE_PROCESSOR"))
		{
			if(scooper.canAwardCargo(cargotype, quantity))
			{
				player.consoleMessage(expandDescription(message.replace("@1", quantity)));
				scooper.awardCargo(cargotype, quantity);
			}
		}
		else
		{
			if(scooper.canAwardCargo("Minerals", 1))
			{
				player.consoleMessage("No extraction!! 1 ton ore")
				scooper.awardCargo("Minerals", 1)
			}
		}

	}
}

Post by **Eric Walch** » Mon Apr 13, 2009 8:18 pm

Screet suggested elsewhere that something like an equipment that extracts the alloys and pure metals from minerals should consume vast amounts of energy. He is very right with this. Normally ore extraction starts with energy intensive grinding of the ore into powder.

Anyhow, I added energy consumption to the ore-precessor. For every scooped splinter it now uses 1 energy bank worth of energy. It will only start working when there is an equivalent of at least two energy banks full of power present. This makes scooping splinters during combat situation unwise. (But I think players have other things to do when in combat).
With a plain adder (just one energy bank) the ore processor now extracts nothing.

I also added different textures for different splinter contents. Scripting is now moved from the script_actions to a ship-script (see previous message). This will give a better flexibility for future additions. e.g. one could now easy add different processing sounds for different splinters.

I uploaded it at he box: Ore Processor 1.53

When Dr. Nil approves these changes I'll make a link from the wiki.

note: while testing this I consulted the new Oolite reference sheet and noticed the "Radioactives" were missing in my copy of the sheet. But I have not the latest release.

Post by **Micha** » Mon Apr 13, 2009 9:21 pm

Eric Walch wrote:
For every scooped splinter it now uses 1 energy bank worth of energy.

Presumably only when the splinter contains something worth extracting? Ie, Mineral-splinters shouldn't use any energy since, apart from the scanning phase, nothing further is actually refined.

Eric Walch wrote:
I also added different textures for different splinter contents.

Hmm, not sure I'm personally keen on this - if you go this route then you might as well just put the name of the contents onto the HUD display. While it's nice to see more variety of textures and models IMHO you shouldn't necessarily be able to tell what a chunk of rock contains.

Alternatively what about an "Advanced Ore Processor" (replaces the Ore Processor if you already have it) which contains additional scanning capabilities which show you what the most likely content of a splinter is? Or even gives a run-down of an asteroid as to what percentage of contents it has? (eg 80% Minerals, 18% Radioactives, 2% Others)

Just throwing ideas into the vacuum

Anyhoo, will give this new version a test-run soon - sounds very promising!

Screet · Post by **Screet** » Mon Apr 13, 2009 9:29 pm

Micha wrote:
Hmm, not sure I'm personally keen on this - if you go this route then you might as well just put the name of the contents onto the HUD display. While it's nice to see more variety of textures and models IMHO you shouldn't necessarily be able to tell what a chunk of rock contains.

I like Erics idea pretty much, but did not see it in action yet. I guess that any geologist could look at a piece of rock and make very good assumptions as to what might be the result of processing it with such a piece of equipment. I guess it would still be good if the different textures each have some likelihood at what they would deliver, so that it's not always a 1:1 relation there.

About the analysis expansion idea, guess that could be fun. However, would anyone really leave the splinters alone if he sees a 90% chance that it turns into simple minerals?

Screet, who had so many "splinter scooped" and nothing happening results with the trunk code recently - is that a bug? Similar observations go with cargo crates...

Post by **Micha** » Mon Apr 13, 2009 9:36 pm

Screet wrote:
About the analysis expansion idea, guess that could be fun. However, would anyone really leave the splinters alone if he sees a 90% chance that it turns into simple minerals?

Depends on how much cargo-space you have and how many asteroids/splinters are around. Would certainly save having to eject all the minerals all the time - which the various textures will allow people to do.

Screet wrote:
Screet, who had so many "splinter scooped" and nothing happening results with the trunk code recently - is that a bug?

Yes - I already raised it.

Post by **Eric Walch** » Tue Apr 14, 2009 9:52 am

Screet wrote:
Screet, who had so many "splinter scooped" and nothing happening results with the trunk code recently - is that a bug? Similar observations go with cargo crates...

This was the main reason I made this Ore-proseccor change. It no longer uses the legacy script for the splinter. The trunk code has currently problems with awarding credits to the player. This version should work well with the trunk. (I have a similar version ready for Cargo_Wreck that should work with the current trunk.) But still this is not the solution as ships scripts_actions should be able to award credits to the player I think.

About the different textures: It is still very difficult to see the differences. To recognise the alloy, gold or platinum, you have to stop dead in front of the splinter and look carefully for recognition. This is partly because all splinter textures are rather smeared around the splinters. Only the gems and the radioactives I also gave a bit different colour. Those splinters are now noticeable on distance. And yes, when you recognise a content you can dump stuff with less value. But is that not part of the fun in the first place?

Post by **Micha** » Tue Apr 14, 2009 8:20 pm

Seems to work on both 1.72.3 and 1.73 (trunk), although I only ever seem to see 2 different textures instead of the 6 or so which are included.

Also, it looks to me as if there's a bug in the legacy-scripting for gems - gem-splinters also yield gold? I'm not quite up to the scripting and when legacy vs javascipt comes into effect so this might be a non-issue.

Post by **Eric Walch** » Tue Apr 14, 2009 9:56 pm

Micha wrote:
Also, it looks to me as if there's a bug in the legacy-scripting for gems - gem-splinters also yield gold? I'm not quite up to the scripting and when legacy vs javascipt comes into effect so this might be a non-issue.

It is an intentional "bug". Once a js script is defined, any legacy script_actions for that ship are ignored. So those script_actions are only used with Oolite 1.65. And that version had a bug that gems awarded by script ended up as Food with the player. This happened only with windows that had problems with the hyphen in the name "Gem-Stones". Kaks added code in the past to prevent those splinters being added under 1.65. I now changed it to let them award Gold with 1.65 and the right Gems with current Oolite. (I put a remark about this in the update notes as I expected comments on this.) The player wont see anything about this with 1.65.

About the textures: They are different, but for the most this difference is hardly visible. To be better visible the texture should be rewrapped around the splinters without distortion. I have no experience in this field and it is the texture distortion of Oolites own splinters. I didn't want to put to much effort in it. I first wanted an opinion about recognisable splinters.

Post by **Micha** » Tue Apr 14, 2009 11:12 pm

Eric Walch wrote:
(I put a remark about this in the update notes as I expected comments on this.) The player wont see anything about this with 1.65.

Doh!

Wer lesen kann ist klar im Vorteil! (People who can read have a definite advantage).

Post by **Eric Walch** » Thu Apr 16, 2009 4:52 pm

One thing about the new energy drop on scooping was still bothering me. It looked more like a crash than scooping. I couldn't add a timer to the splinter script as this script is removed immediately after scooping.

But why not store the splinters in the world script. So I did. The world script now has a timer that is off by default. (Non programmers can replace the word timer by OreProcessor). When the splinter is scooped up it transfers its characteristics to the timer (=OreProcessor) and switches it on.

This timer chews 5 seconds on the splinter and only than shows its extraction message. When the player has scooped up a second splinter in the meantime it starts processing the second. etc. When all splinters are processed it switches itself off. The 1 energy bank worth on energy is now used up in 10 small pieces. It looks better this way. I also added a sound for the processing. Currently a copy of the scooping sound but I hope someone can offer an new sound for it.

This whole thing also tackled the problem of the double messages. Normally the script was executed first and showed the extraction message. Only after that, oolite showed a splinter scooped message. This wrong order was always a bit stupid. Now you only get the splinter scooped message and the extraction message arrives 5 seconds later.

I uploaded it on the same link as before. Ore Processor 1.53b

EDIT:
While playing I noticed one other issue. I just mention it here before someone complains:

Oolite has a mechanism that suppresses identical messages arriving within 6 seconds of the previous. In the past you didn't notice in the large amount of screen messages that one message was missing when scooping up multiple splinters in one go. Now, when scooping up several splinters on one go, the processing messages come 5 seconds from each other. When scooping up 2 splinters that lead to identical messages, the second message is not displayed. The cargo is awarded though.
I see no easy solution for this as it is an Oolite feature to avoid screen cluttering with identical messages. A second, identical message, is shown when there was another message in between. It only compares with the previous content.

Maybe spacing the messages longer than 6 seconds would help, but I already find 5 seconds long. Or I could alternately add an extra space at the end to make sure the messages are different. (edit: Done. And it seems to work)

And I think Oolite has currently a bug that messages are even suppressed after longer time. In an other oxp that broadcasted identical messages every 30 seconds, I noticed only the fist was displayed. A next message was only written to screen when there was an other message in between.
I solved that by using random messages. Now only sometime I had no message when it choose the same as the previous. Probably this is the same reason why in Thargoid's Lave Academy, sometimes the buoys didn't send a message.

Post by **Eric Walch** » Sun May 03, 2009 2:36 pm

I uploaded a new wip version of ore processor: Ore Processor 1.53c

It now uses a custom sound while busy with extracting.

The larger of the two splinter models has a new texture wrapping.

I never was pleased how Oolite smeared the texture around the larger of the two splinters. At one side of the splinter it used a single texture line to paint the whole surface. This resulted in a texture mach from left to right but ended in only banded texture. Bands or layers are seen in rocks created from sediment but not in rocks in space. It just looks wrong.

Yesterday I started using Wings3d for he first time and rewrapped the texture of one of the two Oolite splinters to give it a less distorted texture and now used this wrapping for the ore_processor splinter. Differences in the textures are now more clear for this splinter. Maybe it is even a good idea to change the strange texture wrapping for the splinter in oolite itself.

ovvldc · Post by **ovvldc** » Sun May 03, 2009 10:20 pm

Eric Walch wrote:
About the textures: They are different, but for the most this difference is hardly visible. To be better visible the texture should be rewrapped around the splinters without distortion. I have no experience in this field and it is the texture distortion of Oolites own splinters. I didn't want to put to much effort in it. I first wanted an opinion about recognisable splinters.

I'm not too much in favour of very recognisable splinters. On a real chunk of rock, you'd have to be pretty darn close (in space measurements) see the difference visually, and if it were just a matter of scanner, you could give them different names..

Best wishes,
Oscar