T Wrecks

Absolutely. It is not a file on the same level as what you see in your Windows Explorer, e.g., PDF, DOC, EXE, INI, XLS, TXT, MP3 and whatnot. It is a set of properties tied to the building, and it can theoretically be placed pretty much anywhere. It might help to imagine the Explorer-level files of SimCity 4 (.sc4desc, .sc4model, .sc4lot, .dat) as containers, or maybe drawers. If you have a socks drawer, for example, this drawer is not the actual content - it's not a pair of socks. But it holds all your socks, and it helps you to remember where to find your socks. You could also place your socks elsewhere, and they would still be socks, and they would still work as socks. Just like that, the Explorer-level SimCity files are just containers that help you understand what is where and keep things organised. They are actually all in the same format, and their content are the actual files that SimCity uses. Just like you could move your socks from the drawer to a cupboard (and they'd still work), you could move the actual SimCity files from an .sc4desc to an .sc4lot, or both of those into a .dat, and they'd still work normally. Having model, desc, and lot is just an organisation aid for your convenience. It's just a pointer, really: .sc4desc: This container usually holds one building exemplar (the actual SimCity file) .sc4lot: This container usually holds one lot exemplar .sc4model: This container usually holds the FSH and S3D files that make up the visuals of the model in game .dat: This container may hold anything This is just a vague and non-binding convention, though. You could switch the file names in the list above around as you wish, and everything would work the same. You could merge any two, any three, or even all four of them into one Explorer-level file and assign it either of the four extensions listed, and everything would work the same. Yes, pretty much. You can even stack multiple overlay textures, but think of them as sheets (or strips, or pieces) of paper that you place on a floor tile: If you place a blue cross (+) and a red star (*) in the middle of the tile, either the cross will cover part of the star, or vice versa. You'll have to decide which piece of paper goes on top. SimCity can't do that. SimCity doesn't know "top" or "bottom". It only has one level for overlay textures. If you place two textures that overlap each other, sometimes the first one will be on top and sometimes the second one. If, however, you have a thin strip of blue along the right-hand edge of the tile and a thin strip of red along the left-hand edge, these don't overlap. If you did this in real life, using strips of paper on your floor tile, the strips of paper would NOT end up on top of each other, overlapping each other. They would just lie there, and if someone came into the room after you placed them both on the ground, this new person could not answer the question which of the two strips is "on top". The question simply doesn't apply there. It's s non-issue. This is why it works in SimCity, too. A third scenario is when you have two patterns that overlap each other, but both have exactly the same colour. Think of a blue "><" and a blue "|". Place them on top of each other, and you get a blue ">|<". Doesn't really matter which of the two pieces is on top - since they're bot the same blue, the result will look the same. Hence, this also works without drawbacks in SimCity. This information is packaged into so-called properties. Each property is one line of data that belongs to exactly one object - no matter whether it's the building, a base texture, an overlay texture, or a prop. For example, if you place five identical props on the lot (let's say five identical shrubs), the lot exemplar will contain five properties (lines of data) for each of these shrubs. On a lot with four tiles, one base texture on each tile, an overlay textures on two of the tiles, one building, and these five props, you'd end up with 12 lines of data: 4 base textures 2 overlay textures 1 building 5 props The properties are divided into so-called "REPs". These are simply sets of hexadecimal numbers that are used to code the information I listed in my last reply and identify the object that the information relates to. If you translated this information into human-readable text, the structure would look a bit like this: "An object of the type 'prop' is placed on tile A1, in position X/Y, at a height of Z, rotated towards North/South/East/West, and its IID is "0x12345678". (simplified, but it gets the idea across) As you can see, first comes a lot of information that the lot editor needs to display the object in the correct position and orientation, and finally the object is referenced using its unique identifier. This is part of the TGI. The prop exemplar in question will have a Type and Group ID that tell the game it's a prop, and an Instance ID that tells the game exactly which prop exemplar it is. So each and every texture, prop, and building (and lot) has such a unique ID. As long as this ID is listed, the game doesn't care about the file containers. As long as all the bits of data are there, everything will be fine. In the case of buildings or props, you start with a model. This model has an ID. Let's call it the model ID. This model ID tells all other files "Hey, I'm a model, and this is my unique ID in case some other model has the same name." Then you'd create a building exemplar to turn this model into a building, or a prop exemplar to turn the model into a prop. Both of these exemplar files also have an ID, let's call it the building/prop exemplar ID. This tells all other files "Hey, I'm a building/prop exemplar, and this is my unique ID". And both of these exemplar files have one property that point to the unqique ID of the model from which they were generated. When you design a lot using this building/prop, you will create a lot exemplar file (with yet another unique ID, of course!) that contains a lot of information - among other things, it will tell the game "Please display the building/prop with this particular building/prop ID right here, like this". Then the game will look up the building/prop ID and scan it: "Okay, I know your ID, and I know you are a building/prop, but what the heck do you look like?" This is when it reads the building exemplar file and sees the reference to the model ID. So it will scan its internal files and the plugins folder for a model that matches the ID. Once it has found it, it will display it there. As you read above, you can indeed take one and the same model and create multiple building and/or prop exemplars from it. They will all point to the same model ID and make sure that the building or prop will display this identical model, but the building and/or prop exemplars will all have unique IDs and can have different properties and values. EDIT Oh, and you can rename the Explorer-level file containers to anything you want. Let's say you have made a model of your house. The file name in the Windows Explorer reads "GarlickersHouse.sc4model". You could rename it to "This_is_totally_not_my_house.dat". SimCity wouldn't care at all. Why not? Because the model inside this container has a unique ID, and this unique ID stays the same, regardless of the container file name - just like your favourite red socks will remain your favourite red socks, no matter if they are in a drawer with a label that says "socks" or in a cupboard with a label that says "anything but socks in here".

