MGB Lot and Mod Shack

[rsc204 21,866]

Indeed these cover the new stations in RTMT 4, so SWN won’t need updating to work with it. 

[Simizen 1,100]

Hey, I wanted to let you know about a texture issue with the Catalyst SAM 7 Bikepath override texture.

There seems to be a set of missing textures with the larger, 2x2 culdesac, when drawing a street corner through it:

Also, I really love the way this (SAM 7 override) texture set looks. You've done an amazing job with it.

[rsc204 21,866]

On 24/05/2021 at 10:48 AM, Ryuu Tenno said:

There seems to be a set of missing textures with the larger, 2x2 culdesac, when drawing a street corner through it:

Actually this is a limitation of SAM rather than missing textures. SAM was not intended to cover every Street texture and this setup won't work for any SAM networks. Likewise there doesn't exist any support for diagonal street roundabout using SAM either.

A while back I actually wrote the code needed for these two setups for SAM, but I never had the chance to add it to the NAM because I only got as far as covering SAM 7 / 11 networks.

I believe I included the textures in the last update for SAM 7, so when the code gets added to the NAM in future, it'll just work right away without the need for an update. But right now I have very little time, for example my PC hasn't been switched on for about 2 months, I have no idea when I might be able to finalise/release this. There isn't really an easy way for me to provide a patch or mod for RUL code like this, it must be incorporated into the master NAM Controller Files. If you are comfortable using the NAM Controller Compiler manually, I could share everything needed to build a Custom Controller that'll add these setups for SAM7/11.

[junspud 1,069]

Been having a small issue, tried everything I can think of to work it out.

 

This is with just NAM/P-SWN installed in Plugins folder. The TLA 5 texture under the El-Rail reverts back to transparency at Zoom 3+. Only seems to happen with TLA-5.

I have made sure I have 'NGN NAM E Textures' dat installed. I tried exacting the texture from the dat and making a new one with just the TLA-5 Texture with 'Make a scaled set of 5' option as well but still reverts back.. 

Thanks.

 

[rsc204 21,866]

If the road textures all exist, it's possible that the S3D's are the problem (incorrectly linked textures), I couldn't say for certain without looking, I'll do my best to take a peek if I get a moment.

[junspud 1,069]

10 hours ago, rsc204 said:

If the road textures all exist, it's possible that the S3D's are the problem (incorrectly linked textures), I couldn't say for certain without looking, I'll do my best to take a peek if I get a moment.

Sounds good, thank you, your mods are great.

BTW I tried it out with the 'MGB Euro' version and the same issue presented. I  haven't done much with S3Ds yet but I might take a look and see as well.

[Dead_End 1,630]

I've recently installed the Japanese Walls Set by Mas71 and I've noticed that the arrow prop from that set have somehow turned up on some of the lots from your Diagonal Filler Set.

That prop obviously isn't visible in the game when the lot is placed, but it does prevent any placement of MMP's on the lots. I figured it might be a case of two props using the same ID, but after removing Mas71's files from my plugins folder and reopening the lot there was no other prop there. Would you happen to have an idea of what's going on here?

Edit: The problem seems to occur only on the following (all 1x1 diagonal transition) lots:

Filler MGB $$-$$$ Grass
Filler MGB $-$$ Grass
Filler MGB $-$$$ Grass
Filler MGB Ind $$$/Grass
Filler MGB Ind $$$/Sidewalk
Filler MGB Ind $$/Grass
Filler MGB Ind $$/Sidewalk
Filler MGB Pavement to $ Grass Barrier
Filler MGB Pavement-$ Grass
Filler MGB Pavement-$$ Grass
Filler MGB Pavement-$$$ Grass

  Edited June 12, 2021 by Dead_End  
Added list of lots

[BartonThinks 3,416]

21 minutes ago, Dead_End said:

I've recently installed the Japanese Walls Set by Mas71 and I've noticed that the arrow prop from that set have somehow turned up on some of the lots from your Diagonal Filler Set.

That prop obviously isn't visible in the game when the lot is placed, but it does prevent any placement of MMP's on the lots. I figured it might be a case of two props using the same ID, but after removing Mas71's files from my plugins folder and reopening the lot there was no other prop there. Would you happen to have an idea of what's going on here?

Edit: The problem seems to occur only on the following (all 1x1 diagonal transition) lots:

