GoFSH slice n' dice ignores some tiles

[TheMurderousCricket 5,107]

Hi Everyone,

I am trying to run a 1280x1280 texture through the GoFSH to obtain some image "slices".

However, the slice n' dice option, stubbornly ignores five slices that do contain image, claiming that they were ignored because they are "empty"...

What seem to be the problem here? Or is the source image simply too big for GoFSH and it can't handle a 10x10 mosaic...? That would be strange because when I added a white "control grid" all 100 tiles could suddenly be processed no problem. 

[TheMurderousCricket 5,107]

Slice n' dice is unable to handle even this simple image! Two tiles out of four are left out... What is happening here...?

[CorinaMarie 29,894]

2 hours ago, TheMurderousCricket said:

Slice n' dice is unable to handle even this simple image! 

I've re-quoted and the following no longer applies.

Ofc, we did relax the rule for language and I do see how you are using this for emphasis. However, I prolly would not in this case since you are referring to someone's creation which they spent thousands of hours programming.

Perhaps a polite bug report in their dedicated thread would be better.

  Edited April 1, 2025 by CorinaMarie  
Original quote edited by the OP.

[TheMurderousCricket 5,107]

Maybe you are right... *sigh*

I'll come back when I cool down. I am simply frustrated. It worked the first time I used it and now I keep trying for dozens of times with no effect at all!

I will now rephrase the post.

[CorinaMarie 29,894]

4 minutes ago, TheMurderousCricket said:

I will now rephrase the post.

Thanks. I altered mine accordingly.

[rivit 3,402]

5 hours ago, TheMurderousCricket said:

Slice n' dice is unable to handle even this simple image! Two tiles out of four are left out... What is happening here...?

GoFSH indeed had a problem with correctly determining if a tile was empty - you found a bug. This was introduced over a year ago when I put in checking for empty tiles. Instead of checking the whole tile it was in fact only checking the left third (43 of 128 pixels) to see if they were zero and if so then rejecting the tile as empty. Hence the left tiles were rejected and the right ones were OK.

This was due to a counting error in my programming. My apologies. There is a dedicated thread here in the forums for reporting issues and bugs and asking questions.

When you have returned your seat to the upright position, you will find a new version of GoFSH 4.8.11 here on my one drive.

 

[TheMurderousCricket 5,107]

Hello @rivit. Thank you for investigating this issue, I really appreciate it. I was really upset with this going wrong all the time in a program that is otherwise very simple to use. At one point I even thought that my image processing routine in GIMP does something peculiar to the files, making them unreadable for GoFSH! 

I would once again like to apologize to all who stumbled across and read my previous, irate post.  I'm sorry for Donald Ducking this way yesterday...

[rivit 3,402]

No probs. No program is perfect and getting bug reports is the only way for me to close holes. I'd rather hear about it than have the program wither on the vine. Meanwhile I hope you can resume your projects and now make progress. Cheers

[TheMurderousCricket 5,107]

10 hours ago, rivit said:

Meanwhile I hope you can resume your projects and now make progress.

Yes, it works like a charm now. Some tiles did not turn up in LE, but it's probably due to IID conflict.  I must have used ABCD0004 entry before...

By the way, why does GoFSH insist that the IID should end in either 4, 9 or D...? I didn't notice anything wrong if a different ending is entered.

Speaking of the textures, is @Tarkus still the correct address to ask for a texture range...?  Judging by the first few trials, I need around 3900 texture slots (color + opacity x 'set of fives') if my calculations are correct.

[CorinaMarie 29,894]

3 hours ago, TheMurderousCricket said:

Speaking of the textures, is @Tarkus still the correct address to ask for a texture range...?

I believe I saw in another thread a few months back that @rsc204 has that honor.

[rsc204 21,866]

Nope, Prop Families is my domain, Tarkus to my knowledge is still handling textures.

[rivit 3,402]

13 hours ago, TheMurderousCricket said:

By the way, why does GoFSH insist that the IID should end in either 4, 9 or D...? I didn't notice anything wrong if a different ending is entered.

because textures are made with mips (smaller versions for further away) in SC4 the  textures sets are   ...0-4,  ...5-9,  ...A-E.   Individual textures without mips (like effects and masks) can be anything. In the Slice'n'Dice we are always making mips.

In GoFSH in general I've taken the upper end as the ID for simplicity, because the smaller textures are generated by scaling the largest down.  Inside SC4 itself textures and tiles are usually defined by their smallest ID.

If you use other ID endings then what can happen is that sets of 5 can overlap and you'll end up with weird textures or none at all depending on which get put in a set.    

[TheMurderousCricket 5,107]

@rivit, sorry to bother you again, but I can't even load the texture into slice n' dice now.  The moment I pick a folder, I get this nasty exception...

error_rep.txt

