@caracol @Shiggs @Doctor Machete
I'm sure they did use constants in 90% of the places, it's just that they get compiled away in the msil that we have to read back from.
It's more than that though its not just 32k to 65k type change, there is some other stuff (some other grid arrays, some of the 'update arrays' like updatedsegmentgrids that needs to go from 512 to 1024 because of some the fun bitshifting math they use in places (or at least bitshifting per how the compiler spit it out), though it's basically still mostly itemsize * 2, but not always, and for added confusion 65535 is used as by them as a special flag in some places as an empty\uninited value..sigh...I'm looking at you Render-Manager.
As for why the Uint16's or uShorts that's obvious, save memory(though not necessarily processing cycles on modern hardware), when dealing with a boatload of arrays in this game it does add up, secondly there are a loooot of loops where they process the whole array many time in a very short period of time, doing this 32k times, not problematic, doing it 64k, eh not that bad, doing it more then that...all over the place... hmm I don't know. So 25 Titles\65k grid with 65k limits for these items I'm screwing with should be supportable on systems north of the bare-minimum specs, as for 81 Titles and like them (C\O) going back and reworking all these 16bit arrays to 32bit... forget it, I doubt that even in a big-update, not only is that a boatload more work (it's one thing to up present counts and adjust it current int type maxes, it's a whole other to go back everywhere and change things to ints and array32's), but even the latest and greatest computer may start having issues going beyond 128k item levels if it's done for everything and with their current architecture. Maybe in CitiesSkylines 2.0.
Btw as for progress.
I have them increased (and working atm far as I can tell) for roads, zoneblocks, buildings, paths,(I could do trees but not bothering yet), path-finding, and electricity (why electricity... it's complicated but most systems that hold references or access zone\roadnode,roadsegment\block etc need to be similarly tweaked). I'm focused at present on the roads (nodes\segement\lanes\)\Ped.paths part as my testmap setup is best setup atm for that.
I've modified the the load\deserialize routines to be able to read in existing (v206) saves and adapt accordingly so far for the above items. I'm guessing soon as I touch pumbling\sewage something will pop up needing fixing in that area.
currently working on: The rendering updating\colormap and colorlevel calls updating is what I'm presently working on (presently for road items), there is some massive array that holds the info for this stuff in different parts (ie 0-32k used to be buildings 32k-65k used to be segments and 65-98k used to be nodes), that need adjusting to 0-65;65-131,131-196 etc. I've bumped the values up, as well as the associated RenderInsist calls to use the new wider ranges but at present my roads (though working) have blue\pink spots on them and custom-road prefabs stopped working (or at least the ability to place new ones), that first problem I think I know whats wrong, the second about the road prefabs not working....I don't know yet wtf that's about, probably something easy, almost everything has been....once I actually trace things down to the root problem.
next up: well every time I think I'm close I find an new array bounds error in something I didn't think needed changing so I probably still have some things to work though that I don't know about yet. Baby steps.
After that:
When I think have something semi-stable I'll post a version for maybe DocM to try (without the ability to save yet enabled) or some other brave souls. Then Probably go back through set all my logging flags to 0 or just remove the bloaded debugging code I added and go back though the various serialize functions and make sure saving will work and bump the file format version number to 207 (my load code for v207 already exits). (hey so it would be cool CO if you're reading this to use 208+ as your s.version number! lol yeah I'm not counting on it)... I also have to probably go back and tweak it for the map editior as it is now I only have it for sure able to load an existing v206 map created with the original 1.07c dll.
As soon as that's done C\O will probably put out the next update ...undoing everything. lol But that's ok I'm just playing around with this till then - I will not be trying again after the next update, re-doing all this again via assembly editing\reflexIL ain't gonna happen.
I wish I could do all this as an actual mod but some of the stuff I'm touching isn't touchable that way (and I don't think really could be), not even via injection\redirection as I'm touching private class level items, like the lane deserialize routine touches class level items, even if I inject my own routine I can't touch certain class level private items that it touches from inside there, not without jacking up certain attributes for them in the assembly anyway.
It's fun looking through some this stuff though you can see in the serialize and deserialze function at what version # certain features were added so it's sort of a chronicle or timeline for the development of the game, with that in mind I can tell you the limits for some of this stuff were bumped from 16k to 32k along the way, some of it much later in development.
My present screen as I write this:
~35k road segments (~32,050 on map load then added); show you my current colormap\render issue.
http://imgur.com/sLEkSTJ
edit: Solved that road color issue and the prefabs (was related), on to traffic info map(colors) not updating for new segments and then on to electric and water.