That's pretty much correct. Lots can either be growable or ploppable Every lot MUST have exactly one building. "Building" in this case doesn't necessarily mean anything like a house. It could also be a flower pot, a dustbin, a dumpster - it can be anything, even invisible (example: the Maxis parks). The reason for its existence is that the building holds the building exemplar file, which contains crucial information, such as: - growable RCI or ploppable civic/transportation/utilities - number of demand satisfied (jobs / residents) - tileset(s) - pollution values (can be negative, e.g., for parks) - power/water consumption - plop and maintenance costs (for ploppables) or tax income (for RCI) - which query window to display - which query sound to play when you click on it - etc. Every lot CAN/SHOULD normally have exactly one base texture for each of its tiles [You can remove the base texture later to have a transparent lot.] [More than one base texture on a tile is not normally possible, but can occasionally happen as a bug, which will cause the texture to switch back and forth unpredictably.] Every lot CAN have any amount* of overlay textures and props, but doesn't have to have any. [*technically, there's a limit as to how many object there can be on any lot. Any additional object beyond this limit won't be displayed in game.] Every lot CAN have "land only" and "water only" tiles, but doesn't have to. Every lot holds the lot exemplar file. This file contains the visual information: - Which building... - which texture(s)... - which prop(s).. need to be displayed... - on which tile - in which spot of that tile (x/y coordinates, only for building & props) - at what height (z coordinate, only for props) - in what orientation/rotation It also holds information relating to the lot, such as: - lot size - required roads (straight, left corner, or right corner) - minimum/maximum allowable slope to be able to develop / be plopped on any given terrain - minimum/maximum allowable slope before the lot will have an overall foundation rather than only the building on it having a foundation whereas the lot conforms to any slope - growth stage - zone type/density Some further tidbits: If you want to use any building (remember, doesn't have to look like one - it's just a "function holder"!) in game, you need at least one lot for it. You can assign multiple lots to one and the same building. In the case of ploppables, you normally need a separate menu entry for each of them. You can "recycle" one and the same lot design for multiple buildings (e.g. you could have a fountain that works as an office or as a hospital or as a park). However, you need to be careful with growable RCI lots because you cannot just use e.g., an industrial lot for a residential bulding. The lot exemplar must contain some information that matches the building exemplar, i.e. a residential building will only grow on a residential lot. Lots designed for straight roads in front can grow on corners, too, but corner lots cannot grow on straight road sections. On a higher level, the building exemplar contains the function, and the lot exemplar makes this function accessible by "anchoring" it in the game - both by giving it a visual presence and by giving it a spot to grow (or be plopped) on. The building exemplar represents the abstract functionality, the lot exemplar the "physical" appearance. The building exemplar has, e.g., the actual hospital function, but the lot exemplar is what makes you able to see in game "Hey, this is a hospital". I hope this little list has been helpful - if you want to know anything else or more, don't hesitate to ask.

