Salk Posted April 27, 2006 Share Posted April 27, 2006 I found out that having WeiDU 191 or higher would cause the following bug at installation of Druid Remix: Copying and patching 1 file ... [./override/ALIGNMNT.2da] loaded, 5428 bytes ERROR: [ALIGNMNT.2da] -> [override/ALIGNMNT.2da] Patching Failed (COPY) (Invalid_argument(_)) Stopping installation because of error. ERROR Installing [Druid Remix], rolling back to previous state Link to comment
the bigg Posted April 27, 2006 Share Posted April 27, 2006 OK, after so much time I took the time to look at this. DR code is incorrect: Alignmnt.2da has 10 coloumns, so the max value acceptable is 9; however, DR patches up to the 10th one (which doesn't exist and makes WeiDU fail the install). Solution: at 7430-ish, change //Alignment changes COPY_EXISTING ~ALIGNMNT.2da~ ~override/ALIGNMNT.2da~ FOR (index = 2; index < 11; index = index + 2) BEGIN SET_2DA_ENTRY 6 "%index%" 10 ~1~//Druid SET_2DA_ENTRY 15 "%index%" 10 ~1~//Fighter-Druid to //Alignment changes COPY_EXISTING ~ALIGNMNT.2da~ ~override/ALIGNMNT.2da~ FOR (index = 2; index < 10; index = index + 2) BEGIN SET_2DA_ENTRY 6 "%index%" 10 ~1~//Druid SET_2DA_ENTRY 15 "%index%" 10 ~1~//Fighter-Druid (notice the '10' rather than '11' at the third line) Link to comment
Guest Erik Posted April 27, 2006 Share Posted April 27, 2006 OK, after so much time I took the time to look at this. DR code is incorrect: Alignmnt.2da has 10 coloumns, so the max value acceptable is 9; however, DR patches up to the 10th one (which doesn't exist and makes WeiDU fail the install). Solution: at 7430-ish, change -snip- Yep. As seen in this post Link to comment
the bigg Posted April 27, 2006 Share Posted April 27, 2006 Which I, uh, didn't notice Link to comment
Andyr Posted April 28, 2006 Share Posted April 28, 2006 Is this related to some WeiDU change? The code worked when I wrote it a few years ago. Link to comment
the bigg Posted April 28, 2006 Share Posted April 28, 2006 Yes - WeiDU didn't care if you SET_2DA_ENTRY out of bounds. Which is very bad. Link to comment
Andyr Posted April 28, 2006 Share Posted April 28, 2006 Oh, hmm. But the code did used to work correctly--wouldn't it have just not patched correctly and given the wrong alignments? Link to comment
the bigg Posted April 28, 2006 Share Posted April 28, 2006 older WeiDU would start happily writing random strings to random places of the memory because it didn't check if there was an out-of-bounds (= a buffer overflow). This could lead to both wrong tp2s and, more importantly, CTDs at install. So, it didn't really 'work correctly', it did random things without telling you about them. Link to comment
Andyr Posted April 28, 2006 Share Posted April 28, 2006 What I meant was, even if my code is now incorrect why did it work originally? Did WeiDU change starting counting from 1/0 or something? I am trying to work out why it gives out-of-bounds errors now when it did not in the past. Link to comment
the bigg Posted April 28, 2006 Share Posted April 28, 2006 Because now it enforces the bounds check, while before it didn't Link to comment
Andyr Posted April 29, 2006 Share Posted April 29, 2006 I am not sure I understand what you are saying. - The code is giving an error with the new WeiDU. - The code is bad because it reads more columns than are present. So, it does not work properly. - The code did not used to give an error message. - The code also used to function correctly, and did not read out of bounds. - The code has not changed. - What I am asking, is why is the code now reading out-of-bounds when before it was not out of bounds and gave the desired results? Link to comment
Grim Squeaker Posted April 29, 2006 Share Posted April 29, 2006 I think it was just a fluke that it worked before because the final entry (the out-of-bounds one) was ignored by WeiDU because it didn't know what to do with it. Now it has bound checking, its throwing an error instead, which is correct behaviour but it does show up stealth bugs like this. Link to comment
the bigg Posted April 29, 2006 Share Posted April 29, 2006 What I am asking, is why is the code now reading out-of-bounds when before it was not out of bounds and gave the desired results? <{POST_SNAPBACK}> Before, the code would still have written out of bounds, without telling you about it. the OOB portions of the file would be written to a totally unrelated memory section, which means that the file would still have been correct (since its sectors didn't get any OOB writes); however, a time bomb would have set up in the system, so that, once the OOB section was read again, something bad would have happened - for example the segfaults that plague DR. Link to comment
Andyr Posted April 29, 2006 Share Posted April 29, 2006 Ah, right--so you're saying the new code is writing to the correct bits (explaining why it worked) and some additional bits it shouldn't (which is why it complains now)? Link to comment
Guest penguin Posted May 8, 2006 Share Posted May 8, 2006 hey, um, so I'm just wondering. As I am a non-coding-person, would anyone be able to send me the file that I need to replace or give me a step-by-step walkthrough of what I need to do to be able to install the druid remix? Thanks in advance. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.