Nameless Voice on 3/8/2017 at 21:00
So, then, the problem is that Larry used a non-standard install of TafferPatcher, and that's what caused problems with his FM?
It's still likely others have done the same.
LarryG on 3/8/2017 at 23:45
Not that I used a non-standard install. I used a non-default install, but still a standard install. I wanted to test and see. And I saw and was horrified.
gamophyte on 4/8/2017 at 02:13
Sorry to pipe up, but wasn't there a community driven project to replace the cannon textures with HD versions 1:1? I wonder what happen to that.
LarryG on 4/8/2017 at 02:31
That's the EP2 that NV mentioned.
Quote Posted by Nameless Voice
But the FM wouldn't know which DML files would exist at the time of publishing. The whole idea is that a DML could fix problems in a published FM, as a patch, so users wouldn't have to re-download the entire patched version and restart their game.
So how does the game know which DML files go with which FM? Something has to tell it. I would think that if a user is installing a DML for a fan mission that there would be some sort of installation process which indicates that the FM has DMLs to use. Would that not be part of the FM's configuration? Hence fm.cfg getting a mention.
Yandros on 4/8/2017 at 03:48
Over in the FM forum, Unna has created DML patches to fix tons of old FMs which are broken under NewDark. She just puts it in a file named the same as the .mis file (miss17.mis.dml I believe is the correct format) and NewDark knows to apply the DML when loading that mission. I assume that's all documented in the NewDark docs.
LarryG on 4/8/2017 at 04:17
How does it know that miss17.mis for one FM uses miss17.mis.dml and another miss17.mis from another FM doesn't? What if both need a miss17.mis.dml but different ones? Somehow they have to be associated with specific FMs or it won't work. I don't know how it is done. It just seemed sensible that the file which is supposed to have FM specific configuration information might be involved. In any event, someone needs to muck about and install the dml to something somewhere. In any event, it shouldn't have anything to do with the topic of this thread: mods and how FM authors can keep them from getting applied to their missions.
NV brought dmls into the question:
Quote Posted by Nameless Voice
Allowing the FM selector to disallow mods is no solution either. That has its own set of problems, including not being able to make patches for FMs, let alone a lot of annoyed players forced to play with ugly, low-res original objects just to preserve the author's "artistic vision".
I don't see how preventing mods hampers dml patching. Those are totally different things, no?
voodoo47 on 4/8/2017 at 07:39
dmls need to be placed in a modpath (or game root, or loadpath, but those two will only load for OMs), so a FM that would deny modpath loading would kill any custom dml stuff one could have there. which is not a big deal really, as I doubt too many people experiment with dml stuff, but one way or another, the best thing to do about the whole NTEX vs FMs situation is to go lowtech, and just slap warnings about unsanctioned texture packs all over. the amount of people that refuse to read and install NTEX at the same time and then cry on forums should be manageable.
Quote Posted by LarryG
How does it know that miss17.mis for one FM uses miss17.mis.dml and another miss17.mis from another FM doesn't? What if both need a miss17.mis.dml but different ones?
the easiest thing to do is to stick the dml into the root folder of its FM, that means it will only be activated once the FM is launched. if you want to get smart, you can use fingerprinting, making the dml check for various qvars and objects, and it will only activate if everything matches then. I have already played around a bit and it seems like including a FM dml repository with the patcher(s) is doable, making things convenient on the FM side. I actually shared an example awhile ago.. somewhere.
R Soul on 4/8/2017 at 09:56
NewDarkLoader allows you to have a store of dmls (and replacement files, e.g. fixed textures, strings files with fixed typos, bugfixed missions etc) which get copied into the installed FM's folder after installation.
LarryG on 4/8/2017 at 12:00
So, can (
http://www.ttlg.com/forums/showthread.php?t=146917) NewDarkLoader read a fm.cfg file for a configuration variable and display a warning about using mods with that FM and then let the user choose whether or not to install the mods when playing the FM?
Quote Posted by voodoo47
the easiest thing to do is to stick the dml into the root folder of its FM, that means it will only be activated once the FM is launched. if you want to get smart, you can use fingerprinting, making the dml check for various qvars and objects, and it will only activate if everything matches then. I have already played around a bit and it seems like including a FM dml repository with the patcher(s) is doable, making things convenient on the FM side. I actually shared an example awhile ago.. somewhere.
So folk would have to muck about with the zip and add the dml to the root of the zip, to keep miss17.mis for one FM separate from the miss17.mis for another. In which case, what does that have to do with mods? Nothing that I can see. Nor do I see how editing a zip to include a dml is significantly easier or better than editing a zip to include an updated mis file. I think from what you have said that the dml issue is a bit of a red herring and not really relevant to the discussion of the mods.
Yandros on 4/8/2017 at 12:51
No Larry, they just have to drop the patch DML into the install folder created by FMSel or NDL.
