Wisp Posted February 6, 2012 Share Posted February 6, 2012 i) It serves no discernible purpose, ii) it is pretty much only ever installed because it is there, iii) it's presence is inconvenient and iv) all the other reasons it should be axed. Link to comment
Miloch Posted February 7, 2012 Share Posted February 7, 2012 I used to use it but pretty much manually do the things that it does when I mod. Though it can still serve a purpose... I guess anyone who wants it can always undeprecate it. What are "all the other reasons"? Link to comment
Daulmakan Posted February 7, 2012 Share Posted February 7, 2012 Disabling DLTCEP's startup error messages makes it worthwhile for me. Is there an actual technical reason for avoiding it? Link to comment
Salk Posted February 7, 2012 Share Posted February 7, 2012 I think it should be deprecated but I wonder if there's code there to be salvaged and imported into the Core fixes? Link to comment
berelinde Posted February 7, 2012 Share Posted February 7, 2012 Disabling DLTCEP's startup error messages makes it worthwhile for me. Is there an actual technical reason for avoiding it? If you're a player, not really, but there's no reason to include it, either. If you're a modder, you should never, ever install it. It does things that your mod *should* do, patching in CD_STATE_NOTVALID if you haven't done it already, patching ids, assigning area scripts to areas where the vanilla game did not, patching in a blank song reference to allow mods to use PlaySong(0), etc. Basically, it's there to prevent players from suffering at the hands of lazy modders. Link to comment
Ardanis Posted February 7, 2012 Share Posted February 7, 2012 Ninde and Xulaye mods over SHS either didn't install at all or installed with warning without this component. It's been three years ago, though, so I'm don't know if Kae had updated them since then. Link to comment
ericp07 Posted February 7, 2012 Share Posted February 7, 2012 I've never had such issues when installing Ninde or Xulaye, although both mods required me to manually edit a bit to get them to install with no errors. As for the SHFLM component, I'm with those who'd like to see the component removed. Link to comment
devSin Posted February 7, 2012 Share Posted February 7, 2012 Yes, it needs to be removed. Somebody will have to review the component to see if there's anything salvageable, and there may be things in there that deserve some sort of community release (maybe a tutorial or something), but it doesn't belong in the fixpack. There was a reason for it in the beginning, but the lack of maintenance and the reality of mod development simply make it more harmful than beneficial. Link to comment
plainab Posted February 7, 2012 Share Posted February 7, 2012 It does things that your mod *should* do, patching in CD_STATE_NOTVALID if you haven't done it already, patching ids, assigning area scripts to areas where the vanilla game did not, patching in a blank song reference to allow mods to use PlaySong(0), etc.that right there is the reason it was developed. If every mod under the sun had to put all this stuff in prior to the actual mod content... well it stands to reason to have a singular install for all mods rather than some modders doing it and other modders not and mods not playing nice with each other cause of it. If nothing else, a tutorial explaining what each thing does and why and where you should put it in your mod if your mod touches on any of the stuff. Where it becomes a problem is those mods made with the fixpack and the happy lucky component installed and players installing said mod without using the fixpack. BUT it becomes the modder's responsibility to inform their users that the mod requires the fixpack and the happy lucky component. Link to comment
Ardanis Posted February 7, 2012 Share Posted February 7, 2012 You might be surprised to hear this, but all too often players don't really follow install orders. They're lazy to read and to study all the technical aspects of BG modding. Lately it was somewhat mitigated by BWP, but you may never be certain. As usual - if you want something done, do it yourself. Link to comment
Daulmakan Posted February 8, 2012 Share Posted February 8, 2012 Disabling DLTCEP's startup error messages makes it worthwhile for me. Is there an actual technical reason for avoiding it? If you're a player, not really, but there's no reason to include it, either. If you're a modder, you should never, ever install it. It does things that your mod *should* do, patching in CD_STATE_NOTVALID if you haven't done it already, patching ids, assigning area scripts to areas where the vanilla game did not, patching in a blank song reference to allow mods to use PlaySong(0), etc. Basically, it's there to prevent players from suffering at the hands of lazy modders. Or aspiring, modders-to-be. It seems it's been more useful than I thought. Since the component is optional, I don't really see the harm. If it's the lack of updates, there are several other mods at G3 that could do with an upgrade as well. Link to comment
Wisp Posted February 8, 2012 Author Share Posted February 8, 2012 What it does: Append IDS symbols to animate.ids, anisnd.ids, gtimes.ids, shout.ids and spell.ids Add a header (IDS V1.0) to damages.ids, happy.ids, slots.ids, soundoff.ids and state.ids Add the file moraleai.ids Append the CD_STATE_NOTVALID symbol to state.ids Add a blank mus file to songlist.2da Write references to non-existent area scripts to areas wihout a reference Fix nulled map-note offsets in a bunch of areas (with 0 map notes) Remove undetectable, undisarmable "traps" with no effect (no script) from containers in ar0311.are. ar0327.are, ar0417.are and ar0510.are Conformise spell level and spell type with the spell res for many memorised spells Write duration = 0 for many spell effects with non-temporary timing modes (to appease DLTCEP) Remove ability headers of type 0 from many items (from back when this was thought to stop the drain-charge opcode from destroying the whole item) 1, 4 and 5 should be done by the mod that needs it, as per standard practice today. 7 may be valid, but I assume it was banished to the modder pack because it was, in fact, not. The rest are either bunk or smell strongly of it. Maybe 3 and 10 can be spun off as some make-DLTCEP-happy library. Link to comment
aVENGER_(RR) Posted February 11, 2012 Share Posted February 11, 2012 1, 4 and 5 should be done by the mod that needs it, as per standard practice today. Agreed. Maybe 3 and 10 can be spun off as some make-DLTCEP-happy library. That would probably be for the best. Link to comment
CamDawg Posted July 29, 2012 Share Posted July 29, 2012 The SHFLM was originally planned as a new home for detectable spells until we discovered what a mess that would actually be. As a result it ended up being a largely ignored, largely useless bag of tricks. Deprecate the whole thing, but leave the code intact in case some modder wants to grab some bits or, alternatively, move the whole damn thing to the debugging suite. Link to comment
cmorgan Posted July 29, 2012 Share Posted July 29, 2012 1, 4 and 5 should be done by the mod that needs it, as per standard practice today. Agreed. Deprecate the whole thing, but leave the code intact in case some modder wants to grab some bits or, alternatively, move the whole damn thing to the debugging suite. I agree - move into debugging suite as feedback for modders, and reinforce the docs and to indicate findings without fixing, then allow fixing? Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.