Fixing 0.0625 Min Timer limit

[mrzwach]

Okay, anyways, if any of you have tried to create a projectile system or custom movement system, you probably have noticed that there is a minimum interval for timers/periodic events/waits of 0.0625 seconds.

However, I figured out a workaround for it.

Basically I have a dummy unit in a corner that has a customized EMP ability with a Prepare Time of 0.03125. Then, I have a trigger that runs when the ability finishes casting, which will start a timer with 0.0625 intervals. My periodic event for moving stuff fires both every 0.0625 seconds and each time the timer expires.

Tested it, and it works.

EDIT: Jesus4Lyf from TH forums found a better, more efficient fix.

The way I discovered that was by using 0.0 waits, which seem to equate to 0.03125 in single player (God knows if that's the same for b.net, though - timers on 0 period still go to 0.0625 it seems, so...).

 

[Mepper]

Hm this is a pretty clever way around this problem. +rep!

 

[Redoubt]

Map init
Wait 0.09375 seconds
Turn Trigger 2 on


Trigger 1 - Initially on
Periodic - Every 0.0625
Run Whatever


Trigger 2 - Initially off
Periodic - Every 0.0625
Run Whatever

Surely that would work better. If it works at all.

 

[Dr Super Good]

Well, apparently it would round your Wait 0.09375 seconds into whatever linear it is on so it will actually run both at the same time.

 

[mrzwach]

Yeah, I tried that and it didn't work. I think it just rounds it to sixteenths of a second.

I would like to use a more efficient work-around, but doesn't really seem like thats possible. :\

 

[Hero_Lief]

Of course, there not needing to BE a workaround would be better.

 

[Dr Super Good]

I would like to raise the question of why do you need something running so fast...

Try using the data editor to create someting that behaves like you are after and then using triggers to add the rest. Eg the projectiles could be units or actors which are moved by the game engine itself, you then update the projectile direction and stuff every 0.06 seconds via triggers. This would be far better than WC3's equivelent which will often be slower than the screen update rate or be faster than the update rate if someone has a slow PC.

 

[Quantum_Menace]

Periodic behavior effects also appear limited to this. ARGH.

The reason I need it this fast are to make projectile collisions as accurate as possible, and because I haven't found a way to "stick" units together (as in, have a unit attached to another unit's position and facing).

Updating the unit's position and facing at 16hz looks terrible.

 

[mrzwach]

It looks pretty good at 32hz, unless you have very fast moving units/projectiles.

 

[Dark.Revenant]

A FPS system essentially requires a 0.01s period or shorter. This fix is very helpful...

 

[Dr Super Good]

A FPS system essentially requires a 0.01s period or shorter. This fix is very helpful...

You are talking nonsense.

A FPS system needs only as many frames as are displayed per second. Generally 60.
As for collision accuracy, try improving your system so it looks ahead of the projectile. HINDYhat did this even in WC3 where it could even calculate the precise time of a collision even at a very slow frame rate.

 

[Dark.Revenant]

I'm not talking about projectiles. After all, as I'm sure you noticed, first person shooters are not the only games that use projectile systems. What I'm talking about is the fact that there is no native to return the position of the mouse, only the position of where the mouse clicks.

However, using the functions to find the player's camera yaw and pitch, mouse control can be used to control a crosshair or to customize how the FPS camera moves. However, this requires the camera to snap back at a frame rate higher than the players'. There's a debug function that returns the FPS, but the frame rate could be anything, really, even above 60fps. Frame rates above 60fps are unlikely, but you can never be too sure.

I created a proof-of-concept map that allows the player to use the mouse to control a crosshair image on the screen. I have not implemented mrzwach's workaround yet, so the snap back is very obvious and annoying, plus the crosshair does not move very smoothly. Of course, there is a 100-250ms delay on the crosshair movement, which is probably something that cannot be changed.

Why not just use a custom cursor and detect the UI location of the clicks, you ask? Well, with my method, you can track the current UI position of the mouse, have some kind of turret control method on a vehicle, or extend it to control the camera instead of the crosshair for a true FPS experience, or any number of things.

 

