Further time options

[gtav-ent]

We have reasonable requests for:

• forwards/backwards 5 mins
• forwards/backwards 24 hours (different API)
• "real time", i.e. like system sync but without the sync
• different slow motion speeds, including fast ones

These should be addressed at some point. A left/right << selectable >> menu item might help here.

[dratom]

I tried for a bit to freeze frame the game using the api called for slow motion but it only goes down to 0.0075(or maybe it was 0.075). When you set the time that far down you can see the individual rain drops when it's raining but it takes so long to do anything that it is more or less just a pretty site. It would be pretty neat if it was possible to set the players move speed either high enough to offset the affect(effect?) of lowered time or to set the the player's ped speed independently of the world's(I gave this a shot as well but I was unable to set player's move speed above 1.49(set_ped_move_rate_override looked promising but I was unable to get much use out of it), I also tried increasing anim speeds but was unable to affect anything noticeable). There's also the possibility of exploiting the native game freeze that occurs on game pause(figuring out how to unfreeze the camera and player are likely a separate can of worms).

I did notice however that if you use the airbrake (F6) feature after setting the time rate to min possible then you can move around easily. This probably because the ped movement is set and adjusted outside of the native code environment by appending offset coordinates and is not subject to native anim speeds.

I got off subject a bit there. Back to the feature requests.

I believe there is a set calandar date api that would likely satisfy the "forwards/backwards 24hrs" request. The other three request are likely achievable with that set_time_scale api.

Would these additions all fit under the same submenu as the current "slow motion"?

[gtav-ent]

Some good info there, thanks!

Regardless of all this, the almost-stopped time speed would be a good addition to airbrake mode. As you suspect, airbrake works at normal speed because it's programmatic movement done on a per-frame basis rather than using physics.

I too tried the trick of making the player fast in a slow world but it made no difference. I'd be a bit surprised if it was possible.

There is indeed a 'set calendar' API which is straightforward except for the usual date wrapping (e.g. no 30th February) which presumably is covered by some existing C++ code somewhere.

Yes, they would all go in the Time menu.

[dratom]

