Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Need we "ingame time since world creation" variable for ingame scripts?

Discussion in 'Programming (In-game)' started by krypt-lynx, Oct 12, 2017.

?

Need we "ingame time since world creation" variable for ingame scripts?

  1. Yes, current ways to calculate time intervals are to complex to use/impossible to use

  2. No, current API provides enough tools to do it.

Results are only viewable after voting.
Thread Status:
This last post in this thread was made more than 31 days old.
  1. krypt-lynx Apprentice Engineer

    Messages:
    174
    There is ongoing discussion about request to add a way to obtain ingame time since world creation.
    Saying in another way, to add Internal variable which represent count of logic ticks passed in the world.
    It will allow to track scaled ingame time affected by SimSpeed in easy way.

    Current way to track time is to use Runtime.TimeSinceLastRun. It works fine inside single game session. But it don't work then game load happens. This property have 0 as value inside Save method(), which prevents reading in Save() method and also have 0 value at first run after game load.

    Arguments:

    "We don't need it":
    - It can be implemented using currently available methods: combination of Timer Block and Runtime.TimeSinceLastRun.
    - Nobody uses it anyway.
    - This is metadata

    "We need it":
    - Current possible implementation is too complex.
    - Runtime.TimeSinceLastRun is designed for different purpose.

    About "this is metadata" argument. Despite I'm disagree with this argument in general, it does not even matter.
    It can be easily avoided: only way to count the time does matter, not starting point. Any random offset can be added to this counter and idea still fill work.

    Idea on feedback site: https://feedback.keenswh.com/idea/a...riable-for-use-in-ingame-scripts59df9db0c4630

    Feel free to discus it. I will add extra arguments in this message there if you will post it.
     
    Last edited: Oct 16, 2017
    • Like Like x 2
  2. Forcedminer Senior Engineer

    Messages:
    1,991
    if it does work we can all go.

    Captains log
    gametime 12 hours 31 minutes
    I'm on my way to an earthlike planet I intend to land a small grid craft there with a surplus of parts
    to setup a refining and construction factory
    [​IMG]
     
    • Like Like x 1
    • Funny Funny x 1
  3. Ronin1973 Master Engineer

    Messages:
    4,238

    Well a double in C# has 16 digits of precision. That's 9,999,999,999,999,999 ticks that can be accounted for. That reduces to 16,666,666,666 seconds of time. That's 277,777,777 minutes of gameplay or approximately 4.6 MILLION hours of gameplay. I don't think anyone will be playing for that long. But technically, it's feasible to count every game tick that's happened and then develop a relative amount of game time that's transpired based on a 60 ticks per game second... which probably won't sync to the clock on the wall since 1.0 sim speeds aren't always possible.
     
  4. krypt-lynx Apprentice Engineer

    Messages:
    174
    > which probably won't sync to the clock on the wall since 1.0 sim speeds aren't always possible.
    What is the point. We need a reliable way to calculate this scaled time if SimSpeed was not 1.0. Actually, just a count of ticks since world creation will be equally good.
     
  5. Rasip Trainee Engineer

    Messages:
    9

    A double is a floating point number and there is no fraction of a tick a floating point number would take up a lot more space in ram and the save file (also, that is 16 binary digits precision). You would want to use an int which goes to 2147483647 which is over 414 days. If that isn't enough you can go for a long which goes to about the age of the universe.
     
  6. Pharap Apprentice Engineer

    Messages:
    175
    You're right about everything but floating point numbers using more RAM.
    A float is the same size as int (4 bytes) and a double is the same size as long (8 bytes).
     
  7. krypt-lynx Apprentice Engineer

    Messages:
    174
    > You're right about everything but floating point numbers using more RAM.
    > A float is the same size as int (4 bytes) and a double is the same size as long (8 bytes).

    Your system have at least 4 gb of ram. x64 applications uses 16-byte memory alignment. And you trying to save 4 bytes? :p
     
    • Agree Agree x 1
  8. Ronin1973 Master Engineer

    Messages:
    4,238
    I agree. We're talking about adding one variable to the entire game that updates every tick. While a year's worth of game play seems like enough time, I would rather just go with a ludicrous amount of capacity so it will never be an issue.
     
  9. krypt-lynx Apprentice Engineer

    Messages:
    174
  10. Ronin1973 Master Engineer

    Messages:
    4,238
    Being able to get the number of ticks that have transpired since the game's beginning would be very helpful for scripting events. There is a whole host of little tools, if added to the game, would allow content creators to make a more challenging scenario or multi-player server. Most of the work on updates seems to be about fixing existing bugs and optimizing sim speed. That's great, as it should be. But to make the game blossom, we need to be able to access more feedback from the game.
     
Thread Status:
This last post in this thread was made more than 31 days old.