Jump to content

Incorporating bits of fixpack into core?


Recommended Posts

This is a technical thread, basically aimed at Cam though anyone up to speed is welcome to participate.

 

I'm wondering which, if any, fixes in the fixpack ought to be incorporated into v6. Since we're not distributing the core code, but an EasyTUTU version (assuming you're happy with that method) then pure elegance isn't a reason. I suppose generality might be a reason (e.g. if there's some Fixpack fix that's fixing an instance of a general problem caused by some bug in the core conversion.)

 

Anyway, I don't imagine I'll be trying to put together a v6 any time soon (RL, plus a pending SCS/SCSII update) but in the longer term it's probably worth thinking about - any thoughts? (The only thing that pretty much has to be rolled into v6 is the map crash fix, since there's no point distributing 3MB of broken maps.)

Link to comment

Yeah, EasyTUTU style is the way to go.

 

I think we're close enough now that, really, I feel like there's little-to-nothing that needs to be rolled back to the core. Maybe heavy lifting-type stuff, such as large files (i.e. the 4MB of mini-map MOS files), huge or time-consuming patches (none at the moment), or stuff that needs to go back to the original IWD resources (string fixes?). On principle we should probably roll back in conversion errors--like the incorrect portrait icon for regeneration or the complete miss on the OnIsland() trigger--but from a pragmatic standpoint there's not much reason (those two errors are fixed with, say, 10 files).

 

I feel like if we need a core package update, then sure, go ahead and roll everything in from the Fixpack as you feel like, because it will ultimately save a little time for the end-users. I don't, however, anticipate that there would ever be a Fixpack update vital enough to force an update in Core.

Link to comment
Yeah, EasyTUTU style is the way to go.

 

I think we're close enough now that, really, I feel like there's little-to-nothing that needs to be rolled back to the core. Maybe heavy lifting-type stuff, such as large files (i.e. the 4MB of mini-map MOS files), huge or time-consuming patches (none at the moment), or stuff that needs to go back to the original IWD resources (string fixes?). On principle we should probably roll back in conversion errors--like the incorrect portrait icon for regeneration or the complete miss on the OnIsland() trigger--but from a pragmatic standpoint there's not much reason (those two errors are fixed with, say, 10 files).

 

I feel like if we need a core package update, then sure, go ahead and roll everything in from the Fixpack as you feel like, because it will ultimately save a little time for the end-users. I don't, however, anticipate that there would ever be a Fixpack update vital enough to force an update in Core.

 

That sounds pretty sensible. (& I'm reassured that we do actually seem to be fairly close - the kind of errors being reported now are mostly specific things, rather than indicators of some general feature of the game that the converter missed or got wrong. )

Link to comment

Just wondering what this conversation is all about... but I'll just fire away even if it's not even nearly relevant.

 

EasyTUTU & IwDinBG2: I really like how the conversation was made in the v5, that the BG2 game is left untouched, as this allows a bit more convinience in the install. And as long as you won't go an make a Windows Registery entry, everything is nice and neat(as I hate the whole idiosy of the though that brings).

 

Fixpack: If this was ever about incorporating some or most (G3)BG2Fixpacks relevant fixes and add on's to the games engine(the one in IcewindTUTU directory), then you should give it a go, as long as it doesn't damage core resourses...

 

Fix patching/version: to me, if you can coordinate it so that this thread, or another pinned thread has the suggested install order of the core resources, I don't care if there's 10 000 patches to one version update... that will eventually have everything under it's hood when it get's released.

Link to comment
Fixpack: If this was ever about incorporating some or most (G3)BG2Fixpacks relevant fixes and add on's to the games engine(the one in IcewindTUTU directory), then you should give it a go, as long as it doesn't damage core resourses...

I think DavidW already incorporates relevant BG2 Fixpack stuff in the core package, but that's not what we're discussing here. We're talking about how to coordinate maintenance of the core IWD in BG2 package and the post-install fixpack (ice_tutu_fix).

 

Ideally I'd want only two downloads for this mod: a large, very stable, rarely updated core package for the conversion and then a smaller, oft-updated, nimble package of fixes that would be run after the conversion as a regular WeiDU mod.

Link to comment
Fixpack: If this was ever about incorporating some or most (G3)BG2Fixpacks relevant fixes and add on's to the games engine(the one in IcewindTUTU directory), then you should give it a go, as long as it doesn't damage core resourses...

I think DavidW already incorporates relevant BG2 Fixpack stuff in the core package

 

Yep.

 

Ideally I'd want only two downloads for this mod: a large, very stable, rarely updated core package for the conversion and then a smaller, oft-updated, nimble package of fixes that would be run after the conversion as a regular WeiDU mod.

 

Agreed, though we might want to incorporate the ice_tutu_tweaks bit of the core package into the fix in due course (much as with tutufix in the pre-Easytutu days, come to think of it.)

Link to comment
Agreed, though we might want to incorporate the ice_tutu_tweaks bit of the core package into the fix in due course (much as with tutufix in the pre-Easytutu days, come to think of it.)

 

If you are following the Macready-style (great idea) then the way he worked it out was all of TutuFix that wasn't "subjective changes" made it into the core package; the only reason he kept things in TutuFix was for v4 users and for things that made "tweaks".

 

At this point, with this being legacy gaming and establishing a stable usable modding platform, is there any reason *not* to add every single current thing to the core package, and then build a separate IWD_IN_BG2 fixpack/tweakpack that runs afterwards that updates the core package? It would probably be easier to maintain two separate packages in this case, instead of one IWD Fixpack that would have different needs based on vanilla vs EasyIWD.

Link to comment
At this point, with this being legacy gaming and establishing a stable usable modding platform, is there any reason *not* to add every single current thing to the core package, and then build a separate IWD_IN_BG2 fixpack/tweakpack that runs afterwards that updates the core package? It would probably be easier to maintain two separate packages in this case, instead of one IWD Fixpack that would have different needs based on vanilla vs EasyIWD.

 

At any given stage, there's no reason not to add all current things to the core package. The problem is that updating the fixpack takes minutes and produces a 1MB download, whereas updating the core contents takes hours and produces a 20MB download. So it's just not time-effective to keep updating the core package.

 

Case in point: at some point in the next month or so, I'll reissue the core package because there are 3MB of Cam-produced maps that need to replace the David-produced maps. When I do that, I might as well roll the fixpack into the overall release. But it's not really worth doing that every time a bug turns up, especially as - realistically - the mod is still going to be generating bugs for many months to come.

Link to comment

If it's possible to keep the things to tweakpack and not core, I'd really appreciate it.

 

I mean, there was a discussion in another thread that many "Player1" checks should be changed to "LastTalkedBy" checks in case another party member talks to a quest giver. And the general decision reached seemed like "change it!". While to me, the proposed change would be totally counter to game intent(please note how carefully I'm avoiding the word "horrible"), because IWD is built on "everybody listens to PC, not some companions", just like Dragon Age. So, I don't want to argue the point - I just prefer to see it in some tweakpack(or fixpack, you name it), so I don't need to ever install it.

Link to comment
I mean, there was a discussion in another thread that many "Player1" checks should be changed to "LastTalkedBy" checks in case another party member talks to a quest giver. And the general decision reached seemed like "change it!". While to me, the proposed change would be totally counter to game intent(please note how carefully I'm avoiding the word "horrible"), because IWD is built on "everybody listens to PC, not some companions", just like Dragon Age. So, I don't want to argue the point - I just prefer to see it in some tweakpack(or fixpack, you name it), so I don't need to ever install it.

Umm, no. There was no discussion to change Player1 to LastTalkedToBy, it was to change Protagonist to LastTalkedToBy. And the reason why is because that's how the Protagonist object works in IWD.

 

Feel free to check it out yourself and confirm it works differently in the two engines--which, incidentally, is exactly what I did before I said "change it!".

Link to comment
While to me, the proposed change would be totally counter to game intent(please note how carefully I'm avoiding the word "horrible"), because IWD is built on "everybody listens to PC, not some companions", just like Dragon Age.

In IWD, there are six player-created PCs, and none is more important than the others. There is no Player1 godchild.

 

In IWDNPC, I agree, it's different. But that's a mod, even if it's your mod.

 

(And as Cam says - check out Player1 vs Protagonist in the two engines)

Link to comment

Can I just try to make clear that the question this thread is (intended to be) about is a completely technical coding/distribution question about how to manage the core conversion. It doesn't have anything to do with tweaks vs core.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...