If you have not already taken care of this (the github app I'm using atm is awkward with commits and whatnot) I would like to give it a shot, I'll be free and at my pc within the hour.

Thank You for the detailed response and it makes me feel less failure filled to know that you too had trouble with time - speed.

[dratom]

To clarify I was referring to the 24 hour/5min +/- additions to the time menu when I said that I'd like to take a whack at it. I would try at the multiple speed options but I think that addition would work better as a menu row with multiple position strings. Kind of like a toggle that cycles thru [0.075x,0.5x, 1x, 2x, ...]. Sometime ago I attempted to add an additional menu class but I ran into more hiccups than I had time to fix and ultimately don't think I'll have better luck this time

[gtav-ent]

Go for it - just assign this issue to yourself first.

[gtav-ent]

And I'll add the menu class to support the latter at some point; that's probably one I'm best suited to as I wrote the others.

[dratom]

I looked around the page and I don't seem to be able to assign this issue to myself.

[gtav-ent]

Oh, apparently you have to be a collaborator. Never mind, I'll assign it to myself, carry on!

[dratom]

Thanks for that. I have finished the menu updates and I've added a pretty time lapse option as well. I'll submit it just as soon as I am satisfied all the bugs are gone.

[dratom]

Tested and submitted.

[dratom]

In retrospect I should have rewritten the hour forward hour backward code that was already in the time menu. For some reason the existing code doesn't populate on the ingame phone screen if you have it open when you change the time, I used to think this was normal behavior until I tested the code I just submitted and noticed that the phone clock changes in real time when using the options I added. I have to get some sleep at the moment but Ill probably assimilate the existing code tomorrow if you do not have any objections.

[gtav-ent]

Sounds good to me - I'll hold off merging for now then, as a proper release of 22 is due out later.

[gtav-ent]

I've done the selectable menu item thing. Have you got any experience of what times work well? I can't get much above 1x to do anything.

[dratom]

I've been playing around with this as well but I've had zero success with raising the game speed even a little. I assume whatever limits decreases below 0.075 is also limiting increases above 1.0. Is there perhaps a way to see what the API does behind the scenes or at least what bits it sets? I'm thinking the api rejects anything out of the the aforementioned range and we can bypass this by directly setting bits(I've not yet tried setting bits manually but there are enough examples in the native scripts that it shouldn't be too hard to emulate). If all else fails I can try to spy on the api calls with an IDE but it's been some time since I used one and I'm not sure what I've retained.

[dratom]

Also awesome job on the menu additions, there are 101 improvements that were waiting for that( thou I'm blanking atm ).

[gtav-ent]

I resorted to reading the Native DB docs like I should have in the first place, and that told me two things:

• 1 is the maximum
• 0 is the minimum, but doesn't equal stopped

so for now I'm going with a set of 0.0f, 0.1f, 0.5f, 0.75f, 1.0f.

[dratom]

I usually check Native DB first and decompiled scripts. (* the decompiled scripts are updated regularly enough that it's a good idea to download a fresh copy every few days or so. Same goes for natives.h, but there are few ways of knowing when these are updated as the download links on dev-c do not have linear naming schemes and at least for natives.h they are generated at the time of download). As for natives.h I've resorted to keeping a copy of the last one i downloaded and doing a compare in n++ with a fresh copy to see what's been updated and/or added since there are no other tells for what or when new deobfuscated titles are added.

[dratom]

I'm still curious about what bits the API SET_TIME_SCALE sets since the acceptable range does not occupy 1 byte much less the standard 4 bytes for a float value, also freezing the game completely is somewhere in the source bits seeing as the game freezes completely on pause. Is the scripthook disable when the game is paused? I gave minimal effort to attempting to disable the pause menu filter after invoking a pause but quickly abandoned the effort after noticing that any api overlays disappeared upon pausing. . . . looks like it's back to the drawing board. MUST RESIST SUMMER SALE >>>>> resistance is futile >>>>>> productivity failing >>>>>> beep boop

[dratom]

I just noticed that I didn't get to the point I was trying to make about Native DB after getting off-topic with the script updates. I was originally going to note that it is worth trying values outside of what the comments and or arguments point at as the updates to the arguments are often argument changes from int to float or even from char to int. I'm just trying to point out that the methodology employed in pulling the arguments forward to nativeDB is only accurate to a area not a point. There also seem to be a bit of inconsistency in the native game with signing as there are several places where int>>bool -1 | 0 int>>bool 0 | 1 are mislabeled in arguments. This suggests some ambiguity in the int / uint translation in either the native code or the scripthook. Considering how long this game was in development and that it was originally written for PowerPC and has been ported to x86 would make either case just as likely if not a bit of both.

[gtav-ent]

OK, so some notes:

• there's a native in there somewhere that lets you set whether a particular script can be paused. I haven't tried it. We don't set it on ours because we don't really want to show anything whilst the pause menu is up, and thus are quite happy to be paused.
• remember that all the API calls we make are not direct interventions but calls to R* script methods that probably accept/reject certain parameter values, and seemingly do their best to avoid crashing the game on dodgy script calls. Therefore the byte width etc is irrelevant, unless you were finding the internal memory locations and working on them, which we're not.
• the inconsistency is almost certainly on the R* API designers' part. In general -1 makes for a sensible 'don't care' or 'default' value, but you have to wonder why e.g. the vehicle extras are 0 to turn on, -1 for off.

[dratom]

I still think it's worth considering that the scripthook is mishandling or at least mislabeling the arguments it passes and if we consider field size or at least bit placement there are a few places where this can be tested.

I think the use -1 for off and 0 for on has significance worth exploring and may be related to the above point.

First consider what -1 translates to on a binary level. When passed to an integer field of any size (assuming 2's complement signing) it will setting all the bits in that field to 1.

This tells us that if any argument that achieves different results when passing a -1 as opposed a 1(11 as opposed to 01) and a -1 as opposed to a 0(11 as opposed to 00) is for whatever reason giving significance to the 2nd bit (when counting from Least Significant Bit).

This can be tested by comparing the results of passing a 2 and a -1 (10 and 11). (I took a short break at this point to replaced the -1 with a 2 in vehmodmenu.cpp and test the results. Passing 2 to the last field in VEHICLE::SET_VEHICLE_EXTRA instead of -1 did not break any part of the Vehicle Modifications menu.)

As I see it there are two probable explanations for this behaviour. Either A) In the places where we see int in arguments that are functionally boolean there is the possibility that we have been setting 2 or more fields with 1 number (this might help explain why some API's seem to have been named polar to what their functions are).

B) I don't know what to put for the second explanation it is more of a placeholder for something akin to "It's not significant because if it was It would already be known or at least obvious to anyone of my lack of Ignorance." Or the more popular "If it compiles it ships" abstraction.

As for why -1 is used to disable and 0 is used to enable my best guess is that the bit that is set after masking with 2 is something of a "is other/stock addon set" bit.