Reply to Re: A tal of woe and dispair: init("")
If you don't have an account, just leave the password field blank.
: Ah, the oh-so-useful init line... allowing you to have many, many graphics in any D-Mod imaginable... here follows a tale of woe and dispair so great, that it must be shared over generations to come so as the same untimely fate does not happen to anyone else.
: FIAT v1.00 always had one tiny problem: the Dragons. For some reason, they wouldn't move right... they'd just stick on the same first frame of animation, and move awkwardly about.
: Now, this didn't make much sense... all of the sequences loaded correctly, and so on. In fact, the original Dragon graphics worked fine... just the new ones that went over top of the old ones (thanks to the init line) screwed up.
: Here is one of those init lines, it is correct:
: init("load_sequence graphicselemonstearthdragf2-w8- 908 75 105 100 -43 -18 43 18");
: So what could be the cause? I couldn't figure it out... I thought that it might be the the sequences 90x themselves, having some sort of weird flaw... but nope. I thought perhaps it was the actual bmps themselves that were the problem... nope. I thought of a million things, and none of them solved the problem of the lazy dragon.
: And then, I decided to make an example D-Mod to show the world my dilemma, and to see if they could help.
: The dragons moved in the example D-Mod.
: As you can imagine, this was quite frustrating
I went over everything... and I noticed that in my example D-Mod I hadn't but the dragon graphics in the same folder as before. So I decided to do that.
: Then the dragon turned lazy again.
: So now it was the folder problem... but why? All of the other graphics I loaded over old ones were fine...
: Then I looked at the other lines, and noticed they were all shorter than the dragon lines, by at least one byte.
: So I shortened the folder name by two bytes, tried it, and tada, it worked.
: So what exactly was the problem?
: Seth allocates exactly 79 bytes for the init("") string. My dragon graphics went up to 80, and caused some very weird bug. It didn't ignore the 80th byte (which just controlled the hard box), it just screwed something up thanks to it.
: Interesting to note, the dink.ini doesn't have a 79 byte limit, and has one most likely a bit higher.
: So, there you go: only use 79 bytes in an init("") string!
Thanx for the heads up!
: FIAT v1.00 always had one tiny problem: the Dragons. For some reason, they wouldn't move right... they'd just stick on the same first frame of animation, and move awkwardly about.
: Now, this didn't make much sense... all of the sequences loaded correctly, and so on. In fact, the original Dragon graphics worked fine... just the new ones that went over top of the old ones (thanks to the init line) screwed up.
: Here is one of those init lines, it is correct:
: init("load_sequence graphicselemonstearthdragf2-w8- 908 75 105 100 -43 -18 43 18");
: So what could be the cause? I couldn't figure it out... I thought that it might be the the sequences 90x themselves, having some sort of weird flaw... but nope. I thought perhaps it was the actual bmps themselves that were the problem... nope. I thought of a million things, and none of them solved the problem of the lazy dragon.
: And then, I decided to make an example D-Mod to show the world my dilemma, and to see if they could help.
: The dragons moved in the example D-Mod.
: As you can imagine, this was quite frustrating
I went over everything... and I noticed that in my example D-Mod I hadn't but the dragon graphics in the same folder as before. So I decided to do that.: Then the dragon turned lazy again.
: So now it was the folder problem... but why? All of the other graphics I loaded over old ones were fine...
: Then I looked at the other lines, and noticed they were all shorter than the dragon lines, by at least one byte.
: So I shortened the folder name by two bytes, tried it, and tada, it worked.
: So what exactly was the problem?
: Seth allocates exactly 79 bytes for the init("") string. My dragon graphics went up to 80, and caused some very weird bug. It didn't ignore the 80th byte (which just controlled the hard box), it just screwed something up thanks to it.
: Interesting to note, the dink.ini doesn't have a 79 byte limit, and has one most likely a bit higher.
: So, there you go: only use 79 bytes in an init("") string!
Thanx for the heads up!
