So, cogging is not my strong point. I just want to make sure that this abomination will work for both client and server. I don't want it updated or renovated unless it has to be. I conjured up this beast on a whim, and I'd like to just stick with things that I know work, since testers are hard to find.

Yes, it's ugly, but will it work for all parties involved?

I'm not too experienced with multiplayer cogging; however, I would suggest the following:

Make a server-side-only cog to handle the "toggle" status and a client side cog that locally damages/heals the player based on the "toggle" status (set locally by a global trigger).

If I have time, I'll write up a cog that will do this later.

i strongly suggest removing the 'flags=0x240' completely. this will ensure the cog is run on the host and its effects synced to clients appropriately; i see little reason to make this a purely local and unsynchronized cog.



no cog flags:
1) Joe walks up to a switch and hits space
2) An 'activated' event is sent to the host
[network lag]
3) The host executes the script. Each command that changes the environment (eg. PlaySound, SetWallCel, etc) is implicitly sent as encoded events to the clients
[network lag]
4) The client hears the sound, and sees the mat change

this host-authoritative model is why your lag (as a client) causes switches and doors to not work immediately after pressing them. to combat this, people often use the flags=0x240 trick to allow each client to process the events they trigger immediately, but requires the use SendTrigger to let all the other players know that the door opened.




flags=0x240
1) Joe walks up to a switch and hits space
2) Joe executes the 'activated' event. This calls SendTrigger to send a trigger event to all players, (including himself)
3) Joe executes the 'trigger' event. He hears the sound, and sees the mat change
[network lag]
4) Other clients recieve the 'trigger' event Joe sent, they hear the sound and see the mat change


i dont remember which flag corresponds to which, but one flag (eg. 0x200) specifies that the cogs effects will not be synchronized, and the other flag (eg. 0x40) specifies that the cog can be run from any client. you usually see either neither flag or both flags because only having one has strange effects.

for example, lets say you have a game with four people. if you set only the 'cog can run from any client' flag and Joe activates the switch, the 'activated' event will be run four times (by each player), and the effects synchronized each time. this results in the switch being toggled on, then off, then on, then off again, or a seemingly random on/off pattern. the sound effects will be played four times simultaneously and it is a big mess.

on the other hand, let us pretend that you only set the 'cog effects will not be synchronized' flag and Joe activates the switch. the switch is turned on only for the host, regardless if Joe was the host when pressing the switch. the host will see the switch turn on, hear the sound effect, etc. and to everybody else nothing will have happened.



another thing to note is with flags=0x240, each client has his own set of variables. the variable 'toggle' might be 0 for Joe and it might be 1 for Bill. if care is not taken to utterly ensure synchronization through trigger events, the trap might be on for one player and off for the other. this dualistic nature might be useful in some cogs though, for example a bank account per player and corresponding 'transaction triggers'.

whereas with no cog flags, only one set of variables exists (for the host) and this ambiguity will not occur.


edit: note that flags=0x240 may still allow the cog to appear 'synchronized' because the 'activated' event will still be processed by each player, but there is a catch: if (due to lag) Joe was not exactly in front of the switch on Bill's game when he pressed space then according to Bill the switch was never pressed. this is the reason triggers MUST be used with 0x240, and 'activated' events whose sender does not match the local player must be discarded.