Constant color change
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
-
Inuyasha_989
- Posts: 612
- Joined: Thu Oct 16, 2003 2:51 pm
- Location: Player Connector
- Contact:
Constant color change
I was playing Skulltag online the other day, and i saw 1 of the players was switching colors simultainiously while still playing the game, i kept asking him untill he said that it was scripted and that i could come here to find out. plz tell me if u can thx
ROFL. I made a quick alias list to do this and found a (bug/quirk/oddity) in the process. It's pretty funny, though.
To see it yourself, just start a game and enter this at the console:
] alias cycle "color \"ff ff ff\"; wait; cycle"
] cycle
Look at the Doomguy's face while you play.
To see it yourself, just start a game and enter this at the console:
] alias cycle "color \"ff ff ff\"; wait; cycle"
] cycle
Look at the Doomguy's face while you play.
Last edited by HotWax on Thu Oct 16, 2003 5:21 pm, edited 1 time in total.
Fun with color:
Rainbow man: (With side effect above!) ^_^
] alias cycle1 "color \"00 00 ff\"; alias cycle cycle2; wait; cycle"
] alias cycle2 "color \"80 00 80\"; alias cycle cycle3; wait; cycle"
] alias cycle3 "color \"ff 00 00\"; alias cycle cycle4; wait; cycle"
] alias cycle4 "color \"80 80 00\"; alias cycle cycle5; wait; cycle"
] alias cycle5 "color \"00 ff 00\"; alias cycle cycle6; wait; cycle"
] alias cycle6 "color \"00 80 80\"; alias cycle cycle1; wait; cycle"
] alias cycle cycle1
] cycle
Rainbow man, but only while running:
] alias cycle1 "color \"00 00 ff\"; alias cycle cycle2; wait; cycle"
] alias cycle2 "color \"80 00 80\"; alias cycle cycle3; wait; cycle"
] alias cycle3 "color \"ff 00 00\"; alias cycle cycle4; wait; cycle"
] alias cycle4 "color \"80 80 00\"; alias cycle cycle5; wait; cycle"
] alias cycle5 "color \"00 ff 00\"; alias cycle cycle6; wait; cycle"
] alias cycle6 "color \"00 80 80\"; alias cycle cycle1; wait; cycle"
] alias +colorrun "+forward; alias cycle backupcycle; wait; cycle"
] alias -colorrun "-forward; alias backupcycle cycle; alias cycle"
] bind X +colorrun
Where X is your normal move forward key.
Stealth man! White while he runs, but pitch black when he stops moving:
] alias +colorrun "+forward; color \"ff ff ff\""
] alias -colorrun "-forward; color \"00 00 00\""
] bind X +colorrun
Where X is your normal move forward key.
(Okay, the last two examples only affect the move forward key, but you can easily adapt them for strafe, turn, and backpedal... and jump... and swim/fly... and attack... etc etc etc.)
Rainbow man: (With side effect above!) ^_^
] alias cycle1 "color \"00 00 ff\"; alias cycle cycle2; wait; cycle"
] alias cycle2 "color \"80 00 80\"; alias cycle cycle3; wait; cycle"
] alias cycle3 "color \"ff 00 00\"; alias cycle cycle4; wait; cycle"
] alias cycle4 "color \"80 80 00\"; alias cycle cycle5; wait; cycle"
] alias cycle5 "color \"00 ff 00\"; alias cycle cycle6; wait; cycle"
] alias cycle6 "color \"00 80 80\"; alias cycle cycle1; wait; cycle"
] alias cycle cycle1
] cycle
Rainbow man, but only while running:
] alias cycle1 "color \"00 00 ff\"; alias cycle cycle2; wait; cycle"
] alias cycle2 "color \"80 00 80\"; alias cycle cycle3; wait; cycle"
] alias cycle3 "color \"ff 00 00\"; alias cycle cycle4; wait; cycle"
] alias cycle4 "color \"80 80 00\"; alias cycle cycle5; wait; cycle"
] alias cycle5 "color \"00 ff 00\"; alias cycle cycle6; wait; cycle"
] alias cycle6 "color \"00 80 80\"; alias cycle cycle1; wait; cycle"
] alias +colorrun "+forward; alias cycle backupcycle; wait; cycle"
] alias -colorrun "-forward; alias backupcycle cycle; alias cycle"
] bind X +colorrun
Where X is your normal move forward key.
Stealth man! White while he runs, but pitch black when he stops moving:
] alias +colorrun "+forward; color \"ff ff ff\""
] alias -colorrun "-forward; color \"00 00 00\""
] bind X +colorrun
Where X is your normal move forward key.
(Okay, the last two examples only affect the move forward key, but you can easily adapt them for strafe, turn, and backpedal... and jump... and swim/fly... and attack... etc etc etc.)
Thought I'd revive this thread because of discussion I saw on the Zdaemon forums about this. Some people who should probably know the details of the code are stating that use of such a color-shifting alias causes "lag" in the game, that the changing colors either cause extra graphics load on the clients or cause extra network traffic. Does anyone have a well-informed opinion? Actual test data?
I can't see the logic behind the view that changing player color continually will have any impact on the game performance (zdoom or zdaemon). The data about each player's color is sent over the network in what I assume is a continuous or frequent pattern and certainly isn't much beyond RRGGBB. The client machines always have to render the player sprites and I'd think it irrelevant what color is used or whether the color changes, each screen draw takes the same process whether colors change or not.
It looks as though, due to concern about game performance, the Zdaemon folks decided to somehow disable this sort of alias (or all aliases?) in the just-released 1.05.
I can't see the logic behind the view that changing player color continually will have any impact on the game performance (zdoom or zdaemon). The data about each player's color is sent over the network in what I assume is a continuous or frequent pattern and certainly isn't much beyond RRGGBB. The client machines always have to render the player sprites and I'd think it irrelevant what color is used or whether the color changes, each screen draw takes the same process whether colors change or not.
It looks as though, due to concern about game performance, the Zdaemon folks decided to somehow disable this sort of alias (or all aliases?) in the just-released 1.05.
Well, here's why it's a concern.
Each time a client edits a piece of his userinfo, he sends all the information about his userinfo to the server (name, color, team dm team, etc). This is something like 30 bytes (I'm not at home, so I'm just guesstimating here).
Now, when the server receives this, it tells all clients (aside from the one who just updated his userinfo) about the updated userinfo block. Now, we don't actually send ALL of the userinfo to each client (after all, not all clients need to know things like the "neverswitchonpick" status of other players), so it ends up being something less, like 20 bytes. However, if we're doing this like every tick, each client is going to be receiving a significantly larger amount of data each second than they would otherwise. This could potentially result in increased lag.
It's not really a concern of slowing down the game; it's a concern of more lag due to increased bandwidth consumption.
Each time a client edits a piece of his userinfo, he sends all the information about his userinfo to the server (name, color, team dm team, etc). This is something like 30 bytes (I'm not at home, so I'm just guesstimating here).
Now, when the server receives this, it tells all clients (aside from the one who just updated his userinfo) about the updated userinfo block. Now, we don't actually send ALL of the userinfo to each client (after all, not all clients need to know things like the "neverswitchonpick" status of other players), so it ends up being something less, like 20 bytes. However, if we're doing this like every tick, each client is going to be receiving a significantly larger amount of data each second than they would otherwise. This could potentially result in increased lag.
It's not really a concern of slowing down the game; it's a concern of more lag due to increased bandwidth consumption.
Hey Carnevil, thanks for explaining that. I didn't realize that userinfo was just sent once, until it is changed. So, the impact of such an alias is a bit more data being sent, which can be a problem with modems. I'd still say that as far as slowing the client frame rate due to rendering "lots of color changing bodies", that is probably a mistaken idea. The bodies are rendered anyway and the color is immaterial.
Well, as Steve T. demonstrated recently, the skin color changing can be done directly with a multi-line alias, not needing an exec command, unless some of the alias commands are new enough not to be in the zdaemon 1.05 code.
Well, as Steve T. demonstrated recently, the skin color changing can be done directly with a multi-line alias, not needing an exec command, unless some of the alias commands are new enough not to be in the zdaemon 1.05 code.
The only thing I could think of that's anywhere near relatively new is the "wait" command, and that's been there for quite awhile. (Of course, if they didn't have the wait command, the color change wouldn't be possible anyway, so that's kinda moot.Biff wrote:Hey Carnevil, thanks for explaining that. I didn't realize that userinfo was just sent once, until it is changed. So, the impact of such an alias is a bit more data being sent, which can be a problem with modems. I'd still say that as far as slowing the client frame rate due to rendering "lots of color changing bodies", that is probably a mistaken idea. The bodies are rendered anyway and the color is immaterial.
Well, as Steve T. demonstrated recently, the skin color changing can be done directly with a multi-line alias, not needing an exec command, unless some of the alias commands are new enough not to be in the zdaemon 1.05 code.
)No, the rendering of the players is the same whether the player stays the same color or changes every frame, there's no issue here with FPS at all. That doesn't lessen the impact of the increased lag problem though. Modem or no modem, extra bandwidth is a bad thing. If you're downloading a file at 60K/s, you might not notice a .5K/s loss of transfer speed. If you're playing a game of Doom (or any other online game that is based in real time and requires quick movements and reflexes), the wasted data being sent translates to 50-100 extra ping minimum, and that's Not Good(tm).
Disabling exec is not something I think should have been done. First off, there are countless harmless uses for loading in a config file, from loading in a custom control scheme when another player takes over, to custom text binds for team-based play, to map rotations (on the server side). Secondly, once you've exec'd a config file in that contains aliases, they're saved to your ini file. Anyone who's used such aliases before is going to be unaffected by having the exec command removed. Finally, anyone with enough knowledge to create the binds doesn't need the exec command to do it and can easily get around that limitation.
I'd sooner take away "alias" than "exec", but that's not really a great option either. If you took a cue from id and removed "wait" that would kill recursive aliases, including all the examples I gave above, as well as removing the ability to "cheat" using aliases that do things for you... although I don't know how much of an impact such aliases really have on Doom. The best solution I can think of would be to disallow any changes to playerinfo from an alias. If the user enters "color FF FF FF" to the console, the playerinfo updates. If they hit a button bound to an alias that has a color command, the command is simply ignored and not sent to the server. That would remove the bandwidth problem. Better still, if it was processed but not sent to the server, it would still change the color on the user's own computer, so it wouldn't affect single player at all.
Another alternative is to add in flood detection for things like this. When a player makes a change that sends such data to the server, he is barred from doing so again for a short period of time, say 5 seconds or so. This allows someone to make changes to their player as often as they like, but doesn't allow them to have an alias that rapidly floods the server with unnecessary data.
Seems that the command line +exec command is not disabled, well, at least for zserv32.exe. It's rather annoying though that other command line parameters are ignored, such as -warp and +dmflags, or perhaps just overridden by what's in the zserv.cfg file.
I know, wrong forum. Anyhow, first tests with zdaemon 1.05 look pretty good and I put up a doom2 coop server (Rarefiles COOP).
I know, wrong forum.
Anyhow, first tests with zdaemon 1.05 look pretty good and I put up a doom2 coop server (Rarefiles COOP).I totally agree. Disabling exec and/or alias is just really a cheap way out and is not the best way to solve the problem. IMO, the best solution is the one you mentioned, and will probably go into Skulltag 95f. Requiring a certain amount of time to pass before a server updates the userinfo to all clients is probably what I will end up doing.HotWax wrote:The only thing I could think of that's anywhere near relatively new is the "wait" command, and that's been there for quite awhile. (Of course, if they didn't have the wait command, the color change wouldn't be possible anyway, so that's kinda moot.
No, the rendering of the players is the same whether the player stays the same color or changes every frame, there's no issue here with FPS at all. That doesn't lessen the impact of the increased lag problem though. Modem or no modem, extra bandwidth is a bad thing. If you're downloading a file at 60K/s, you might not notice a .5K/s loss of transfer speed. If you're playing a game of Doom (or any other online game that is based in real time and requires quick movements and reflexes), the wasted data being sent translates to 50-100 extra ping minimum, and that's Not Good(tm).
Disabling exec is not something I think should have been done. First off, there are countless harmless uses for loading in a config file, from loading in a custom control scheme when another player takes over, to custom text binds for team-based play, to map rotations (on the server side). Secondly, once you've exec'd a config file in that contains aliases, they're saved to your ini file. Anyone who's used such aliases before is going to be unaffected by having the exec command removed. Finally, anyone with enough knowledge to create the binds doesn't need the exec command to do it and can easily get around that limitation.
I'd sooner take away "alias" than "exec", but that's not really a great option either. If you took a cue from id and removed "wait" that would kill recursive aliases, including all the examples I gave above, as well as removing the ability to "cheat" using aliases that do things for you... although I don't know how much of an impact such aliases really have on Doom. The best solution I can think of would be to disallow any changes to playerinfo from an alias. If the user enters "color FF FF FF" to the console, the playerinfo updates. If they hit a button bound to an alias that has a color command, the command is simply ignored and not sent to the server. That would remove the bandwidth problem. Better still, if it was processed but not sent to the server, it would still change the color on the user's own computer, so it wouldn't affect single player at all.
Another alternative is to add in flood detection for things like this. When a player makes a change that sends such data to the server, he is barred from doing so again for a short period of time, say 5 seconds or so. This allows someone to make changes to their player as often as they like, but doesn't allow them to have an alias that rapidly floods the server with unnecessary data.
There's no way to really stop an individual client from spamming the server with whatever information (userinfo changes, chatting, etc), but the server CAN take measures against flooding other clients with this spam.