📧 Message Board Archive

Graphics init problem... you there Paul?
I'm trying to load new graphics for walking and idling for dink. And I figured it was just a case of changing the lines:

     init("load_sequence_now graphics\dink\walk\ds-w1- 71 43 38 72 -14 -9 14 9");

     init("load_sequence_now graphics\dink\walk\ds-w2- 72 43 37 69 -13 -9 13 9");

     init("load_sequence_now graphics\dink\walk\ds-w3- 73 43 38 72 -14 -9 14 9");

     init("load_sequence_now graphics\dink\walk\ds-w4- 74 43 38 72 -12 -9 12 9");



     init("load_sequence_now graphics\dink\walk\ds-w6- 76 43 38 72 -13 -9 13 9");

     init("load_sequence_now graphics\dink\walk\ds-w7- 77 43 38 72 -12 -10 12 10");

     init("load_sequence_now graphics\dink\walk\ds-w8- 78 43 37 69 -13 -9 13 9");

     init("load_sequence_now graphics\dink\walk\ds-w9- 79 43 38 72 -14 -9 14 9");



     init("load_sequence_now graphics\dink\idle\ds-i2- 12 250 33 70 -12 -9 12 9");

     init("load_sequence_now graphics\dink\idle\ds-i4- 14 250 30 71 -11 -9 11 9");

     init("load_sequence_now graphics\dink\idle\ds-i6- 16 250 36 70 -11 -9 11 9");

     init("load_sequence_now graphics\dink\idle\ds-i8- 18 250 32 68 -12 -9 12 9");



with a new directory and then run the above in the holdingdrop procedure as per the sword scripts, but man does some weird stuff happen. Dink starts spinning on the spot, sometimes changing to a staircase. Other graphics get changed to Dink.



I ran into a similar problem on SOB with using the init line. Just wondering if anyone has hit this kinda problem before or not.



At the moment my only work around seems to be using the actual sp_base_walk(1, [seq no]) command instead of load_graphics_now. Kinda boring because it means using up graphic slots.
Re: Graphics init problem... you there Paul?
: I'm trying to load new graphics for walking and idling for dink. And I figured it was just a case of changing the lines:

:   init("load_sequence_now graphics\dink\walk\ds-w1- 71 43 38 72 -14 -9 14 9");

:   init("load_sequence_now graphics\dink\walk\ds-w2- 72 43 37 69 -13 -9 13 9");

:   init("load_sequence_now graphics\dink\walk\ds-w3- 73 43 38 72 -14 -9 14 9");

:   init("load_sequence_now graphics\dink\walk\ds-w4- 74 43 38 72 -12 -9 12 9");

:   init("load_sequence_now graphics\dink\walk\ds-w6- 76 43 38 72 -13 -9 13 9");

:   init("load_sequence_now graphics\dink\walk\ds-w7- 77 43 38 72 -12 -10 12 10");

:   init("load_sequence_now graphics\dink\walk\ds-w8- 78 43 37 69 -13 -9 13 9");

:   init("load_sequence_now graphics\dink\walk\ds-w9- 79 43 38 72 -14 -9 14 9");

:   init("load_sequence_now graphics\dink\idle\ds-i2- 12 250 33 70 -12 -9 12 9");

:   init("load_sequence_now graphics\dink\idle\ds-i4- 14 250 30 71 -11 -9 11 9");

:   init("load_sequence_now graphics\dink\idle\ds-i6- 16 250 36 70 -11 -9 11 9");

:   init("load_sequence_now graphics\dink\idle\ds-i8- 18 250 32 68 -12 -9 12 9");

: with a new directory and then run the above in the holdingdrop procedure as per the sword scripts, but man does some weird stuff happen. Dink starts spinning on the spot, sometimes changing to a staircase. Other graphics get changed to Dink.

: I ran into a similar problem on SOB with using the init line. Just wondering if anyone has hit this kinda problem before or not.

: At the moment my only work around seems to be using the actual sp_base_walk(1, [seq no]) command instead of load_graphics_now. Kinda boring because it means using up graphic slots.



Do your sequences have the same number of frames than those replaced?

If not then you could have such problem...

BTW, it's the cause of Dink's hit glitch in EOT.

Re: Graphics init problem... you there Paul?
: Do your sequences have the same number of frames than those replaced?

: If not then you could have such problem...

: BTW, it's the cause of Dink's hit glitch in EOT.



Actually, it doesn't have to be the same number of frames.  It just has to be less then the number of when it was first initialized...



Which is why I can't figure out the EOT2 problem.  I know it seems like its a number-of-frames issue, but look at the dink.ini.  Stolen right out've Dink.  And the only other sequence used for Dink is the Slayer Claw punching one, and thats just a slightly modified punch script.  It should work fine... but it doesn't.
Re: Graphics init problem... you there Paul?
: : Do your sequences have the same number of frames than those replaced?

: : If not then you could have such problem...

: : BTW, it's the cause of Dink's hit glitch in EOT.

: Actually, it doesn't have to be the same number of frames. It just has to be less then the number of when it was first initialized...

: Which is why I can't figure out the EOT2 problem. I know it seems like its a number-of-frames issue, but look at the dink.ini. Stolen right out've Dink. And the only other sequence used for Dink is the Slayer Claw punching one, and thats just a slightly modified punch script. It should work fine... but it doesn't.



I have added 1 frame to the slayer claw hit sequence (just copied the last ones to make equal number) and it works fine for me.

BTW, in the dink.ini file sequences mentioned have equal number of frames. Comment is wrong.

