Gone FSHin'

[junspud 1,066]

I think the answer to this is no, but is there a possible method of 'inverting' the 'DEFC0' function? IE using a single D0 file for a set of textures, to expedite the recoloring of them?

Doing it manually is fine, but if one wants to make an override for an existing set of dirt paths or such, it can be a lot of copy/pasting into all of the D0 files.

Thanks...

[rivit 3,391]

Theoretically yes, but I'm having a bit of trouble imagining the workflow scenario. Only an all Green EDIT D0 comes to mind. 

If you already have a set of (fsh) textures that have been extracted you have their C0 and D0. I've always done color manipulations on the C0's in Photoshop or even IrfanView or another tool using an action because I have that much more control over the process, and then I reassemble the fsh.

If the idea is to EDIT the C0s with GoFSH arbitrarily later then a similar scenario exists - you throw the D0s through a Photoshop action that manipulates the RGB components, into a form needed for EDIT as you wish. This could be as simple as making them all Green.  ie RED,BLUE CHannel=0, GREEN channel 255.

Could you please give me more detail of what it is you want to do? 

[junspud 1,066]

On 5/6/2025 at 5:30 PM, rivit said:

Theoretically yes, but I'm having a bit of trouble imagining the workflow scenario. Only an all Green EDIT D0 comes to mind. 

If you already have a set of (fsh) textures that have been extracted you have their C0 and D0. I've always done color manipulations on the C0's in Photoshop or even IrfanView or another tool using an action because I have that much more control over the process, and then I reassemble the fsh.

If the idea is to EDIT the C0s with GoFSH arbitrarily later then a similar scenario exists - you throw the D0s through a Photoshop action that manipulates the RGB components, into a form needed for EDIT as you wish. This could be as simple as making them all Green.  ie RED,BLUE CHannel=0, GREEN channel 255.

Could you please give me more detail of what it is you want to do? 

Using a single all green D0 for a large group of textures was the main idea I think, but using an action like you mention works well enough.

BTW I noticed the street from road roundabout textures for TSR got disfigured by NAM updates (I assume anyway, I remember them looking normal before), I ended up fixing it in PS for personal use.

TSR Roundabout.7z

[rivit 3,391]

cheers.  thanks for that - roundabouts have always had tricky-to-draw joins to the rest of the network.

[junspud 1,066]

On 7/30/2025 at 7:29 PM, rivit said:

cheers.  thanks for that - roundabouts have always had tricky-to-draw joins to the rest of the network.

Yes I think the textures ended up shifting somehow in a NAM update, I forgot to take a screen but it was just slightly not joined right anymore.

I did also adjust and add a few other textures (US) to accommodate NAM updates from 48 and 49. 

The included X tile originally had a very subtle mismatch between the C and D, I think just because both the US and EU tiles had the same alpha but different styles, so this one has the US adapted to the EU styling instead. The 5F07230 tile just had some black jaggedish lines showing up or something (I forgot exactly what tbh) and so I just cleaned it up a little.

I tried adapting the lot version of the tunnel portal into the new draggable street tunnels in NAM.DLL and slope mod, but I end up with this broken portion at this particular rotation and zoom. Not sure why, I assume it's probably something obvious I'm just unaware of. Maybe because the draggable version is a proper network tile and so contains more textures which the lot version lacks?

Thanks.

 

TSR NAM Adjustments Jhsp.zip

[rivit 3,391]

Thanks. You have been busy - I might have to hand my archive over to you to maintain. 

 As for the tunnel not sure there  I don't know how to make draggable street tunnels work at all. Looks like a wrong orientation of the texture, maybe 180 deg out.

[junspud 1,066]

On 8/21/2025 at 9:39 PM, rivit said:

Thanks. You have been busy - I might have to hand my archive over to you to maintain. 

 As for the tunnel not sure there  I don't know how to make draggable street tunnels work at all. Looks like a wrong orientation of the texture, maybe 180 deg out.

Since the tunnels looked identical to the FLUP tunnels I thought they'd be the same, but after a closer look at them them I see they're different in a few ways.

One thing I've been confused about, sometimes when I extract  textures using GoFSH, I'll use the 'save only largest' option, but I still end up with some much smaller textures. I don't know much about models and BATs and such at the moment. The draggable tunnels are  an example of this;

When I exact the TSR tunnels, I get the expected result of the uniform large textures, so it isn't a 1:1 replacement like I originally attempted. Is it a difference in the way they're rendered or something?

Thanks.

[rivit 3,391]

2 hours ago, junspud said:

sometimes when I extract  textures using GoFSH, I'll use the 'save only largest' option, but I still end up with some much smaller textures.

Yes, well thats one of the mysteries of windows msg handling that I can seem to get on top of. Despite deliberately giving a way to just get the biggest textures, it does still occasionaly give them all. I've not been able to get to the bottom of it.  In the case of these tunnels though, I see in my archive that I only made the largest ones. 

2 hours ago, junspud said:

Is it a difference in the way they're rendered or something?

For models used in networks we have two methods available

- one is that of a BAT - so you will have 20 textures, 4 orientations, 5 zooms.,  so in your example above the ..430 texture is orientation 3 and zoom 4.  The rendered texture contents scale as 146x,73x,32x,16x,8x relatively speaking.  What this means is that the Zoom3 texture is Half the zoom4,  and the zoom2, 1, 0 are also exact multiples of each other. But you cant use the 4 to make all of the others with clean integer scaling. From 3 to 2 will go blurry very quickly  73/32 being relatively prime. Also each zoom has a subtly different perspective.