[Dr Super Good]

Your method will probably fail outside of singleplayer.

Anything camera related requires syncronization and so running a sync option 200 times a second will cause commands to be unresponsive due to the net traffic, latency would also kill it.

 

[Dark.Revenant]

It can also be done locally and then updated/sent to the server when something important happens (you know, like an actual FPS). Only the player's crosshair X and Y position would need to be put through the network. Even if it's 60+ times per second for everyplayer, something like that is not impossible to sync for a game that relies heavily upon such a system.

Either way, there is no other viable method for a full FPS experience. The built-in mouse-controlled camera movement is very limited, but it can be kludged into a state that is viable for a TPS.

 

[Dr Super Good]

Most FPS do not use 100% tight syncronization like RTS games do. In FPS it uses a lot of approximations and reduced sample rates. Hits are usually calculated asyncroniously and sent out. I am not sure SC2 can support this kind of syncronization.

 

[Dark.Revenant]

It may be an engine unoptimized for the task, but i figure that 25 KB/s is not hard to maintain for the modern internet gamer (25 KB/s is the cost of sending a 2x16 float array 100 times per second), and I doubt that anyone but the host would have to stream even half that for this system.

The main argue point, really, is the latency; the camera yaw and pitch (and target, too, I suppose) are always about 200ms late. In other words, the laggiest player's ping will decide the playability of the map.

 

[Quantum_Menace]

My collision system is 100% data editor content, which is why I'm frustrated by the timer limit on periodic behavior effects. I had hoped to avoid having to trigger it at all.

I could add some extra enum areas that look farther ahead in an arc, but projectiles don't always go straight, and are also supposed to collide with each other, and this setup won't help if they approach at a right angle.

I may have to just settle for slower shots with larger hit areas.

 

[Dr Super Good]

It may be an engine unoptimized for the task, but i figure that 25 KB/s is not hard to maintain for the modern internet gamer (25 KB/s is the cost of sending a 2x16 float array 100 times per second), and I doubt that anyone but the host would have to stream even half that for this system.

The average gamer has 40 or less KB/sec upload (I have 800KB/sec DL and 40-30KB/sec UL)... Inorder to get a decent latency you are looking at having a upload of 400 KB/sec which is not available to most people in the world at an afordable price. Firstly 2(arrays)*16(elements)*32(bits per float)*100(per second) is 100KB/sec. Secondly you clearly know nothing about computers as you have the package data which is additional size (a few bytes per package) + resends and other protocle dependent data. As you can see your idea is total logistical nonsense.

Quantum_Menace, or learn some maths...
Have you never stoped to realise that you are after working out when 2 lines intersect?. . . HINDYhat managed to work out circular intersections in WC3. With some more complex math you could do something like it in SC2 for even curvy projectiles.

Also there must be a reason why blizzard did not do this, perhaps they have provided some other way to create what you are after which you are not aware of existing.

 

[oops_ur_dead]

Cause, you know, you absolutely HAVE to send everything about the game, all the variables and shit, regardless of whether or not there is a change. And, you know, NOTHING is local in SC2, so you have to send all the data over the internet to be able to calculate it. By your logic, it would be impossible to access the internet, because you have to first download the entirety of it before you can go on it.

Also, for your argument to be correct, a person would have to be making 100 actions per second. I think at most people will make 20. That is an absolute maximum, the real number is probably around 10, since ping for most FPS players tends to be about 100. That makes even your faulty calculation a lot more manageable at 10-20 kbps

 

[Dr Super Good]

oops_ur_dead, your first comment is making little sense and unclear who it was aimed at.

RTS games sync via orders. Basicaly it is syncronized such that orders will run exactly on the same frame, even if peoples clients are 1-2 frames off and any given time (why there is a background latency to help allow this). Every order you issue sends data to everyone giving the representation of your units on their client those exact same orders. Other data has to be specifically syncronized inorder for it to be able to execute without it causing 2 players clients to start exibiting different results (OOS) which is why there was latency on trackables and the keyboard buttons. Additionally this is why the TriggerSleepAction was slower in multiplayer, as it had to syncronize the wait due to it being inexact even in single player.

