General Question Help with an UCGO resource function

[Buzz313th]

I am having difficulty figuring out why the UCGO function, "EatCloserCargoByType" is not removing any resource weight from the UCGO resource cargo. I am not recieving any errors and the rest of the code is working fine.

Maybe if some of you fine fellas can take a look at this for me, I would appreciate.

			// Load closest battery into Cargo slot 0
			// And check slot 0 status
			dFullBatteryMass = 80;
			switch (hUcgo.GrappleOneCargoByType("battery",0))
			{
			case 1:
				strcpy(oapiDebugString(),"Ok Cargo Grappled Battery");
				if ((hUcgo.GetCargoSlotMass(0) / dFullBatteryMass) < 0.01)
				{
					hUcgo.ReleaseOneCargo(0);
					strcpy(oapiDebugString(),"Battery has less than 1% charge.  Charge Battery before use");
				}
				else
				{
					//Charge Internal Tanks With Battery Power but leave
					//less than 1% charge in battery
					dBatteryEaten = ((hUcgo.GetCargoSlotMass(0) / dFullBatteryMass) - 0.009);
					hUcgo.EatCloserCargoByType("battery", dBatteryEaten);
					strcpy(oapiDebugString(),"Charging Internal Battery Tanks With External Battery");
				}
				break;

Thanks

JB

 

[Urwumpe]

ok, aside of the fact that you don't eat batteries, you only consume the stored "mass-less" energy.

There is the trouble maker:

dBatteryEaten = ((hUcgo.GetCargoSlotMass(0) / dFullBatteryMass) - 0.009);

The function expects a mass in kg, not a ratio.

 

[Buzz313th]

I understand you don't "Eat" batteries, but to use the UCGO standard and functionality, I had to eat something.

Ohh man, the mistake is pretty obvious isn't it... Thank alot...

JB

 

[Urwumpe]

I understand you don't "Eat" batteries, but to use the UCGO standard and functionality, I had to eat something.

You can always replace damaged batteries.

 

[Buzz313th]

First off, thanks for the help.. That fixed it...

Good point about replacing the batteries, and I thought about just letting the UCGO code destroy the batts when empty, but I liked the idea of charging and discharging batts (Ucgo resource cargo) and having to actually move the batts to and from the charging source and the draining source. I think it adds more depth than having the vessels create and destroy the UCGO cargos.

Thanks again...

JB

 

[dansteph]

I urge to not do this each frame

My view on this:

Use an internal tank (a simple value) that you decrease with electricity consumption.
When empty check for Cargo "battery" ressource , use it to refil your "tank" and EMPTY the cargo by half his weight only.

Now consider "half weight" cargo as "used battery" (not able to refill your tank) and the full one as full battery.

Dan

 

[Buzz313th]

I was planning on doing the tank checks and consumption around every 5 minutes and the UMMU checks for o2 consumption rate every 5 seconds.

I was gonna drain the batteries and o2 tanks down to 1% before both needed recharge.

...

JB

 

[dansteph]

Cargo Imho should not be used as tank but to refill your internal tank. Either automatically either manually.

"5mn check" mean nothing and can lead to all sort of problems when you can accelerate time at 100'000x

<1% could also lead to problem due to that, refill at <10%

I may post consumption code helper but currently I'm really busy.

Dan

 

[Buzz313th]

Cargos have always been intended to be external tanks to refill internall tanks, so no issue there, you and I are on the same page.

Why would 5mn checks cause a problem? Isn't it better than 5 second checks? I would much rather do the checks and calculations every 5 minutes and then also spread the code out amongst 60 frames, but at my level of C++ understanding, I'm really not sure how to spread out code checks and functions through a time period. The best I can do right now to keep from pulling too many resources is complete the code for the checks and calculations every 5 minutes or so in a single frame.

Please explain to me why draining the Batteries and oxygen cargos to 50% instead of 1% is a better alternative. Either way really makes sense, but I don't see the advantage of one over the other.

I appreciate any help as this is just my second code project and vastly more complicated than the battery creating solar panel that was my fisrt project...

JB

 

[dansteph]

because at 100'000 time warp 5 minute pass in less than second. So next check might happen "weeks" after the battery is supposed to be empty.

You should base your check on internal level and more 10% than 1% (because of same problem)

For using cargo you can use them until 1% if you want it's a good idea.
Keep 1% if you want the empty cargo remain, keep nothing if you want that they disappear once used. (trash managment or not, might be a good idea or not (scenario full of trash after weeks))

Now you'll have to choose how much "battery weight" is needed to refill your "tank"
I choosed 4 cargo for the Arrow to refill 100% O2 you can make an arbitrary choice based on the gameplay you want.

Now you'd probably do also an O2 consumption ? simulating electricity and not a main life system might seem strange.

Dan

 

[Bj]

Now you'll have to choose how much "battery weight" is needed to refill your "tank"

I didn't know electricity had weight :shrug:

Actually, it would be better if each cargo would carry electricity (say full charge version), then have another cargo version that is depleted version. It would be up to the pilot to eject the batteries or not.

 

[Eccentrus]

Battery's electricity is basically electrons stored in a contraption so yes, it does have mass, but infinitesimally small.

 

[Buzz313th]

because at 100'000 time warp 5 minute pass in less than second. So next check might happen "weeks" after the battery is supposed to be empty.

You should base your check on internal level and more 10% than 1% (because of same problem)

For using cargo you can use them until 1% if you want it's a good idea.
Keep 1% if you want the empty cargo remain, keep nothing if you want that they disappear once used. (trash managment or not, might be a good idea or not (scenario full of trash after weeks))

Now you'll have to choose how much "battery weight" is needed to refill your "tank"
I choosed 4 cargo for the Arrow to refill 100% O2 you can make an arbitrary choice based on the gameplay you want.

Now you'd probably do also an O2 consumption ? simulating electricity and not a main life system might seem strange.

Dan

Dan, I am using "SimTime" as the clock and SimTime apears to change it's rate relative to the time compression rate. Wouldn't my battery and resource check based on SimTime not be adversly affected by simtime rate? If I'm wrong please lemme know.

The internal tanks of both Electricity and O2 will be the determining factor on sustainability for the habitats, again the cargos "outside" the habs will just fill the internals when they drop below 90%.

I made the decision to use UCGO cargo to represent a battery as too keep a standard instead of having to code a proprietary vessel to represent a battery. Because of this decision and that UCGO cargo use "weight" as a variable, I have to represent the battery charge level as weight. But this conversation has brought up a good point, that the smaller the delta in battery weight between a full charge and an empty battery will better represent a realistic battery. So say a full battery at 80kg's and an empty battery at 70kg's. With a charge rate of plus 1 kg per hour and a discharge rate of 0.5 kg's per hour. As long as any future UCGO battery chargers or dischargers (UCGO vessesls that are dependant on battery resource) are coded to follow this example, we won't have any batteries floating around with less than a standard weight representing a charge. Than again, if other devs create a vessel to use battery and don't adhere to a standard discharge level and just use the battery up until the Ucgo cargo vanishes, then a 1% discharge level for an empty battery makes more sense from a gameplay perspective...

JB

---------- Post added at 04:47 PM ---------- Previous post was at 04:34 PM ----------

Ohh, and Dan...

I am planning to use O2 as a consumption variable as well as electricity....

The overall plan is this...

The habitat will consistently use electricity to maintain positive pressure. Pressure will be controlled via an outflow valve, just like a pressurised aircraft. Rate of electricity consumption will not change and overall rate will be relative to the size of the habitat.

O2 consumption rate will folllow your example with the DG4, using the quantity of UMMU's present in the current habitat to determine O2 consumption rate. This unfortunately is my stopping point as I need to figure out how to code the vessel to search for UMMU's and then count the UMMU's within the vessels own breathable area radius to use as a factor to change the rate of O2 consumption...

A few forum members were kind enough to jump in on another thread I posted to give me some hints on how to detect other vessels within a certain radius. I understand the principal of coding this, but I'm sure my initial code will be ineficient.

JB

---------- Post added at 05:00 PM ---------- Previous post was at 04:47 PM ----------

I didn't know electricity had weight :shrug:

Actually, it would be better if each cargo would carry electricity (say full charge version), then have another cargo version that is depleted version. It would be up to the pilot to eject the batteries or not.

That could be done... seems like another good alternative. So correct me if I am not on the same page here...

With this idea, you would be skipping the weight variable all together on the discharge cycle... And a device that uses battery would add "x" amount of electricity to it's tank per "Charged Battery"?

I am using this method, kinda, to charge the batteries as the UCGO code does not allow to "reverse drain" (Charge the weight in the UCGO container). But it does allow to hold a container for "x" amount of time before it can be released, thus simulating a charge and then the code deletes the empty battery and creates a full battery in place of it.

JB