These exceptions actually started to be more frequent now than they were in the previous version. I didn't write in the support thread because I can see that the version on STEX is 4.8.6 and I don't want to confuse others.

[rivit 3,402]

I think this indicates that an image has failed to load in some sort of odd way - normally these get trapped and a dialog comes up say x went wrong continue or finish? Could you attach the image to a private message to me please. I'll see if I can trigger it here.

Are you running on a 32 or 64bit OS?  Can you load any image at all after exiting and then starting the program again? 

[TheMurderousCricket 5,107]

I run 64-bit OS. I can't even load any image, because GoFSH crashes after choosing a directory. That is, right after I click the "Pick" button.

I don't know what happened. Yesterday it worked! 

[TheMurderousCricket 5,107]

Strange... You know what? I kept clicking about mindlessly and switched to "Transit texture". The folder could then be picked and images could be chosen.

Then I returned to "Lot/Terrain texture" option and it too, mysteriously, started to work normally... 

*

I also noticed that in one case, Slice n' Dice seems to confuse the naming order for the slices, resulting in the creation of one incorrect pair. But! What is also interesting is that right before it, there is a colored tile which is technically empty. It seems that this is where the problem sits.

The names can of course be corrected so that a .fsh archive can be successfully created but it is an additional work nonetheless.

 

[rivit 3,402]

OK - Im going to have to go a quite a bit deeper to find this - so give me a bit of time. Something nags me that you're maybe using the program in way I havent considered so I need to experiment a bit. Thanks for the pic though - thats enough for me to make a similar texture to check with. I take it untitled and untitled_op are the separated source color and alpha. 

~~~ a couple of hours later

Here's what I think is going on - you're processing the Color and Saving, and then the Alphas and Saving as D0 in separate passes. In the color pic the bottom left corner is white which is not empty - empty is black.  When you look at the alpha pic this is black so empty.

So in pass 1 you get 15 tiles, but in pass two you only get 14 and its at the bottomleft 4E where things go awry, because now the C0 and D0 do not match.  You can see this in my reconstructed version above. Your conclusion about that tile  was correct.

You've a couple of ways to solve this:  

1) if doing separate passes then make sure irrelevant parts (tiles) in the color map are black and match the alpha. you'll get 14 matching pairs.

2) load a 32bit bitmap, where the alpha is part of the image.  When processed you get 32bit C0s and no D0s and GoFSH will make these into FSH with Alpha. (e.g. overlays for lot textures).  In the case above you would have got 15 textures, with correct alphas. One 4E would be all white with a black alpha - a dead tile.

Now there are traps when using PNGs instead of BMPs as source files. For normal textures without alpha all OK, but if you need alpha then the way Microsoft treats PNGs will lead to problems as alphas are not correctly preserved - so lesson here dont use PNGs if you want correct alphas in MS Windows.

I think thats the slicing problem - the program is doing what its designed to do.  In general, make sure irrelevant parts (tiles) in the color and alpha map are black  

~~~

I have no idea yet as to what the loading problem is or could be. I need more data to work with.

 

  Edited April 5, 2025 by rivit  
added response

[TheMurderousCricket 5,107]

8 hours ago, rivit said:

Here's what I think is going on - you're processing the Color and Saving, and then the Alphas and Saving as D0 in separate passes. In the color pic the bottom left corner is white which is not empty - empty is black.  When you look at the alpha pic this is black so empty.

You are absolutely right. I noticed this yesterday night and wanted to write back first thing in the morning. Thank you for going through the trouble of checking this in spite of my own misrepresentation of data. Hope you are not mad at me. 

What's the deal with this strange exception though? Do you have any ideas? Slice n' dice works fine again. It's really strange.

Moving on, I think I really suck at using your tool... 

I can successfully cut up big texture into smaller pieces and then make a fsh .dat out of them. In the slice n' dice I use the initial IID of ABEE0004 to, like you say, use 4, 9 or E as the last number to designate a texture set. However, I must be doing something wrong, because about one-third of the textures I make never show up... What is more, they also don't even have the endings in the range you mentioned, despite the initial IID. As you can see, 0, 5, A are the values that constantly repeat (at least in the textures which do appear) and most of the other material is just missing... Any tips or instructions on where do I make the mistake?

[rivit 3,402]

No thats not wrong, you havent made a mistake, youre just learning how SC4 works - as I wrote a couple of posts back the Tilesets are numbered 0..4, 5..9, and A..E.

GoFSH uses the upper number, SC4 uses the lower number. So LE will always show the lower number (and you can tell from the shape its right) and in-game it will display the appropriate tile as the right zoom. If they were dodgy LE couldnt display them.

Im not sure why they would disappear after making them but two things could be the case:

