voodoo47 on 20/3/2019 at 11:09
less screens one has to go through, the better, I think.
it's pretty easy to add the fingerprint qvar even to the oldDark missions, one just has to set up oldDark Dromed. shouldn't be that difficult, if one decides that the oldDark missions + fingerprinted mods is a combination that should be offered by the patcher. also, an additional fingerprint block can be added that will check positions of concrete objects in the oldDark missions and permit the dml on that base, if you don't want to touch the levels.
Quote Posted by Jax64
perhaps it would be good practice to eliminate any possibility of problems occurring.
that is impossible by design, so it's always a question of how much stuff you want to fix/enhance vs how much trouble you (don't) want to potentially cause.
Jax64 on 21/3/2019 at 21:30
Perhaps my statement was somewhat hyperbolic. It seems that t2skies has a lower likelihood of causing problems than the other mods with mission DMLs, especially considering that FMs with custom skies will supersede them. Though despite this, it would probably be best to load the mission-specific sky DMLs only for the intended original missions. It will likely employ the same fingerprint method that will be used for the Carry Body Mod.
I would prefer to not change the old missions, as they are only copied if the old missions are detected and are left alone completely if the fixed missions are not selected. Using an object-based fingerprint block seems to be the best solution. In fact, I was not aware multiple fingerprint blocks could be specified until my recent tests confirmed it to be true, as it does not seem to be mentioned in the documentation.
On account of this, the Carry Body Mod miss1.mis.dml will look like this:
Code:
DML1
FINGERPRINT
{
QVAR "T2origmis" == 1
}
FINGERPRINT
{
75 [115 21 9]
271 [89 2 11]
162 [62 119 4]
521 [18 77 3]
361 [-87 5 28]
959 [-53 -54 17]
789 [45 -103 1]
542 [22 -73 4]
}
//sword guards in this mission use different models
+ObjProp 533 "invlimbmodel" = "LMarcher01"
+ObjProp 521 "invlimbmodel" = "LMarcher01"
+ObjProp 213 "invlimbmodel" = "LMarcher01"
+ObjProp 217 "invlimbmodel" = "LMarcher01"
+ObjProp 106 "invlimbmodel" = "LMarcher01"
+ObjProp 198 "invlimbmodel" = "LMarcher01"
+ObjProp 207 "invlimbmodel" = "LMarcher01"
+ObjProp 262 "invlimbmodel" = "LMarcher01"
//Basso and Jenivere
+ObjProp 75 "invlimbmodel" = "LMbasso"
+ObjProp 177 "invlimbmodel" = "LMjenv"
As long as each new version of the fixed missions implements the new quest variable, the DML should load even if the checked objects are changed, thus making it compatible with both the unmodified missions and all future versions of the included fixed missions.
voodoo47 on 21/3/2019 at 22:01
yes, that should be the correct syntax (two fingerprint blocks mean if just one is a match, the dml will load). this means we can now load candles for the fixed OMs only, but carrybody for both fixed and unfixed OMs (while not loading for any FMs) - whoever designed this really knew what they were doing.
agreed with the sky stuff as mentioned earlier, though some FMs will inevitably not look as originally intended (our old friend bad practice - if the FM uses custom oldsky, and it doesn't have a custom name, the hires sky will inevitably load, changing the aesthetics, maybe more, maybe less. as you may have guessed, I don't consider this a big deal - "my stuff doesn't work properly with this mod" "disable the mod then").
//ah, one more thing - when constructing the obj position fingerprint block, using objects that are unlikely to be moved or otherwise changed is preferred, so ideally, markers and similar non-phys objects that are not part of the world visible to the player. probably shouldn't matter too much in this case as T2origmis should work reliably, but hey, good practice is always a good idea.
Jax64 on 22/3/2019 at 17:32
Yes, the ability to use DMLs for such fixes is very impressively well-designed and most helpful in this situation.
The latest T2Fix build now incorporates the two-block method to fingerprint the Carry Body Mod and t2skies, with the Interactive Candles only using one block since they are only intended to be used with the fixed missions. I suppose even with this, some missions using default assets will still be affected by these mods, but then again, that is what the installation types are intended for. If someone does not want a particular mod, they can either not select it or select a type that fits their desires.
voodoo47 on 22/3/2019 at 17:41
agreed. and pretty sure all the fingerprinted mods have almost zero chance of breaking even the most shoddily constructed FM - this is as safe as you can get.
bassoferrol on 22/3/2019 at 18:55
I´m playing Thief Gold with TFix and with the candles mod activated and everything seems to be OK. No problems so far.
Are the assets that I´m using also valid for Thief2 or something extra/modified is needed?
(
https://megaupload.nz/w1FemcTdm1/candlest1_rar)
voodoo47 on 22/3/2019 at 20:45
you won't have to do anything manually (that's why a patcher exists) - the T2 version of the interactive candle mod has been fully integrated into T2Fix, just keep the mod enabled when patching up.
Jax64 on 23/3/2019 at 21:19
It looks like you have the vhotted candle models in that archive, so your assets should be valid for Thief 2, though there seem to be a variety of other models that are likely not needed and a significantly larger trcandle.bin. However, you are missing the DMLs that actually add the flames to the candles, which is a vital part of the mod and differ between Thief 1 and Thief 2. As said above, T2Fix currently has this all set up properly, so all you would need to do would be to select the mod on the components page to have everything working properly.
Speaking of, with the beginning of the Thief 2 20th Anniversary Contest, it may be appropriate to make this public. I have valued all feedback thus far and will continue to do so, but it seems that all major concerns and issues that have been brought to light have been addressed.
voodoo47 on 23/3/2019 at 21:37
quick check on the latest version (0.37b), looking solid - I wouldn't be too afraid to go public at this point.
also, maybe consider adopting the TFix style version numbering system - the number corresponds to the NewDark version used, and the letter indicating the patcher build.
Jax64 on 23/3/2019 at 22:00
I agree. The TFix numbering system makes it very easy for users to understand which version they are intended to use and which version of NewDark it incorporates since they correspond appropriately.
Therefore, the first public build will be version 1.26 and will likely be finalized with a topic on the General Discussion forum sometime within the next day or so, unless I am made aware of another issue that needs attention.