Filler MGB $$-$$$ Grass
Filler MGB $-$$ Grass
Filler MGB $-$$$ Grass
Filler MGB Ind $$$/Grass
Filler MGB Ind $$$/Sidewalk
Filler MGB Ind $$/Grass
Filler MGB Ind $$/Sidewalk
Filler MGB Pavement to $ Grass Barrier
Filler MGB Pavement-$ Grass
Filler MGB Pavement-$$ Grass
Filler MGB Pavement-$$$ Grass

When you're placing flora, the game won't let you place flora on top of other props. This is based on the occupancy size of the prop, which is the blue footprint you see in the lot editor. Even if the prop is set to be invisible, it's still there, and you won't be able to place flora anywhere within that blue footprint.

[Dead_End 1,630]

On 6/12/2021 at 1:10 PM, Dead_End said:

I've recently installed the Japanese Walls Set by Mas71 and I've noticed that the arrow prop from that set have somehow turned up on some of the lots from your Diagonal Filler Set.

That prop obviously isn't visible in the game when the lot is placed, but it does prevent any placement of MMP's on the lots. I figured it might be a case of two props using the same ID, but after removing Mas71's files from my plugins folder and reopening the lot there was no other prop there. Would you happen to have an idea of what's going on here?

Edit: The problem seems to occur only on the following (all 1x1 diagonal transition) lots:

Filler MGB $$-$$$ Grass
Filler MGB $-$$ Grass
Filler MGB $-$$$ Grass
Filler MGB Ind $$$/Grass
Filler MGB Ind $$$/Sidewalk
Filler MGB Ind $$/Grass
Filler MGB Ind $$/Sidewalk
Filler MGB Pavement to $ Grass Barrier
Filler MGB Pavement-$ Grass
Filler MGB Pavement-$$ Grass
Filler MGB Pavement-$$$ Grass

Did some additional testing and the problem seems to in fact be related to Mas71's Walls Pack 2. The prop is no longer present after removing these files from my Plugins folder. My apologies for the earlier mistake and I hope no-one wasted any time trying to replicate the problem based on the wrong information!

[rsc204 21,866]

On 12/06/2021 at 1:10 PM, Dead_End said:

I've recently installed the Japanese Walls Set by Mas71 and I've noticed that the arrow prop from that set have somehow turned up on some of the lots from your Diagonal Filler Set.

This is something I added to help more easily orient the various filler pieces when placing them. This is totally optional, if you have the props installed (part of the Mas71 walls sets) these appear during placement, otherwise they simply don't appear.

On 12/06/2021 at 1:10 PM, Dead_End said:

That prop obviously isn't visible in the game when the lot is placed, but it does prevent any placement of MMP's on the lots. I figured it might be a case of two props using the same ID, but after removing Mas71's files from my plugins folder and reopening the lot there was no other prop there. Would you happen to have an idea of what's going on here?

The blocking of MMPs is a result of Occupant Sizes, every Prop has such a Property defining the space to reserve for it, by default that will be the size of the Prop itself, such as is the case with Mas71's original Props. The complication here is whether or not the Occupant Size is ultimately being picked up from the Prop Exemplar or from the LotConfig (Lot settings)? I quite deliberately altered the v2 set to ensure the Lots were ruthlessly optimised in this regard, so make sure you've removed v1 if you previously used that.

On 13/06/2021 at 5:22 PM, Dead_End said:

Did some additional testing and the problem seems to in fact be related to Mas71's Walls Pack 2. The prop is no longer present after removing these files from my Plugins folder.

Just bear in mind you shouldn't have to go to the extreme of removing any content from Mas71, honestly his walls are so indispensable I re-ID'd a couple sets to use more than one at a time. If all else fails, ensuring the following file loads after all of Mas71's file should force the smaller (intended) Occupant Size.

zMAS71OccSize.dat

On 12/06/2021 at 1:41 PM, BartonThinks said:

Even if the prop is set to be invisible, it's still there, and you won't be able to place flora anywhere within that blue footprint.

Except when you reduce the Occupant Size, doing this frees up that space for other items, but can lead to Props colliding if you aren't careful. Since a disappearing Prop wouldn't collide, it's a good work-around to use in these situations.

