New EasyTutu Version Available

Remove all ads!

Hello -

A new version of EasyTutu is now available for download.

For the most part, this new version consists of bugs I've fixed over the past three months. I've also furthered the conversion of the game journal to a BG2-style implementation for the last chapters. Unfortunately, the journal still isn't done yet, but I am happy with the current level of progress. I deliberately handled the entirety of the expansion before chapters 5 to 7, because I knew that working on the portion of the game which takes place in the city of Baldur's Gate would be like crossing a pool of quicksand -- very difficult to come out clean on the other side once you've waded in. But for the first time I can say that the finish line is in sight. There is certainly much left to do, but much more is done than undone in the city at this point.

In any case, the EasyTutu changelog contains the full details of what's included in this release. The downloads are in their usual spot on the main EasyTutu page.

For those of you interested in Gorilym's Mac port of the EasyTutu game content, I've also updated the Mac packages to the level of this current release.

Happy holidays.

 

No progress on the Beregost save bug, huh?

I was just playing earlier and lost a save to that. Not that I'm complaining, just thought I'd ask. Keep up the good work.

 

New version

Did you correct the StrRef interpreting issue too, the one which causes warnings in certain editors for modders who use EasyTutu resources?

 

Hello -

I wouldn't expect any movement there anytime soon. It's not that the desire is lacking...it's just that the cause of the problem is a bit of a puzzler.

I wasn't aware of an issue with strrefs. Are you referring to the values found in "empty" slots? If so, I honestly don't view it as much of an issue. Any strref with anything past, say, the eighteenth or nineteenth bit set is pretty clearly a "blank."

You'll generally find me reluctant to pick up and modify game files when I don't perceive much potential benefit for end users. As a consumer of mods myself, nothing irritates me more than formerly working code being turned into not-working-code, especially when the reason for the change doesn't add anything to the game.

That said, if there is some sort of substantial hue and cry from the modding community, I'm certainly willing to listen. But this is the first I've really heard anyone openly complain about strrefs (aside from complaining that they're dynamic in Tutu, a headache which we all share).

 

Then we're thinking in a similar way in this respect.

No, it's not about modifying existing game files, it's that EasyTutu seems to make a little error during the conversion (or for some other reason, all EasyTutu StrRefs get changed):
http://forums.gibberlings3.net/index.php?showtopic=7401
In other words, the MSB is not set (to 1) for the 32-bit value, which will result in (2^32) - 1, instead of -1.

If this applied to existing game files, I wouldn't say anything, but as I've said above, it seems EasyTutu does it, with all of its files (which are OK in the original game). It's easy to say what a modder said i.e. that "it's DLTCEP's fault", but it won't help on those mod makers who use DLTCEP and receive lots of (modal) warnings. All in all, I just say that where the game correctly uses -1, let's not change it when it's unnecessary, especially for lots of files.

(Note: WeiDU SAY #-1 causes the same problem because OCaml uses 31-bit integers and somewhere in its code, there is still int instead of int32. Did you use WeiDU in any phase of EasyTutu's development, perhaps that's the source of the "problem"?)

 

Hello -

I understand what you are saying, but the horse is out of the barn, so to speak. EasyTutu began as Tutu v4 with Tutufix v15 core bug fixes. Since then, the development paradigm I've used is that each release uses the previous release as a starting point. So, I'm not starting from scratch every time I build a new release; I'm starting from the last release.

I suspect that the issue traces back to the original Tutu converter. But in any case, it is done; and now reverting to something else would mean editing hundreds of files.

Regardless of the particulars of the case, though, I still maintain that it's a bit silly for DLTCEP to issue warnings over these values.

 

Indeed, DLTCEP strives for perfect consistency, but modal warnings in this case are a bit overkill. Nonetheless, many modders work with EasyTutu or use its resources, and they can do nothing to prevent this.

Do you think I would have recommended this change if it was about the manual processing of a thousand files? No, only a few clicks. With the program that I made and is available through the linked Gibb3 topic. Or with a short TP2 + WeiDU. Whichever you like. Many modders would appreciate it, I'm sure. Well, of course, it's your call, as EasyTutu is yours.

 

Hello -

I'm not worried about the speed or efficiency with which I can amend the files. I just resist editing hundreds of game files for a change that brings nothing to the game and which the vast majority of end users would hold in absolute ambivalence.

I suspect that at least half of EasyTutu users don't even know what a strref is. I would further venture to guess that an even larger percentage do not care if the bit pattern used to signify an unassigned string reference conforms to a rigid standard. So where does that leave them? If I undertake the edit, the best possible outcome is that I won't break anything. And their reward for that level of perfection? Nothing (that is visible in-game, anyway). And if I fall short of perfection? I've broken something that didn't used to be broken.

Many problems start this way. A clear goal and the best of intentions. But I can tell you that a substantial number of issues I end up supporting at the Tutu forums can be characterized as regular expressions gone wrong. And while mods which add content or customization to the game are worth a little risk, I don't believe this issue is.

If you've got a tool that handles this issue already, great. You can characterize it as a piece of a modder's toolkit that will reduce irritating errors for them. If I run across anyone else experiencing frustration over this issue, I will remember that a tool exists to address it and advise them accordingly.

 

Just one comment:

If something is not risky, then it's this: a very simple file manipulation procedure that is applied on N files in the same way. (There are a few filetypes, but these require very minimal changes on the algorythm.) You obviously know that everything is 100% deterministic and accurate here (at least between the limits we need it): in other words, it can't happen that it changes the first 100 files in a different way than the other N-100. The theoretical risk is 0. It's OK if you don't trust my program (although it was well-tested by more people, you've full right not to trust a program which source you don't know). Furthermore, it works only with CRE files. But there are plenty of programming languages you can use, or just WeiDU if you prefer it: a few lines of source code (=> functionality is fully visible to you), and you can try it on test files first. Coding-testing-applying, no more than 10-15 minutes in worst case for one filetype.

I understand that you want EasyTutu to be as player-centric as possible, which is correct because eventually it's for players, not modders. On the other hand, based on those I've explained above, I don't think it would be too risky at all to apply a primitive procedure on the files, for the sake of DLTCEP users. However, you're the author, and as I've said, it's up to you how you estimate the risk, and what decision you make.

 

Sounds great, I can't wait to give it a try!