Reply to Re: WDE 2 crash
If you don't have an account, just leave the password field blank.
Closest I did to getting rid of it was temporarily removing the "Please Wait" flashing banner for a while, due to it sometimes causing a crash, but it's back now I think.
I did some more little tests. This one created a collapsible box without using preload_seq beforehand or a wait before running draw_hard_sprite and ended up having an improper hardbox each and every time it first ran, while still generating a square I couldn't walk into. In the duck test, the duck graphics were already cached because of the map sprite duck, and always worked as expected.
After creating a second collapsible box and running draw_hard_sprite on it, the first box with the improper hardbox had its proper box applied, while still leaving behind the original bogus hardbox. The second box and all those following also received proper hardboxes. Only running draw_hard_map to recalculate the entire screen's hardmap got rid of the first box's improper box, while keeping the proper one.
With a wait (I used 100ms) or preload_seq before running draw_hard_sprite, the first box received its proper dink.ini-specified hardbox box every time. In all cases, it generated some sort of square on the hardmap I couldn't walk into, even if it was not the one specified in dink.ini.
I did some more little tests. This one created a collapsible box without using preload_seq beforehand or a wait before running draw_hard_sprite and ended up having an improper hardbox each and every time it first ran, while still generating a square I couldn't walk into. In the duck test, the duck graphics were already cached because of the map sprite duck, and always worked as expected.
After creating a second collapsible box and running draw_hard_sprite on it, the first box with the improper hardbox had its proper box applied, while still leaving behind the original bogus hardbox. The second box and all those following also received proper hardboxes. Only running draw_hard_map to recalculate the entire screen's hardmap got rid of the first box's improper box, while keeping the proper one.
With a wait (I used 100ms) or preload_seq before running draw_hard_sprite, the first box received its proper dink.ini-specified hardbox box every time. In all cases, it generated some sort of square on the hardmap I couldn't walk into, even if it was not the one specified in dink.ini.
