vortext

cp made interchangeable sets of textures for a variety of sidewalk mods. This is the entry for the vanilla sidewalks, in the description is an overview of all options. Could be interesting for this project.

Thanks for confirming pollution isn't it. Uneven terrain seems a likely culprit indeed. @Daeris maybe worth to try to smooth out the seabed and see if that makes a difference. And yeah, with the benefit of hindsight we probably should've made a more condensed set with a few premade 'show' pieces, so to speak. Ah well, be it as harbor or walkways it's nice to know it's still being used.

hi @Daeris, pinging is quite alright, I still lurk in the background (or rather I still have email notifications ) As for what the issue is, contrary to @SIM-ple Jack I don't think that's the waterbug actually. Reason being it's such a prominent and well known issue I'd reckon it would have surfaced way sooner. Like, we'd likely be aware of it in the early stages when discussing the feasibility of the project. Then again, I could be completely wrong. Been so long since I played, the ins-and-outs of particular game quirks (of which there are many) escape me at the moment (and don't even have it installed anymore so can't do a quick check). Out of curiosity though, how does the (water) pollution look like at that spot? Just one thing that sprang to mind as to what could have a graphical effect on the props.

hi! got a PM from Barton over at sc4d, great to see people are still interested in doing historical accurate builds, as much as the game allows that is. Just checked some backups, and seems like I may have some unreleased props tucked away. Most are just bits-and-pieces, e.g. walls, some workers which I'm not sure actually made the release and couple of small buildings, including a tramstop. Sadly the horse drawn tram never made it onto the dropbox. Krashspeed was working on it when he shared that picture. That's also the reason those items I mentioned were unreleased, most were not up to Krashspeeds' standards. Though honestly they were rather decent already, he was quite the perfectionist. Now onto the cobble stone roads discussed in @CT14's thread, and asked about in the pm. First of all this picture was just concept art really, and I only got around to a (half baked) implementation for roads. I have found an alpha version and have attached it to this post. Please note I have not looked at it (no sc4 or tools installed) though iirc it's missing some tiles, has only few proper transition tiles to the default streets and there's no wealth grasses or anything, just the bare road surface for all wealths. In other words, your mileage may vary. Interestingly I also found all the .psd source files, which iirc Noah actually used as a basis for various cobble stone tram networks of his own. In that regard he made a lot more progress than me, though I don't know what the latest status is of his works. Finally I should mention for a historic city you may also want to look into SimPolska buildings, various barns and walls especially should fit right into any historic era really. vrtxt cobble stone roads b7.dat

Are you kidding me, this is just SC4 with some low-fi filter applied in photoshop, right?! What's next, around the world in sc200?! Fantastic set of pictures, excellent really!

Neither term rings a bell unfortuantly. However I noticed it seems like you're using one of CP's terrain mods, which are not suitable for seasonal flora out-of-the-box, and require installation of the Seasonal Flora Patch. Do you have this installed in this test city, or otherwise adjusted the Flora Tuning Parameters? Thing is this timing mechanism initially was intented to simulate forest growth over time, and consequently Maxis introduced some randomness into the cycling over stages. Otherwise a sappling forest planted at the same time would continue to grow in lockstep which arguably looks kinda silly. However for seasonal flora to work this randomized update pattern is undesirable, and figuring out how to enforce 100% updating of the flora during each cycle actually was the breakthrough which made it possible in the first place. As you might have guessed this is done in the Flora Tuning Parameters. The discrepency in appearance vs cycle date seems to echo the randomized updating that occurs with vanilla settings, versus patched setting necesarry for seasonal flora to properly work.