Daaaang, good call! I sure love the old ones that didn't quite hold your hand so much and where your soldiers didn't have predetermined roles but developed their skills as they used them. Not to mention the subtle horror atmosphere - great stuff! Not without flaws, but still: immensely enjoyable, with every campaign you played writing its own story. For example, I remember that one time in Terror From the Deep when the aliens attacked my base right in the first month. You're lucky to have such a dark and destructive family! This game is so much fun as multiplayer, especially if everyone is more or less equally good or bad. Does anyone remember Earth 2150?

The non-W2W one with the round cupola and the rooftop pool is an oldie but goodie by oneil_1, Lake Point:

This is odd indeed. By default, if a prop has the Item Name propery set, it will display its name in a little speech bubble when you hover your mouse cursor on it. If it has the property "Query as main building" set to "True" and the "User Visible Name Key" set to zero, it will display the name of the main building on the lot as if it were an organic part of it rather than any independent name - pretty useful if you slap together several building props. Let's say you have some modular school building props - the classroom wing, a gym, maybe a washroom building, and an outdoor sports pitch - and you want them all to query as "Barton Elementary School". That's a situation where setting the props up to be queried as the main building is useful. I didn't know that these properties had any influence on whether props may appear or not.

Hi Dead_End, this sure looks like the correct place for this question to me - it is related to custom content, after all. Concerning your issue, what I can tell you for sure right now is that the ID 0xa000004a belongs to a default Maxis prop family that is composed of 5 different flora items: Flora2x2x2_QuarterShrub_1EDF Flora2x2x2_Quarterbush_2833 Flora2x2x3_Fluffybushsm_1ED8 Flora2x2x3_Fluffybushtiny_1ED8 Flora2x2x3_Spherebush_1EE1 Placing this prop family on a lot will normally cause any of its five constituent props to appear randomly. I have just downloaded and checked the lot in question, and this prop family is there alright. This looks like a simple lotting mistake - happens to me as well when I make one lot and save, rearrange stuff and save again, and then it turns out in game that I forgot to delete a prop (family) that was used on the first lot, but ended up not being required on the second. It does happen occasionally that there is an ID conflict, but in this case it looks highly unlikely. The rural corner bike stand, by the way, has the same bush/shrub prop family placed on the exact same spot. This makes it even more likely that it was simply an oversight on the part of the lotter, a prop that should have been removed - just like when you create a series of related documents by copy/paste, and you forget to delete a word from two documents of this series where this word doesn't apply. Fixing this should be as easy as deleting the prop from the affected lots and saving. You will lose the menu icon in this case, however. To avoid that, you can use LEProp to open the lot and save the icon first. Then you edit the lot and save so the icon is overwritten with an automatically generated default icon. However, you can open the edite lot in LEProp again and import the previously saved, original icon.

Well, the central question at this point is really this one: If you developed all surrounding cities until demand was gone or even turned negative, you can expect nothing else but zero or negative demand when you start the next tile. If all surrounding cities, however, have positive demand, then this would really be a strange case. I'd also like to remind you of a post I made further above in this thread: It helps to consider your region as the city, and the city tiles as neighbourhoods. It's absolutely possible that your city currently has enough manufacturing and high-tech industry so it doesn't need even more in another neighbourhood.