1) you didnt make overlays but base textures (so when alpha=white). It kind of depends what you're aiming to do - base textures are shown in a different requester in LE.   To guarantee overlays you must have some part of the tile with alpha black  alpha not white (r,g or b<> 255), 1 pixel is enough. 

2) you have an IID conflict and the conflict loads after your textures so LE only shows them. I dont think this is likely.

Zoom goes from 0 to 5,  or 1 to 6 depending on how you count,  the 0 to 4 are the tiles you make and the highest zoom (5) is upscaled by SC4 to the show in the closest zoom. 

As for the file thing - I've no idea really, but when in doubt pick new so that a windows file requester is shown to pick the file. This bypasses any GoFSH logic.

  Edited April 5, 2025 by rivit  
clarification

[TheMurderousCricket 5,107]

5 minutes ago, rivit said:

Zoom goes from 0 to 5,  or 1 to 6 depending on how you count,  the 0 to 4 are the tiles you make and the highest zoom (5) is upscaled by SC4 to the show in the closest zoom. 

This is important to me from the calculation point of view...

If I wish to create 100 distinct textures... do I then request for 100 IID slots, or 500 (5 zooms x 100 base tiles) IID slots...?

7 minutes ago, rivit said:

As for the file thing - I've no idea really, but when in doubt pick new so that a windows file requester is shown to pick the file.

I don't understand.  Could you rephrase?

[rivit 3,402]

Just now, TheMurderousCricket said:

100 IID slots, or 500 (5 zooms x 100 base tiles) IID slots...?

you'll always make sets of 5 so you need 5x the number of tiles you're making. Generally you'll end up with more slots than you can use when requesting a range.

File requester - GoFSH will show the last used folders - and has new and pick as buttons at the bottom of the requester. Select NEW and then a windows file requester will be shown.

[TheMurderousCricket 5,107]

7 minutes ago, rivit said:

File requester - GoFSH will show the last used folders - and has new and pick as buttons at the bottom of the requester. Select NEW and then a windows file requester will be shown.

Oh, ok, you mean that exception. Well, I guess it's ok for now. Hopefully just a random free radical.

What do you think the cause for missing textures is, though?  I might send you the image I am trying to process but it's under an NDA, you know. 

[rivit 3,402]

I explained that above - check base textures in LE as well as Overlays. I think the 1/3 are those with white alpha (interior tiles in your big image) and have been made as base textures.

[TheMurderousCricket 5,107]

Oh dear... Yes, sorry. I was leaving home and didn't read your reply carefully enough. I'm sure you are right. I'll check it when I get back.

[TheMurderousCricket 5,107]

I managed to find all textures alright. Interestingly, one of them was in overlays despite being perfectly opaque to me. It took me quite a time to find it! 

I decided to do two tests today but sadly, they failed. All I got was this... 

 

When it should actually look like this...

 

There is also another 10x16 lot I made which returned exact similar result. Maxis textures are fine, but anywhere my textures are supposed to be, all I get is this corner stain (which also happens to be one of the tiles I made).

I checked in iLives that the IDs of my textures are correct - the IIDs are there in the file! But it still doesn't work. I should also mention that both lots display correctly in the LE.

I also identified that this little blob is the first texture to appear in the .dat I compiled in GoFSH (occupies IID ABEE0000 - 4) that contains all other pictures. As if it overrode all other .fsh slices all over a lot...?

What is wrong now? 

[TheMurderousCricket 5,107]

Another test. .fsh .dat redone from scratch (without opacities, to save time). Result is exact the same with the first bitmap dominating all lot tiles...

(I am sorry for three consecutive replies and all the fuss... Just updating you on the developments. @CorinaMarie, if you think this is a better idea, scoop my replies out and move them into the dedicated support thread, please).

[rivit 3,402]

This texture behaviour makes no sense to me.  Can you attach the test .dat to a PM to me please.  I need to be able to see what it has made and also see if I get the same results as you do in LE and In-game.

 

[CorinaMarie 29,894]

2 hours ago, TheMurderousCricket said:

@CorinaMarie, if you think this is a better idea, scoop my replies out and move them into the dedicated support thread, please).

I'll boot this over to @rivit. 

If he wants any or all of this moved to his thread I can push the buttons to do so. If not it can all stay here. (From a staff perspective it's fine with me either way.) And, as a support thing, posting 3 or 4 or more times in a row with new info is also ok. That assures everyone they've read the latest beeps whereas one can miss an edit.

[rivit 3,402]

hi Cori - its good here - we are learning things as we go and its a distinct theme

[TheMurderousCricket 5,107]

19 minutes ago, CorinaMarie said:

That assures everyone they've read the latest beeps whereas one can miss an edit.

15 minutes ago, rivit said:

we are learning things as we go and its a distinct theme

What rivit says. We might be up to something and from the looks of it, it's not pretty.