Topic: Shouldnt cargo add weight to your bot, and change speed?
Really weird: installed modules changes speed, but huge cargo dont.
http://www.perp-kill.net/related/239910
You are not logged in. Please login or register.
Perpetuum Forums → Feature discussion and requests → Shouldnt cargo add weight to your bot, and change speed?
Really weird: installed modules changes speed, but huge cargo dont.
Probably because robot attributes are calculated at deployment and making cargo weight it down is a pain on database for every difference in cargo.
I'd actually love to see it happen: cargo weight factor on the bot speed AND passability. It would have to be implemented as type of effect, like demobbing, but it's doable, although server cpu time unfriendly.
o/
we had that already some time ago:
Fix: Items in robot cargo won't affect maximum speed anymore. (This was an intended feature but it doesn't work quite right, so it has been disabled for now)
it was a pain with a sequer full of looted missile launchers or armor plates moving with average 2 kph
remember, the cargo system is based on volume, not mass. also your robots cargo is a compressed teleport buffer (cargo is stored in form of energy - or how would you explain that a sequer could transport several heavy mechs and tons of ore)
we had that already some time ago:
Update news for 2010-03-26 wrote:Fix: Items in robot cargo won't affect maximum speed anymore. (This was an intended feature but it doesn't work quite right, so it has been disabled for now)
it was a pain with a sequer full of looted missile launchers or armor plates moving with average 2 kph
remember, the cargo system is based on volume, not mass. also your robots cargo is a compressed teleport buffer (cargo is stored in form of energy - or how would you explain that a sequer could transport several heavy mechs and tons of ore)
They failed with formulas then.
Here's my suggestion how to handle it:
Max possible reduction of running speed due to full cargo is 20%.
At 50% filled cargohold, the running speed is lowered by 10%.
At 30% cargohold, running speed is reduced by 6%.
... and so on.
You don't have to reduce it by 99%. An empty truck irl won't drive 90% slower if it's full.
I'm not a programmer, but I can't imagine that it's so hard to implement or that it will eat all server resources.
You are forgetting to consider other factors in mechanical design, such as engineering for loads. Given a sequer's visual design and stated purpose, I would expect its rated (equipment screen) performance to apply for a full cargo load, not an empty hull. Its optimized to be a hauler, not a combat bot. If anything, I would expect it to be *faster* than rated for an empty hull, though this would be a limited due to the tradeoffs involved in engineering and gearing a torque-heavy drivetrain to support the 80U cargo load.
your robots cargo is a compressed teleport buffer
This. STFU and close this thread already.
your robots cargo is a compressed teleport buffer (cargo is stored in form of energy - or how would you explain that a sequer could transport several heavy mechs and tons of ore)
If cargo stores in a form of an energy: why my reactor or acc. recharge time still same? Maybe mass in cargohold transmutating in pure volume of green butterfly energy or something else. I can write here 100500 such histories about teleporters and mad squirrels in gophos head.
The main point of this topic is bring cargo into a game mechanics.
For example: CPU run navigation program in parallel thread. Installed modules reduces speed because of CPU load. Total robot weight reduces speed too, but less than high CPU load.
/*A really big set of formulas, what proofs my idea*/
Any other thoughts?
I'm not a programmer, but I can't imagine that it's so hard to implement or that it will eat all server resources.
hm. Imagine you have 1k items in your hold, a bit unrealistic, but doable. All of them have different mass. Now you decide to put some of them out of the can. And you for example made a mistake, you need to put them back, and others out again.
Every item must be tagged in the database where its positioned, probably by placeholder IDs. If that means 1k item stacks for 1 cargo hold that may be moved with one drag and drop and then moved again, that means 1k database entries updated x2 with their new location. Per player. Then you need to find them and calculate the new weight, then calulate the new speed and slope capability and apply them to the robot.
And this should happen for every can looting, every reloading, every mining, harvesting, stack splitting, storage stacking,....
The process can be optimized to an extent like only updating latest changes in cargo hold contents and adding /subtracting the differences only, but that system can make mistakes easily and you can never optimize the extreme problems like adding the complete cargo at once. See where I'm getting at?
Cheers o/
EDIT: cleared some typos.
Yes, i'm agree. This is a lot of calculation, but we dont know certain how implementing of this system will affect server performance, because server-side written by DEVs not us . So time will show. I really want to see less such weird thing in this game.
Also 1 other thing. I think that slope capability is calculated when you login / deploy to terrain ,so that the map of the island is calculated for you where you can go and where you can not. This can not be changed on the fly i think with current mechanics, but is doable otherwise
I could be wrong and the DEVs already have it cooked up
o/
Ignoring physics one one hand then suggesting fixes to mechanics that require it on the other hand makes my head want to explode.
Either the cargo is materially in the hold, which means you'd need a bot larger than a Mech to carry a mech, or its not materially in the hold. Since a sequar can carry a mech, it can't be materially in the hold. Therfor the arguement about mass vs speed is moot.
From a game play standpoint, moving slower with cargo is not fun. I don't care how much memory it takes on the game server, or how the game database can be setup to allow for it. 90% of the transport people will just stop playing, the other 10% may continue to haul at 15kph, but the game will grind to a halt from lack of material.
And the transparent troll by OP to try to slow sequars down to make them easier to kill is transparent.
The only basis we can evaluate this on is in terms of game interestingness - not physics. Would the game be more interesting if empty bots were faster? Yes, there would be slightly more choices and consequences.
Really weird: installed modules changes speed, but huge cargo dont.
would be logical if speed is reduced because the additional modules leave less energy for movement
but is not logical if game mechanic try to tell us its because of weight
but afaik there was somehow explained that cargo is nor a real playe in ur robot but a dataspace where the data of the stuff u teleport into ur cargo bay is stored
and one ur unload it u teleport it out of this dataspace back into real world
this would explain why cargo have no weight
because u dont carry the stuff
u just uploaded the stuff into ur teleporter cargo bay
and bigger bots have a larger dataspace to upload more information = more volume data
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
Generated in 0.048 seconds (81% PHP - 19% DB) with 23 queries