- the other is an S3D model which is scaleable so may use just one texture, or in some cases 3 or 4 but always at one size, which can then scale linearly. Viaducts and the RRW Tunnel are  made this way.

~~

The shortcut way is that doing what you normally do for a 5 mipset for each orientation (but manually renumbering after) using the 4s will look OK in game at the 2 closest zooms but the others when downscaled are off in perspective - however you can frequently get away with it because the 2,1,0 are so small.  This is what i did for the street tunnel - I only made the largest ones as its a small model and the centrelines lines disappear pretty quickly as you scale down so you need to be fixated on it to see the difference with MAXIS street.  

If you really want to give yourself a test then you need to edit all 20 of the original model textures, replacing maxis street with the TSR street and taking account of the shadows. Its fiddling time. There is a method in Bender to take a flat street (use the Lot version for color match) and make the perspective correct image of it to use when editing the model though. This saves a lot of heartache. However YMMV.

[Eggman121 1,035]

Hello.
I have started using Linux Mint as my operating system and have been able to get the suite of programs that I use for making content working on the Linux file system.
One issue that I have not been able to resolve is the Packing of FSH files into .dat files from GoFSH scripting.
I think it is due to the directory file structure but I could be wrong.
If anyone knows any pointers on how to resolve this issue I would like to know.
Most of GoFSH functions as intended in on Linux but the scripting and FSH to DAT sections are the issues I am having trouble with.
Thanks
-eggman121

[hugues aroux 3,779]

@Eggman121  Good morning,
 
Very often, when I encounter this error, it's because I have a BMP file (re)naming error, either in one or more C0-D0 pairs, or a missing file (D0, etc.). The script analyzer (source, destination, DEFC0, etc.) won't detect this. The process proceeds to datapacking and then stops with this message, since the working directory is empty!
And in this specific case, would you have renamed, manipulated, or moved any content from the "RRW Reskin Kit"?

[rivit 3,391]

@Eggman121     Since Windows and Linux/UX use different path separators its possible that the  \  or  /  in filepaths could be getting scrambled or misinterpreted. Windoze uses \ , Linux /.

Although I do try to cater for both I've no idea if it is completely correctly implemented, or if the Wine emulation deals with it well enough, as I've never tested on Linux.

It could explain empty output folders though. In the log that displays in the Builder it will tell you if (and where) no files were found or produced as it runs. The _ReaderLoadList.txt is probably empty when it fails, or is suddenly truncated where its baulked.

[Eggman121 1,035]

Hello.

First of all sorry for the delayed reply. RL is pretty hectic these days.

I think I understand why the FSHxDAT is failing at packing FSH files to .dat packages on a Linux filesystem.

The reader load list implies looking at a C:\ location as linked below.

Linux does not have a C:\, D:\, E:\ ect. I'm sure you already know about this.

My question is that is it possible to change the formatted location somehow to look for root locations on linux?

This is the last program I need to get working on Linux. 

No urgency and Thanks for the tips so far.

-eggman121

[rivit 3,391]

Hi @Eggman121

Nice sleuthing - that narrows it down a lot. Ultimately all GoFSH is doing is using a fully expanded Path, even though the scripts may be defined with relative paths.  So unless the bottom of the filesystem tree is not C: it will feature.

Have you tried on another volume (assuming you have one)? Just any old USB volume should be enough to check this. I always have my work folders on a TEMP volume in reality Z:  i.e. I avoid C: altogether for anything that isn't OS oriented.  

I wonder "Is there a permissions thing going on?". I assume C: is also Root: - do you (or Nemo) have permissions to modify root? or does Nemo absolutely protect C:  by default to avoid damage by accident?

Now my memory of UX (read 1980s) has me thinking that you can assign a volume name to any folder (dont know if modern Linux allows this or it depends on flavour). It may need to be a single letter name to work in GoFSH given its Windows origins. Will that work (at all?) or even on an underlying C: volume?

Telling GoFSH that it cannot use C: rooted paths is not a viable option on Windows (it works on all OS volumes), but maybe there is a way to disguise/redirect the issue on Linux.

EDIT:  I thought id better check if what I was suggesting could work and the following Google query suggests it can:

can you assign single letter volume names to folders on linux mint 

But (good news bad news), way down in that answer there is also another clue.  : is not allowed in a filepath under Linux. So the volume C: is illegal, and so all paths with colon in it will fail. I would have thought that Wine might have dealt with that itself. I don't know how to do that selectively as yet, so any clues into how I can tell if I'm (as GoFSH) running on Linux (under Wine presumably) are welcomed. Then I might be able to patch it. 

  Edited February 7 by rivit  
check myself

[Lab Rat 12]

Automated Notice Message

All posts after 1 March, 2026 @ 01:37 GMT were lost in the site crash.

We've added this message thread divider in every topic across all forums for what were then active threads. (We decided active is if the most recent extant post (from the backup) was on or after 1 January, 2026.)

This divider serves as notice that the conversation was interrupted. Answers and further discussion which used to be here have been lost. Keep this in mind when replying. Our hope is to rebuild what is missing.