Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001100Zandronum[All Projects] Suggestionpublic2012-10-04 23:322013-06-08 19:08
ReporterWatermelon 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version1.0 
Target VersionFixed in Version 
Summary0001100: Less of a tic delay for teleporting
DescriptionZandronum has a few extra tics when you go through a teleporter. This is critical in duels, as it gives the opposing player enough time to eradicate the effectiveness of teleporters. ZDaemon allows players a much quicker response time when exiting a teleporter.

Therefore, is it possible to control it via a new cvar like sv_teleportdelay [tick value], or possibly a new compat flag like compat_fastteleports?
Steps To Reproduce1. Go through a teleporter on Zandronum
2. Go through a teleporter on ZDaemon (try shooting when you go through and moving and notice a slight less tic delay
Additional InformationThis can mean the difference between winning/losing duels when its close. I'd go through and then try to aim quick and shoot, though due to it locking you facing straight you cannot combat the player as easily.
Attached Files

- Relationships

-  Notes
User avatar (0004957)
Blzut3 (administrator)
2012-10-04 23:41

Wouldn't the more important question here be which port is actually closer to vanilla?
User avatar (0004958)
Watermelon (developer)
2012-10-05 01:21
edited on: 2012-10-05 01:21

I think Skulltag is closer to vanilla, but from a competitive standard it hurts players bad on this port. Many people who play from ZD complain about the teleporter delay being slightly longer on here, which makes play in maps like IDL2012-.wad MAP14 much more irritating to retrieve the flag. For those of us who play on all three ports competitively, a simple few tic delay completely changes the gameplay on a dramatic scale (or rather for something it was not intended).

Therefore by adding something like sv_teleportdelay in gametics, it would allow servers to emulate ZDaemon behavior and assist in our competitive CTF and duel scene. I can't stress enough how this miniscule thing -- while seeming small -- is a very huge game-changer when playing duel or CTF maps.

User avatar (0004960)
Qent (updater)
2012-10-05 04:31

I am curious about exactly what the difference is. Is Zandronum really closer to vanilla?

Assuming it is, how many balance hacks from other engines is enough? Will we need compat_zdaemonsupershotgun and compat_droppeditemsfallthroughbridgethings? While more features and accommodation of typical competitive play are good things, I wouldn't call perfect ZDaemon emulation per se a worthy goal to strive for.

Which brings up another question: how do Zandronum and ZDaemon compare to Odamex in this regard? Emulating ZDaemon might be premature.
User avatar (0004961)
Watermelon (developer)
2012-10-05 14:46

So far the following are the only things required for meeting the competitive standards from ZD/Oda:

- ssg (easily modifiable through decorate [check])
- rocket physics (committed [check])
- old random (in zandronum [check])
- teleport delay


There is only one left on the list.
User avatar (0004966)
Blzut3 (administrator)
2012-10-05 18:24

I understand that a small item like this could be a game changer, but I keep being told that competitive players like oldschool (aka vanilla accuracy). If you're going to demand the old random number generator, old rocket physics, etc why would you not want the old teleportation time?

Honestly, I'm the last person to be talking about vanilla accuracy, but I do think this kind of thing crosses the line between intentional changes and accidental changes to fix bugs/support new features. Assuming Zandronum's behavior is correct and ZDaemon's is not anyways.

That said, tuning the teleport delay may be a useful as a moding feature, so perhaps some kind of generic way of implementing it should be suggested for ZDoom?
User avatar (0004972)
Torr Samaho (administrator)
2012-10-05 20:00

Quote from Watermelon
There is only one left on the list.

I'm pretty sure this list will be extended as soon as the last missing part is implemented ;).

Anyway, before we decide what to do with this somebody should find out how Vanilla Doom handles this.
User avatar (0004977)
unknownna (updater)
2012-10-06 07:33
edited on: 2012-10-06 08:22

I think that this is caused by the teleport/spawn/respawn prediction in Zandronum.

Quote from Torr Samaho
After respawning the player is prevented to move for a fixed amount of tics. Server and client both start to count this time directly after spawning the player, but since the spawning on the client is delayed by the ping, the player was allowed to move on the server while the client was still thinking it may not move yet. To account for this I increased the non-movement time on the server by the client's ping (which seemed to fix the problems for me) and now also made the client not send any movement requests while it locally still thinks it is not allowed to move (which seems improve the situation for you).

I recently tested ZDaemon 1.09 and can tell you that it's worse there under the same circumstances (600 ping) when it comes to teleporting. You jitter around when using teleporters. But perhaps it's desired by low-ping users to not have any teleport/spawn/respawn prediction.

On a side note, I noticed that the client prediction for doors was a lot better in ZDaemon. You don't jitter there compared to Zandronum.

Edit:

Quote from Watermelon
So far the following are the only things required for meeting the competitive standards from ZD/Oda:

- ssg (easily modifiable through decorate [check])

I'd be very interested in hearing how you're going to emulate the vanilla blockmap behavior (compat_hitscan) with DECORATE. Also, you forgot about the bridge thing issue and the silent spawn issue.

User avatar (0004979)
Torr Samaho (administrator)
2012-10-06 09:01
edited on: 2012-10-06 09:03

Quote from unknownna
I think that this is caused by the teleport/spawn/respawn prediction in Zandronum.
I don't think that the prediction has a noticeable effect on this (at least not with a reasonable ping). ZDoom itself (and possibly also Vanilla Doom) prevents the player from moving for 18 tics (about .5 seconds) even in single player, I'm pretty sure that this artificial delay is the reason for this ticket. We could easily reduce this delay with a dmflag if we want to. I'd still like to know though whether we are emulating Vanilla Doom or ZDaemon with this change.
Quote from unknownna
On a side note, I noticed that the client prediction for doors was a lot better in ZDaemon. You don't jitter there compared to Zandronum.
Feel free to make a new suggestion ticket for this (in case there is no ticket yet).

User avatar (0004984)
Dusk (developer)
2012-10-06 11:17
edited on: 2012-10-06 11:17

Quote from Doom source code


        // don't move for a bit
        if (thing->player)
            thing->reactiontime = 18;


So I suppose Zandronum is correct.

User avatar (0004986)
unknownna (updater)
2012-10-06 12:03

Is it any different in ZDoom 1.23b33?
User avatar (0004994)
Watermelon (developer)
2012-10-06 15:39
edited on: 2012-10-06 15:39

> I'd be very interested in hearing how you're going to emulate the vanilla blockmap behavior (compat_hitscan) with DECORATE

What does that do?
Actually I tried emulating the ZD SSG the other day, and for some reason I just cannot do it right... maybe that compat_hitscan does something -- though what does it do exactly?
I tried googling it and looking at diff's to see what the change was but all the sites won't load.

User avatar (0005000)
Watermelon (developer)
2012-10-06 17:05

As a side note, based on the above discussion... does that mean I'm getting an illusion due to lag (or possibly lackthereof lag) that there is more of a delay but clients are on par with other servers, or is there actually a physical delay happening?
User avatar (0005004)
Torr Samaho (administrator)
2012-10-06 17:21

I think I don't understand exactly what you are asking. After being teleported, Vanilla Doom prevents the player from moving for 18 tics. To keep things synchronized the client will wait for exactly 18 tics before it allows movement while the server waits for 18 tics + the player's ping. So on the client it should look like exactly an 18 tic delay.
User avatar (0005011)
Qent (updater)
2012-10-07 01:28

Since desirability of the delay depends on the player's ping, maybe it would be better as a client option, instead of a DMFlag?
User avatar (0005014)
Torr Samaho (administrator)
2012-10-07 07:38

I think it's safe to say that players would always want to have as little delay as possible, so clients shouldn't be deciding this.
User avatar (0005037)
Blzut3 (administrator)
2012-10-07 16:32
edited on: 2012-10-07 16:33

Quote from Torr Samaho
To keep things synchronized the client will wait for exactly 18 tics before it allows movement while the server waits for 18 tics + the player's ping. So on the client it should look like exactly an 18 tic delay.

Wouldn't this caused an increased delay for higher ping players? Shouldn't the client be waiting for 18 - ping and the server waiting for 18?

User avatar (0005051)
Watermelon (developer)
2012-10-08 14:24

If you spike as soon as you enter a teleporter, will the game add on that possible lag spike?

Tic wise, if you go: 30 30 890 30 30
And you teleport on 890, will you get a large delay from the teleporter even though afterwards you've returned to a normal ping and had the proper update from the server?
User avatar (0005053)
Edward-san (developer)
2012-10-09 00:18

Quote
Wouldn't this caused an increased delay for higher ping players? Shouldn't the client be waiting for 18 - ping and the server waiting for 18?


we should test it: what happens if client teleports with emulated high pings (around 500, for example)?
User avatar (0005055)
ZzZombo (reporter)
2012-10-09 03:09

I can say that (ping 300-400): you will frozen for a while (a half of second or so) until your client realize he can move off the teleporter. In v98d it also could show "Connection interrupted" while this is happening.
User avatar (0006150)
Watermelon (developer)
2013-03-20 05:50

People could always edit the source, so there's no need for this to really be open.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: ZzZombo
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2012-10-04 23:32 Watermelon New Issue
2012-10-04 23:41 Blzut3 Note Added: 0004957
2012-10-05 01:21 Watermelon Note Added: 0004958
2012-10-05 01:21 Watermelon Note Edited: 0004958 View Revisions
2012-10-05 04:31 Qent Note Added: 0004960
2012-10-05 14:46 Watermelon Note Added: 0004961
2012-10-05 18:24 Blzut3 Note Added: 0004966
2012-10-05 20:00 Torr Samaho Note Added: 0004972
2012-10-06 07:33 unknownna Note Added: 0004977
2012-10-06 07:39 unknownna Note Edited: 0004977 View Revisions
2012-10-06 07:43 unknownna Note Edited: 0004977 View Revisions
2012-10-06 08:22 unknownna Note Edited: 0004977 View Revisions
2012-10-06 09:01 Torr Samaho Note Added: 0004979
2012-10-06 09:02 Torr Samaho Note Edited: 0004979
2012-10-06 09:03 Torr Samaho Note Edited: 0004979 View Revisions
2012-10-06 09:03 Torr Samaho Note Revision Dropped: 4979: 0002722
2012-10-06 09:03 Torr Samaho Note Revision Dropped: 4979: 0002723
2012-10-06 11:17 Dusk Note Added: 0004984
2012-10-06 11:17 Dusk Note Edited: 0004984 View Revisions
2012-10-06 12:03 unknownna Note Added: 0004986
2012-10-06 12:04 unknownna Status new => feedback
2012-10-06 15:39 Watermelon Note Added: 0004994
2012-10-06 15:39 Watermelon Status feedback => new
2012-10-06 15:39 Watermelon Note Edited: 0004994 View Revisions
2012-10-06 17:05 Watermelon Note Added: 0005000
2012-10-06 17:21 Torr Samaho Note Added: 0005004
2012-10-07 01:28 Qent Note Added: 0005011
2012-10-07 07:38 Torr Samaho Note Added: 0005014
2012-10-07 16:32 Blzut3 Note Added: 0005037
2012-10-07 16:33 Blzut3 Note Edited: 0005037 View Revisions
2012-10-08 14:24 Watermelon Note Added: 0005051
2012-10-09 00:18 Edward-san Note Added: 0005053
2012-10-09 03:09 ZzZombo Note Added: 0005055
2013-03-20 05:50 Watermelon Note Added: 0006150
2013-03-20 05:50 Watermelon Status new => closed
2013-03-20 05:50 Watermelon Assigned To => Watermelon
2013-03-20 05:50 Watermelon Resolution open => fixed
2013-06-08 19:08 Watermelon Assigned To Watermelon =>
2013-06-08 19:08 Watermelon Status closed => feedback
2013-06-08 19:08 Watermelon Resolution fixed => reopened
2013-06-08 19:08 Watermelon Status feedback => closed
2013-06-08 19:08 Watermelon Resolution reopened => no change required






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker