Problems With GZDoom Not Respecting Tic Delays

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!)

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: Problems With GZDoom Not Respecting Tic Delays

Re: Problems With GZDoom Not Respecting Tic Delays

by Void Weaver » Wed Aug 14, 2019 7:37 pm

A bit offtopic but you can just specify weapon lowering or rising speed in function itself. So A_Lower(24) will deselect weapon 4 times faster.

Re: Problems With GZDoom Not Respecting Tic Delays

by 22alpha22 » Wed Aug 14, 2019 12:34 pm

Ok that makes sense now that I think about it. I wasted several hours trying figure it out where problem was before I isolated it to the fist but I didn't know what the actual problem was. Glad to have this worked out. :)

Re: Problems With GZDoom Not Respecting Tic Delays

by Graf Zahl » Wed Aug 14, 2019 2:07 am

You shouldn't call A_Raise and A_Lower repeatedly in the same state. This behaves subtly different in case the desired animation ends. With only one call per state it jumps to the ready state, meaning that the following A_Raise states never get called. But with your new grouping it jumps to the ready state just as before, but since the anonymous function hasn't ended yet it will also run through the subsequent A_Raise calls and mess things up quite badly.

Sadly the weapon code suffers from some serious design issues that cannot be undone without breaking 25 years of modding.

Problems With GZDoom Not Respecting Tic Delays

by 22alpha22 » Wed Aug 14, 2019 1:20 am

I've recently started simplifying my weapons in my mods by using Anonymous functions rather than a billion or so jumpifs, in the process I've run into a peculiar, game breaking problem. After I simplified my unarmed weapon (code below), switching from the unarmed weapon to any other weapon now causes the other weapons to switch near instantly despite there being delays in how many A_Raise is called per tic. Not only that, after switching to a new weapon from the fist, the new weapon behaves strangely, with random weapon actions performing much quicker than there supposed to and sometimes the weapon locks up completely. If the weapon locks up, it wont respond to any command and becomes impossible to switch away from. Even more strangely, the rest of the game continues to run fine, I can still move and interact with the map. I have to manually remove the weapon via console commands to regain control of my arsenal. This only happens when switching from the fist to another weapon. Switching from any other weapon to another doesn't break anything.

The new unarmed fist:
Spoiler:
The old fist:
Spoiler:
Note when I reverted back to the old fist code, the problems went away.

Another weapon's code for reference:
Spoiler:
When switching from the fist to this weapon or any other, the weapon raises instantly and behaves unpredictably. When switching from any other weapon, it raises at the normal speed and behaves as expected.

Top