Movement prediction interfering with InputProcess

Ask about ACS, DECORATE, ZScript, or any other scripting questions here!

Moderator: GZDoom Developers

Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.

Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
Accensus
Posts: 2354
Joined: Thu Feb 11, 2016 9:59 am

Movement prediction interfering with InputProcess

Post by Accensus »

Attached example. Tested on 4.8.1. and 4.8.2. Likely nothing recent.

Start a local co-op session and make sure one of the players has movement prediction enabled. When you click LMB on the predicted player, a counter should increase by 1 and get printed. What happens is that the counter stays at 1 regardless of how many times you spam LMB.
This only happens if InputProcess calls a UI function on the player. If I increase the counter in InputProcess directly or a function on the handler, it works just fine. Hopefully this is addressable. If not, oh well. Guess I'll have to play a specific mod without movement prediction.
You do not have the required permissions to view the files attached to this post.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47995
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Movement prediction interfering with InputProcess

Post by Graf Zahl »

The code looks unsafe. In multiplayer games you shouldn't bypass the network barrier and write directly into a game object like this, even if the variable is marked UI.
I cannot help you here, but this belongs in the scripting forum, not into bugs.
Accensus
Posts: 2354
Joined: Thu Feb 11, 2016 9:59 am

Re: Movement prediction interfering with InputProcess

Post by Accensus »

I see. Thanks for the heads-up at least. Unfortunately, I'm out of options because NetworkProcess is play scope so I have no other way of setting UI variables besides making everything play scope and running absolutely everything through SendNetworkEvent, which is a lot of data, and SendNetworkEvent is extremely limited in the type of parameters I can pass around. Not to mention moving everything to play scope essentially violates any sort of design pattern I've tried to implement where the UI builds the data it's supposed to display out of existing playsim data. For an example, if I have a bunch of items and I want to filter only a specific type to display by building a sorted array, I do that in the UI code, because it's not the playsim's job to create a specific array that's only ever used in UI context, and if I need to do something on the item in the filtered array, I pass it back through SendNetworkEvent through the event's name using the "eventname:classname" approach. To fix this would essentially require a complete refactor at this point, and even then it's not a guarantee it'll even be possible.

In other words, ah fuck, I'm screwed.

If none of the above makes any sense, it's probably because I'm not going into full detail about how the entire inventory system works or even looks like, which would take quite a bit to explain, and the mod is a WIP with no public download so I can't link it yet either.
User avatar
Rachael
Admin
Posts: 12911
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Preferred Pronouns: She/Her

Re: Movement prediction interfering with InputProcess

Post by Rachael »

Ideally the UI should not be sending a lot of data to the play scope anyhow, nothing more than final selections and/or input events.

There should be no problem though with UI having unlimited read-only access to data. I am kind of surprised if it doesn't.
Accensus
Posts: 2354
Joined: Thu Feb 11, 2016 9:59 am

Re: Movement prediction interfering with InputProcess

Post by Accensus »

In my case it's only final selections. To summarize it in a relatively basic sense:
There is a UI struct called MenuData on the player.
Player opens inventory menu (play scope variable indicating which menu), from then on everything is UI. A list of inventory items is built. Selecting an item using InputProcess navigation sets MenuData's SelObject. The purpose of MenuData is to be a data bridge between the drawing code in the statusbar and InputProcess. Both read and write to it. When you confirm the final action, InputProcess does SendNetworkEvent with the corresponding information, usually just the class name of the selected item (MenuData.SelObject.GetClassName()) which is then FindInventory'd in NetworkProcess, along with any misc data.

The reason this is set up like that is because the inv system acts on 3 levels: core handler -> player -> selected items. Both the player and items have OnInputProcess which can be used to control level-specific menu operations. For example, left mouse button at the main inventory menu (player level) may do one thing, but for the item submenu (level) it can do something else. This allows modders to completely customize how their item interacts with the custom menus they add. To refactor this would mean to throw out the entire modularity out the window and hardcode the interactions. Not to mention the abstraction. I can easily replace the entire playsim code and not have to touch one bit of the UI code. As it should be.

Theoretically, in how much danger am I if I were to run a co-op session in which all players have movement prediction disabled, thus allowing all menus to function the same as in singleplayer?
Accensus
Posts: 2354
Joined: Thu Feb 11, 2016 9:59 am

Re: Movement prediction interfering with InputProcess

Post by Accensus »

Welp, fixed it by moving MenuData to the handler and storing a reference to the handler on the player and accessing MenuData through that at the player level in the player class's OnInputProcess, since the end point is essentially on the same class as the original method caller (InputProcess on the handler) and does not write into a different object.

Return to “Scripting”