Pimpstick Posted September 17, 2013 Share Posted September 17, 2013 [spoiler=Script (Note:There are no sound commands because I have yet to add them)]/// - Mode 1C03 -C07 -3 p- standing.png9 p- Attacking1.png2 p- Attacking2.png2 p- Attacking2.png2 p- Attacking3.png3 p- Attacking4.png5 p- Attacking5.pngC04C1AC1F3 p- Attacking6.png3 p- Attacking7.pngC015 p- Attacking8.png5 p- Attacking9.png3 p- standing.pngC06C0D~~~ -/// - Mode 3C03 -C07 -3 p- standing.png9 p- Crit1.png3 p- Crit2.png7 p- Crit3.png9 p- Attacking1.png2 p- Attacking2.png2 p- Attacking2.png3 p- Attacking3.png3 p- Attacking4.png5 p- Attacking5.pngC04C08C1F3 p- Attacking6.png3 p- Attacking7.pngC015 p- Attacking8.png5 p- Attacking9.png3 p- standing.pngC06C0D~~~ - Mode 5C03 -C07 -8 p- Attacking1.pngC058 p- Attacking1.pngC01C063 p- standing.pngC0D~~~ - Mode 6C03 -C07 -9 p- Crit1.png3 p- Crit2.png6 p- Crit3.png8 p- Attacking1.pngC058 p- Attacking1.pngC01C063 p- standing.pngC0D~~~ - Mode 7C024 p-Dodge1.pngC0E4 p-Dodge2.pngC01C06C0D~~~ - Mode 8C024 p-Dodge1.pngC0E4 p-Dodge2.pngC01C06C0D~~~ - Mode 93 p- standing.pngC01 -~~~ - Mode 103 p- standing.pngC01 -~~~ - Mode 113 p- standing.pngC01 -~~~ - Mode 12C03 -C07 -3 p- standing.pngC04C1FC013 p- standing.pngC06C0D~~~ - End Animation Data Okay. I was getting ready to insert a pirate edit after testing the standing frame on Blazer's sample script in the Ultimate tut.It went in with no fuss so I prepared the other frames, though when I fed my full script to the creator it gave me thisYeah, real helpful FEditor . It said the last path was "Attacking1.png" which is this frame here.I check the colours, making sure there were 16 along with fixing alignment a little with Usenti, saved it and tried again and got the same error. I try it on the school computer, re-download FEditor and tried re-saving the frame, but I got the same issue. In a slight haze, I decided to use the sample script again, only this time use the attacking frame and to my surprise, it went in without fuss. Giddy with joy, I fire up FEditor and try again only to have the same issue pop up. So I came up with another silly idea, take out the standing frame and see what happens. Somehow the first attacking frame went in, but not the second; "Attacking2.png" Intrigued, I took the full script and replaced mode 1 with copies of the sixth attack frame "Attacking6.png" and start Mode 3 with the stand frame [spoiler=Partial Example]/// - Mode 1C03 -C07 -3 p- Attacking6.png3 p- Attacking6.png3 p- Attacking6.png3 p- Attacking6.png3 p- Attacking6.png3 p- Attacking6.png3 p- Attacking6.pngC04C1AC1F3 p- Attacking6.png3 p- Attacking6.pngC013 p- Attacking6.png3 p- Attacking6.png3 p- Attacking6.pngC06C0D~~~ -/// - Mode 3C03 -C07 -3 p- standing.png9 p- Crit1.png3 p- Crit2.png Somehow mode 1 went through just fine, but at mode 3 it chokes on the standing frame. At this point, I'm confused so I use the debug script in the doc since my frames have the same name as the ones used. It works on the frames in the doc, but it still chokes on two different frames of mine. It feels like I can give the thing twenty copies of the same frame and it wouldn't care, but I give it two different frames and then it gives up on me. At this point, it feels like I have run out of ideas and patience so now I ask for help. Is it small formatting error I missed with the frames, did I miss a certain command on the script or is it something else? Any help would appreciated. Quote Link to comment Share on other sites More sharing options...
CT075 Posted September 17, 2013 Share Posted September 17, 2013 A- why are there random dashes in front of the commands B- check that a ll your frames use the same set of 16 colors Quote Link to comment Share on other sites More sharing options...
Aleph Posted September 19, 2013 Share Posted September 19, 2013 (edited) It sounds like Cam guessed the issue correctly but I find it hard to believe that even a me that young would not provide an error message that actually says so. Fortunately FEditor is a crappy Java app so you can just load it in NetBeans, set a breakpoint in the load function and step through it. Edited September 19, 2013 by Solais Quote Link to comment Share on other sites More sharing options...
Blue Druid Posted October 28, 2013 Share Posted October 28, 2013 (edited) I had this problem too. Check if the attack frames have 16 colours and if they already do, they have to be the same colours as the ones in the standing frame. If you can't see a difference in the colours by just looking at them, the check on Usenti if all the R G B numbers of the colours match exactly. E.g. a colour in your standing frame might be R 31 G 31 B 31 whereas what you think is the same colour in Attacking1 might be R 31 G 31 B 30 Edited January 12, 2014 by Blue Druid Quote Link to comment Share on other sites More sharing options...
Aleph Posted October 30, 2013 Share Posted October 30, 2013 (edited) A better way to do it is to make a series of palette pixels in the area FEditor expects. This input is unnecessary if the rest of it is valid as FEditor can deduce the palette on its own. However, if there is an issue with the data then you can use a program like Usenti to do a colour count. If the palette pixels are in the palette area of each image then Usenti will identify any frames that are over 16 colours much more simply than manually checking RGB values. Then you can identify problem frames and correct them all at once using a find/replace on colours or something (reduce to 16 in usenti before doing the replace to be sure...maybe. There's a smart way to do it, whatever it is). Personally, I use the top right 8x8 tile for placing the palette pixels. This is because images are decoded from top right to bottom left. Tiles are probably decoded in the same order, so it'd start at the top right 8x8 pixel tile, and then grab the first 8 pixels from the top row of the tile from right to left and the next 8 pixels from the row below that, and so on. FEditor uses each pixel it encounters to deduce palettes. Each time it encounters a new colour it adds it to the next free slot in the palette. If it meets a 17th new colour, it throws an exception. I don't believe there's any logic to check if palettes have been reordered, so the only way to be sure they're deduced correctly is to place the palette pixels in the top right of each frame in the same order and be sure they're the first pixels that are decoded by using the location that I use. If you look at the top right of each debug animation frame you'll notice I did this. The "palette area" is the 8 pixel wide column at the far right of any image loaded into FEditor, be it batte animation frames or portraits. This isn't actually mentioned in the place it should be if it's in the doc at all. The Gameboy Advance uses 4BPP images most of the time. This is the only format I have written a container for as of yet, but if I write any more container formats in the future, they will likely follow these principles, just as the 4BPP container does. The container format is only for converting between the target format and the standard bitmap format. All other common formats, such as PNG, are converted to a bitmap prior to being used as input. Because of this, only the expected resulting bitmap you would get from converting an image your choice to the bitmap format needs to meet these criteria: https://dl.dropboxusercontent.com/u/336940/Software/Hextator's%20Doc/Media/Games/Reverse%20Engineering/Console/NGBA/Fire%20Emblem/Apps/FEditor%20Adv/doc/Writing%20Error%20Examples.txt I used the palette specification system the GBA image class decodes to force the colors of the stripes in the example to be colors 0 and 15 of the resulting decoded palette. Had I not, the mouth frame area, which is the only area of the portrait not compressed and therefore the only vulnerable part of the portrait, would have been decoded first, because the decoding algorithm reads from left to right, bottom to top, in the order specified by the standard bitmap specification. Because of this, the colors in those stripes, assuming I had not manually specified the palette order, would have been assigned different color indices and thus the problem could not have occurred. [...] This entails not using manual palette specifications that specify the color of a stripe that is between stripes of the background color in a portrait to be the 15th color and then placing those stripes over mouth frames, or for other FEs, anything that isn't compressed when inserted (example: mugs in FE 8). Oops. Edit: I just noticed you were doing that anyway (unless those linked images have been updated). Whatever Edited October 30, 2013 by Insidious Silence Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.