Re: Graphics init problem... you there Paul?
: : : Do your sequences have the same number of frames than those replaced?

: : : If not then you could have such problem...

: : : BTW, it's the cause of Dink's hit glitch in EOT.

: : Actually, it doesn't have to be the same number of frames. It just has to be less then the number of when it was first initialized...

: : Which is why I can't figure out the EOT2 problem. I know it seems like its a number-of-frames issue, but look at the dink.ini. Stolen right out've Dink. And the only other sequence used for Dink is the Slayer Claw punching one, and thats just a slightly modified punch script. It should work fine... but it doesn't.

: I have added 1 frame to the slayer claw hit sequence (just copied the last ones to make equal number) and it works fine for me.

: BTW, in the dink.ini file sequences mentioned have equal number of frames. Comment is wrong.



Comment is right.  The regular punch sequence is 5 frames... sword swing is 6.  :P



And I've done it to a greater extent in FIAT.  In the dink.ini, I've loaded 50 frame 'blank' sequences (for the boss and other things I didn't want people to see in the map editor), and loading sequences over them with much less frames in main.c or start.c
Re: Graphics init problem... you there Paul?
: : : : Do your sequences have the same number of frames than those replaced?

: : : : If not then you could have such problem...

: : : : BTW, it's the cause of Dink's hit glitch in EOT.

: : : Actually, it doesn't have to be the same number of frames. It just has to be less then the number of when it was first initialized...

: : : Which is why I can't figure out the EOT2 problem. I know it seems like its a number-of-frames issue, but look at the dink.ini. Stolen right out've Dink. And the only other sequence used for Dink is the Slayer Claw punching one, and thats just a slightly modified punch script. It should work fine... but it doesn't.

: : I have added 1 frame to the slayer claw hit sequence (just copied the last ones to make equal number) and it works fine for me.

: : BTW, in the dink.ini file sequences mentioned have equal number of frames. Comment is wrong.

: Comment is right. The regular punch sequence is 5 frames... sword swing is 6. :P

: And I've done it to a greater extent in FIAT. In the dink.ini, I've loaded 50 frame 'blank' sequences (for the boss and other things I didn't want people to see in the map editor), and loading sequences over them with much less frames in main.c or start.c



Well, maybe I'm wrong, but the sword swing works OK if I make slayclaw 6 frames. No wells or hearts in the end of sequence.

Re: Graphics init problem... you there Paul?
: : Do your sequences have the same number of frames than those replaced?

: : If not then you could have such problem...

: : BTW, it's the cause of Dink's hit glitch in EOT.

: Actually, it doesn't have to be the same number of frames. It just has to be less then the number of when it was first initialized...

: Which is why I can't figure out the EOT2 problem. I know it seems like its a number-of-frames issue, but look at the dink.ini. Stolen right out've Dink. And the only other sequence used for Dink is the Slayer Claw punching one, and thats just a slightly modified punch script. It should work fine... but it doesn't.



I have added 1 frame to the slayer claw hit sequence (just copied the last ones to make equal number) and it works fine for me.

BTW, in the dink.ini file sequences mentioned have equal number of frames. Comment is wrong.

Bingo you were right
Yes, this was bugging me all day and I decided to make the number of graphics equal 8 for walking and it seems to have stablised itself. I'd actually increased the idle to 8 but I'm guessing that since the dink.ini file takes 4 graphics and replicates them for this sequence, thus bringing it up to 8 it should be fine.



Whoo-ho, Dink now has a new walk.
Re: Graphics init problem... you there Paul?
: I'm trying to load new graphics for walking and idling for dink. And I figured it was just a case of changing the lines:

:   init("load_sequence_now graphics\dink\walk\ds-w1- 71 43 38 72 -14 -9 14 9");

:   init("load_sequence_now graphics\dink\walk\ds-w2- 72 43 37 69 -13 -9 13 9");

:   init("load_sequence_now graphics\dink\walk\ds-w3- 73 43 38 72 -14 -9 14 9");

:   init("load_sequence_now graphics\dink\walk\ds-w4- 74 43 38 72 -12 -9 12 9");

:   init("load_sequence_now graphics\dink\walk\ds-w6- 76 43 38 72 -13 -9 13 9");

:   init("load_sequence_now graphics\dink\walk\ds-w7- 77 43 38 72 -12 -10 12 10");

:   init("load_sequence_now graphics\dink\walk\ds-w8- 78 43 37 69 -13 -9 13 9");

:   init("load_sequence_now graphics\dink\walk\ds-w9- 79 43 38 72 -14 -9 14 9");

:   init("load_sequence_now graphics\dink\idle\ds-i2- 12 250 33 70 -12 -9 12 9");

:   init("load_sequence_now graphics\dink\idle\ds-i4- 14 250 30 71 -11 -9 11 9");

:   init("load_sequence_now graphics\dink\idle\ds-i6- 16 250 36 70 -11 -9 11 9");

:   init("load_sequence_now graphics\dink\idle\ds-i8- 18 250 32 68 -12 -9 12 9");

: with a new directory and then run the above in the holdingdrop procedure as per the sword scripts, but man does some weird stuff happen. Dink starts spinning on the spot, sometimes changing to a staircase. Other graphics get changed to Dink.

: I ran into a similar problem on SOB with using the init line. Just wondering if anyone has hit this kinda problem before or not.

: At the moment my only work around seems to be using the actual sp_base_walk(1, [seq no]) command instead of load_graphics_now. Kinda boring because it means using up graphic slots.



It looks like EOT problem. After replacing hit sequence the graphics were messed