Francis90b

@CorinaMarie A Dos-based program would do mightily fine indeed! Please share the script once you think it's in ok-ish form, I would like to take a look to see how it works .

@CorinaMarie I imagined that by using Excel converting a position list to the desired format would have been doable (if one is a bit careful). Nor I mentioned that the footprint of everything someone wants an overlay for within a given city tile will need to be traced down on on a 1 pixel=1 tile representation of that city tile, using a single RGB combination. Both seemed straightforward, making the issue of the middle link between these two phases even more glaring. What I stumbled upon is just a script for Wolfram - don't even know for which of the gazillion of softwares they have in their suite that script is for. But perhaps there's a way to do a script that's accessible and easy for the general public? Whatever script might be used to generate the position list, though, it will need to do the following things: 1) To load the image. 2) To cycle through it, looking for every pixel which has a specified RGB value. 3) To record the position of each pixel identified in that way and 4) To print out the position list.

@CorinaMarie Sorry, I didn't provide Bendyburg as an example of something I would like to do. I provided it as a typical example of a situation in which the autoplacement method might not necessarily be effective unless some way is found to automatically mark down the position of the pixels intended for autoplacement. What's there so far (thans everyone!) helps with grids made up by orthogonal segments. Defining a grid of paths spanning a large city tile, with a N/S or E/W path every 1024 mtrs (64 tiles) just take eight lines. However, defining a single diagonal running NW to SE would take 256 lines....which someone would need to write, one by one. With something like "Bendyburg", writing a list would be downright insane - unless the list of pixels actually exists- With no ability to generate that starting list, one would actually do things much quicker as they had always been made. But "Bendyburg" is the representation of a fairly typical real life scenario. EDIT: Wolfram does it. How, i have no idea. And I have no idea about how it might be done with other tools.

Thanks! For the sake of general discussion I've been wondering how the DLL might react if it is instructed to run autoplacement on the same tile withinin the same set of instructions or in two different sets run at different times. In the example below I'm making a nice little cross: "Placesomething" 3 1 3 5 "Placesomething" 1 3 5 3 The tile that would appear twice is 3 3. I surmise that DLL should be able to handle this without crashing. But I can't rule it out entirely. Can someone confirm that it will keep running? If it does, the following might happen: - Same tile *and* same zone specified: the DLL will run the first line and the second line, and the tile will be zoned once, according to the first line.The second line will be run, but given that the zone it specified was already present on that tile, there won't be any change. - Same tile *and* a different zone specified: the DLL will run the first line placing the zone specified there, then the second line where a different zone has been specified, replacing the former. -Same tile, a *zone* specified in the first line, and a *network* which would obliterate it in the second line: the DLL will run the first line zoning the tile, and then the second line, replacing the zone with the network. -Same tile, a *network* specified in the first line, and a *zone* in the second line: the network won't be replaced. - Same tile, two networks which can intersect each other: the DLL will place both, creating the intersection. -Same tile, two networks which cannot intersect each other (e.g. ground highway and railroad): a) the DLL will place the network that has been specified first *but not* the latter one or b) the DLL will *replace* the network that has been specified first with the latter one - which is the case? This, as far as general musings are concerned. There's a lot of potential in using the DLL that way: if someone had the map of a real terrain and knew the precise coordinates they can also extract a map view from Google Earth or similar, trace down what they want to recreate in game, and use the DLL to do that. That will be someone's gold, i'm sure. But that brings me to the other half of the issue, so to speak. Writing down paths on the text file is cool... PlaceZone 8 25 65 25 65 (point) PlaceZone 8 25 65 25 95 (line) PlaceZone 8 25 65 29 95 (bounding box) ...but finding some other way to do it might be even cooler for non-griddy situations. Take a look at this example, the little quaint Bendyburg: The blacks are the intended position of roads, the whites everything else. Almost no straight segment there: not really practical to write it all down as a set of lines and points, is it? I wonder if there might be some tool that might help to list every single pixel possessing a given RGB value? If there's any way to do that, the list can be used to create placement instructions for the DLL. And it wouldn't matter how convoluted or messy a pattern is, it would be replicated reliably....even Bendyburg.

Thank you very much for the updated version! I was somewhat aware of the DLL's existence when postimg my inquiry, and wondering if it could help somehow. "PlaceZone" seems exactly what I was looking for, more so than "PlaceNetwork". The difference being that while placing a network on a tile would flatten it, placing a zone shouldn't necessarily do that - except when the ground is significantly steep. Someone might choose to use PlaceNetwork to mark down specific intersections or relevant points: flattened/altered ground wouldn't be an issue over a single tile. But I was looking forward to establish contiguous "ribbons" of marked tiles following the path of planned roads. Placing single network tiles along a contiguous path effectively flattens the terrain along that path - great for terraforming, but not necessarily desiderable in this case. Placing zones (i'm thinking industrial) - would minimize that effect. This is how I imagine it ought to look like: [EstablishedTile] RunOnceCommandList= File:(path) Then, within the file: PlaceZone (zone type) (tile coords) Therefore: PlaceZone MediumIndustrial 25,64 PlaceZone MediumIndustrial 25,65 (snip) PlaceZone MediumIndustrial 36,44 PlaceZone MediumIndustrial 36,45 Etc, etc. Did I get that right?

