I would like to make a post about a few little things I observed with Thing creation/removal and multiplayer unsynced cogs. When testing CW mod in multiplayer, I noticed a little thing that should not have been. There is a scope section in a cog that runs using a very fast pulse, the cog is flagged to be totally unsynced. The problem was that whenver I toggled a scope, lag would errupt. I typed in the ping command many times and, ping skyrocketed up to about 2000msec and more for extended periods of time. Something I should point out is that the scope uses Things for a crosshair image, a scope "camera", and a "look vector" template. In the first version of this code, each of these was rapidly created, camera would be set, then destroyed in the next pulse where the camera would be created and set again. This was somehow causing lag in multiplayer, yet the cog was totally local.

So I came up with a theory of why there seemed to be lag produced by the scope code. You know, JK never seems to mess up the Thing count and ID system in multiplayer, not even with locally created and destroyed Things. It must be because the every Thing created, local or not, must be logged somehow to prevent confusion with other Things on other sides of the game.

Take this scenario for example. I have a locally created thing on my side of the game and it is ID'ed as Thing # 1337. That will make the next thing created in the game be Thing # 1338, but what about the other players game? On his side of the game, Thing # 1337 does not exist. The next thing created in his side will be # 1337. So lets say a new thing is created now globally. When a verb or whatever code is executed on that thing, how does it manage to execute on the correct Thing on all sides of the game when the Thing count is not synchronized? That's the thing, the count must be synchronized. Anything in a local cog is not sent across the network, but if a thing is created locally, it is forced to keep the count and ID's up to date.

Also something that adds to this theory is that I simplified my scope code to have less thing creations. Instead of creating a scope image Thing, scope "camera" Thing, and a "look vector" Thing rapidly, I created the image and scope "camera" Things only once, only to be reoriented every pulse. I did this instead of having Things created and destroyed in a new position every pulse, so I would no longer be messing with the Thing count at an extreme rate. The "look vector" remained rapidly created and destroyed though because it was my only way to retrieve the player's "true" look vector. I had this tested immediatelly in multiplayer and the lag was significantly reduced to something waaay more acceptable for my 56k. The ping commands I ran rocketed up to about 700msec instead of something close to 2000msec when I toggled the scope.

I posted this for all too see because I know it is usefull when dealing with local cogs. It is especially usesfull for a camera or scope I have just described, and is most essential for a Thing-based first-person weapon.

I am not entirely sure how the JK engine works with these sorts of things and I might not be entirely correct, but it seems to have worked for my own modding purposes.

[edit] I mispelled Theory in the thread title.

Hmmm, interesting. Someone should really do some scientific tests about this matter. Rapid pulses are quite crucial for many mods...
Are you sure you couldn't have avoided a lot of your pulses with attachements?

Why would you ever have a rapid pulse in a global COG?

Also, how fast are your pulses? I notice a lot of editors feel the need to make their pulse delay something like 0.000000001. 0.01 is fine. That's 10 milliseconds, more than enough.

If what I read is true, a pulse: message is only processed, at best, once each frame (rendered). So whether you set the pulse to 0.0001 or 0.00001, pulse: will only be called once per frame. So while 0.01 should be enough, 0.0001 (and so on) just makes sure you get a pulse: call each frame.

Personally, I use 0.1, with a rare 0.01, and I use 0.001 when I want a pulse: call per frame.

QM

I never even thought of that.... Well, that *might* explain some of the bugs in my vehicle coding. Hmmmmmm, more testing, greatttttt :p

I've had short pulses running only at 0.05 and they still manage to fill the console buffer before the external GUI console can display them. Which leads me to believe it's much faster than once per frame.

[irrelevant]Pretty sure 0.0001 is the fastest JK supports[/irrelevant]

Keep in mind 0.05 is 20 pulses per second, which would be a relatively low framerate. JK framelimits to about 60 which would be a pulse of 0.016666, so that should be the fastest possible pulse that'd function, assuming you're getting 60 FPS and JK can only call pulse: once per frame at fastest.

Does JK truncate decimals at the 6th decimal place, or does that only apply when using PrintFlex()?

QM

The framerate limit is dependent upon whether you have vsync on or not...jk can run at close to 5000fps in the right situations
Rounding on numbers isn't based on decimal places, it is related to the size of the number (larger numbers lose more precision). The jk console probably limits the numbers to a certain number of decimal places when printing, but internally they don't have that same rounding.

Is there a vsync setting in JK? I never managed to find one, and I have vsync off in every other game I play. I always hated being stuck at 60 in JK.

QM

There isn't one, you'll have to force it off in your video drivers, or you could look for a setting that sets the default refresh rate in full screen to something other than 60 (I think at least ATI's drivers have this, and there are other ways to change it too).
If you are getting a cap of 60 though, you probably want to look for the setting that changes the full screen refresh rate though, because no vsync + 60hz is still 60hz refresh, even though the game runs faster than 60hz without vsync.

Woah, cool, Sige is right. 140 fps on canyon oasis, 450 on really low settings.

I think you're on to something.

The reason I posted this is because thing creation is synced no matter if the cog is local or not. I know that created things are used a lot in fast pulses like crosshairs, cameras, weapon models, even to just retrieve the player's "aim vector". This needs to be kept in mind because mods like SS3 usually ban the use of crosshairs because of lag, even on fast connections.

I don't use any attachments because they don't stay in a postion around the player perfectly if it's offset from the player. Especially when the player rotates while stationary, the attachment will stay in place and rotate, but it's position wont align itself with the player, unless he's moving.

The pulses I used to go at 0.005 and they now go at 0.01, but I might set it back to 0.005 if it doesn't look good after I try those framerate tricks.

I noticed that all really long decimals in JK and JK-related stuff stop at six digits a lot. In JKL's, there are always things like "vel=(0.000000/3.000000/0.000000)", "movesize=0.012300", etc.

I don't know if pulses are independent from framerate or not, they seem to be, but sometimes they don't. At least the fire message seems to be dependent. You can sometimes hear inconsistant firing sounds in fast weapons at lower framerates.

For your mod in particular PO, since you use thing based weapon models, consider using the traditional POV model system to add the crosshair graphics so you don't have to use an additional thing for them. Also, this will keep the crosshair graphic from getting weird looking when you press into a wall. Personally, I think your earlier usage of the POVShake to similate a scope was nicer than your newer thing-based camera system.

QM

Thats a good idea, but I don't know if I can get the crosshair pov to shake with the camera, but I guess that would be realistic. I scrapped the SetPovShake because I couldn't seem to get the crosshair Thing to be synced with the SetPovShake offset, it seemed to be off by a frame or so and wouldn't stay in position all of the time. Make a camera Thing and teleporting the crosshair to it seemed to keep it in place.

What the... I turned off Vsync and all of the sudden antialiasing in JK starts working... I never knew...

Are you sure the scope/crosshairs still lag even when on a local cog, because even if the thing count increases, this still doesn't mean JK keeps track of the thing and its properties regularly, such as posistion, pyr/lvecs, health, timeleft, etc, for what JK might do is only increase the thing count and not sync anything else, but I couldn't think of any way to test this theory.

I think it only affects the count, so if your creating/destroying an object every pulse that's where the problem might come from. I changed my scope from a camera that is destroyed, created, and reset every pulse, to one that is created once and then repositioned every pulse. Lag seemed to have went way down on that one.

I take that back, I remember now that it was in a loop in startup, not in a pulse.

Are you sure this is the case? Most of my multiplayer testing has been done on a LAN but I haven't noticed any extra lag creation when I was careful to assure things were done locally.

Could you show us the cogs?