search

FWGS / hlsdk-portable

Portable Half-Life SDK. GoldSource and Xash3D. Crossplatform.
https://xash.su
Other
273 stars 126 forks source link

Scripted Sequence inconsistent with Valve Behavior #200

Closed ValeTheVioletMote closed 3 years ago

ValeTheVioletMote commented 3 years ago

So, this is a bit of a mess, because this is actually something of a bug in valve's version, but the functionality is necessary.

When a monster is subject to a scripted sequence with instantaneous movement and without an animation, in both xash and valve, the monster gets stuck in a scripting state after teleporting. This is a bug, from what I've learned.

However, Valve has a workaround that isn't present in Xash. If the monster, while in this stalled state, receives a trigger, they break from their script and resume normal behavior (such as attacking the player.)

Personally, I'd like to see the bug fixed, but at the very least we should implement the valve workaround.

ValeTheVioletMote commented 3 years ago

Seems to have been caused by d86b0bf

ValeTheVioletMote commented 3 years ago

To align with what GoldSrc does, d86b0bf would need to be undone. But I'd rather not do that...

...As it's a bug, the ideal solution would be to instead appropriately make the monster idle once it has teleported and has no anim. Fixing this would cause no harm to anyone who's implemented a workaround on their maps, as it'd just be another call of MonsterUse to draw it out of IDLE.

FreeSlave commented 3 years ago

I believe that in Opposing Force they used to call the same scripted_sequence two times in a row for a workaround. Did not think about triggering the monster itself. I will look closer into it.

Can you provide the particular example where this workaround is used (like a map in Half-Life or a mod)? So we could test it.

ValeTheVioletMote commented 3 years ago

Can you provide the particular example where this workaround is used (like a map in Half-Life or a mod)? So we could test it.

I can give you a bsp with it and you can compare what happens on xash's current hl.dll vs valve's hl.dll. I don't have a reference to an official use, no. I was doing development in my own maps and read up on it. I made maps with it prior to switching to Xash. Thought something had gone wrong with my map until I opted to swap the hl dll back to the pre-xashsdk one. And that's when I made this issue.

I just went and checked TWHL and see the same tip as you said - call the sequence twice. I'm not sure where I picked up "trigger the monster" from, but it must have been before I came across TWHL.

It's possible this is a needless fix, then. If a fix at all. Now we'd be concerned that a SS is called twice.

ValeTheVioletMote commented 3 years ago

Went and confirmed that calling the sequence twice produces the expected behavior.

It is technically "valve" behavior to be able to trigger the monster. But both of these are workarounds against the same issue.

I don't know if this change should be implemented, though.

If there are cases, like in OpFor, as you said, where a sequence is triggered twice to complete, then this """fix""" (#202) could potentially cause those to be run twice. And if they have targets for each completion, now their targets have run twice. Very dangerous.

ValeTheVioletMote commented 3 years ago

I would much rather update my maps to call the sequence twice. Thankfully, I'm using MESS, so I only need to change one file.

FreeSlave commented 3 years ago

If you're making a mod with its own dlls (not just a mappack) you can replicate the behavior from SoHL where monster teleport via scripted_sequence does not have such bug.

As for https://github.com/FWGS/hlsdk-xash3d/commit/d86b0bf480f886ec40c93d2cf84e47ba5fd292de I did this change in my fork and nekonomicon commited it to master for some reason. Now I don't even remember the reasoning behind this change, it might be that this change is not needed in vanilla Half-Life at all. I will try to recall.