Home » ADMIN OFFICES » BETA TEST - JA2STI Editor » STI File Problem/Challenge: Extend Explosion Animations
STI File Problem/Challenge: Extend Explosion Animations[message #336149] Thu, 25 September 2014 21:03 Go to next message
Tox

 
Messages:249
Registered:February 2000
Location: www.webcodesign.de
Hi folks,

after almost two days straight researching why adding / removing frames from the ZGRAV_C.STI animation breaks it, I'm still puzzled. I figured out that byte 49 of the STI header is used, even though the source code of the STCIHeader indicates it's not. I found a way to get that byte right, at least identical to all the files I know of that have a byte 49 other than 0. But still adding/removing frames doesn't work.

Has anyone ever figured out a way to extend ZGRAV_* anis? And if so, how? If not, go ahead and give it a shot! Wink


JA2STI Creator
Re: STI File Problem/Challenge: Extend Explosion Animations[message #336200] Fri, 26 September 2014 15:04 Go to previous messageGo to next message
Realist

 
Messages:27
Registered:September 2005
Location: Duesseldorf, Germany
I had a go at ZGRAV_C.sti, adding 1-2 frames and it seems I get the desired results by
1. updating the frame count byte in the first record of the appdata section
2. extending the appdata section with another record of 16 zero-bytes per additional frame
3. reflecting the changed size of the appdata section in the STCI header (this might be bytes 49-53).

Very minimal testing in Stracciatella suggested the modified animation works. I wouldn't be surprised if the game breaks elsewhere, though. Removing frames might be similar, but didn't test.
Re: STI File Problem/Challenge: Extend Explosion Animations[message #336201] Fri, 26 September 2014 15:06 Go to previous messageGo to next message
Tox

 
Messages:249
Registered:February 2000
Location: www.webcodesign.de
that sounds promising, can you send me your files?

flugente suggested that the appdata size is not written as the header description seems to indicate. I've updated my algorithm to incorporate that, but there's still something breaking everything. didn't test with stracciatella, though - used a customized version of 1.13 build 4870.

[Updated on: Fri, 26 September 2014 15:10] by Moderator


JA2STI Creator
Re: STI File Problem/Challenge: Extend Explosion Animations[message #336203] Fri, 26 September 2014 15:40 Go to previous messageGo to next message
Realist

 
Messages:27
Registered:September 2005
Location: Duesseldorf, Germany
Sent you the files (to the mail address from your profile page).

I don't know if I understand Flugente's concerns about this thing entirely. However, I agree that Sirtech's file formats are a mess all across the board, worst offenders to me personally are JSDs so far. :compsmash:
Re: STI File Problem/Challenge: Extend Explosion Animations[message #336213] Fri, 26 September 2014 19:30 Go to previous messageGo to next message
Tox

 
Messages:249
Registered:February 2000
Location: www.webcodesign.de
looks like I'll have to plan extra time if I wanna make a JSD editor Wink

JA2STI Creator
Re: STI File Problem/Challenge: Extend Explosion Animations[message #336714] Wed, 15 October 2014 23:49 Go to previous message
Tox

 
Messages:249
Registered:February 2000
Location: www.webcodesign.de
Realist
I had a go at ZGRAV_C.sti, adding 1-2 frames and it seems I get the desired results by
1. updating the frame count byte in the first record of the appdata section
2. extending the appdata section with another record of 16 zero-bytes per additional frame
3. reflecting the changed size of the appdata section in the STCI header (this might be bytes 49-53).



very interesting. it seems I overlooked the frame counter in the animation header. that plus increasing the appdata size - offset as suggested by flugente - seems to do the trick. haven't checked removing of frames or adding new frames to files with multiple animations, though.

JA2STI Creator
Next Topic: Feature Request List
Goto Forum:
  


Current Time: Tue Oct 23 23:42:46 EEST 2018

Total time taken to generate the page: 0.00961 seconds