Thanks, @matias93 ! I considered , and taken into account, the opportunity to run the road-laying and mapping process as a multi-pass procedure, checking in-game if the alignments I drew are suitable in practice as they should be in theory, and revising the map if I find that this isn't the case: I composed the non ortho section by putting together the footprints of puzzle pieces, which should imply that if I lay them correctly, they should work without adjustment, but the terrain, as you can see, is far from being flat. Hence it might well be that there is some excessive steepness within the path of a road, and that a certain bend which I placed at some point, maybe to avoid a small buff, ought to have been placed further or earlier on the road. Or that a certain path might look doable on the map, but like an exciting rollercoaster when implemented into the non-flat reality of the game. I should clarify that I do not plan to recreate the real Saint Paul, and my map has been edited and distorted to suit my vision. I took note of the method you developed for overlaying Simcity4-excerpted map views on Google Earth, and appreciate your mention of it and the careful explanation you provided at the link you posted. However, I'm afraid it might not be of much use in the specific situation i'm in. I've been wondering if there's a way to instruct the game to plop something (for example a single tile of industrial zone, or a water pipe) on a given set of coordinates within a given city-tile, and to automate that process to some extent. That way, it might be possible to generate the equivalent of an overlay, which I can then use to place roads.

G'day, I've been thinkering with the idea of developing a whole region by laying down just the transportation infrastructure, without building an actual city, similar to how it's done in some "roadgeekery" CJs. For that purpose, I've been tracing every road I intend to lay inside the game on a region overview I have gotten from Terraformer - please see first image. There are non-orthogonal or winding stretches of road, and for those I took note of the footprint of the puzzle pieces I might need to recreate them, and checked that the combinations I need would be doable in game without modification. Many more roads will follow, inclusing some rather winding ones - the second image kind of gives an idea of some I would like to incorporate in the road grid. That's doable too, just by doing what I've been doing. I'm now concerned with finding a way to translate all of that planning into the game, individual city tile after individual city tile, following an efficient and reliable method. In Cities skylines that is definitely possible - an external image is overlaid on the terrain map, and roads can be efficiently and accurately plotted from there. Alas, this is not as straightforward in SimCity4. Common sense has it that I should take careful note of the position of every interection and every non-orthogonal segment, and work methodically from there - which is what I intend to do. However, I understand that this method alone might not necessarily be the most efficient, and might not grant sufficient reliability. Sure, in some cases erring 1-2 tiles might not represent an issue, but in general it would be far better if I can make the roads I plotted on the overwiew align as intended. I'm looking forward to more insight from someone who might have found themselves in a similar situation. Thanks in advance. PS: The map is an excerpt from Drunkapple's /Dobdriver's beautiful "Minneapolis" map, with further edits. I might attach it upon request, if it is possible.

The following images come from the stunning Gransintemango: I adore all the vegetation it uses - but unfortunately I don't know much about what's available out there as far as vegetation goes and thus I'm not very good at identifying what's what. Perhaps I might ask there to get some help finding the answer? Thank you.

I'd offer a further alternative. The 1916 zoning resolution stated that when a building was built on a corner plot, and when the two sides were subject to different height limits, the designer could adopt the more generous of the two height limits to the side that would otherwise have been subjected to the more restrictive one, and that within a maximum distance of 150 ft (45.7 mtrs) from the corner point. Looking at your model, I would wager that the real building was built following such rule, and the recessed area (on your model's left) marks the beginning of the zone where the regulation loophole i mentioned wouldn't have been appliable anymore. Then, the architects added a specific twist - a recession as deep as the one present on that building wasn't really necessary (it could have been a standard wedding cake facade as in the rest of the building, the setbacks just needed to start slightly lower than they do on the rest of the building), but by creating it the architect improved the access to light in that area of the building. Being that 46.4 mtrs (the frontage on the 3 tile front) isn't much more than 45.7 (the 150' allowance), i'd say that, for SimCity's sake, these two might be considered as equivalent. In your case, that would mean to chop off the leftmost area. The advantages would be that it might be an easier approach to follow, and would result in much less (and hopefully no) shrinkage to be applied anywhere, the disadvantage is that it would deprive the building from a rather interesting facet, especially in SimCity's perspective. I already intended to mention it, but i believed that it wasn't really an option...but, for the sake of completeness, i reconsidered.

