-
Announcement
-
Simtropolis Returns! 05/26/2026
See here for details about our site recovery efforts.
-
Search the Community
Showing results for tags 'conflicts'.
Found 4 results
-
Testing Seaports Potential Conflicts / Ensuring Functionality
hi_density posted a topic in SC4 - Custom Content
Hey all, I have a question about Seaports. I've gone crazy with mods and packs after discovering this whole new world of SC4 through Rob's Red Hot Spot. Anyway, after really loading up on goodies and spending tons of time installing them I have started to finally understand how things work and are organized to a decent extent. Now, here's where the potential problem is... I dowloaded and installed the BSC Functional Seaports at the beginning of my learning curve. I have Peg and BSC Seaports installed and essentially I want to know how I would go about testing my setup. I have all dependencies, I am asking purely about ensuring proper game functionality... -
Playing SC4 recently with NAM 39, I came across the following problem: The rail texture in use under the OWR viaduct reverts to Maxis Rail. Not a big deal, but today I decided to try and track down the cause and came across an interesting discovery. First I jumped over to my Windows machine, using an identical copy of the NAM, the problem doesn't appear. Having hunted down the exact texture ID in use for this piece, I then used Plugins Analyser to find all instances of it in my Plugins folder. NetworkAddonMod_BaseContent.dat Inside folder 1_Core This contains the original Maxis texture that appears by default on the Mac. RealRailway_Textures_Legacy.dat Inside folder 2_Additional Network Features\Rail (RealRailway)\0_Rail_Legacy\5_Legacy_Textures_RRW This contains the override for RRW, the texture you correctly see by default in Windows. Now I can't explain why a folder named 1_Core is loading later than one 2_Additional Network Features, but clearly this is what happens when playing the Mac version. Here is the Root of the NAM folder: For no reason I can pinpoint better than a hunch, I decided to remove the underscores from these folder names: And whaddya know: Now the intended load order is preserved and the RRW texture appears. It might be too early for sweeping statements, but I have the feeling if we remove special characters like underscores, Mac users will resolve a number of load order issues that result in little annoyances like this. I tried switching them for Hyphens, but that just reversed the texture to the wrong one again. I simply don't know anything much about Apple/Linux file systems and how they interpret the order of characters. But certainly, underscores and hyphens do odd things. I hope this helps some others to resolve some issues with NAM and other content. If we can be confident of the exact behaviour, I'm hoping we can find a way to name the NAM folders/files, such that they just work on either Windows or Mac, without any further effort. @Tarkus: Just wanted to alert you to this development .
- 2 Replies
-
- 8
-
-
-
- mac
- load order
- (and 2 more)
-
Hey everyone. I'm wondering if anyone knows why I keep running into a certain problem with item names and user visible name keys on custom props. Basically, I've been creating new versions of existing props by creating new exemplars and using the S3D TGIs from existing prop packs. When I make a new prop, I'll often give it a unique name via the Item Name or User Visible Name Key property. But when I try this with certain props, it seems to not only break the prop in question, but also causes serious issues with the original prop pack. The issue has come up most frequently when I try to create new props using models from BSC Mega Props - CP Vol 02. I'll create a new exemplar, direct it to one of the S3D models from this prop pack (usually, I'll copy/paste the RTK1 or RTK4 value , and assign a new item name or name key. When I do that, the prop fails to appear in game. Worse yet, as soon as I plop or grow a lot with one of these props, other props from BSC Mega Props - CP Vol 02 stop generating. The effect is similar to prop pox, except it's restricted to props from specific prop packs. Originally, I couldn't figure out which property or properties were causing this problem, but after a lot of testing, it seems to be entirely caused by the item name or name key. When I delete these properties, the props appear as they're supposed to, and I no longer have any issues with other props generating. When I add the item name or name key back to the file, the problem starts up again. What really confuses me is that this issue only seems to crop up with certain props, or possibly props from certain prop packs. I've created other props using this method, and assigning an item name or name key doesn't seem to cause any issues. The only difference between the props that work and the props that don't are the RTK1/RTK4 values. Anyone know what's going on here? I've scoured the SC4 Wiki and Googled this issue to death trying to figure out what's going on, but I can't find anything that says certain S3D models can only be used with a specific item name or name key.
-
So Russia intervened, the "kurds" or "kurder" in Swedish withdrew and Turkey accepted to end any hostilities as far as i know so it´s peace for now at least in that area. But that Turkish president Erdogan seems to be a bit on the brutal side overall when using phosphorus on the civilians for example but that will probably not be the end of it entirely if i may take a guess on it. Much like Ireland perhaps where it just is one prolonged friction between two groups and i just say....CALM DOWN! Stop it and put down all arms entirely. It´s not that hard if you want to, trust me. The difficult thing for the human race is to say now in unison when the politicians are ready to let YOU fight. They would never dream themselves to put themselves in harms way, nor the rich. They know what´s what and are no fools. The common man neither, and we have a heart at least. Edit: And guts, lets keep em´on the inside of ourselves shall we.
