Jump to content

artoo

Community Members
  • Posts

    161
  • Joined

  • Last visited

Posts posted by artoo

  1. 3 hours ago, Stan` said:

    That seems incorrect to me, in fact I started a scifi mod some time ago, with the goal to make it an alternative to starcraft, and walking speeds were the least of my concerns. The ability to make mines sockets and to stop flying vehicles were more annoying that that. Of course the huge number of new buildings and their design to make was also worrysome.

    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.

  2. 2 hours ago, Freagarach said:

    As I (and others) said earlier, the values _are_ mꞏ*s-1. The values are "realistic" in the sense that a ~4.5 m tall person _might_ be able to walk this fast (ignoring any physical constraints of our structure at that length).

     

    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.

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

  4. 3 minutes ago, Loki1950 said:

    it's a composite compromise with several different scales to make displaying the game elements possible/understandable and easier to code the underlying simulation so the actual units are just abstractions not connected to the real world

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

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

  6. 5 minutes ago, LetswaveaBook said:

    We should indeed really find the real life pierce damage value of an Javelin! Our current value seems not good for gameplay IMHO.

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

    Here comes walk and run speed into play, can you escape a Javelin for example, by horse maybe etc ...

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

  8. 4 minutes ago, Lion.Kanzen said:

    Yes, this is a daunting task.

    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.

     

  9. 4 minutes ago, Lion.Kanzen said:

    could you create more physics?

    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.

  10. 15 minutes ago, hyperion said:

    Ok, create a cube of 1m x 1m x 1m in blender and import it into 0ad. IFF a unit with effective speed of 7 moves anything other than the distance of 7 cubes lined up per second it's a bug. Anything else you find confusing or unreal goes under artistic freedom.

     

    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?

    • Like 1
  11. 47 minutes ago, Stan` said:

    So the actual default value is 9 not 7.

    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.

  12. 19 minutes ago, LetswaveaBook said:

    am not sure about this, but I feel that once you get 21 years of experience you will realize

    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.

  13. 5 hours ago, Freagarach said:

    I'm not an expert and maybe @bb_ has more input on this.

    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.

  14. 4 minutes ago, Reyhan said:

    There is another solution: make this unit completely unaffordable in most games

    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.

  15. 14 minutes ago, ChronA said:

    This is the same **** that makes people keep changing the projectile gravity to 9.81!

    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.

  16. 3 hours ago, Freagarach said:

    Here is your answer, @artoo. If one would scale the units down to ~1.5 m (so roughly divide by three), the walk speed can be reduced without looking strange.

    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.

     

  17. 11 minutes ago, Lion.Kanzen said:

    It is only to be patient.

    I am, I tracked down the bug. :yes:

     

    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.

     

  18. 13 minutes ago, alre said:

    It's all about making the game play in the desired way.

    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.

  19. 23 minutes ago, Stan` said:

    Note that actor variants define the animation speed.

    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.

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

×
×
  • Create New...