I'll do some specific testing when I get a chance, at the time of release I tested them a lot and was sure I'd resolved the 'reserved space' problems, but it could be without the Prop overrides (attached) it just doesn't work as intended.

[BartonThinks 3,416]

3 minutes ago, rsc204 said:

This is something I added to help more easily orient the various filler pieces when placing them. This is totally optional, if you have the props installed (part of the Mas71 walls sets) these appear during placement, otherwise they simply don't appear.

The blocking of MMPs is a result of Occupant Sizes, every Prop has such a Property defining the space to reserve for it, by default that will be the size of the Prop itself, such as is the case with Mas71's original Props. The complication here is whether or not the Occupant Size is ultimately being picked up from the Prop Exemplar or from the LotConfig (Lot settings)? I quite deliberately altered the v2 set to ensure the Lots were ruthlessly optimised in this regard, so make sure you've removed v1 if you previously used that.

Just bear in mind you shouldn't have to go to the extreme of removing any content from Mas71, honestly his walls are so indispensable I re-ID'd a couple sets to use more than one at a time. If all else fails, ensuring the following file loads after all of Mas71's file should force the smaller (intended) Occupant Size.

zMAS71OccSize.dat

Except when you reduce the Occupant Size, doing this frees up that space for other items, but can lead to Props colliding if you aren't careful. Since a disappearing Prop wouldn't collide, it's a good work-around to use in these situations.

I'll do some specific testing when I get a chance, at the time of release I tested them a lot and was sure I'd resolved the 'reserved space' problems, but it could be without the Prop overrides (attached) it just doesn't work as intended.

Oh, that's interesting. I had originally written out some details about altering the occupant size, but I figured that would also require modding all of the relevant LotConfig properties. If I'm reading this correctly, the game ignores the LotConfig properties if they conflict with an override prop's modded occupant size?

[rsc204 21,866]

21 minutes ago, BartonThinks said:

If I'm reading this correctly, the game ignores the LotConfig properties if they conflict with an override prop's modded occupant size?

It's possible but flies against my original thinking, that said I've only ever messed around with this for the Building on a lot. For Buildings it's quite the opposite, the value in the Buildings Exemplar is ignored, only the 'fixed' value from the LotConfigPropertyLotObject is used. In other words if you create a new lot, but subsequently adjust the Occ. Size, you have to manually update the hex values in the correct Reps of the 0x00000000 line.

Hence I recommend for PIM-X users, to also ensure you get the right Occ. Size the first time, otherwise it's quite a PITA to correct. Something I certainly wasn't aware of when making what was I think my second mod for SC4 many years ago.

It's possible that Props work differently, instead using the linked Prop Exemplar values, but until I've run some tests there, I would be of the thinking they'd work like the Buildings. It's quite possible use of an out of date version of the filler set, some conflicting override or other factor would explain the problems in this case. But if it turns out the value is read from the Prop Exemplar, everyone wanting to MMP these lots freely, may need to have the attached override for MAS71s Props. But I tested the hell out of these lots to ensure MMPs went everywhere, so unless I messed up my test environment, I'd expect the values from the LotConfig are the ones the game would use.

[Tyberius06 12,267]

Last year I spent a little time checking and fixing some Occ Size on a few lots, which were reported to be causing Immortal Lot Syndrome. Maybe one of the most infamous of all is Bixel's The Arch I (the LEX version only in the HKABT Bixel Mega Props vol. 08) and its belonging lot set the BXL CAM Residental Lots vol01. Both of them are locked (not for long though, probably I'm gonna reopen them this week after I upload the fixed versions), because whoever made the CAM lot version, did set the recalculated value for the building examplar Occ size (note: this model is offset by 12 or 8 meter so wouldn't fit onto the lot size what either Bixel or the CAM lot creator used, this is why Bixel back then edited the Occ size to get a smaller rectangle on the LOT), BUT copied the original LOT config data with the building rectangle from the original lot made by Bixel. Since now the Occ Size of the Building examplar was bigger than the rectangle size on the lot and it was offset too, the building rectangle with improper values was overhanging the lot and this triggered the immortality bug. 

I found other lots where the original creator used a smaller/edited rectangle/Occ size to fit the model onto a smaller lot, while the PIM-X'd version started causing ILS due to the default set Occ Size (to serve the purpose of the Filling Degree). 

The most problematic was however Bixel's offset model, where I actually chose to center the model with tweaker. I needed to move the rectangle a bit on the original lot, and now the CAM version can use the default dimesions of the model without any issue.

I don't know if it was supposed to be a PIM-X feature (which then either wasn't implemented or simply did not work as intended), that when you edit the Occ Size it should change the size of the rectangle on a LOT.  

 

