Ore Processor (v.1.52)

[DaddyHoggy]

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

I have always presumed/assumed - that despite ships having "view ports" or cockpit windows that in fact much like a modern submarine all the pilot's viewing is done via cameras and electronic enhancement - therefore I can happily accept the fact that once an ore processor is fitted it had a subsystem that plugs into the viewport camera and highlights differences in the splinter type.

[ovvldc]

I have always presumed/assumed - that despite ships having "view ports" or cockpit windows that in fact much like a modern submarine all the pilot's viewing is done via cameras and electronic enhancement - therefore I can happily accept the fact that once an ore processor is fitted it had a subsystem that plugs into the viewport camera and highlights differences in the splinter type.

I understand. Personally, I presume/assume there would be sensor overlays, but with a 'true' picture of what it looks like underneath.

Best wishes,
Oscar

[Cmdr James]

Well, we know for sure it isnt just simple windows, as this would make rear view impossible on most ship designs, at least it would need a long walk to the rear window.
I would think most ships have some window at the front, as its always nice to be able to actually see whats happening, even if there is a fault or a scratch on the camera lense. But clearly it must be mostly electronically rendered, just based on ship sizes, window locations etc.

[Eric Walch]

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..

I agree that the gem and radioactive splinters are maybe a bit to colourful. You can tell them apart from a distance to easy. So I played a bit further and doubled the number of textures. But now without the stronger colours. Every splinter type now can appear with two different textures. (11 different textures in total) This gives a large variation in splinters and makes mining more to a fun. Not as boring anymore as it was. This extra textures now doubled the zipped file size from 160 to 380 kb. Still reasonable small.

Ore Processor 1.53d

Version 1.53c is also still available. Can Dr. Nil decide for himself what he likes better. He has not yet logged in but he off cause has the last word on his baby.

[Eric Walch]

Despite a PM to Dr Nill in May and a personal E-mail I haven't had a reaction by Dr Nill.

In the mean time I had several reactions that version 1.53d was liked as best. So today I updated the page for the Ore Processor of on the wiki and put the previous version 1.53d there as version 1.53.

[Rustybolts]

Thanks for the post didn't even know a newer version existed. I like the energy drain and the sound it makes when processing, make this version much better.

[Micha]

Just found a bug with the Ore Processor 1.53 using Oolite 1.73.4.

When scooping, the Ore Processor doesn't add scooped items immediately to the ship manifest - only once it's finished processing it. So it's possible to keep scooping into the Ore Processor queue.

Then when the Ore Processor is finished and tries to add whatever to the ship manifest, errors occur. Unfortunately it also ends up getting stuck in an endless loop trying to add whatever it just finished processing to the manifest - the only way around it is to Dump some cargo to make room.

An exception is also posted:

Code: Select all

Exception: Error: PlayerShip.awardCargo: Cannot award 1 units of cargo "Alloys" at this time (use canAwardCargo() to avoid this error).
    Active script: "oreProcessor" 1.53
    OreProcessor.js, line 46:
    			player.ship.awardCargo(this.type[0], this.quantity[0])

So either, as suggested, wrap the awardCargo with a 'canAwardCargo' and if that fails, auto-dump the processed item, or, (imho) a better approach would be to keep a tab of how many items are in the Ore Processor's processing queue and prevent the ship from scooping more items if the ship manifest + Ore Processor queue fill the ship's hold.

[Eric Walch]

So either, as suggested, wrap the awardCargo with a 'canAwardCargo' and if that fails, auto-dump the processed item, or, (imho) a better approach would be to keep a tab of how many items are in the Ore Processor's processing queue and prevent the ship from scooping more items if the ship manifest + Ore Processor queue fill the ship's hold.

Good catch. I wonder why I missed it. As long as the cargo is not added I can't prevent scooping up new splinters. Scripted splinters don't add to the cargo by itself, so the easiest will be to just ignore the remainder when the manifest is full.

The only way to prevent scooping when the queue holds enough to fill the bay it to temporary remove the scoop itself. I'll think about either solution and use the one that looks best.

For 1.74 it will be easier to make it correct working. By then we very likely can remove cargo by script. That opens a solution to immediately add the splinter as minerals and than on conversion by the oreProcessor remove the mineral again and replace it with whatever came out of the refinery.

