This is mainly to help isolate functionality in the hopes of adding a specialised object class for this type of object as suggested by @julealgon in https://github.com/diasurgical/devilutionX/pull/2344#discussion_r667415019
For example, AddSCambBook performs almost the same logic but uses var6 instead of var8 for the trigger condition/identifier.
Due to the way this function is used it was easiest to also change ObjIndex to return a reference to the object instead of the index. Also added an explicit conversion from Size to Displacement to make one of the uses slightly cleaner to express.
Really blanking on a good name for that function. Might not even be necessary given I think the BreakCrux use is effectively dead code, it could be rolled back into SyncCrux.
Instead calling the function directly makes it easier to see common code patterns
DoorSet really only cares if the door opens to the left or the right
Can take a bool instead of the object type.
these two functions are always called together, can probably be combined or have a wrapper introduced
Move SyncL1Doors to near declarations of other SyncDoors functions
Simplify checks in SyncL3Doors
The function is only called with objects of type L3LDOOR or L3RDOOR so there's no real need to check again.
Take door by reference in SyncL3Doors
Removes one use of the Objects global.
Door by reference 2, SyncL2Doors
Simplify logic in SyncL2Doors to match L3Doors
Almost the same code, can probably be combined to a single function with appropriate parameters.
Use Point in DoorSet params
Use switch in DoorSet
Instead of a whole bunch of if statements where only one can be true
Replace object index with type in DoorSet
This function doesn't need any other object property. Still references the dPiece global unfortunately.
SyncL1Doors door by reference
Replace code that mutates a copy of door position with Direction
Inline if/else statement for L1LDOOR
Only difference is the value of the second parameter
Also updated declaration of temporary/local variables to match
convention. This includes inlining int oi in LoadMapObjects as this
matches the way SetOBjMapRange is called in other areas.
Because of the heavy usage of this function in objects.cpp and the mixed use of aliases and direct references to the active object in Operate*Door functions I've done some refactoring of those areas beyond what is strictly necessary. Hopefully this makes sense and is reasonable to include in this change.
ephphatha
Anders Jenbo
Vladimir Olteanu
qndel
Juliano Leal Goncalves