Is there a Time & Date command in script (4 game Save & Load)?

#1 @Leroy, the getRealTime and getSimTime console functions provide timestamps ... which are interger values representing the number of (milli)seconds since either the OS epoch or the simulation start ... check those out ...

as for the IO code, no clue...

#2 Thanks David, I'll check those out, any way of getting the date through script also?

#3 Leroy, the date is in the value returned ... it's just not in a "readable" format :)

#4 Oh, understood, thanks David! :0)

#5 For me, gerealtime() is returning me the time since the computer is running, not the actual date and time.

The thing that disturbs me is that the actual time and date is showed at the very start of the console log. So there would be a way to now them by "reading" the first console line (though I don't know how to do that in script) and then adding the sim time to the init time to have the actual time of the save.

#6 Thanks for that Benjamin, I think I could read the data from the console file (guessing off the top of my head, although i'm not sure). Only other thing is, does the console file get created in the same or similar fashion when the game is packaged/released?

#7 Yep, it does ^^

#8

ConsoleFunction( getTimeStamp, const char* , 1, 1, "Get a timestamp YYYYMMDD_HH.MM.SS_ms"
                "the milliseconds (ms) should be taken w/ a grain of salt.")
{
   static char retBuf[128];
   Platform::LocalTime lt;
   Platform::getLocalTime(lt);

   S32 ms = Platform::getRealMilliseconds() + 300;

   ms  = ms - ((ms / 1000) * 1000);
   ms /= 10;
   
   dSprintf(retBuf, sizeof(retBuf), "%4d%0.2d%0.2d_%0.2d.%0.2d.%0.2d_%0.2d",
      lt.year    + 1900,
      lt.month   + 1,
      lt.monthday,
      lt.hour,
      lt.min,
      lt.sec,
      ms);

   return( retBuf );
}

#9 Thanks for the confirmation Benjamin :0) Thanks for the code example Orion! :0)

I'm having a go at these right now! I'll update what I achieve (or don't) later! Thanks again guys!

#10 1. I don't think it's possible to read the console.log as it's in constant use, you can't even copy the file.
2. I keep getting a parse error with the code given Orion. (Is this intended for the source code? If so, where is it suppose to go?)
3. getRealTime and getSimTime don't make any sense to me as I have nothing to compare it to anyway? Isn't that what it's for

I have to say, I find this all a truly bizarre, even QBasic has functions for getting time and date (if I remember rightly), and Im pretty sure it's somewhat necessary for save/load systems among other things, so who's got the resource/function that is needed for this? I can't believe this is a original feature request because it seems like people generally aren't all that sure how to do it?

I'm just a little surprised that with all of torquescript's sophistication and power, it seems to be missing very simple, basic functions. I thought it was simply a case of the date/time command not been added in the help/documentation. It just shouldn't be this complicated and long just to get time and date.

Forgive me in advance if this reads a little aggressive/negative (not my intention) or I'm misunderstanding something here...

#11 The code example i gave is engine-side. that is, it's C++. i would put it in main.cc, right below getRealTime().

and yr right, it's a bit of an outage that there isn't a getTimeOfDay function in stock torque script.

#12 Thanks much Orion, it works a treat! :0) Only one problem, after successfully fixing the '#include "platform/platformAudio.hreal" error in the main.cc file, rebuilding the exe seems to of caused some problems with the file reading functions and has basically messed up my user profile reading system :0(

Being a C++ novice, it's seems I have next to no chance of going through c++ code and correcting the problem :(

So thanks very much to all again and if you have any other thoughts/solutions, they will be more then welcomed! Now I'm trying to contemplate the prospect of trying to release a game with no date/time saved in the save/load system, oh boy! :-S

#13 Ai yai yai. yah, it sounds like it might be simplest to skip this part for now.
eventually you'll probably want to recompile the engine for one reason or another,
but if it's fooling with behaviour of scripts i'd give it a pass for the time being.