Seasonal versus evergreen flora examplar files differ in which Resource Key Type (RKT) it uses. Simply put evergreen flora reference a single model by means of RKT1, while seasonal flora examplars references 3 models by means of RKT4. The timing itself is controlled by the Flora Parameter properties in the examplar file. Note this property is always present but obviously isn't used when the flora examplar file contains RKT1. Before continuing it's important to realize the notion of September 1st, or any other date for that matter, is by convention. Or to put that another way; the timing mechanism relies on counting the number of days passed since planting date (in a roundabout way), and progressing through the models referenced by the RKT4 untill the entire cycle resets. Now for the technicalities, this is going from memory but iirc it works as follows. First of all the order in which the RKT4 models are shown is determined by the first rep for their entry. (in bold below, example is Grfe_norway_maple_seasonal_A) 0x00000000,0x00000000,0x00000000,0x00000000,0x27812821,0x5AD0E817,0x9C03BDEF,0x00030000 - 1st 0x00000001,0x00000000,0x00000000,0x00000000,0x27812821,0x5AD0E817,0xBC03B8A4,0x00030000 - 2nd 0x00000002,0x00000000,0x00000000,0x00000000,0x27812821,0x5AD0E817,0xBC05058A,0x00030000 - 3rd This is important because the first rep in the Flora Parameters property determines the duration of appearance (in days) for the last RKT4 entry. The overall duration is determined by the 6th rep in the Flora Parameters. The duration for the other 2 RKT4 entries are determined by subtracting said value from the overall cycle duration and dividing by 2. So for seasonal flora the 1st rep in the Flora Parameters typically is 180, the 6th rep is 363. So this means the last RKT4 model will show for 180 days, leaving (363-180) / 2 = 91.5 days for the other 2 entries. Now obviously the game doesn't do halve days but the flora update interval isn't that exact to begin with so that's okay. Now a slightly different example; the vanilla noble fir mmp. While technically not 'seasonal' it uses the exact same timing mechism to simulate growth over time. The 1st Flora Parameter rep has a value of 1200, the 6th a value of 6570. So this tells us the overal growth cycle will last for 6570/365 = 18 years. And because this uses RKT5 the first 2 models will actually last 1200/365 = ~3.25 years each, meaning the last full-grown model will be on display for a little under 12 years. So all this to say; the dates involved don't really matter and are a semi-arbitrary convention, which was arrived at by lots of experimenting when seasonal flora was developed. The game instead seems to keep track of 'days passed since planting' for each flora item, and uses that day count, in combination with the Flora Parameter property, to determine which model from the RKT4 it should display.

This is very exciting, opens a whole new avenue of modding to explore! With regard to mixed use, perhaps the following property is also worth looking into. Allow Joint Occupancy 0x2781286 Bool if true different types can occupy the building simultanously note it seems to apply to buildings, not lots themselves, so I guess a building examplar should define multiple occupant types and have this property be true. Whether or not the simulation actually does anything with this.. anybody's guess atm but given the success of converting ploppable res into growables worth a shot.

Been seeing your pictures in various 'show us your...' threads for a while now so figured it was time to drop by here to say I positivly love the distinct and unique Santana style of development. Keep at it!

Thought I'd add my two cents. Regarding changing the world it's rather simple imo even though it sounds incredibly cheesy; be the change you want to see. Or to put that another way; in order to change the world start by changing yourself. You want the world to be more positive, so be more positive yourself. Be kind to people, don't rush to judgement, have patience with yourself and others. As for how to start coding; honestly the framework / language doesn't matter as long as you learn the fundamentals first of all. How to structure a program, how to use interfaces & classes, how to use callbacks and events, etc. You learn this best by picking something you feel most comfortable with. Personally I actually learned coding with Processing because it offered such a clean and clutter free environment to work in compared to other, full fledged IDEs (which scared the crap out of me at the time). Fast forward a couple of years (understatement ) and now I work as data analyst / developer for my day job and use C#, Javascript, R, Python, Java and most recently Kotlin (not to mention data query languages like sql, graphql, mongoshell and general purpose stuff like powershell, bash, rst, plantuml, etc). Do I know all the ins-n-outs of every language and framework? Of course not! However, about 95% of skills you pick up learning a single language can be applied to other languages and paradigms (debugging for instance is such a skill). So find something - a language, a framework or project - which satisfies your curiosity and can hold your interest for long enough to allow for in depth learning. Don't be afraid this will pin you down because as I said, most of the skills you develop during this period will be applicable to coding in general later on.

Kotlin is developed by JetBrians, same company behind Intelij IDE (available here, community edition is sufficient) so I'd recommend using that since it comes with full Kotlin support - though language packs are available for other IDE as well, e.g. Visual Code. Also helps that Kotcity is pretty much configured for Intelij, so you can easily import the project and get up and running in no time.