This puts it in a nutshell. I agree with this pretty much 100% - currently in theoretical terms. But I know this was what I enjoyed when I was still playing, and what I might enjoy again once (if) I start playing again. In any case, and particularly @Raymond7cn: Thank you - yes, indeed, I'm enjoying that modding and lotting stuff. I guess it's another way of imagining things, working on them, and seeing it come together slowly.

Wait, you can play this game? These days, I mostly play Lot Editor, iLive Reader, LEProp, SC4Tool, Plugin Manager, GoFSH and Excel in relation to SC4... with the goal of playing SC4. Eventually. Soon...ish. Hopefully. Maybe. Who knows?

This one may be possible using the Lot Editor, probably even with Maxis props. There are rocks of various sizes and colours. Pile two small ones on top of one another and try to hide the seam as good as possible, then pile a big one on top - finished. Copy and rotate a few times or use slightly different rocks, distribute these over a tile with grass/dirt texture, and you should have something that looks reasonably close to the real thing. The rocks released by Cycledogg, Pegasus, or nbvc (plus maybe other authors that I'm forgetting right now) might also be useful.

Wow, these are lovely! I totally missed the second post with the diagonals, too. One thing I'd like to mention for the orthogonals: If you want them to be compatible with other US W2W buildings (such as the ones made by NYBT, Jason, nofunk, and a few others), these all use a setback of 1 paver from the front edge of the lot - since the standard base texture has 10 of these pavers and a tile is 16m x 16m, this corresponds to 1.6 m. I don't think this is possible with your current design if you keep those little front yards. So it's a design decision at this point: Lose a bit of realism for better compatibility in game, or live with different setbacks in game and have a fully realistic recreation? There is no right or wrong answer here; it's simply a trade-off, and the decision is a matter of taste and preference. I just wanted to bring this little aspect to your attention. ...and with this being said, I'm looking forward to your next progres shot because I know it will be amazing again.

Well, this image attached to the post with the Census Repository screenshots indicates that, in this particular city, ~8,000 out of a total ~12,000 industrial jobs are high-tech, with dirty and manufacturing industry each addding another ~2,000. Demand for I-D is bottomed out at -6,000 due to 20% tax rate, I-M and I-HT are encouraged by 0% tax, but demand is practically zero. This would indeed suggest that I-HT jobs were driven up artificially (0% tax) to an unnaturally high proportion, with demand only being as high (!) as zero due to the tax cuts. I'm pretty sure if taxes in this situation were reverted to a normal level, I-HT demand would plummet. Let's assume for a minute that this was your first (and only) city in the region. If you now start a neighbouring city, you'd initially inherit that zero demand from the first city (and this is only assuming you'd set I-HT taxes to 0%, too!). Then, your new Sims would come in in that current city. They'd start with a lower EQ and at a younger age (where your EQ isn't that high yet). This would drive I-HT demand in the current city even lower. If the original "inherited" I-HT demand started at zero, it would eventually become positive again as the Sims in your current city become better educated (and older). However, if more of your cities have these artificially high levels of I-HT, chances are you're creating negative demand in many places, which will accumulate and "unload" on any new city. My advice is: play with the game mechanics, not against them. As EQ increases, I-D demand will plummet eventually, and you can bulldoze huge areas of I-D that's no longer used, i.e. the buildings will still be there, but few if any Sims will actually work there (remember the route query!). In the beginning, it's a nice growth booster, though. Exclusions by 20% tax are quite a radical measure already, but at least they can be reverted easily. Tax cuts to 0%, however, will throw your city out of balance gradually, and it can be really hard to recover from that. You are improing nothing by plopping the buildings that won't grow, either. You're just adding to the imbalance this way. Playing the long game and reaching good I-HT levels "organically" usually pays off.