[rsc204 21,866]

On 05/06/2021 at 11:00 PM, junspud said:

This is with just NAM/P-SWN installed in Plugins folder. The TLA 5 texture under the El-Rail reverts back to transparency at Zoom 3+. Only seems to happen with TLA-5.

4 of the 5 models incorrectly link to the standard NAM textures, not the special darkened ones for use with Puzzle Pieces. As such, only Zoom 5/6 currently link to the SWN texture in question. Installing the following patch (DAT Pack it into the file ML JPN EL Rail 2013 for NWM.dat ideally) and the sidewalks should appear.

zML_ElxTLA-5 Fix.dat

I recall seeing many similar issues with the ElRail mod not linking to the intended Puzzle-Based textures, so I suspect there are others to find too.

[junspud 1,069]

16 hours ago, rsc204 said:

4 of the 5 models incorrectly link to the standard NAM textures, not the special darkened ones for use with Puzzle Pieces. As such, only Zoom 5/6 currently link to the SWN texture in question. Installing the following patch (DAT Pack it into the file ML JPN EL Rail 2013 for NWM.dat ideally) and the sidewalks should appear.

zML_ElxTLA-5 Fix.dat

I recall seeing many similar issues with the ElRail mod not linking to the intended Puzzle-Based textures, so I suspect there are others to find too.

Oh no kidding,  my bad I guess I had the 2013 El-Rail mod in my plugins folder also as opposed to just NAM/SWN. Nice you tracked down the problem and provided this fix thank you again.

[rsc204 21,866]