FPS games on the contary send approximation data as to what the players and NPC/AIs are doing, like WoW and MMORPGS. The entire game runs pretty much on 1 server usually (to reduce cheating) or many in the case of WoW and MMORPGS. The data the player receives is approximations of what other characters around them are doing which are updated 5 (old games) - 20+ (newer) times a second. These packets are small consisting of prety much cordinates and status data for each character near by. Additionally the packets of far away players you never receive. In the games, the clients are usually not in sync at all to what is happening, however they are constantly being resyncronized which is why characters and stuff can appear to jump and do stupid stuff at times of "lag" (freelancer was notourious of this and WoW I believe exibits this). As the data being transmited is small, the packets are small so the ping is low due to less time being spent transmiting the data.

FPS games on consoles might use asyncronous client syncronization, where your client sends weather a shot hits or not to the server which relays the action. Additionally movmenet data and stuff is based on your client (free lancer and most games use this which is why cheating can occur). This is the least lag prone as you will hardly ever notice lag caused misses due to it prety much treating you as playing in singleplayer with perodic updates. However this is not usabled for PC games due to how easy people can cheat with it.

 

[cookies4you]

im pretty sure blizzard will allow full controls of timers and the time limit in later patches or the real starcraft II. most likely, the timers are limited to the times needed for projectile speeds, as opposed to those required for FPS projectile systems. that, or we can storm blizzard inc. with pitch forks, torches and cheese to command them to GIVE US OUR .01 TIMER INTERVAL LIMIT!!!!

 

[Dark.Revenant]

WC3's timer interval was way faster than 0.01, so I'm wondering why SC2's is so different. There has to be a reason, but I'm drawing a blank.

Also, I'm betting that there's a way to sync the system at a 0.1s period and when the player clicks the mouse, while it goes on locally at 0.01s.

 

[Dr Super Good]

I do believe that SC2's triggers might have some form of multi thread support (mentioned multiple times in the native list I think) and so the timing intervals might be related to that.

Like I said, if blizzard keeps it like this, then obviously they have not intended timers to be used for projectile systems. Try looking at effects and data as perhaps you can bind a function to them there which updates as fast as needed. (I know you can bind AI functions to some data but not sure about effects).

 

[Dark.Revenant]

I use the data editor for projectiles, but the camera isn't a projectile.

I'll find a way to do this properly, eventually.

 

[Quantum_Menace]

Data editor effects appear forced into the .0625 second increments, as I noted earlier. Even weapons have a maximum firing rate of 16 times a second.

I'm of the impression that the 1/32 second "fix" doesn't help at all. If I set a trigger to repeat endlessly with a 0.0 wait and display the X coordinate of a moving unit, it repeatedly gives me pairs of the same value. It's as if the wait tries to increment .03125 seconds, but the actual action is forced into the next .0625 second increment.

Either that, or the unit's position is not actually updated any more than 16 times a second.

 

[oops_ur_dead]

They're probably gonna change the intervals before release. They already cut down the latency, so its fully possible they'll change the timer intervals.

 

[Dr Super Good]

Data editor effects appear forced into the .0625 second increments, as I noted earlier. Even weapons have a maximum firing rate of 16 times a second.

WC3 had this same cap or atleast simlar. Limited to eithor 8 or 16 attacks per second.

 

[Quantum_Menace]

Movers are also limited by this.

I set up a projectile that never changes its height (horizontal throw followed by guided with no pitch or roll) to get it to spin in the air above its target. Setting the yaw rate (as displayed in raw data) to 1440 (4 rotations per second) makes it move in a square pattern, showing it will only change its direction 16 times a second.

At least this means there's no information loss between the intervals; you can tell where the projectile's actor was between intervals by linear interpolation.