rsc204

Time for some changes around here, after a number of years of updates things have become fragmented somewhat, so in an attempt to make things simpler to find, I am summarising everything in one place that I've created/released over the years. In addition to my main development thread, please find a special thread relating to all my BAT Models here All my small mods/fixes are being updated into my Lil' Bits thread here Complete information on using GoFSH texture automation can be found here See all my official (STEX) releases by clicking here Probably a good time to explain that I'm both RSC204 here and MGB204 on SC4Devotion, MGB was not available to me here if I remember correctly but is my preferred handle. Here is a quick peek at some of my more popular mods: Sidewalk NAM (SWN) - Intended to replace sidewalks on NAM networks that otherwise show the default Maxis one. Available in three variants or download the repository and make a custom version for any sidewalk using automation: MGB Euro Pavements - My own custom sidewalks SWN for Paeng's Sandstone Pavements SWN for Catalyst's Asphalt Sidewalk Extension Terrain Grass NAM (TGN) - Intended to replace the Grass on NAM networks to match one of four terrain mods: Berner Oberland by Gobias Sudden Valley by Gobias Appalachian by Lowkee Pyrenean by Orange (TSC)

Just came across the following information when accessing Hide and Seek!, which currently stands as the largest combined repository of Japanese content: Of course this is using an online translation tool, but it does appear the domain will expire next Feb. However it's not completely clear if the downloads on that site will remain available after that date at another site. The good news I suppose is that we have 10 months or so warning, rather than the site just shutting off one day. But I figured this may have slipped under most people's radar since I never saw it mentioned elsewhere.

Is that a bridge?, that's really the only explanation I can think of for why the roadway suddenly has a vertical gap. The lights are wrong because the T21s used were likely created for the original and less wide Maxis Highway, which MHO is simply a visual override of. However, since MHO includes special T21s, I think what may have happened was that the bridge was build before MHO was installed. In such cases, the bridge model itself will automatically change, but to 'refresh' the T21s, you'd need to demolish and re-build the bridge. I'm curious to know if doing so fixes either issue, note that it was me who added these MHO bridges, so unless a recent update elsewhere has broken things, I know for sure it was all working fine.

This is a 13 year old thread and to no one's surprise the information is well out of date. LHD support in NAM is not complete, but there are a number of factors that need consideration. For LHD to work as intended, three different components need correct LHD variants, Textures, Paths and T21s. Anything texture related (stoplines etc), probably comes from the NAM, to my knowledge where LHD is possible, all rail crossings should have LHD variants. There are some caveats here, for example if you install a mod like my TGN, if a texture replacement also replaces the same crossings, it too will need to support and be setup for LHD use. But it should be noted that it's not always possible to have the stop lines in the right place, because certain textures are re-used in multiple configurations (Rotated or Mirrored), which in some cases means that even for RHD users, the stop lines won't be correct in all instances either. This problem especially affects OWR crossings, where the game's 'Tidal Flow' system, doesn't really allow us to differentiate between the two possible directions of traffic. Pathing is probably the simplest component of all this and generally speaking LHD support is pretty complete, if you notice rail automata disappearing consistently at a crossing, that's a sure sign the paths are not correct though. T21s are kind of like a 1x1 Lot, you can design a bunch of Props (models) that will be placed onto a transport network, this is how we get crossing barriers, lights, catenaries and just general decoration. Specifically for Rail crossings, Jondor's set is for me a must have, since it expands the basic NAM setups, supports LHD and generally looks way nicer, with customisation options too. However as of this moment, there is not a complete set of LHD crossings anywhere I know of, the OxD and DxD setups being the major omission. These aren't necessarily perfect in RHD either, since it's been an area that was mostly ignored by modders. Given the combination of the base Networks, SAM, NWM and RHW crossings and a handful of more unique pieces, added with the complexity of the T21 settings, it's not a simple job to fix even though I have it in my todo list and have made some progress in this direction. I've explained this in more detail in the following guide: In addition to explaining how to make the change and links to some useful mods to use with it. So for example, this is just another case where compatibility fell through a gap, NAM doesn't support LHD configurations for stop lights, so you need SRM. But, SRM has some bugged setups like this that are ultimately the root cause of why they still don't correctly appear. There is no game limitation going on here, I have released an expansion for SRM to cover mostly the newer NAM FTL and QuickTurn setups. I did some bug fixing whilst there, but there remains quite a bit of work I'd like to do there also. I think in conclusion, it's fair to say LHD support is not and probably never will be perfect, but I decided to stick with and improve things and for most users it's fine to use.

The GoG version is pre-patched, so you don't need to worry about that angle. So the first question is, does the original building have night lighting?, not all BATs do and if not, then GoFSH would not have any lighting to convert.

