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

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001858Zandronum[All Projects] Suggestionpublic2014-06-25 10:172018-09-30 21:35
Assigned ToDusk 
PlatformOSOS Version
Product Version 
Target Version1.3Fixed in Version1.3 
Summary0001858: Client-to-server mechanism to ACS_Execute to supersede ConsoleCommand("puke")
DescriptionConsoleCommand is evil as we all know. One current 'valid' use of it is to make a puke request to call server-side ACS from the client-side.

I'd want to natively implement this behavior by adding a new rule to script calling: if a server-side NET script is being called from the client-side, the client would send a puke client command.

Right now, in such a case the client... runs the script on its own, causing a ton of desyncs since server-side scripts are the ones that alter the gamesim... I'd want to write this off officially as undefined behavior (it certainly isn't defined behavior in Zandronum source!) and replace the behavior with a client-to-server mechanism.

There's a few quirks to this behavior as a result of this being a client-to-server puke call:
- it only works with NET scripts. It would obviously be disastrous to let this work with non-NET scripts as this is client-to-server and thus it would let any client activate any script.
- the script activator will always be the local consoleplayer no matter what was the activator of the client-side script. Same reasoning as above - modified clients could set the activator at will otherwise and for instance cause other players to sell their weapons in AOW.
- being client-to-server, the packet sent is unreliable and there is no guarantee that the packet will ever reach the server.

These quirks are all also present with the current ConsoleCommand("puke") workaround.
Attached Fileszip file icon [^] (675 bytes) 2014-06-29 16:52
? file icon test_serversidenonnetscriptfromclient.pk3 [^] (1,015 bytes) 2014-07-09 20:39
? file icon ammocountdesync.pk3 [^] (1,084 bytes) 2014-07-10 13:17
png file icon Screenshot_Doom_20140710_161537.png [^] (98,433 bytes) 2014-07-10 13:18

- Relationships
child of 0001070newDusk Phasing out the dangerous ConsoleCommand for various additional/improved ACS commands 

-  Notes
User avatar (0009739)
Dusk (developer)
2014-06-25 12:27

Here goes: [^]
User avatar (0009755)
Torr Samaho (administrator)
2014-06-26 18:46

That sounds like a good idea. Will look at the implementation in detail.
User avatar (0009779)
Torr Samaho (administrator)
2014-06-29 10:53

Looks good, transplanted. We just have to keep in mind that we'll need to introduce a compatflag to restore the old behavior in case there are mods that break because of this change.
User avatar (0009782)
Dusk (developer)
2014-06-29 12:54

This is undefined behavior we're addressing here... then again, all bugs kind of themselves already are that. I'll add a compat_clientacsexecute...
User avatar (0009789)
Dusk (developer)
2014-06-29 17:09 [^]
User avatar (0009792)
Torr Samaho (administrator)
2014-06-29 19:29

User avatar (0009924)
Qent (updater)
2014-07-09 20:43
edited on: 2014-07-09 23:59

This causes strange behavior in Russian Overkill (using 2.0, 2014.07.09-20.19.28: [^]), shown in the example test_serversidenonnetscriptfromclient.pk3. Connect to a server, switch to NewChainsaw, and attack. With the compatflag off, you will get the error "P_CheckClientToServerACS: Cannot run server-side non-NET script 123 from the client" and it will give you the wrong number of cells (should give cells equal to the number of bullets you currently have).

(The WADs used on the server were
hr2final.wad - dad338e1968aea4df05d465e864d78f3
hr2-final-fix.wad - 0949cc1a6745ed477e34029f8d21d235
ro_pb_2.2_zan_01.pk3 - f51227da2b2c5375f5076195d41e46be
ro_class_v3_zan_01.wad - 7946173686660ef61e662ee117f689cc
newtextcolours1_170.pk3 - 242ee38839ed48fdb36bda4794208e8b! [^] is a link to Russian Overkill. The gun in question was the SchwarzerZwerg2. The compatflag does work to restore old behavior, however.)

User avatar (0009929)
ZzZombo (reporter)
2014-07-10 09:17

My mod seems to break from ^.
My weapon w/o the compat. flag just prints the error into client's console (why? isn't it the server what decides how actors should act?) and with it enabled just plainly skips all calls to ACS from its states, I even made the script in question to PrintBold() a meaningless message just to check if the game skips the ACS call, and it indeed does, even tho the whole animation plays as if nothing went wrong. So I'd increase the severity of this ticket, it completely breaks game.
User avatar (0009930)
Dusk (developer)
2014-07-10 13:12
edited on: 2014-07-10 13:19

What I think is going on is that both peers executed the ACS script on their own and acted accordingly with the results just happening to be consistent. Now the mechanism doesn't allow the script to be executed on the client's end (but does on the server!), the server never tells the client how much ammo was recieved and the ammo counts go out of sync.

EDIT: Indeed appears to be an unrelated bug that the mechanism has revealed. The new example wad ammocountdesync.pk3 has a chainsaw that will desync the cell ammo even if the compatflag is on.

In case anyone's wondering, the "rcon printinv 0" is a debug build-exclusive feature which allows the server to peek at other players' inventories.

