You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As more cases get found where default values can be influenced by other variables, it might be better to try and reset values to zero on extraction so the tag better matches what it probably was before it was built.
To do this we would have to check if the current value in a field matches what it would have been defaulted to had it been zero under current circumstances, and if so, set the value to zero.
A case where this is important is sound tags. Some values could have been defaulted differently based on the sound class, and if these values are pre-set in the extracted tag it would cause changing the sound class afterwards to have a different effect than if it had been changed in the original tag.
side note, I think invader-sound defaults things when remaking a tag, we might need to have it not do that.
The text was updated successfully, but these errors were encountered:
This is doable, I'm not sure it's a good idea to assume the original tag was 0 in all cases.
As you know, there are values that get defaulted even when they aren't 0, so there is no way to retrieve this information. Invader typically warns about these, of course, but they are still more-or-less modified.
Also, there are entire structures that get added by default, such as pathfinding spheres. For pathfinding spheres, one would have to figure out which object referenced the collision model, and this has a chance of failing if multiple objects reference the same collision model, as at that point, we wouldn't know if they intended for the pathfinding sphere to be that big for everything or if they just let the map builder do it.
Also, of course, resetting defaulted values doesn't necessarily make it like the original tag. Some tags, even Bungie tags, have the values set to the default value in the original tag file, so now it will actually match less.
I think it would be better to do this on a case-by-case basis. Have some values get reverted but not all.
As more cases get found where default values can be influenced by other variables, it might be better to try and reset values to zero on extraction so the tag better matches what it probably was before it was built.
To do this we would have to check if the current value in a field matches what it would have been defaulted to had it been zero under current circumstances, and if so, set the value to zero.
A case where this is important is sound tags. Some values could have been defaulted differently based on the sound class, and if these values are pre-set in the extracted tag it would cause changing the sound class afterwards to have a different effect than if it had been changed in the original tag.
side note, I think invader-sound defaults things when remaking a tag, we might need to have it not do that.
The text was updated successfully, but these errors were encountered: