Zandronum

Console log: http://pastebin.com/MExFRAFq.

Since this is something completely broken and I have no slightest clue about any possible causes, and therefore creating a "minimal example .WAD" isn't possible, due to this I won't create a ticket yet. I want a developer to give me an idea about what's going on. Basically most actors behave like being +SERVERSIDEONLY (invisible and silent), but but but I don't jitter when I bump into them, and health bars I created works correctly, that means they do exist on the client side, I also correctly see any projectile attack they perform. Regarding the ZDemonTrail actor I'm already aware what's wrong with that particular actor.

P. S. I extensively use inheritance, and perform complex jumps from the parent class to child and vice versa, can that be the cause? And once again, everything works fine offline.

https://www.dropbox.com/s/hq77jyl4zfu72 ... 9.pk3?dl=0 if somebody wants to look at the mess.

Try -NONETID on ZDemonTrail and see how many of the warnings this fixes.

Found out the cause:Rewritten that and similar places into I assumed that the client awaits the server to instruct where to jump to. Turned out it just ignores the jump locally and proceeds to next state. Who in sane mind does code like that? Logically the client has to freeze the actor into it's current state if a jump instruction can't be handled on its side.

ZDemonTrail was a clientsided actor, I just forgot to clear that flag inherited from its parent class, obviously the server couldn't tell the clients to copy alpha and render style to it.

But it's not all done yet. I'm spammed to death with the following line: "FindStateLabelAndOffset: Couldn't find state!". The ticket I created earlier about a similar issue is still new... How does the server fail to find a state? I'm really curious.

*how do you have DECORATE labels that are present on the server and not present on the client?*

ZzZombo wrote: I assumed that the client awaits the server to instruct where to jump to. Turned out it just ignores the jump locally and proceeds to next state. Who in sane mind does code like that? Logically the client has to freeze the actor into it's current state if a jump instruction can't be handled on its side.

This is how Carnevil originally designed the jump handling in Skulltag. I have explained that it works like this numerous times on both the Skulltag and the Zandronum forum over the years. I thought how jumps are handled is widely known by now.

ZzZombo wrote: But it's not all done yet. I'm spammed to death with the following line: "FindStateLabelAndOffset: Couldn't find state!". The ticket I created earlier about a similar issue is still new... How does the server fail to find a state? I'm really curious.

I didn't have a chance to fix the issue yet, but already found out that the warning is sometimes erroneous. If you turn off the warnings and everything works fine, just ignore it till I had a chance to fix the issue.

Regarding the underlying problem that makes setting states on the client difficult for the server: ZDoom only stores the current state as C pointer. It doesn't keep track of the last label or the offset to the last label. For ZDoom this kind of bookkeeping is completely unnecessary. Since the pointers depend on the memory blocks allocated to Zandronum by the OS, the pointers on client and server differ, so the server can't simply tell the client to jump to the memory address specified by the pointer, but tries to find the nearest label and the offset to the label since the labels are the same on clients and server. Unfortunately the conversion from pointer to label plus offset is not trivial.

Circunei Z wrote: *how do you have DECORATE labels that are present on the server and not present on the client?*

See above.