Ideas
I think it is possible to do so.

Looking through the source recently I saw that a demo is basically just the packets sent by players to the server(obviously). So each part of the packet describes position, yaw, pitch, and other values at that point in time.

When you play a demo you are reading the positions, yaws, pitches, etc. from each packet and interpolating to fill in the gaps. I don't see any reason you couldn't play those packets in the opposite direction. Or even skip packets.

Speaking of packets, I noticed that the packets have the potential to vary in size. I wonder if it would be possible to reduce the size of packets sent to the server while some constant action is taking place.

For instance, when a player is afk/dead, must they really attempt to send 25 packets per second telling the server their position, yaw, pitch, etc? If something like a variable width packet is possible the first bit of data might describe whether any action was taken by the player. If no action is taken the server knows they must be standing still and there is no need for the server to receive position data(or any data for that matter). The first bit tells the server no change was made and the server just uses the previous packet's data.

More generally, until some change has taken place between two packets is it really necessary to update the server with every bit of data? If I'm running in a straight line down a corridor, maybe swinging my aim around, the only thing that has changed is my position, yaw, and pitch. Why not just send the data that has changed? Upon firing my weapon I can report to the server that such action has taken place and the server becomes aware of my new status. And maybe every 25th packet is a standard packet updating the server on every detail.

If it's not possible to do so during a live game I would like to at least see it done in demos. I think you could reduce the file size of demos substantially by doing so.
Thanks given by:
(25 Jul 12, 08:07PM)Mael Wrote: Looking through the source recently I saw that a demo is basically just the packets sent by players to the server(obviously).
Actually, it's the packets sent from the server to the (i.e. all) clients, but you got the idea.

(25 Jul 12, 08:07PM)Mael Wrote: So each part of the packet describes position, yaw, pitch, and other values at that point in time. When you play a demo you are reading the positions, yaws, pitches, etc. from each packet and interpolating to fill in the gaps. I don't see any reason you couldn't play those packets in the opposite direction. Or even skip packets.
Correct, but that's only true for the position packets. There are others as well (e.g. shoot, reload, died, item spawned,...), look in protocol.h for the full list. To roll those back, you'd need to undo whatever effect they had (e.g. "revive" a player, add ammo back into the magazine,...). As you noticed, the demos consist of packets as they were sent during the game. They incrementally rebuild whatever happened in the game, contrarily to e.g. a (non-compressed) video where every frame contains all the information available for that specific point in time.
Sure rewinding a demo is still possible, but it would be a PITA to implement, and you'd basically have tons of code just "mirroring" the functionality of other code.
Skipping packets, on the other hand, is completely impossible for anything but position packets. Well, not impossible of course, but the game/demo would completely desynchronize.

(25 Jul 12, 08:07PM)Mael Wrote: Speaking of packets, I noticed that the packets have the potential to vary in size. I wonder if it would be possible to reduce the size of packets sent to the server while some constant action is taking place.
You would be correct, but basically there are no packets being sent for constant action. Even the position packets will almost always have some delta to the previous one (position - even if it's just rounding error, orientation, velocity). You'll hardly ever stand completely still.

(25 Jul 12, 08:07PM)Mael Wrote: For instance, when a player is afk/dead, must they really attempt to send 25 packets per second telling the server their position, yaw, pitch, etc? If something like a variable width packet is possible the first bit of data might describe whether any action was taken by the player. If no action is taken the server knows they must be standing still and there is no need for the server to receive position data(or any data for that matter). The first bit tells the server no change was made and the server just uses the previous packet's data.
Something like this should be possible, at least for dead players.

(25 Jul 12, 08:07PM)Mael Wrote: More generally, until some change has taken place between two packets is it really necessary to update the server with every bit of data? If I'm running in a straight line down a corridor, maybe swinging my aim around, the only thing that has changed is my position, yaw, and pitch. Why not just send the data that has changed? Upon firing my weapon I can report to the server that such action has taken place and the server becomes aware of my new status.
Well, but that's exactly what's happening already ;) The only thing that's being sent continuously is the position packet with position, yaw/pitch/roll etc. See above.
Thanks given by:
(25 Jul 12, 09:12PM)tempest Wrote: Sure rewinding a demo is still possible, but it would be a PITA to implement, and you'd basically have tons of code just "mirroring" the functionality of other code.
I must've been wrong.
Maybe you can only skip back in time not rewind?

What exactly was implemented in SVN?
Thanks given by:
Rewind isn't actually a rewind in the sense that it plays back gameplay in reverse until it is paused or resumed, but that it skips back in time by the specified amount.

setmr jumps to the specified minutes remaining.
Thanks given by:
(25 Jul 12, 08:03PM)Z3R0 Wrote:
(25 Jul 12, 06:19PM)Nightmare Wrote: being able to /newmap 7 /newmap 8 etc. on a server.

Wait. What? D: You can do this already, no?

V-Man couldn't yesterday, and I've never been able to, on a normal server. D:

Edit Update: You need to be in edit mode just to do so. Which stillllllll requires a coop-able map to be ready. Hence /newmap 7 while in standard mode would be a nice addition. <3
Thanks given by:
How aobut we seperate the normal server list and modded server list.
First "Join a Server"
then choose:
"Join a Normal server" (show the normal sever)
"Join a mod server"(show the modded server)

