15 replies to this topic

[Wisp]

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.

[Miloch]

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"?

[Daulmakan]

Disabling DLTCEP's startup error messages makes it worthwhile for me. Is there an actual technical reason for avoiding it?

[Salk]

I think it should be deprecated but I wonder if there's code there to be salvaged and imported into the Core fixes?

[berelinde]

Daulmakan, on 06 February 2012 - 05:31 PM, said:

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.

[Ardanis]

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.

[ericp07]

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.

Edited by ericp07, 07 February 2012 - 08:54 AM.

[devSin]

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.

[plainab]

Quote

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.

[Ardanis]

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.

[Daulmakan]

berelinde, on 06 February 2012 - 11:18 PM, said:

Daulmakan, on 06 February 2012 - 05:31 PM, said:

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.

[Wisp]

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.

Edited by Wisp, 08 February 2012 - 10:01 AM.

[aVENGER_(RR)]

Wisp, on 08 February 2012 - 09:52 AM, said:

1, 4 and 5 should be done by the mod that needs it, as per standard practice today.

Agreed.

Quote

Maybe 3 and 10 can be spun off as some make-DLTCEP-happy library.

That would probably be for the best.

[CamDawg]

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.

[cmorgan]

Quote

1, 4 and 5 should be done by the mod that needs it, as per standard practice today.

Agreed.

Quote

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?