If it's realism you're after I'd suggest implementing a mixed building type as well, i.e. ground floor for commercial, upper floors for residential as that's quite common. Could be designated with a mixed zone, or perhaps with a policy setting of sorts.

Ah yeah no, I see what's going on now; got confused by the 'time out' inside a tick, like is the case in the liquidator & contract fulfiller classes. Fair enough.

Hehe, I'd like to think of perfect as the muse of good. At any rate, got the project running in intelij and will have a more thorough look at it later, however, at first glance I'm a bit puzzled there seems to be multiple time keeping mechanisms? Is that correct or am I reading it wrong? Also there doesn't seem to be any actual population underlying the simulation as the number is calculated from labour, however, not every person in a population will provide labour (e.g. childeren, eldery, etc. Of course the numbers can be fudged later on a la simcity2013 but yeah, YEGH indeed).

he, must be something in the air these days as over the past week or so I've also been working on a simulation engine written in Kotlin! Mainly as an exercise to learn the language really, and as such is nowhere near the level yours is at. If interest I've uploaded a snapshot to github. Actually repo is private on gitlab because it's very much in flux and, well, I'm kinda embarrassed to share it tbh. Also don't have a build system or anything, however, for those interested I've uploaded a runnable jar to dropbox, available here. Please note the gui is just a glorified debugger at the moment, so please lower your expectations accordingly, and then lower them some more. At any rate, double-click the jar file and small window should appear. Then make sure the window is in focus and press p to make time run. Then a bunch of nonse will scroll by rather fast, which represents the population of no less then 2 (!) persons working on some rather generic tasks. All this to say it's a really cool project and I'm excited to see where it goes!

yep I can attest to this as I induced prop pox in a region with solely custom content of my own making - so I had only myself to blame. .

@simlacroix the mountain lake is done with JENX' Poseidon water effects. @JurisicSantiago the region is an amalgamation of various other regions and thus not available at the moment, I'll look into how much hassle it'd be to prep the files for upload.

For once happy with how it´s shaping up, took me long enough.

He, no, sorry I meant the automata settings ingame! Specicially the #Cars/Sims settings, found under Graphic Options. I never bothered with the Automata Tuning examplar, though I'm curious if you can actually find a more permanent fix that way.

no magic pill, I just set the automata to low and indeed nix the rkt for all other pesky things like garbage trucks, mayor limousine etc. And if all else fails there's strategic picture taking and photoshop.

Yeah Xannepan's terrain paints are pretty amazing alright. To clarify I did not make new instances (which would require editing the effects dir) but rather simply replaced the textures to suit my own needs. From memory it was a pretty straightforward, i.e. get some textures (preferably 1024x1024, or 512x512) apply a noisy circular mask to them and turn them into fsh files with whatever tool you prefer - and of course make sure the fsh have the correct TGI to actually replace the originals. The sand mmps is pretty neat, I've always liked ionionion's Filling Gravel because of their large surface area while not covering everything completely. Yours look like a welcome addition to that concept.

Closest I found to heather is the purple bonnets in RRP pasture flora, or *cough, shameless plug* the seasonal variant in my mmps pack.

yeah using RKT4 to offset props will result in shadow issues, you're better off using SC4ModelTweaker to offset the actual models. Other than that it looks pretty good to me, so maybe don't throw the towel in just yet!

Well, the only enabled terrain texture table is called 'TropicalTextureMapTable', and based on the odd moisture patterns, which has been noted before, it's been sort of understood that apparently the hydrology simulation is tropical as well. Hopefully less confuzlling now. Oh and in case anyone is wondering, the other Texture tables are called Desert, Temperate and Artic respectively.

No I dont think so. Rather it's that the settings in the ini file seems to pertain to (regional) rendering, rather than the running simulation ingame. For instance Lowkee's Apalachian terrain mod offers an erosion setting, which makes for smooth region rendering (i.e. without any visible seams along the city tile borders). However it's mostly unknown what effect the other ini settings have, let alone how the simulation would make use of them.