User avatar (0009948)
Torr Samaho (administrator)
2014-07-12 15:39

Hmm, ammocountdesync.pk3 reveals design problem of your new mechanism, in the sense that it changes behavior it was not supposed to change. Or did you intentionally want your mechanism also to cover DECORATE constructs like

     TNT1 A 10 A_GiveInventory("Cell", ACS_ExecuteWithResult(1, 0))


And you are right, this example also shows a Zandronum bug unrelated to your mechanism.
User avatar (0010014)
Ijon Tichy (reporter)
2014-07-20 17:12
edited on: 2014-07-20 17:14

Why are we hijacking current syntax to achieve this, now? Since this sort of client -> server behaviour can't exist in ZDoom's network model, there's no reason to worry about ZDoom compatibility with this. An ACS_RequestExecute(snum[, a1[, a2[, a3]]]) (does not get blocked the way ACS_Execute does) would avoid compatibility issues and make the client->server exchange explicit, rather than implicit, which would avoid /many/ headaches.

User avatar (0010063)
Dusk (developer)
2014-07-28 13:30
edited on: 2014-07-28 13:40

The mechanism's been replaced with a new RequestScriptPuke ACS function now:

use the following to try it out:

special -122:RequestScriptPuke (1, 4);

User avatar (0010344)
Dusk (developer)
2014-10-05 22:22

Marking as resolved as 1.3 is now released.

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: Esum
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2014-06-25 10:17 Dusk New Issue
2014-06-25 10:17 Dusk Status new => assigned
2014-06-25 10:17 Dusk Assigned To => Dusk
2014-06-25 10:18 Dusk Relationship added child of 0001070
2014-06-25 10:22 Dusk Summary Client-to-server mechanism to ACS_Execute to supercede ConsoleCommand("puke") => Client-to-server mechanism to ACS_Execute to supersede ConsoleCommand("puke")
2014-06-25 12:27 Dusk Note Added: 0009739
2014-06-25 12:27 Dusk Status assigned => needs review
2014-06-26 18:46 Torr Samaho Note Added: 0009755
2014-06-29 10:53 Torr Samaho Note Added: 0009779
2014-06-29 11:11 Torr Samaho Target Version => 1.3
2014-06-29 11:12 Torr Samaho Status needs review => needs testing
2014-06-29 12:54 Dusk Note Added: 0009782
2014-06-29 12:54 Dusk Status needs testing => assigned
2014-06-29 16:52 Dusk File Added:
2014-06-29 17:09 Dusk Note Added: 0009789
2014-06-29 17:09 Dusk Status assigned => needs review
2014-06-29 19:29 Torr Samaho Note Added: 0009792
2014-06-29 19:29 Torr Samaho Status needs review => needs testing
2014-07-09 20:39 Qent File Added: test_serversidenonnetscriptfromclient.pk3
2014-07-09 20:43 Qent Note Added: 0009924
2014-07-09 20:45 Qent Note Edited: 0009924 View Revisions
2014-07-09 20:53 Qent Note Edited: 0009924 View Revisions
2014-07-09 20:57 Qent Note Edited: 0009924 View Revisions
2014-07-09 21:04 Dusk Status needs testing => assigned
2014-07-09 23:59 Qent Note Edited: 0009924 View Revisions
2014-07-10 09:17 ZzZombo Note Added: 0009929
2014-07-10 13:12 Dusk Note Added: 0009930
2014-07-10 13:12 Dusk Note Edited: 0009930 View Revisions
2014-07-10 13:16 Dusk Note Edited: 0009930 View Revisions
2014-07-10 13:17 Dusk Note Edited: 0009930 View Revisions
2014-07-10 13:17 Dusk File Added: ammocountdesync.pk3
2014-07-10 13:18 Dusk File Added: Screenshot_Doom_20140710_161537.png
2014-07-10 13:19 Dusk Note Edited: 0009930 View Revisions
2014-07-10 13:25 Dusk Status assigned => needs review
2014-07-12 15:39 Torr Samaho Note Added: 0009948
2014-07-12 15:39 Torr Samaho Status needs review => feedback
2014-07-20 17:12 Ijon Tichy Note Added: 0010014
2014-07-20 17:14 Ijon Tichy Note Edited: 0010014 View Revisions
2014-07-20 19:37 Dusk Status feedback => assigned
2014-07-28 12:54 Dusk Status assigned => needs review
2014-07-28 13:30 Dusk Note Added: 0010063
2014-07-28 13:30 Dusk Status needs review => needs testing
2014-07-28 13:40 Dusk Note Edited: 0010063 View Revisions
2014-07-28 13:40 Dusk Note Edited: 0010063 View Revisions
2014-10-05 22:20 Dusk Fixed in Version => 1.3
2014-10-05 22:22 Dusk Note Added: 0010344
2014-10-05 22:22 Dusk Status needs testing => resolved
2014-10-05 22:22 Dusk Resolution open => fixed
2018-09-30 21:35 Blzut3 Status resolved => closed

Questions or other issues? Contact Us.


Copyright © 2000 - 2021 MantisBT Team
Powered by Mantis Bugtracker