snatcher

You want to increase it a little? How about 6 minutes between saves with a maximum of 4 "soft" saves and a 5th "hard" save. That way we have a permanent save every 30 minutes of gameplay. __auto_1.save __auto_2.save __auto_3.save __auto_4.save __auto_20250121193402.save

I now understand what is going on and how to approach the misleading getTime() and wait() at a millisecond level. Thanks, stgatilov.

My advise is to ship the mod the way you like it. Period. If you think your mod is too extreme and want to please a broader audience then try to get that sweet spot. Configurable settings should always be your last option.

Thanks nbohr1more! It all is in there. We are moving from: (2.12) Vertical Sync No and Uncap FPS Off to: (2.13) Vertical Sync Yes and Uncap FPS On. I don't personally care to be honest, but it is worth noting players will soon get marginal differences depending on their setup. It would be nice to measure 2.12 (capped 60fps) vs 2.13 (uncapped 300fps).

This is how wait() cascades in the source code: void idThread::Event_Wait( float time ) { WaitSec( time ); } void idThread::WaitSec( float time ) { WaitMS( SEC2MS( time ) ); } void idThread::WaitMS( int time ) { Pause(); waitingUntil = gameLocal.time + time; } realClientTime from getTime() and time from wait() seems to be the same at a point in Game_local: // update the game time framenum++; previousTime = time; time += idMath::Imax(int(timestepMs * g_timeModifier.GetFloat()), 1); realClientTime = time; this->minorTic = minorTic; Therefore both getTime() and wait() are not reliable, at least, for precise timed events. I truly hope someone makes me look like a fool! I don't want any of this to be true.

Vertical Sync On or Off seems to produce varied results as well. My conclusion is that getTime() is not reliable, at least, for precise timed events.

Can anybody explain what is going on here? Download the script attached to this post and place it in script/tdm_user_addons_tic_test.script Script contents: void user_addon_init_tic_test() { float waitTime = sys.getTime() + 0.5; while (1) { if (sys.getTime() >= waitTime) { sys.println(waitTime - sys.getTime()); waitTime = sys.getTime() + 0.5; } sys.waitFrame(); } } Launch any mission Check the console Switch Uncap FPS On and Off and/or toy with the Max FPS Go back to the mission and check the console Can you see how the output varies greatly depending on the setting? I didn't expect a perfect zero every time by any means but since we are putting "time" to the test and not "frames" I expected consistent outputs regardless of the FPS settings. This is what getTime() does in the source code: void idThread::Event_GetTime( void ) { ReturnFloat( MS2SEC( gameLocal.realClientTime ) ); } tdm_user_addons_tic_test.script

Well done @chumbucket91 ! The mod works just as advertised

Yeah, the imperfect but reasonable gamma counterbalance is somewhere between 1 and 1.1. Thanks for the feedback, thebigh. One benefit of this change is that brightness can now be increased and whites stay in check. 2.12; gamma 1.2; brightness 2 2.13b1; gamma 1.2; brightness 2 It is worth noting that in 2.12 the brightness slider goes from 0.5 to 2 and in 2.13b1 brightness goes from 0.5 to 3 therefore I don't know if my comparison is fair. Once again, I am just trying to be constructive before this goes to the bin.

What I detect here is that with gamma set to 1 the game already looks a tad darker than before, but not too much to raise any alarm. I find this solution a good compromise if we are to embrace the new tone mapping. The Dark Mod shouldn't be shy about darkness anyway. By default, that is.

Mandrasola: Some windows have lost their mojo 2.12 2.13b1

@Taffingtaffer, @Baal, @Daft Mugi, @Frost_Salamander, @thebigh, @JackFarmer, @kingsal, @datiswous What do you think? I don't fully understand this change but I am sure there are good reasons behind it it and that the math checks. I am just trying to stay positive.

An addition to my, never acknowledged (too much asking, I know), previous report: AT1: Lucy's quest: funny things going on in the background during the briefing

Screenshot?

The implementer simply forgot to set the gamma to 1 by default (where it actually belongs). With gamma set to 1 blacks are a tad darker, whites aren't as bright and saturation is improved. Do please compare 2.12 with gamma set to 1.2 (default) and 2.13b1 with gamma set to 1 (not the default).