If you misdiagnose a problem, then you are likely to misdiagnose the solution too, I feel you have misunderstood my intent here. Clearly it would appear you are dealing with save file corruption, but is that caused by Prop Pox?, there is a chance it isn't, the point I was trying to make is that file corruption, however it manifested ultimately leads to the same result. But the method used to at least prevent this problem reoccurring, would differ based on what is triggering the problem, hence there are important distinctions to consider. I'm not saying it can't be Prop Pox, I'm saying that the only known file to be identified that caused it was the BDK dependency file, since you do not have this, there is only 1 other way that you can verify if the problem is or isn't Prop Pox. You'd need to identify whether any of the Mods you have installed are overriding existing props that are RKT1 based, but having switched to RKT4 props in the process. So whilst Prop Pox is quite incredibly specific, what I'm trying to say is that the symptoms you have do seem reminiscent of Prop Pox, but not a single confirmed mod has exhibited the specific alterations in the god knows how many years since this issue came to light. What this means practically speaking is not that your problem can't be Prop Pox, but I have long suspected that Prop Pox should just be more generalised as File Corruption, but what matters here though, was it an RKT change that triggered your file corruption? However once more and I assure you I'm not trying to be blasié, it doesn't matter, because there is no way to fix such a corrupted file once it has the trigger, there is data in the wrong place. Only it doesn't start causing data to be incorrectly written unless the save file grows such that it hits the threshold where the game compresses the data. So what if it's not an RKT change behind this, which to me seems to be more likely, well that's a problem too because now it could be anything so we don't even know what to look for. However, since most users aren't able to look at their entire Plugins suite and check for RKT1 Props that have been overridden in this manner, it's quite possible that is the case, but how can we help you to locate the potential cause? No, because whether it is Prop Pox or isn't Prop Pox doesn't matter, it's all just semantics, since regardless of which it was, you are unable to take advantage of the only known fix for the problem, which is SC4Fix.DLL. The solutions noted in the thread you linked do not apply to you and that's because the .DLL is necessary to provide a permanent fix, since it alters the format of the save data in such a way that no additional file corruption can occur. Which conversely also means that it prevents said corruption if it was installed before any corruption would have otherwise occurred. I have personal experience here, I triggered file corruption that absolutely was not Prop Pox, simply by adding too many new Props into the save file in one go, rather than saving in chucks, overwhelming the save file. At least that's the best explanation I can give for everything that was going on, but that's not important, what is, having SC4Fix.DLL prevented that same corruption from happening, allowing me to continue using my otherwise damaged save file. Does your problem warrant research?, well yeah if you were able to work out the specific cause of your corruption, yes. So if you can check for the RKT mismatch (Prop Pox), maybe you find a file no one else knows about that could trigger Prop Pox. But otherwise, I can't even give you anywhere to look or what to look for, it would be pure guesswork. The only reason I can tell you how I did it, was because I was messing around with modding and could de-construct things and use an unaffected backup and do a ton of experiments to make sense of what had happened. Motivated in no small part by my desire to make a fully seasonal T21 mod with random trees and because we can not safely override RKT1 with RKT4 props, the specific cause of Prop Pox, I had to find another way to approach it. What I'm saying is, here's the most complete description of the problem I can give you, if you understand that and the limitations of what can be done, then this will greatly help you to look into the problem further. But if you are looking for an answer that involves what file do I have installed that causes Prop Pox (or file corruption in the manner shown)?, then the only answers anyone can give you are, do you have the BDK file, or this is the cause (trigger) scan your entire plugins for anything that might do this. What I can not do, is go through your specific Plugins folder looking for the cause, I can only lead this horse to the water. Off the top of my head too, I do not know of some automated method to do this, only sifting through a ton of data and ruling every file out to narrow it down. Which even if you could and would do that, should you find that no such RKT changes were present, there is no other specific criteria anyone can give you beyond that. I feel you've failed to take into account the whole when coming to this conclusion, that's certainly not what I was trying to convey explicitly, but whether you like it or not I can't really summarise it otherwise. With the exception of adding (as I've attempted to today), how you might find the root cause, limitations in that regards notwithstanding.

Are you renaming the output files at some point, the -A0/-C0 pairs is how GoFSH outputs by default so if that's not present I think you've been tinkering and you really shouldn't. Likewise, you can't use a scaled set of textures for BATs, since they aren't scaled in the same way Network and Lot textures are. Also, why are you messing with DXT settings?, it's not likely to help matters either, leave things alone unless you know what you are doing would be my advise. With that all said, I've ran through a sample DAT file with some of my models and converted them from MN to DN (you might need a different Colour Correction, depending on the source files), but this shows you the process: Note that the final DAT contains ONLY the new Nite textures, either load these later than the original DAT or (ideally after testing them), DAT Pack them into the original file so you don't end up with duplicates.

(Mod note): Just in the process of setting everything up. It may take a while, for now I'm keeping this thread locked. Go-FSH Texture Automation This thread will serve as a home for discussion of Texture Automation for SC4. What is texture automation and why would I want to use such a thing? In the past, if you wanted to customise in-game textures, it meant a lot of arduous work, finding, extracting, converting, editing and then re-packaging textures. But recently GoFSH has been developed to automate many common tasks, which is good news not just for modders, but for regular folks too. It is now possible for creators to release customisable texture mods, users just need a copy of a working repository and GoFSH will do almost all of the work for you. How does this work in principle?, for example, say you'd like to see a custom sidewalks on those NAM textures which otherwise won't show them. That's exactly what my SWN mod was designed for, however rather than being limited to the handful of sidewalk variants I've released, you can use the same process to make a custom version. You simply download the SWN repository, install the GoFSH application (STEX Download here) and use them to create your desired sidewalk mod. Below are some basic tutorials to get you up and running. I hope to add a list of available repositories (with links). I'll also be adding some of the more complicated stuff in due course.

Index of 'Install and Go' Customisations, created using Automation Alternative RRW ReSkin Styles:

As ever with modding, there are limitations and you have to decide which you can and can't live with. Sometimes we can alter those things, this is not one of those cases.

Best you can do is modify the textures to replace the transparent areas with sidewalk, I have such textures somewhere as part of my SWN mod for example. As for adding Props, two potential solutions, first use a lot that has overhanging props, second would be to create T21s (these define props added to networks such as traffic lights and street lamps). In either case I am unaware of anyone having made them for the Turbo Roundabouts that you could download.

4GB patch is not going to help you with this problem. If your game crashes after the splash screen (intro window), then you have a compatibility issue, not uncommon running a 2003 game on modern hardware. Do you see the intro videos at all before it crashes? Usually these problems all stem from either video or audio incompatibilities, the former typically being the #1 issue. Windows removed legacy support for many things and you'll need a compatibility layer, known as a DirectX Wrapper to bridge the gap. There are many such wrappers around as this issue is not unique to SC4, but generally dgVoodoo2 is the easiest for most users to setup, see here for details:

Right, but this isn't the Real World, it's a videogame which means it was coded to simulate the real world, so not all logic from real world applies. So, if you don't want your forests to attract crime and other things, plant them with the God Mode and Mayor Mode tools which are intended for this purpose.

Hence I used the qualifier, 'In Theory', because the general consensus for years was this was the only problem, but that simply doesn't fit with the facts we know. See when you say always, first thing that pops into my head is, you don't have Prop Pox, you do have a problem, but it's not specifically Prop Pox. Again, every time someone comes across corruption, the first culprit is Prop Pox, but often that's simply a misdiagnosis and when you make assumptions... File corruption is not fixable, you might remove the corrupted data and somehow reformat it such that new data can not be corrupted again, but there is no way to fix the broken parts. Imagine you've a 3m MP3 file and 2% of it has gone bad, whatever you do that 2% is gone forever. How can a computer put that data back together if it doesn't know what sequence of 0's and 1's are needed to do it? So if you obliterate a city, rather than create a new one, the latter of which actually creates a brand new save file, I suspect that might be your error. The corruption remains in the save file and so it keeps coming back eventually. Not one of the three things you list has ever been connected with Prop Pox, ergo you probably don't have that and troubleshooting the wrong fix ain't gonna help you. I can show you large cities full of farms, nothing about that is an issue for the game. Certain lots may be affected by your problem, but that's not in any way connected to the cause. Heck, even with the BDK it isn't Lots causing the problem, it's Props from a dependency file. As for street styles, that's just a texture change, literally couldn't be less connected with the problem you are having. Right but you are playing whack a mole, which should tell you your efforts in the long run are futile. If my car had the same consistent fault that no matter how many times I had fixed it, kept going wrong, I'd replace my car. In the same way, I think you might need to accept this city is toast and move on. The save file size changes because you are forcing it to switch between a compressed and uncompressed sate, the latter of course would be larger by its nature. But you aren't fixing anything, you are just shuffling the data and setting yourself up for the next time the data gets compressed and things inevitably go wrong again. What is behind all this?, couldn't tell you, it would take a ridiculous amount of investigation to find the root cause. What I can tell you is that this save file is toast and you should start over. If this issue happens with multiple cities/save files, yeah that sucks I know. It doesn't matter that a DLL solution exists, if you are using the 64-bit Mac version you simply will NEVER be able to use it. Blame Apple, in the name of security it is not possible to side-load code under MacOS from Catalina onwards. So, either Aspyr have to adopt and validate said DLL and incorporate it officially as signed code or Apple have to reverse course on security in MacOS. Since no pigs are flying around, you might have a long wait for either of those things to happen.

In fairness these two things have nothing to do with each other, one on hand you can never use a save file once it's been saved using the 64-bit version, with any other version of SC4. But on the other, using the native Mac game means you can not rely on the SC4Fix.DLL to prevent the problem from occurring. In reality most people simply should not find themselves affected by Prop Pox, as an issue it has always been over-blown, granted because IF it happened it was pretty catastrophic. But it's nowhere near as common a problem as it has been made out to be, there were a lot of politics surrounding it and it was weaponised by some. Shit if I typed that sentence 10 years ago, I'd probably be insta-banned for having done so, which only serves to illustrate my point really. Many people also mistook other problems for Prop Pox and I would go so far as to say, many other instances of data corruption all got lumped in as Prop Pox, amplifying it. In theory, provided you aren't using content in your Plugins that trigger the issue, then you should not suffer Prop Pox. The one file that was identified to trigger it has long since been updated on the STEX, so make sure you aren't using an older copy of PEG's Beach Development Kit. Of course, it's not really that simple and based on years of posts and feedback, it is very clear that others have managed to get Prop Pox, without having any known 'trigger' files installed. I've always maintained something else is at work, but no credible efforts were made to look into it and in my view, a large part of why is that it suited some to pin the blame on the Pegasus team. I'm not gonna dredge that up again here, but the Prop Pox thread on SC4D is a wonderfully boring read if you want to go through it yourself. What I can say is that the DLL absolutely seems able to both prevent and fix the issue, should it arise. But that's never going to be an option for Mac users, so either run the Windows game or accept this is one of those things you can't control. Logically, there must be other files out there that trigger the problem, because folks who never had the BDK got Prop Pox, multiple such instances have come to light. But because it was never determined what other files might be a problem, you can't know what to avoid. Personally, I also feel the nature of SC4's method of saving is prone to the potential for problems, ultimately it's data corruption and it seems unlikely to me that this is somehow inherent to one specific property being altered. What SC4Fix does is alter the way the save data is created, avoiding certain ways that could corrupt your data. Frankly speaking there really isn't a 100% foolproof way to protect yourself against the problem unless you use the DLL, which for the Native Mac port simply is never going to be an option.

Basic steps are: Use FSHxDAT to extract all the FSH textures from a given model, for your first try it's simpler using a single SC4Model file. Convert those FSH files into BMP. Use the Adjust Colour function to change the Night setup as desired. Convert the adjusted BMPs back to FSH. Import the new FSH into a DAT. Load said DAT after the original file to test the changes. If everything worked, you can directly replace the original FSH with your modifed ones. Either by DATPacking them together or manually doing so using Reader.

It is not, the worst that can happen is corrupted or broken save files that can not be recovered by means other than a backup. But if you can't restore the Plugins folder to match the backup save file, that won't save you either. I have spoken about this before and whilst it's really hard to pin down a specific set of do's and don'ts, the bottom line is doing this is rolling the dice. Whenever you edit items that exist in your save files (cities), including installing mods that do this, the only safe method is to remove existing instances from your cities, before you add the changes to Plugins. Which is in and of itself quite tricky to do and easy to miss something, once you save the file once with a mismatch, that problem is now 'baked-in' to the save data. As someone who mods a lot, I quickly learnt if you are going to be messing with files, only do it in cities you don't care about. Even being super-careful, I've a couple cities that are effectively broken because I messed up or missed something. Can you mostly get away with doing this?, sure it's totally possible, but ask anyone who tinkers a lot and all will have lost cities at some point.

Generally speaking most monorail content is built by simply dragging the monorail tool, the only ploppable or puzzle pieces are limited to the L4 or High Elevated monorail and some special pieces for crosslinks. The vanilla game (without NAM), does create a roundabout when you cross NS and EW lines and make connections between them as tight as possible: In fact, you can also do the same with both regular rail and elevated rail networks also. However, NAM removes this setup because it's totally unrealistic for rails, but orders of magnitude more so for a high speed monorail line. In short its very unrealistic and was felt the inner roundabout should be altered just to make diagonal connections instead.

It's the NAM.DLL which is part of the NAM 50 Beta release, which is only available through SC4Pac currently.

@JulianMIA So I think we first discussed this issue in like 2018, sorry I couldn't respond when you last brought it up. Anyhow, I can't be sure it will help, but I have found a few alternative properties that are very similar to those used in a Foundation Exemplar. Specifically the two highlighted, seems to give an alternative option for Top Textures, which presumably is another Axis from Side Textures? Not sure if you want a second set of textures for it, I just copy/pasted the properties to make a screenshot. Anyhow, when I came across this I immediately thought of your problem, at least it's somewhere to start poking around.