and Auto download. for parts on maps like a models, sound, texture,etc ( there's no files you download from server when u are playing other server or singleplayer)

-this message by my little brother [SODA]__Pico__ becuase he is bored playing ac and then he wants me to post this.
Thanks given by:
(26 Jul 12, 01:24PM)Nightmare Wrote: Hence /newmap 7 while in standard mode would be a nice addition. <3

Would be nice, but another mastermode would need to be added for coop (or something like that, idk). That would stop people joining matches, typing /newmap 7 and leaving :>
Thanks given by:
Make it vote-able like modes. D:
Thanks given by:
Or that.
Thanks given by:
Yea votable. Then idiots can vote it in and halt gameplay entirely.
Thanks given by:
(28 Jul 12, 01:10AM)Mael Wrote: Yea votable. Then idiots can vote it in and halt gameplay entirely.

Exactly my trail of thought. Imagine getting all jiggy with it on a 10vs10 sniper@camper, then a /newmap 6 vote comes in.. It gets F1'd, you get nubs accusing/kicking/banning people of fly hacking, spawn killed.. Structures similar to that of the male anatomy drawn on the floor in a sand texture, an infinity kill/frag fest with no time limit.
Thanks given by:
How aobut we seperate the normal server list and modded server list.
First "Join a Server"
then choose:
"Join a Normal server" (show the normal sever)
"Join a mod server"(show the modded server)

and Auto download. for parts on maps like a models, sound, texture,etc ( there's no files you download from server when u are playing other server or singleplayer)

if would be more awesome on assaultcube
Thanks given by:
No lies, a modified server list would be nice. It's a bit silly to completely erase them, as some are quite fun. I think could only be implemented IF server owners specify exactly what their mod is...
Thanks given by:
hmm.... i see
Thanks given by:
Everytime I play on ac_douze, I think it would be great to have this mode :

LSS ac_douze, but the goal is to stand the longest on the middle platform (the pillar). Maybe with a countdown or something ^^. If 2 players are on the pillar, no one has his countdown decreased.

I wish I could do it myself, but it's hard to get any information on how to do this (I only know CubeScript).

Btw, a Mafia mod would be awesome :D. (role play chat only)
Thanks given by:
Been thinking about this for a couple days now:

Stoppage time? In match mode, if someone disconnects whilst in game, the match freezes and the time it takes before the disconnecting client to reconnect is accumulated and added onto the end of the game. Alternatively, the clock could also simply pause whilst the disconnected client is gone. This saves the hassle of everyone spamming 'STOP!11ONE' during a match!

This might also have been suggested, but:

Disabling teamkills after the round is over? There's nothing more irritating than a death to be added to your score after a decent TOSOK round by some baffoon on your team who is under the impression that once the round is over, teamkilling is legal for five seconds. So, why not give them what they want? Everybody wins :D
Thanks given by:
(28 Jul 12, 03:44PM)Ashxelor Wrote: (role play chat only)

ಠ_ಠ
Thanks given by:
What ? xD

Why not having totally different and inappropriate mods ?
Thanks given by:
@spamma: Very good ideas. Even though the idea of freezing the match when someone disconnected has already been mentioned long time ago, adding the idea of "extra time" of the time a player was d/c'ed is awesome. Devs must read this.
Thanks given by:
It really needs to be a pause feature though, due to TKTF.
Someone disconnects during our games, and we have to drop the flag, ruining our rally.
devs y u no do it?!
Thanks given by:
(30 Jul 12, 01:36AM)#M|A#Wolf Wrote: @spamma: Very good ideas. Even though the idea of freezing the match when someone disconnected has already been mentioned long time ago, adding the idea of "extra time" of the time a player was d/c'ed is awesome. Devs must read this.
Adding to this, maybe a limit could be added, so if a player disconnects for longer than any given amount of time, the match would end...
Thanks given by:
nope paul, ending a game solves nothing
Thanks given by:
(31 Jul 12, 04:31AM)Xenon Wrote: nope paul, ending a game solves nothing
Well at least it would help to decide when its been long enough before a player can come back? I mean, shouldnt there be a limit to how long can someone disconnect? Sometimes people might not agree on what is long or short enough, thats where my idea came from...
Thanks given by:
You already have the option to pause the game. There's no need to set a time limit. We'll just be arguing over what the limit should be then.

There was substantial debate over the afk-kick timer. I imagine a game-ending timer would be more divisive.
Thanks given by:
Would be great to be able to edit the brightness of a mapmodel directly, and/or have "negative" light/shadows.
Thanks given by:
Why would you want that? Are you trying to simulate a light-emitting mapmodel? If you are I'd just place a few lights in/around the model. The model and its surroundings will be illuminated appropriately.
Thanks given by:
It should be clear in my context that I want to darken mapmodels. When they get too bright/darker would look better.
Thanks given by:
I like that idea. For example, if you're trying to make a platform blend in with the ground texture, lighting can make it stand out by being too dark/light. It's especially obvious with multiple models very close.

Ofcourse, you can just mess with light values to try and fix it.
Thanks given by:
Tip for working with that is not to put the light at the same square that the mapmodel is place on. Only only one lighting effect is put on the model. Only the square that you put your model on will provide a light value for the mapmodel. It isn't independent for the mapmodel. Because of this, you may want to move your light away from your mapmodel a certain distance. You almost never want it on the same square.
Thanks given by:
I have the light several cubes away and the model is too bright. Are you saying only the closest light is a applied to the model? Like I can make a less bright light in the same square to darken it?

Append: Doesn't seem to work for me. I like the brightness of the cubes the model is on, but not the brightness of the model itself.
Thanks given by: