Project UGCO Mining/Smelting Rig.

[Ashaman42]

I'm currently planning a mining/smelting rig based on the wonderful UCGO. Initially going for a ground based set up so as to avoid thrust and fuel concerns but may do a space based system later.

Initially I'm planning an unpackable drilling rig that fills an internal tank on one command and produce a "metal" cargo from this tank on a second command.

Later I plan to split this functionality into two, having one unit that drills and produces "ore" and a second that processes this "ore" into "metal".

What do people think regarding controlling this unit, I could either go with external action areas from ummu or having the vessel enterable with ummu and controllable from inside/it's hud. Any particular preference?

 

[Notebook]

Not like me to be greedy, but both please!
Be nice to have a habitable indoors control room, for semi-permanent installations, and a bare-bones plant with all the controls on the exterior for those UMMU moments.

N.

 

[Ashaman42]

Ok, will probably do one control method to start with and get it all working and then do the other later. As to which I do first it depends what I find easiest

Just doing some planning for the moment and then will start work properly once I get home to my computer tomorrow.

 

[kevinvr]

Ok, will probably do one control method to start with and get it all working and then do the other later. As to which I do first it depends what I find easiest

Just doing some planning for the moment and then will start work properly once I get home to my computer tomorrow.

That sounds like a great idea. I used to play Colobot a lot and one could drill for metal or uranium and use it to make buildings or powercells.
This UCGO is changing the way we play orbiter... It is Great!! Much more to do now... Thanks to Dan and people like you!.
Don't stop!!
I think a hud and controls inside a breathable area will be great!

 

[Ashaman42]

Well at the very least I'm finding my modelling skills aren't very good Not that I really know what I'm doing regarding dlls either.

Have got a place holder drill rig modelled, am going to have a go at some coding now, if anyone would like to collaborate on this little project don't hesitate to send me a message

 

[dansteph]

Notice it's "UCGO" not "UGCO" (Universal Gars... ? :lol: ), it's not a serious problem appart if peoples search for "UCGO" addons on orbithangar as stated in the doc. They would not find yours.

Cheers

Dan

 

[Ashaman42]

Ah, now that's a silly mistake, it's correct in my code though

Will make sure it goes up on orbit hangar correctly.

---------- Post added at 01:03 PM ---------- Previous post was at 10:23 AM ----------

Ok, I've managed to get my miner to save how much ore has been mined by using:

oapiWriteScenario_int(scn,"ORE",ore);

in void Drill::clbkSaveState (FILEHANDLE scn) and when I open the scenario file in notepad there is a line called ORE with the correct value.

My main problem is trying to get this value to load back when I start orbiter again. I've tried

oapiReadItem_int(scn, "ORE", ore);

in void Drill::clbkLoadStateEx (FILEHANDLE scn, void *vs)

This doesn't seem to work, the vessel shows 0 ore and instead of loading up at the location it was when I saved it is at 0 long and 0 lat.

 

[dansteph]

I forgot (I'm always in hurry)

Wonderful project ! exactly in UCGO's philosophy.


Some hint:

-oapiReadItem_int is meant for config file, not scenario.
-I would use double to increase your tank and use also timestep value to make it independant of framerate (else high end computer might see tank filled in seconds instead of minutes for low end)
-Naming your variable is important, you should always include the type (d=double,f=float, i=int etc. etc.) and the name should be explicite

Correct naming example:

double dCrewCaptainO2Consumption;
int iNumberOfCargosAboard;
float fOreTankIncreaseFactor;
double dOreTankValue;

Call for troubles:

Ore
CoolValue
IDontRememberWhatThisValueDoAndItsType

Ore tank solution In brief:

in class header:

double dOreTankLevel;

in clbkSetClassCap: (initialize of class variable is mandatory)

dOreTankLevel=0.0;

saving value:

void ShuttlePB::clbkSaveState(FILEHANDLE scn)
{

	// ORBITER, default vessel parameters
	SaveDefaultState (scn);
        //  only if you have UMMU
	Crew.SaveAllMembersInOrbiterScenarios(scn);
        // Only if you have UCGO
	hUcgo.SaveCargoToScenario(scn);

       // your value save:
      oapiWriteScenario_float(scn, "OreTankLevel", (float)dOreTankLevel);
}

loading value:

void ShuttlePB::clbkLoadStateEx (FILEHANDLE scn, void *status)
{
	char *line;
	while (oapiReadScenario_nextline (scn, line)) 
	{

		//Only if you have UMMU
		if(Crew.LoadAllMembersFromOrbiterScenario(line)==TRUE)
			continue;
                // only if you have UCGO
		if(hUcgo.LoadCargoFromScenario(line)==TRUE)
			continue;

               // load of your value
               if(!strnicmp (line, "OreTankLevel", 12)) 
               {
			sscanf (line+12, "%lf", &dOreTankLevel);
		}

		// ORBITER, unrecognised option - pass to Orbiter's generic parser
		ParseScenarioLineEx (line, status);
	}

        // here you value is restored
}

Increase of OreTankValue independant of framerate:

void ShuttlePB::clbkPostStep (double simtt, double simdt, double mjd)
{

       // increase of Ore tank:
       dOreTankLevel+=simdt*0.5;  

}

You should make test and change the "0.5" value to have the correct increase speed. Use oapiDebugString to display on screen to see it increasing in real time (not to be used for release)


Hope this help ?

Dan

 

[Ashaman42]

Thank you very much Dan, that has helped a great deal.

---------- Post added 01-18-10 at 06:46 PM ---------- Previous post was 01-17-10 at 09:18 PM ----------

Ok, a question for you all regarding some design choices that Buzz313th (who has kindly offered his modelling/texturing skills) and I have been mulling over:

We're currently trying to decide whether to build a miner that produces ore which can be directly used by a smelter (which I plan to make next/concurrently) to make metal

or have the miner produce unrefined ore, which is used by a refiner to produce ore which is in turn used by the smelter to produce metal.

The second approach is more believable in terms of how large/capable buildings that are packaged into a deployable 1.3m^3 are likely to be but I'm not sure if people will find that's too many intermediate cargoes/steps.

Of course do the buildings even need to be deployable from cargo boxes? I like the idea or bringing 3 or 4 boxes that could unpack and perform these functions for a colony or outpost.

 

[Buzz313th]

Work in progress...

Hopefully will be done texturing today.

JB

 

[garyw]

That's coming along nicely and I'd say that hauling 3 cargos shouldn't be an issue for most people as it's more believable and provides for a nice set of actions to do on a world you might want to mine.

 

[Urwumpe]

That's coming along nicely and I'd say that hauling 3 cargos shouldn't be an issue for most people as it's more believable and provides for a nice set of actions to do on a world you might want to mine.

Yeah. Also you CAN do assembly actions with UMMU 2.

I think that 3 cargos is actually a pretty small number regarding the standard box size, but a good gaming compromise.

But I would do some minor design changes, if I may suggest:

• There could be a lift-tower like structure on it (and even if it is just for carrying a small robotic mining head)
• the colors could be more yellow-black
• The computer should be better integrated into the side, ideally with a fold down keyboard, instead of a folding screen.
• The conveyor belt is good, but maybe a corkscrew would be simpler to animate/not animate at all.
• Also, it would be a good design issue to connect the mine after finding something (gathering geologic samples!) directly with a refinery for reducing the cargo mass, that returns refined ore and soil/slag.

 

[Ashaman42]

Yeah. Also you CAN do assembly actions with UMMU 2.

I think that 3 cargos is actually a pretty small number regarding the standard box size, but a good gaming compromise.

But I would do some minor design changes, if I may suggest:

• There could be a lift-tower like structure on it (and even if it is just for carrying a small robotic mining head)
• the colors could be more yellow-black
• The computer should be better integrated into the side, ideally with a fold down keyboard, instead of a folding screen.
• The conveyor belt is good, but maybe a corkscrew would be simpler to animate/not animate at all.
• Also, it would be a good design issue to connect the mine after finding something (gathering geologic samples!) directly with a refinery for reducing the cargo mass, that returns refined ore and soil/slag.

I'm only an amateur at C++, though I think it's coming along nicely, don't suppose you'd mind giving some pointers on having more than deployable cargo to create a vessel? Would you do something like just having one cargo being unpacked but coding a check for the other required one within a certain radius?

Well I'm planning on doing a refinery next, hopefully with Buzz313th modelling again, was planning to have that take the rock cargo and return an ore cargo. Was just going to have the refiner return ore and assume the soil/slag was dumped, could have it appear as a cargo too but would end up with lots of waste to cart off unless we also built a destruction unit.

If it is within grapple range of the miner unit that would pretty much automate the reduction of rock to ore. Rock cargos would briefly be in existence on the ground though.

 

[kevinvr]

That's coming along nicely and I'd say that hauling 3 cargos shouldn't be an issue for most people as it's more believable and provides for a nice set of actions to do on a world you might want to mine.

It looks great! 3 cargo's sounds good.
I just spent 2 days setting up a scenario to go to the moon. With UCGO it is much more realistic and loads of things to do... if you want

 

[Buzz313th]

But I would do some minor design changes, if I may suggest:

• There could be a lift-tower like structure on it (and even if it is just for carrying a small robotic mining head)
• the colors could be more yellow-black
• The computer should be better integrated into the side, ideally with a fold down keyboard, instead of a folding screen.
• The conveyor belt is good, but maybe a corkscrew would be simpler to animate/not animate at all.
• Also, it would be a good design issue to connect the mine after finding something (gathering geologic samples!) directly with a refinery for reducing the cargo mass, that returns refined ore and soil/slag.

Those are good ideas, but from a design standpoint we wanted the "miner" to unpack believably from a 1.3 cubed box. And a corcscrew or tower would need more material. The idea behind this design is that it is using compact lasers to bombard the rock in a hole beneath the cover to break the rock up and digg the hole with the conveyor bringing the scattered rock up to the 1.3 meter empty bin.

The pics your looking at are not textured yet, I am still working on details shading and decals. The tone and color will be decided on after I see what it looks like in orbiter. Can't go too dark since there is no other light source except the sun.

Your idea of the computer is a good one. Originally I wanted to just place like a pelican case next to the miner with a touchscreen ontop, representing that one wireless touchscreen is used to control different types of machinery made by the same manufacturer and it would be packed up and taken away with the UMMU. We will see.

The idea that Ashaman and I are discussing, is designing this to just create raw rock. The resource would look like a pile of rocks in a open 1.3 box. This resource would be just Raw Moon Rock". Then others can use that resource to refine it to whatever they think can be extracted from raw moon rock. We are also considering making the machinery dependent on another UCGO resource, "Battery". The battery resource would be created by a solar array every so often and then the battery would power anything that realistically would need electricity, such as our miner or a refinery.

JB

 

[Urwumpe]

I'm only an amateur at C++, though I think it's coming along nicely, don't suppose you'd mind giving some pointers on having more than deployable cargo to create a vessel? Would you do something like just having one cargo being unpacked but coding a check for the other required one within a certain radius?

I'd deploy the core structure for it as cargo and then do the following:

- I define an action area for it.
- I unpack the next module from cargo.
- In game, on triggering the action area, scan the vicinity for the next needed module. If found, install it and go to the next outfitting stage. Otherwise give a warning message that the next part is missing.

 

[T.Neo]

Are you going to include a lathe/milling machine and or sheet metal production devices? :rofl:

 

[Urwumpe]

The UCGO lathe...ok, ordered.

 

[T.Neo]

CNC or manual?

 

[kevinvr]

. We are also considering making the machinery dependent on another UCGO resource, "Battery". The battery resource would be created by a solar array every so often and then the battery would power anything that realistically would need electricity, such as our miner or a refinery.

JB

Did you also play Colobot??:lol::lol:
Fantastic idea though!