Campaign Creations

A handful from me:

- X knocked their own head off and got it lodged where the sun doesn't shine.
- We found X's license plate. Does anyone want to marry it? (GLaDOS reference)
- X just zapped X but blew up and went sky high.
- X crashed into X's cycle. The result was too gruesome to describe here.
- Where the heck did X go?
- X exploded and rung X's bells in the process.
- X bounced off X's front tires and sent them crashing. X followed soon after.

I just watched the first FFS playthrough of it, the first match, the vent commentary was fucking hilarious.

Indeed. :p

Btw, it's possible to get fairly cheap mics to go on Ventrilo. Still using the one that came with my Pentium II 433 mhz right now.

That must be why your quality is so TERRIBLE

How do you get the camera to move smoothly and respond to mouse rotation at the same time? I'd check it myself BUT I CAN'T.

Magical wizard powers!

But seriously, I enable CameraForceMouseRelative and CameraSetMouseRotates, and simply issue the move order at a polar offset relative to player camera yaw in the main update thread (which iterates 32 times per game second or ~48 iterations per real second of Fastest).

Too bad battlenet imposed latency and the engine interfere with responsiveness; the latency introduced is less severe than it would be for input capture, which would nearly double the time between input and response, a problem simply avoided by getting camera yaw instead of trying to track mouse input. The engine also imposes a limitation like how the event manager communicates with the galaxy virtual machine, to a limit of 1/16 game second precision, so while the main loop updates 32 times per game second, the camera yaw value is only updated 16 times per game second.

Of course there has to be a limit somewhere, a player's camera data is asynchronous, but it just seems silly the synchronization occurs in 1/16 game time precision rather than the more basic 1/32 game time precision the engine is based on. Not that it's terribly important, for most applications, but time sensitive shit would benefit from a control on that, some throttle.

EDIT: Update is still in the works. I procrastinated for a bit, but am back to scripting shit while my modeler makes some high poly custom vehicles.

Sounds like the same inconsistent bullshit they've been pulling since Diablo 2.

Blizzard still thinks Extra High Latency helps with packet loss/disconnection.

I meant, how did you get the camera to follow the unit smoothly? Pan camera disables mouse rotation unless it's done instantly, which is choppy, and follow unit group lags behind the unit.

Not that the camera choppiness matters anymore for me, since there seems to be another unavoidable choppiness in something I tried to work with. There also doesn't seem to be a way to force-rotate a mouse-rotated camera by an offset angle... hmm...

Is there really that much more input lag? Also, do you think that multiple mouse/key triggers would lag more? Logically registering just one event would enable transmission of mouse and key data between players for use by all trigger events, and multiple triggers wouldn't make the same data be pointlessly sent multiple times. Not that Blizzard is necessarily logical...

And TBH, I haven't even seen any significant evidence of anything being run at 32 times per second. Everything I've ever seen only runs at 16.

If I got it right, and the lag almost confirms it, the camera is not following the unit, rather the unit is following the camera.

Glad you asked that Xenon; there is some debate with regards to whether additional input trigger events cause more lag, but we do not have quantifiable empirical evidence of this yet. There is anecdotal evidence that shows more triggers result in more lag and that disabling input triggers has no effect, as the events remain registered in the event manager. The lag itself is caused by synchronizing the data 16 times per game second across all players; I'm sure you can imagine how bad this can be on top of the imposed latency.

In any case, I have a pastebin up of the Input script I wrote that captures all key, button, and mouse input and stores it in a struct array (there is a GUI version I had someone make on sc2mapster). It simplifies input capture, effectively working how we would like for it to work natively, easy as accessing a variable, it reduces the input capture to 5 triggers maximum (key down, key up, button down, button up, and mouse move), which can be disabled by the user via the constants at the beginning of the script.

About the camera, it tracks the unit smoothly since I reduced the Target Smooth, Smooth Time Minimum and Smooth Time Maximum to 0.1 in the Cameras data.

Yeah, I saw that on Sc2mapster along with the lag discussion, which is why I asked.

I might have to test whether the difference in the detection of camera yaw and mouse movement is actual or just perceived, since the camera gets moved in real-time and outputs the angle, making it easier to control precisely than when getting delayed feedback from the mouse.

I'm gonna be on vacation for a week.

Back from vacation, working on the update. I've probably done more today than I had in the weeks before I went on vacation.

NO F'ING GAPS! I'm in.