Seeing... triple?

[BlademasterSlsh]

I've got an interesting little issue. I went to make a new unit for the SWTC and I thought I had it all ironed out. The image was a 256 BMP and they were all the same size, even saved with the same names as the vultures pictures (which I was using to test it). I compiled everything, but when I went to try it I found colors distorted (which I half expected) and not one, but three micro-sized images below the unit selection circle. They all moved in unison, and it could be a cool effect, but I just want one. Any ideas? The only thing I can think of that might be causing it is that the units are not the same up and down as they are left to right. They are 120x117. I know the vulture image by default is 100x100, so that might factor in somewhere too.

[Durandal]

If you used RetroGRP to compile them, then the BMP's aren't all in RLE compression, which is an annoying thing of Retro's.

That or you didn't take the palette into consideration when compiling them. Common problem.

[BlademasterSlsh]

If you used RetroGRP to compile them, then the BMP's aren't all in RLE compression, which is an annoying thing of Retro's.

That or you didn't take the palette into consideration when compiling them. Common problem.

The palate may be part of the problem, but I'm not worried about that. I'm worried about seeing three. (See screen)

[Durandal]

Well aside from the fact that the palette is fucked up, these are not compressed using RLE compression, and I already assume that you're using RetroGRP to compile them, even though you didn't clarify on that.

Is that the case?

If I had time on my hands, I'd just take the GRP and remedy it for you. Maybe tomorrow.

[BlademasterSlsh]

Yes, I am using RetroGRP. I am fairly positive I can fix the palette by pasting into one of the extracted BMP's (if I remember some past thread right), but I will probably need a way of fixing this in the future.

[Durandal]

You can't just paste the palette in, because it doesn't match the color values to their closest ones. All it does is override the existing values with the palette's own, giving you crazy colors. An easy fix is to take the graphic and paste it into an existing Starcraft graphic in Paint, which magically does map them to the closest values in the Palette.

But even then, this isn't the error, the RLE Compression is. Just use SFGRPConv. It will save you a lot of time and effort. You can get it here;

http://shadowflare.samods.org/dwnload.html#SFGrpConv

I noticed that SFGRPConv isn't in the modding and resource guides. What's the deal?

[BlademasterSlsh]

But even then, this isn't the error, the RLE Compression is. Just use SFGRPConv. It will save you a lot of time and effort. You can get it here;

http://shadowflare.samods.org/dwnload.html#SFGrpConv

I noticed that SFGRPConv isn't in the modding and resource guides. What's the deal?

All I know is that I have no idea where to get the palate from to use SFGRPConv, and as you said, it isn't in the guides. Can anyone offer some help?

[Durandal]

Well, you could have just extracted it from an image with the palette already implemented, but I'll save you the trouble.

http://www.mediafire.com/?jy3yb29y101

This is the one I use, should be okay for all Starcraft units and buildings.

[shaggydavid]

why not add the extra 3 pixels to the frame. i know numbers like 64, 80, 96, 100, 128,ect. work fine but numbers that are "odd" to the game tend to have undesired affects. i have run into this problem before years ago, and i haven't had an issue on any grp converter. i hope this will help and if it is for the swtc, i can resize the frames. i did it to a couple of other models for flametrooper.

[BlademasterSlsh]

I think I've managed to resize them alright now by using Word, but it is just the long process of copy and pasting them into paint, cleaning them up, and adding team colors now. Durandal's solution of using SFGRPConv worked great.

Question: Is there a way to add extra frames into a movement cycle without tinkering with ICE/ICECC? Like if I were to maintain the same numbering scheme as the extracted BMPs and added the extra frames, would SFGRPConv know how to handle them? (I'm assuming the answer is "no", but I want to double check before I make more work for myself).

[Edit] Almost forgot. Yes, david, this is for the SWTC

[Durandal]

Is there a way to add extra frames into a movement cycle without tinkering with ICE/ICECC? Like if I were to maintain the same numbering scheme as the extracted BMPs and added the extra frames, would SFGRPConv know how to handle them? (I'm assuming the answer is "no", but I want to double check before I make more work for myself).

I'm not sure what you mean. If you add in extra frames, SFGRPConv will add them in and you'll just have more frames. Whether the Iscript utilizes them is in the Iscript. If you're inserting frames into the middle of the walking graphic, then yeah it'll utilize them, but it will also push up the other frames and likely cause the last part of the movement animation to spill into a different part of the iscript, like the attack animation.

Ice isn't a difficult program to understand, it wouldn't hurt to tinker with it.

[Twitch6000]

I think I've managed to resize them alright now by using Word, but it is just the long process of copy and pasting them into paint, cleaning them up, and adding team colors now. Durandal's solution of using SFGRPConv worked great.

Question: Is there a way to add extra frames into a movement cycle without tinkering with ICE/ICECC? Like if I were to maintain the same numbering scheme as the extracted BMPs and added the extra frames, would SFGRPConv know how to handle them? (I'm assuming the answer is "no", but I want to double check before I make more work for myself).

[Edit] Almost forgot. Yes, david, this is for the SWTC

No to add more frames then the unit already has you need to make that frame and add the frame in icecc.ICECC is the only program I dislike in modding due to all the things you have to do in it =[.