[Cmdr James]

Or check before adding, and if manifest is full not add it and spawn a new splinter close to the ship.

Anyway you cannot rely on the queue depth limiting, I could queue up many splinters, then scoop a canister while the queue is digested.

[Eric Walch]

Or check before adding, and if manifest is full not add it and spawn a new splinter close to the ship.

Anyway you cannot rely on the queue depth limiting, I could queue up many splinters, then scoop a canister while the queue is digested.

OK, fixed now. Uploaded as version 1.54.

I can not prevent the scoops picking a splinter up when there are some busy processing. (Maybe later with Oolite 1.74). So now I added the check when processing is ready. When in the meantime the hold was filled the player gets a "could not store" message and a splinter is ejected again.
Then, before processing the next splinter I again look if this one can be stored. If no, it is also ejected, if yes processing starts.

This way allows to process splinters, even with full bay if the splinters are kg or gr goods.

But oolite itself has still a few problems with cargo. My Manifest screen shows:

Code: Select all

Cargo 169 t (170 t):
  50 t x Food
  23 t x Textiles
  2 t x Radioactives
  40 t x Alloys
  52 t x Furs
  4486 kg x Gold
  8 kg x Platinum
  9 g x Gem-Stones

The ton goods add up to 167 ton. For the remainder of 4494.009 kg it calculates 2 ton. should be 4.5+ = 5 ton.

It just looks it just uses 1 ton for Gold/Platinum each. And than on docking the same cargo adds up to 167 ton. (just evaporated 2 tons)

(The 4 tons of Gold are just part of two cargo contracts and not scooped gold. Mining is not that lucrative.)

[Eric Walch]

Users of 1.74 should update Ore_processor to version 1.57.

This version makes use of some new 1.74 features and fixes a bug that on some special conditions could lead to the processing sound not shutting of.

It was released a few weeks back and the Ore Processor can be downloaded from the wiki

[JeffBTX]

The Ore Processor doesn't seem to be working for me, but I suspect that it is inter-OXP-related.

Ore Processore 1.57
Oolite 1.74.2

I have only a few OXP's installed, but this (presently) includes Griff's NormalMapped Asteroids and Griff's NormalMapped Rock Hermit. Only those 2 of Griff's NormalMapped files as individual downloads (for now), NOT the "Griff's All-in-One" download. (I am presently using Smiv's Shipset v2 and Smiv's Accessories for ship and station textures).

I scooped up many splinters (From around 8 to 10 boulders) and all I got was minerals, no indication that the Ore Processor was doing anything (the Ore Processor .OOG sound never kicked in).

I've now UnInstalled Ore Processor 1.57.

MY GUESS is that the Ore Processor does not recognize "Griff's NormalMapped Splinters".

Another note (probably has no direct impact); Smiv's Accessories DOES include remodeled/retextured asteroids / rock hermits; but the Griff's NormalMapped Asteroids and Rock Hermet apparantly sucessfully overides Smiv's (for appearence) at all times.

[Eric Walch]

MY GUESS is that the Ore Processor does not recognize "Griff's NormalMapped Splinters".

That is correct. The griff asteroids are made of pure mineral without any trace of ore in them.
You might want to add asteroid storm in addition. Those asteroids contain sometimes valuable ore that can be processed

EDIT: I just looked inside the griff asteroids code. It would be fairly easy to build a link to them in Ore Processor, in a way you don't get errors when the griff asteroids are not installed.

[JeffBTX]

Eric;

Thanks. I read the description for Asteroid Storm, sounds good.

I've uninstalled Griff's Asteroids and Rock Hermit, I've just downloaded Asteroid Storm and re-downloaded Ore Processor.

[JeffBTX]

Eric;

Response to your edit;

The reason that I am not using Griff's all-in-one is that it is technically incomplete (mainly Iso stations) and it makes the universe "look goofy" if appearances are generally inconsistant.

Griff's asteroids and rock hermit look GREAT, but appearance-wise, they are kind of inconsistant with Smiv's ships and stations. I'll just leave Griff's files uninstalled for now.

WHEN Griff's all-in-one reaches a complete state, then I might consider it, and hack it to make it ore-processor compatible (fortunately I have some programming experience, hacking OXPs doesn't seem to be difficult).

Thanks again - laters.