MantisBT - Zandronum
View Issue Details
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.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-10-04 23:32WatermelonNew Issue
2012-10-04 23:41Blzut3Note Added: 0004957
2012-10-05 01:21WatermelonNote Added: 0004958
2012-10-05 01:21WatermelonNote Edited: 0004958bug_revision_view_page.php?bugnote_id=4958#r2697
2012-10-05 04:31QentNote Added: 0004960
2012-10-05 14:46WatermelonNote Added: 0004961
2012-10-05 18:24Blzut3Note Added: 0004966
2012-10-05 20:00Torr SamahoNote Added: 0004972
2012-10-06 07:33unknownnaNote Added: 0004977
2012-10-06 07:39unknownnaNote Edited: 0004977bug_revision_view_page.php?bugnote_id=4977#r2715
2012-10-06 07:43unknownnaNote Edited: 0004977bug_revision_view_page.php?bugnote_id=4977#r2718
2012-10-06 08:22unknownnaNote Edited: 0004977bug_revision_view_page.php?bugnote_id=4977#r2721
2012-10-06 09:01Torr SamahoNote Added: 0004979
2012-10-06 09:02Torr SamahoNote Edited: 0004979
2012-10-06 09:03Torr SamahoNote Edited: 0004979bug_revision_view_page.php?bugnote_id=4979#r2724
2012-10-06 09:03Torr SamahoNote Revision Dropped: 4979: 0002722
2012-10-06 09:03Torr SamahoNote Revision Dropped: 4979: 0002723
2012-10-06 11:17DuskNote Added: 0004984
2012-10-06 11:17DuskNote Edited: 0004984bug_revision_view_page.php?bugnote_id=4984#r2728
2012-10-06 12:03unknownnaNote Added: 0004986
2012-10-06 12:04unknownnaStatusnew => feedback
2012-10-06 15:39WatermelonNote Added: 0004994
2012-10-06 15:39WatermelonStatusfeedback => new
2012-10-06 15:39WatermelonNote Edited: 0004994bug_revision_view_page.php?bugnote_id=4994#r2735
2012-10-06 17:05WatermelonNote Added: 0005000
2012-10-06 17:21Torr SamahoNote Added: 0005004
2012-10-07 01:28QentNote Added: 0005011
2012-10-07 07:38Torr SamahoNote Added: 0005014
2012-10-07 16:32Blzut3Note Added: 0005037
2012-10-07 16:33Blzut3Note Edited: 0005037bug_revision_view_page.php?bugnote_id=5037#r2758
2012-10-08 14:24WatermelonNote Added: 0005051
2012-10-09 00:18Edward-sanNote Added: 0005053
2012-10-09 03:09ZzZomboNote Added: 0005055
2013-03-20 05:50WatermelonNote Added: 0006150
2013-03-20 05:50WatermelonStatusnew => closed
2013-03-20 05:50WatermelonAssigned To => Watermelon
2013-03-20 05:50WatermelonResolutionopen => fixed
2013-06-08 19:08WatermelonAssigned ToWatermelon =>
2013-06-08 19:08WatermelonStatusclosed => feedback
2013-06-08 19:08WatermelonResolutionfixed => reopened
2013-06-08 19:08WatermelonStatusfeedback => closed
2013-06-08 19:08WatermelonResolutionreopened => no change required

Notes
(0004957)
Blzut3   
2012-10-04 23:41   
Wouldn't the more important question here be which port is actually closer to vanilla?
(0004958)
Watermelon   
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.
(0004960)
Qent   
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.
(0004961)
Watermelon   
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.
(0004966)
Blzut3   
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?
(0004972)
Torr Samaho   
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.
(0004977)
unknownna   
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.
(0004979)
Torr Samaho   
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).
(0004984)
Dusk   
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.
(0004986)
unknownna   
2012-10-06 12:03   
Is it any different in ZDoom 1.23b33?
(0004994)
Watermelon   
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.
(0005000)
Watermelon   
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?
(0005004)
Torr Samaho   
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.
(0005011)
Qent   
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?
(0005014)
Torr Samaho   
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.
(0005037)
Blzut3   
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?
(0005051)
Watermelon   
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?
(0005053)
Edward-san   
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)?
(0005055)
ZzZombo   
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.
(0006150)
Watermelon   
2013-03-20 05:50   
People could always edit the source, so there's no need for this to really be open.