![]() |
The Black Wyrm's Lair Terms of Use |
![]() ![]() ![]() ![]() |
![]() |
![]()
Post
#1
|
|
Forum Member Posts: 4 Joined: 4-September 08 ![]() |
I am in the middle of installing Big World and specifcally the Lost Crossroads Spell Pack for Baldur's Gate 2 = SpellPackB5 and am encountering an error.
When trying to install the Core Files and Graphics it fails with the following error. "DEITM049.ITM: read out of bounds". Can anyone help resolve this. Thanks. |
|
|
![]() |
![]()
Post
#2
|
|
![]() Master of energies ![]() Council Member Posts: 3327 Joined: 9-July 04 From: Magyarország ![]() |
Glad to hear that. I hope you will practise that intolerance the other way around as well, i.e. when you see real bashing against BWL members and works.
QUOTE(Galactygon) QUOTE QUOTE Why isn't the file fixed in such cases when the problem is known? If it's just about a header field, it wouldn't result in any modification of the file content-wise. I actually meant that the third-party code (e.g. in this case, SpellPack) could fix it instead of suppressing possible errors due to it (with "ELSE 0"). It's acceptable in cases when the buggy mod isn't supported (and that is what I suspected that time). Yes, I am thinking on ways to do it. I can already guess that in some cases the last effect in the last header isn't fully defined (with the opcode being a BYTE instead of SHORT), and I have to insert 0 bytes until it is. Regarding the solution of the concrete problem discussed in the present topic, I made a reference to it in this paragraph: QUOTE(Baronius) BeachBum: as far as I can see, the file you attached is still invalid (IEMF detected an error). I quickly corrected it with a hex editor, the feature block offsets seemed to be invalid in the extended headers. As TheBigg has said, the culprit is DEITM049, and if you want to fix it, the base of the solution can be read above. If you're speaking generally (more precisely, in the context of other out-of-bounds error with SpellPack), this 0-byte insertion doesn't sound like an elegant solution (I even don't remember why such a thing is needed in WeiDU). If you show a code example where you believe there is such a problem, I can say more if you're interested. -------------------- Mental harmony dispels the darkness.
|
|
|
![]()
Post
#3
|
|
![]() ![]() Mod Developer Posts: 1158 Joined: 22-July 04 From: Sweden ![]() |
Glad to hear that. I hope you will practise that intolerance the other way around as well, i.e. when you see real bashing against BWL members and works. When anything like that happens in my subforums, I will. I am not the type who goes into stuff like this in other threads in other forums, but when it spills over to here, I have to draw a line. If you're speaking generally (more precisely, in the context of other out-of-bounds error with SpellPack), this 0-byte insertion doesn't sound like an elegant solution (I even don't remember why such a thing is needed in WeiDU). If you show a code example where you believe there is such a problem, I can say more if you're interested. This is what I meant, really. We were cross-talking a bunch. A macro that fixes the number of effects if there is a gaping disagreement between that and SOURCE_SIZE. I do not have my macros up at the moment and I have never done anything like this, so I am posting my thoughts rather than testing them through trial and error. 1.) The macro looks at the last header, counts the number of effects and compares it to SOURCE_SIZE. 2.) If the (number of effects times the feature block size plus whatever other offsets there might be) is larger than the SOURCE_SIZE but not by more than 48 bytes, then we assume the last feature block didn't get filled in. So we expand the SOURCE_SIZE gets with zeroes as needed. 3.) If the (number of effects times the feature block size plus whatever other offsets there might be) is larger than the SOURCE_SIZE by at least 48 bytes, then we assume there is something wrong with the number of effects. We then start counting the number of effects manually until we run out of bounds, counting feature blocks that might be less than 48 bytes. In that case, we go to 2.). This sounds somewhat right, would I have to account for headers that go before the last header, or is it always the last header that causes all the problems? -Galactygon -------------------- |
|
|
![]() ![]() |
![]() |
Lo-Fi Version | Time is now: 7th October 2025 - 01:33 AM |