Repository navigation
entity hull boolean conflict fix + separate tab - #1476
Conversation
better checks for entity view and step height mutator and convar bool usage so they don't override net.writebool()
|
what happens if this isn't done btw: 2026-10-04_05-34-00.mov |
|
changed it a bit so they are now on their own tab, and have their separate checkboxes so the two different convars have a proper purpose. 
|
forgot you were still there, get out.
lionstrykes10911
changed the title
bring these back in and fix standing hull being checked twice (what?)
nvm, those checks ALSO messes up the boolean for resetting hole
|
gladly make any changes, just try not to cause hull scales to stop working again. |
2026-10-05_18-52-31.1.mov |
removing the OverrideStepAndView property would undo any saved user choice that is because it won't get converted to the new split properties of step and view which are false by default
reduce calls of ApplyMatrix don't use the setter inside itself even if it's mostly an empty function in the false case. the bool is already false by being pre-loaded from the class's DefaultVars when the part is created, before further initialization but we got a bigger problem. the split won't be absolutely backward compatible after all. after deliberating some alternatives to preserve proxy read/write functionality, I found no immediate solution that avoids overwriting the successor properties on initialize
|
No need. There was no recursion. The worst that happened is a double call of ApplyMatrix from calling the step and the view setters, and maybe not having checked whether proxies on OverrideStepAndView should still work or not. That's on me though. But never call functions recursively unless specifically absolutely necessary and you make sure to add recursion guards. That's a rule. Never mind that, though. Calling the setter had no effect there since we overwrote the default setter function with the goal of erasing the old property after transcribing it to its successors. We still kind of got a conflict though, so the backward compatibility won't be absolute due to the contradiction between proxies having access to the setter, and initialize changes needing to be neutered to prevent a hidden property from overwriting our changes to the successors. It's sensitive when we're removing or hiding a property. Migration is fine for one time though. As for what happens to that property with regards to proxies, there's a conflict. I'm making the decision. |
|
Ighty'o then, your call if there is anything else that you think should be changed. |
2 participants
better checks for entity view and step height mutator and convar bool usage so they don't override net.writeboolean() and cause entity to reset hull sizes when it shouldn't