Crate&Barrel is turning out pretty well ! I really like the wooden pergolas, they're a nice touch. Are the windows and doors meant to be flush with the facade, as in this case? Or are they meant to be recessed from the facade line, even by a small amount, like there (please look at the brown rowhouse on the picture's left, the one with the orange windows)?

Wow, this update has been a wonderful surprise ! The model is impeccable, everything looks spot on. As far as your dilemma goes, i'd voice my support for the 46.4 mtrs option. In any case, a 51.8 mtrs width is just enough to go above 3 tiles in width (48 mtrs maximum), but not nearly enough to fill a four tile width in any satisfactory way unless you incorporate some filler model, either by looking at the would-be adjacent buildings in reality or devising some of your own. As to how to apply the shrinkage, you might either just rescale everything down to a certain percentage, or consider every element of the building insisting on the excessively broad side and reduce it by a given amount until you reach the desired result. The latter approach may be more time-consuming, but might allow you to play with facade elements (i.e. windows and piers within the tower) until you can find a balance that is perfectly satisfactory to you - you might even, for that purpose, reduce different elements by a different amount (e.g. "i'd reduce all piers on that side by 0.1 and all windows by 0.2"). There isn't much difference between the two approaches in the end - if you believe that the first one is too "crude" or doesn't satisfy you in the overall "feel" it delivers, you can experiment with the latter, "localized" approach. Architects actually resorted to these strategies when confronted with the issue of fitting an elevation they devised into a street frontage that was slightly too wide or too narrow.They even implemented that deliberately, for example to help adressing the issue of corner plots having a significant difference between the two street frontages. A good example might be found in Liverpool's Oriel Chambers: https://external-preview.redd.it/TyJSGz2ks6Qy1484SyRwsPUeH_ReG9Pdywk-vstnW6g.jpg?auto=webp&s=41a68f2233fd8e8412faaa3973f979ff368d7fb0 The stunning oriels defining it are in relation with the width of the building's facade at each side, and in this way they make the context work with, and not against, the architect's idea. And a Manhattan-specific one might be Warren & Wetmore's 366 Madison avenue: https://42floors.com/images/H1de5fd2e6c5d47039eeea379b510fd27b3b75808S780x520W0seB505153O/36f89df9aaebf177d7977d8004219bfea34d17ed I believe that, if implementing them might represent a slight deviation from the letter of the building you're trying to represent, they would not, in and by themselves, undermine the connection between your model and the essence of tha building, or any building in general, which is the result of an idea and the circumstances in which such idea found its implementation. Whatever your decision might be, i hope to see more .

Really nice design! To me, they look more as a modern interpretation of prewar twin towered specimens, more similar in "feel" to The Kent (200 east 95th, being built right now) than to the Century. Personally, i feel this makes them even more valuable - in reality there's some kind of enduring fascination for historical styles, and that generates buildings which, for the better or the worst, are part of nowadays urban landscape...having more examples of that on the ST can only be a good thing.

I'm looking forward to see how the skylight well will lit up at night :). Jasoncw is right, there's a common standard by which BATs which are supposed to meet the sidewalk straight away are set back one sidewalk tile (1.6 mtrs) from whichever side of the LOT where a sidewalk is expected to exist.Oh, and there's also a standard dictating for 3.2 mtrs setback, but that's much less frequently used, afaik. There's a silver lining on that, though, because several corner buildings in Manhattan have one, or both sides being 100' wide, 100' is equivalent to 30.48 mtrs, and then the usable lenght of 2 sc4 tiles next to a corner, assuming you're using the 1.6 mtrs sidewalk standard, is (32-1.6) 30,4 mtrs. I didn't know the original base was smaller than the "new" base the tower ended up with...had to dust off a pic in my archive to notice it . Both the towerless version and the original base would bring something interesting to the game. The towerless version might probably be quicker and easier to make, as you'll "just" have to remove the tower and fill the resulting gap with a roof.The "old" base will also require you to surgically remove the three floors which were added in the middle of the "new" base, and to check wheter the "narrower" side of the "old" base can actually fit within the constraints imposed by SC4 grid without leaving too much of a gap. And you're way too kind as far as my random musings about buildings are concerned .

I really like the example of a melody's notes - time as a neutral void, within which episodes of awareness occur, irrelevant and essential at once.These episodes, as they happen, become detached from the very matrix which allowed them to exist at all, and still they're the only way we might be aware of it.And their perception is entirely subjective, based on the relevance one attributes to them. Under this light, quantity-based time standards can be regarded as they are - a clearing house between individual perceptions, nothing more than an universally accepted fiction. And the set of questions the OP chose further reinforces the essence of perceived time as being an interplay of fictions experienced at individual and collective levels, strictly linking it to the ethical dilemma of how to balance individual and societal expectations...quite a vast topic to deal about in it's own.