I've been working on expanding the SRM to support some of the new NAM features since it's release. As mentioned on the Show us Your threads, of the 4 styles from SRM, only the two European Variation 1 styles (that's both a LHD and RHD version) are going to be supported. You can use this with the other two RHD variants, but note that these T21s will not have the same pattern/layout as the remainder of SRM in such cases. However, you should be free to use whichever Stoplights and Poles you want, since the IDs are the same.

So far I've managed to cover all of the QuickTurn options, which will also work with some FTL setups too:

Here I'm showing the LHD versions, although as mentioned before the actual T21 layouts work for both RHD or LHD players. However, most of these setups use Left or Right turn signals, those do need to be switched for LHD/RHD play, so attached on my Dev thread (here) are both versions.

Bear in mind I had to use the "Sizeof 7" cheat to essentially view them in zoom 7, only then can you actually make out such minute details like the direction of lights.

Just plop either the LHD or RHD dat from the following attachment into the same folder you use for SRM to add FTL, QuickTurn and OWR SITAP support:

SRM FTL and SITAP Addon.zip

If you were using the previous version ENSURE YOU REMOVE THE OLD FILES before installing the update, this replaces the old version.

I do want to update this to include the remaining FTL and OWR Signalisation pieces, but no guarantee I'll either do it this century or keep RHD support if I do. Update: As of Jan 22, I've updated this patch so that it now includes all FTL, QuickTurn and OWR SITAP setups prior to NAM 42, i.e. it doesn't include the new RHW-based stuff yet. No plans to add that right now, 300 T21s down and I'm done for a bit, *phew.

[AsimPika3172 1,155]

Cool! Wait for next release because I got this one...

Using NAM 42 LHD Euro version, but showed Yellow lines for USA version... 

[rsc204 21,866]

On 15/09/2021 at 1:18 AM, AsimPika3172 said:

Using NAM 42 LHD Euro version, but showed Yellow lines for USA version... 

My screenshots are LHD Euro NAM 42 also, however I am using custom variants of both my TGN and SWN mods, which might force the correct EU textures. Should it turn out to be missing textures from the LHD NAM files, I'll upload an interim patch for them. But regardless the T21s themselves should work just fine.

OK, so I had totally forgotten about this post, sorry. Indeed there is a problem with the TGN textures. There is nothing wrong with NAM.

At this link you can find replacement TGN FTL - EU.dat files, which all EU users ideally need. Just pick the folder, based on the version of TGN you use and overwrite the original file, found inside z____MGB Mods\G - TGN\1 - Maxis & Basic NAM, with the downloaded one.
If you want this patch, please update your TGN to version 2.45 or later.

[AsimPika3172 1,155]

thank you! 

[junspud 1,069]

Was wondering, I came across this post which had a link to a TGN repository;

https://www.sc4devotion.com/forums/index.php?topic=17750.msg517269#msg517269

But the link no longer works, is it still possible to download this? 

Thanks.

[rsc204 21,866]

I updated my online files, because a change in direction developmentally, I realised constantly modifying my personal repositories to release a public variants would become too much work. So I've switched to a system where I keep my personal copy on my computer, which I can manually sync only the parts I want, with my OneDrive folder. Upon manually running this process, the online version gets updated automatically. Provided I keep my private development works in a specific folder, this solution doesn't create any additional workload to keep an updated version available for others. This is something I was very much in the process of setting up, in fact I only got as far as getting the basic content online so I could work through any kinks in my processes. 

All my texture repositories will be maintained from this folder (OneDrive) from here on out. Currently that includes my SWN, TGN, Rural GLR, SAM 6, SAM 7 and SAMB repositories.

Specific to TGN, there will be content included in the latest release version that is currently not online. I do want to get those additions merged into the whole, but I simply lack the free time to do it right now. So depending on what your plans are, I could send you those addons I have finished working on separately or you can wait until I update the online copy.

SWN should be pretty complete, since it's based on my most up-to-date files.

My SAM7 and SAMB mods are rather complex, requiring multiple scripts to run with different textures. It's all usable, but not documented fully, but again I'm happy for others to have access to my resources. I did leave some notes as comments at the top of the GoFSH script .txt files though. Again it's all very much a work in progress and I may have lots of the newer textures personally, that right now aren't online. So if you've plans to do anything I usually cover, it's worth checking with me before making new pieces. Eventually, I plan to have everything better documented and to keep things more up-to-date.

[junspud 1,069]

On 9/16/2021 at 6:05 AM, rsc204 said:

I updated my online files, because a change in direction developmentally, I realised constantly modifying my personal repositories to release a public variants would become too much work. So I've switched to a system where I keep my personal copy on my computer, which I can manually sync only the parts I want, with my OneDrive folder. Upon manually running this process, the online version gets updated automatically. Provided I keep my private development works in a specific folder, this solution doesn't create any additional workload to keep an updated version available for others. This is something I was very much in the process of setting up, in fact I only got as far as getting the basic content online so I could work through any kinks in my processes. 

All my texture repositories will be maintained from this folder (OneDrive) from here on out. Currently that includes my SWN, TGN, Rural GLR, SAM 6, SAM 7 and SAMB repositories.

Specific to TGN, there will be content included in the latest release version that is currently not online. I do want to get those additions merged into the whole, but I simply lack the free time to do it right now. So depending on what your plans are, I could send you those addons I have finished working on separately or you can wait until I update the online copy.

SWN should be pretty complete, since it's based on my most up-to-date files.

My SAM7 and SAMB mods are rather complex, requiring multiple scripts to run with different textures. It's all usable, but not documented fully, but again I'm happy for others to have access to my resources. I did leave some notes as comments at the top of the GoFSH script .txt files though. Again it's all very much a work in progress and I may have lots of the newer textures personally, that right now aren't online. So if you've plans to do anything I usually cover, it's worth checking with me before making new pieces. Eventually, I plan to have everything better documented and to keep things more up-to-date.

Thank you for this, I was actually wanting to do a version of your Sandstone GLR but with cobblestone instead, you have the rural version here which I don't use much so that's awesome.

I've also spent a lot of time going through NGN and some others with GoFSH to customize my textures a bit, overriding TGN avenue curves with the NGN version for example, so these repos are a much appreciated resource.

[rsc204 21,866]

49 minutes ago, junspud said:

I've also spent a lot of time going through NGN and some others with GoFSH to customize my textures a bit, overriding TGN avenue curves with the NGN version for example, so these repos are a much appreciated resource.

Currently the TGN repository doesn't actually cover NGN, in fact NGN didn't even get the TGN updates from Feb either. This is because I've a new system for swapping out the D0 files that need to change to make that mod. However there is a work-around, when using GoFSH, add your sidewalk textures as both the Paving and Grass textures, this will ultimately give you the same end-result.

2 caveats there, some TGN features aren't desirable for NGN (I use a custom script), I also kept grass in very specific circumstances, where removing it simply makes no sense. So for example Roundabout Centre's, the last thing you want is a mis-match of grass/sidewalks there. In time that will all be added to the online repository, but my workload is already far exceeding any time I might possibly have to progress much. So I have to focus on the TGN stuff to begin with.

[junspud 1,069]

16 hours ago, rsc204 said:

Currently the TGN repository doesn't actually cover NGN, in fact NGN didn't even get the TGN updates from Feb either. This is because I've a new system for swapping out the D0 files that need to change to make that mod. However there is a work-around, when using GoFSH, add your sidewalk textures as both the Paving and Grass textures, this will ultimately give you the same end-result.

2 caveats there, some TGN features aren't desirable for NGN (I use a custom script), I also kept grass in very specific circumstances, where removing it simply makes no sense. So for example Roundabout Centre's, the last thing you want is a mis-match of grass/sidewalks there. In time that will all be added to the online repository, but my workload is already far exceeding any time I might possibly have to progress much. So I have to focus on the TGN stuff to begin with.

The ability to have a custom version of TGN is great though, swapping out certain textures/alphas in the TGN/SWN repos with textures extracted from NGN or ect is what I'll probably do for now... Right now I have TGN/SWN installed and then a mishmash of specific overrides taken from NGN and other sources, all of which can now just replace the relevant textures in the TGN or SWN repo, for the most part anyway I think.

[rsc204 21,866]

An updated version 1.42 of the Type 01 style RRW ReSkin is now ready to download on my Google Drive. This should include support for all RRW content up until NAM 42.

:Edit Nov21:
The release-version can now be found here on the STEX.

In case this is gobbledegook to you, it's a mod that makes your RRW networks look as follows:

[Eggman121 1,052]

Thanks @rsc204 & Hi everyone.

I see this as a beta release for arguments sake so if there are any issues please post a screenshot and tag me in and I will try to follow up with updates.

The reason for this is that I did find some issues, Mainly irfanview garbling up some of the -D0s

But for now, Enjoy.

Best.

-eggman121

[Girafe 1,729]

Thanks for sharing

Will give it a try for sure

[Girafe 1,729]

reporting few issues:

crossing (ortho and diag) with OWR or REW still display old RRW texture

Crossing (diag) with street / SAM, Road brings some whitening to the rail texture

Edit1: same issues for straight rail with OWR / REW diag crossing

 

[rsc204 21,866]

I have the correct OxD OWR by RRW textures here, are you certain there isn't some override acting on this? A sure fire way to know would be to add zoning, if anything but the Maxis sidewalks appear, the mod containing those textures, will be overriding the ReSkin.

It might be worth mentioning at this point, that could include my SWN, TGN/NGN and SAM Mods, Rivit's TSR and various SAM mods or anything else that may include crossing textures. Rivit's RUM for RRW has an automated repository now, which allows users to make a special patch which covers all combinations of such textures. But due to the sheer number of variants, it's simply impractical to offer them all more directly. Every RRW Reskin release should come with the necessary source textures, those used to make the reskin, so users have the necessary tools to create such patches. Find mine with the documentation installed by the mod.

As for the brighter sleepers, I think that's because the regular diagonal sections are not correctly brightened (in the RRW source repository). If you draw a 45° bend from ortho to diagonal and build a crossing close to the start of the diagonal, you'll see how they match up better with the Ortho RRW sections. I'm not sure which way round is best fixed at this point, thanks for letting us know, it's certainly something I'd prefer to see addressed.

[Eggman121 1,052]

1 hour ago, rsc204 said:

As for the brighter sleepers, I think that's because the regular diagonal sections are not correctly brightened (in the RRW source repository). If you draw a 45° bend from ortho to diagonal and build a crossing close to the start of the diagonal, you'll see how they match up better with the Ortho RRW sections. I'm not sure which way round is best fixed at this point, thanks for letting us know, it's certainly something I'd prefer to see addressed.

I should have a solution this afternoon AEST. Just need to tinker with Irfanview's colour replacement tool in the Batch conversion/ Rename section.

-eggman121