artoo

Yeah, a c&c generals like mod is in my mind, using accurate physics. The scale multiplier decoupled from actual speed definitions would be required. If I had a team to plan a mod using 0AD engine, it would be essentail to know eg scale. As it would be now, I would have at least one coder in the team effectively forking the engine and make changes, or pick another engine probably and no extra coder.

And I pointed out, that if you just remove the scaling factor from essentially input parameters, your balancing team works against real values, nothing would change, you just remove the multiplier from walkspeed input and have it multiplied with the real speed. Just like run speed is done. Anyhow, I have my answer, your engine would not be suitable for say a scifi mod, if speed input works on undocumented upscaled values. Thanks, close the thread.

From my view, I can conclude the thread. @Stan` and your team, don't take it as harsh criticism. I think the situation would already be cured a bit, relatively immediately code wise, if you give your balancing team real life values to work with. If the dev team hid away the scaling factor or left it in the template wouldn't matter so much.

Which make balancing so hard. Who of the average balancers does differential equations, factors in various scaling factors when attempting to balance it? Hands up please.

An idea I have, I could be made so, that eg a Persian horse run fast, very fast compared to other civ horses, a distinctive feature of the Persians. Ie Persian horses could be a very valuable trade good. Back to Javelin, a Persian horse could narrowly escape a javelin, assuming a max speed of ~23 m/s or 82.8 km/h.

I think a gold standard, ie real life values to benchmark whatever against would be a good thing. I di have real javelin data. Assuming 800g Jav, it would be thrown about 30-40 meters with a speed of ~20 m/s. I am not sure how the cav in 0AD does many maneuvers without stir ups. Here comes walk and run speed into play, can you escape a Javelin for example, by horse maybe etc ...

The reason I think it would be better to have the engine run on real life values is, you can accurately balance this. Could be a separate little project, I think it is a lot easier to balance everything against true scale first, like you calibrate a balance, once this is done, it should and hopefully scales. Easier to use real values than doing wild guesses in a scaled model.

Right, and priority has what fills the fridge. Here is a mock up unit motion entity snippet: <UnitMotion> <FormationController>false</FormationController> <PassabilityClass>default</PassabilityClass> <WalkSpeed>1.9</WalkSpeed> <ScaleMultiplier>3.6</ScaleMultiplier> <RunMultiplier>3.3</RunMultiplier> <InstantTurnAngle>0.8</InstantTurnAngle> <Acceleration>3.1</Acceleration> </UnitMotion> 1.9 m/s = ~7 km/h ScaleMultiplier would be the factor to multiply with (could default to 1), atm, 3.6, 3600/1000 the conversion between m/s and km/h, which is the minimum that walk and run animations somehow need to be fluid in one game second.

If you change the physics so the earth day has more hours, yes. Apart it would be almost full time job, doubtful. Btw, I am saying, calibrate walk speed to real values, and introduce a scale multiplier fo those who want, require need it.

You still set blender to eg metric, using meters, yep, and a scene is still a given time in seconds? You have ranges in meters and projectile speeds that are close to realism, but walk speed, nope, in fact use avg km/h speeds in m/s. If you were tasked to add a default human walk speed in m/s to a simulation, would you expect funnily a value that matches the km/h avg human walk speed, or a pretty off sounding m/s value? If I was to make a say scifi mod, and wanted accurate physics based speeds, would the actor view show me proper animations, given it has a fallback values of 7 and 12? 12 is also a good pick for a human run speed btw. Would my mod using the game engine run smoothly with real values, Or would I have to adjust to a certain factor too?

It defies all logic to use 7 or 9 m/s for walk speed, like arbitrary, but these are sane values in km/h.

Still same thing, why is this 9 km/h if the documentation is m/s? Unless you walk 9m in one second? Kind of very misleading, a dev assumes from the values set km/h, if code comments state "lets take the human walk speed here as default" and wonder about m/s documentation. Atlas' actor viewer is operating in km/h for walk & run animations. I would expect in the templates given the m/s documentation a value of 2.5(9km/h) but not 9.

I will realize its pointless to talk devel issues with players. But seriously, it may be meaningless to a player, but this is an issue the dev team should look into. If the values are a mistake, this could impact performance, and effect also gameplay, like formations might behave differently and few other things. Just because the units are scaled 4m, you still want to have a close physics simulation, and not like weird Gs, and an undocumented factor, modders need to be aware of and always carry over that factor, otherwise you waste lot of time.

This is what I am also interested in. If indeed the default speeds are km/h, but the engine expects m/s, and editor has also km/h set in the game interface, would this little inconsistency trigger the redoing of say animation sequences, so the engine runs on a real walk speed? The factor should be about 3.6 atm I guess, is this deliberate choice or mistake? If it is choice, then unit motion values in the entity template should probably in km/h then? It would explain much if it is a mistake, why the balancing of movement seems like mission impossible when using m/s in the templates. Despite the fact, it would be possible in theory to nicely simulate human and horse movement, including speeds and acceleration.

Very powerful unit, best limited in numbers, but Han may only have 2 champ unit types. Not sure yet.

I think that would the the right direction to take. The Han elite archers also have capability to switch to fire arrows. I was considering simply a limit, say one regiment of 20 can be built only. An upkeep could be added to make them expensive as well, so you can't field many of the champ units.

Correct, as upstream did with a patch that's probably not included yet. You should not be having like 5x the G to make projectiles look ballistic, and that's not so much related to size and scaling. This is a RTS, real time strategy simulation, the engine has parameters, in SI units. Other RTS have an entire physics engine, so what G is set as default matters for example.

Yes, thx, I arrive at a factor 3 roughly, and I was wondering where and why this is set. Hence my attempt balancing has a 1:3 range approach, ie max bow range is 1/3 of real range. Anyhow, I think the simulation is wrongly calibrated so to speak, depending if 7 m/s was deliberately picked, or a mistake made using actually 7 km/h without conversion to m/s. The editor has 7 and 12 set for walk and run speed, same there, km/h or m/s? 12 km/h would be a proper run speed too, but 12 m/s, well, that's a Cheetah.

Would be nice if I found myself proper time to make a phab acc, go through the process, to open a review request for patch, along with the balancing I have in a branch on GH.

I am, I tracked down the bug. source/simulation2/components/CCmpUnitMotion.h, line 248, it sets a walk speed of 7.0. Code explicitly documents m/s, so 7 m/s is wrong, should be 1.9 and all will be fine in terms of yet to achieve balance. I would call this a bug, unless deliberately chosen for mysterious reasons.

As a 20 years software developer, this pains me to read.

Correct, 1.5 is a conservative walk speed, if you take 1.8 or 1.9 m/s, like maybe jogging, you get ~7 km/h. So something is off with the walk speed, 7 m/s is like roadrunner, unless 7 km/h were meant to be set, ie ~1.9 m/s.

I am basically telling you, there is most probably a bug, inconsistency between m/s and km/h, which is significant. Unless this is an undocumented feature, when all values are in m/s, should be a bug, wrong default/fallback value. Its a difference if the unit moves with accurate 1.5 m/s in game, or 7 m/s, if probably 7 km/h was in mind of the dev, ie got confused, which can happen. To make it clear, convert 1.5 m/s to km/h.

I was on the hunt for this mysterious factor that seems to apply to walk speeds, ie the physics of unit motion. The Editors's ActorViewer.cpp in my view gave a hint, it looks to me as if the mysterious factor is about 7, which pretty good approximately matches my current 1.5 m/s walk speed times atm factor 4, using accurate acceleration etc. 7 km/h would be a avg walk speed, but isn't it supposed to be m/s? I think somewhere in the code might be a mismatch between m/s and km/h for walkspeed, and hence all derived speeds like run. Simply put, my hunch is, instead of using default values in m/s, somehow km/h sneaked in. Would be little bug with big effect, like accurate walk speed of 1.5 m/s has to be multiplied by a factor to have fluid motion.

@Stan` Is the documentation on walk speed wrong? I get the impression the unitmotion walk speed is in km/h, not in m/s as documented? If I use accurate 1.5 m/s walkspeed, the animations are too slow. If I use km/h, all is pretty nice? Edit: Looking at actorViewer.cpp l. 401, it looks as if the default value for speed is too high, hardcoded? 7 f? m/s or km/h? The latter would kind of be accurate.