Parent Cohorts

[Diggis]

This topic is specfically aimed at Coego, as it's in regards to an email (Quoted) he sent me, which am finally getting round to actioning.  But I posted it here, as it's the type of discussion that is best in the open where everybody can see the answers.

Coege, you mention parent cohorts a lot in the email conversation we had regarding MML's and their Modding. I've finally decided to update my MML's in line with your suggestions below, and realised I have no idea about Parent Cohorts.  I assume they are a file that all the other reference, but no idea how to create it. 

Hi Shaun,
I have made quite many changes to your MML (pls check the attachment). Tried to improve the MML, and the end result is more suitable for MML use, to my opinion. You can use this lot as a template for your future MMLs, if you like it.
In general the building exemplar has been simplified a lot. The changes are:
- The busstop props were replaced by a specially-made prop.
- All park/landmark-related properties and effects have been removed. I tried to make a really neutral lot that does not affect the gameplay at all. For the same reason, property Demand Satified has been removed as well.
- Secondary building properties like pollution, power, water etc have been removed as well.
- Changed the Parent Cohort of the MML building. The original one was the Maxis standard Park Cohort, which caused Park-related properties to be inherited to the MML building exemplar.
- Parent Cohort was not set to 0,0,0, instead a new Cohort (a copy of that in the RTMTV3 buildings) was added. This was to keep the game from displaying a building foundation on steep slopes. I couldn't find an easier way, see also this thread on SC4D. I couldn't use the original either (it has the Condotional Building = true property added), I needed a new one (with a different ID). This change, together with slope properties in the lot exemplar allow the lot to be placed on slopped terrain without terraforming (flattening).
- The query was changed from the standard Maxis Park to the standard Maxis Landmark. This is the simplest query I found in the SC4 dats, displaying the Maintenance Cost only (not that it is needed, but as said above I could find no simpler query).
- The query sound was chaged from Park (voices, dogs barking etc) to that of the ingame parking garage (sounds like unidentified "noise").
- The Budget Item: properties have been changed (so as not to cause crashes with the new query and occupant groups). Maintenance cost was set to 0.
- Plop Cost and Bulldoze Cost properties were removed (they default to 0).
- The City Exclusion Group property was added. This allows the lot to be plopped only once in a city (really a desirable feature?).
Please take a look at the lot and commend. I would also fell grateful if you could take a look at the wording (not a native speaker).
Some interesting findings:
- Removing the Plop Cost property causes the plop cost (displayed by default next to the lot name in the menu) NOT to be displayed! A useful feature for such lots.
- The fences you have used are slope-oriented, so the lot looks nice even on steep slopes. So I kept these.
I think the above changes have made the lot more suitable for MML use. If you wish to use these for your future MMLs, you could also consider the additional improvements below:
- Add a custom query: the one I have used works, but this "Maintenance Cost" field is not needed. You could add a bigger query containing instead credits (scripts by Daeley, lots by Diggis etc) and logos and images, and possibly some generic messages (not specific to any MML) like instructions. I could help if needed.
- Add custom sounds: the sound I chose was just an acceptable sound for this lot, but you may want something more reminiscent of "construction". You can search file sounds.dat (it contains a huge number of sound effects, many unknown) or search the web for a "construction" sound (hammers, machines, jackhammers ets) and have it imported in a datfile. There are two basic sound properties that can be set, the plop sound and the query sound (there is also a "nearby" sound).
- The above files, together with the cohort that prevents the building foundation can be included in an "MML dependency", or instead copied in each MML you make (the IDs should be the same). In the former case you can release updates that will affect all dependant MMLs at once.

Any help people can offer on this, and possibly any of the other points that are likely to come up I'd much appreciate it.

[Andreas]

So these are the changes cogeo made to the MML construction lot, right? Well, to be frank, I never really cared about the properties of the construction lots, I simply made a copy of one of the lots that came with the set, put some construction props on them and added a custom icon, along with the LUA script etc. But cogeo certainly has a point, they could be improved to reflect the purpose a bit better, and they shouldn't have any impact on the game (although the effects are rather tame, and only temporary in most cases).

A parent cohort is more or less a template that is used if not all properties are present in an exemplar file. Cohort files have basically the same structure as exemplar files, and they are linked to a building exemplar file via the parent cohort ID. So if the building exemplar file doesn't provide any pollution properties, for instance, but they are present in the cohort file, the game will inherit them to the building exemplar file.

Most MML construction lots are derived from park lots, so they carry the Maxis park lot parent cohort ID by default - which makes them acting like a park, depending of the included or inherited properties. We can either terminate the link by changing the parent cohort ID to 0,0,0 - or maybe even create a special MML construction lot parent cohort that carries the desired properties (such as no pollution and park/landmark/demand effects, nor any plop or maintenance costs). The exemplar file of the construction lot could be very simple and only contain the IDs for menu icon, description etc.

Also, if we'd create some kind of "MML Essentials", those could contain a custom query sound, UI, the newly created cohort file etc. - I think this would be feasible if we'd create a new "MML Mega Pack" that contains every MML mod we created so far. Personally, I don't think it's mandatory, since the MML lots stay only temporarily in a city in most cases, but it's certainly a nice idea.

[Diggis]

That is basically what I was thinking for my MML's.

I was going to do a custom query (more stuff to learn ) and sound etc, and include that in a parent cohort, along with any other necessary information, such as polution etc.  Not 100% sure how to got about creating it, which is why I was asking.

[Andreas]

Well, I haven't used cohort files that often so far, but as usual, creating one shouldn't be harder than any other modding - make a copy of an existing one and modify it as desired.

[Diggis]

Makes sense.  Can I copy all the details from an exemplar file that I want constant into one?

[wouanagaine]

BArby should come in, as f I recall she has found out some examplar props that are not working if placed
in cohort

[cogeo]

Let's clarify a few things.
The RTMT pack has two cohorts.

The one is for the RTMT buildings. It was a last minute addition, so as to make these lots not display a building (not lot) foundation, if placed on slopped terrain. By default SC4 displays a building foundation, even if the "building" (gray rectangle) does not have a model (Resource Key Type X), and this looks ugly. The only way I found was to have a parent cohort with the Building Foundation property set and a building exemplar without this property (please check also this thread). Weird (the exemplar should inherit this property), but this is how SC4 works. The SC4 park lots work this way too. If anybody knows how to do this in an easier way, please post.

So the RTMT buildings/lots did all reference a common parent cohort. This made possible to make the MML by modding (adding the Conditional Building = true property) only this cohort and not each RTMT building exemplar (these instead inherit the property from the cohort), thus simplifying both modding and maintenance (should I want to change sth in the building exemplars, I won't need to change the MML as well). I think this should be the recommended method for new packs (or versions), but if you want to make a MML for an existing pack (esp if it's not likely to change in the future) the "classic" method, ie taking copies of the pack's building exemplars and adding the Conditional Building = true property is OK. This would be really hard for RTMT, since it actually has 5 sets of the building exemplars (for the various NAM/CAM capacity settings), ie you would need 5 MML plugins!

The other cohort is for the MML building itself! The purpose is again to make the construction lot not display a building foundation. As said above, if someone can suggest an easier way (or this feature is not desirable) this cohort is not needed. The lot exemplar has the slope-related properties set to values that cause no terraforming when the lot is plopped (it just "sits" on the terrain).

As for the custom query, sounds etc, these of course are not technically "necessary", but they can be fun (imagine hearing a jackhammer sound when plopping the construction lot and not the default plop sound). About the rest (no pollution, park effects, jobs etc), I don't see why to put them in the cohort, the building exemplar should just not set them - they default to 0). But if you finally do use custom query/sounds, you can add these to the cohort, and not to every construction lot you make.

A few things about cohorts:
- A cohort is like an exemplar. It contains a list of properties. While the cohort itself is not a lot or building exemplar (ie it does not act as a building or lot), it "inherits" its defined properties to all its "descendants" (exemplars and cohorts referencing it). Setting a property in a cohort amounts to setting this property to all its descendants. Thus it can be useful when you want to define properties common to building or lot exemplars of a pack.
- A cohort can reference (by setting the Parent Cohort property) another cohort. This can reasult in a sort of a "hierarchy". A building or lot referencing the last "descendant", will "inherit" the properties set in all its "ancestors".
- If a property set in an ancestor is set in a descendant as well, the value set in the descendant will "override" the one in the ancestor - only for the cohorts/exemplars referencing the descendant; those referencing a cohort "above" the descendant containing the override will instead "see" the "old" (the ancestor's) value.

Making a cohort is easy:
- As Andreas said, take an existing cohort, make a copy, and of course change the instance ID (check the cohorts in simcity_1.dat and pick an ID out of the range used by SC4, so as to avoid conflicts).
- Then simply add/remove/modify the desired properties.
- Check if the cohort you have chosen has the Exemplar Type property defined. If yes, then check if the value is "Buildings" or "LotConfigurations" (or anything else). If the value is say "LotConfigurations", the cohort is a "lot" cohort - it should be referenced by lot exemplars only, and contain only properties that can be set in lot exemplars.

Hope this helps.

[Diggis]

Thank you, looks useful.  Will try it tomorrow.   

[jeronij]

I have an old explanation saved in my HD. I cant recall the author  , but this is one of the first existing SC4 modding documents.

I post it here, because I think it explains the relation between cohorts and exemplars in an easy and understable way. Most of you do already know what cohorts and exemplars are, but surely other members would like to know more 

COHORTS AND EXEMPLARS

Lately, I''ve been digging through the reader trying to figure out the relationship between cohorts and exemplars in regards to buildings. I think I have learned a lot, and I understand the organization of exemplars, cohorts, buildings, and lots much better now.

There is a well-defined relational structure to the exemplars and cohorts for buildings. I say relational structure, because its not exactly higherarchial. Its more like the relations in a database...one table singly or mutliply linked to other tables. There are several root cohorts, for residential, commercial, and industrial buildings, as well as parks, landmarks, and civic buildings. The root cohorts for zoned buildings have a number of child cohorts, one for each building size. These child cohorts then have many child exemplars, one for each building of a given size. Parks and the like only have one root, which is linked directly to the child exemplars.

Exemplars are where the higherarchial nature ends, and the relational nature begins. Each building has two exemplars. One defines the building itself, its size, properties, effects. The other defines the buildings lot and stage. The buildings informational exemplar is related to the lot exemplar through the LotConfigPropertyLotObject property, specifically the line that starts with 0x00000000, and ends in the instance number of the buildings informational exemplar, which also happens to be the instance number of the buildings first 3DM file.

The lot exemplar is also related to a parent cohort, but this cohort is different from the informational exemplar. The lot exemplars parent cohort defines only a few things, and the most important of them are the LotConfigPropertyMinSlopeAllowed and LotConfigPropertyMaxSlopeBeforeFoundation. These two properties define the minimum slope angle a lot may be placed on, and the maximum angle before a foundation is placed under the lot to keep it flat. This can be useful for houses that don''t need to be placed on a perfectly flat lot (stilts or a raised foundation could be used), etc.

Each lot exemplar can also reference a number of other exemplars, or directly reference other items, such as FSH textures. These other items can be flora, props, etc.

The informational exemplar is the most confusing of them all, and the one we will have the hardest time fully deciphering unknown values for. This exemplar contains information about a building, what kind of building it is (usually by its parent cohort), what effects it has on your rating, on crime, on pollution, etc.

[Diggis]

Thank you Jeronij, this is one of those Gems that gets lost in the depths of time, and needs to be resurfaced every now and again.

[wouanagaine]

Hopefully, soon anyone will have a visualisation of those inheritance relations  

[High5Tower]

I appreciate Diggis for putting this topic on the front page. I have been slowly correcting my Empty Lot syndrome from my plugins,thanks to the great article by RippleJet so this info about Parent Cohorts has been on my mind. I am actualy starting to understand this stuff,fascinating!  .

[Diggis]

OK, I am trying to create one now and a few questions have arrisen

1. How do I check this property?

Check if the cohort you have chosen has the Exemplar Type property defined. If yes, then check if the value is "Buildings" or "LotConfigurations" (or anything else). If the value is say "LotConfigurations", the cohort is a "lot" cohort - it should be referenced by lot exemplars only, and contain only properties that can be set in lot exemplars.

2. Is there any rules to setting group ID?  On most stuff they are set and I don't touch them.

3. If a file references Cohort 0x0000, 0x0000, 0x0000 does that mean it doesn't reference one?

4. If I add the occupant group: Landmark to the cohort, will it add it to the MML, or ignore it as there is already an occupant group?

[cogeo]

1. Very simple, just look at the properties list at the right panel in iLive (just like with exemplars) - check if property Exemplar Type exists or not.
2. Getting conflicts with other cohorts is very unlikely because you can assign values to both the group and instance IDs - the Parent Cohort property has three IDs (T, G and I), and a conflict to occur both G and I IDs have to be the same, which is almost impossible. Just open simcity_1.dat in iLive and sort items by Group ID and then by instance IDs to find ranges that are not used by Maxis. Unlike texture and prop-family IDs, there is no centrally-kept registry (the "Index" maintained by BarbyW), so pick the ranges yourself.
3. Exactly!
4. Not all props are inherited the same way from cohorts to exemplars. An example is the Building Foundation property, mentioned in my reply above. There are two possibilities, either the Occupants Groups set in the (building) exemplar will "override" (replace) those set in the cohort, or Occupant Gropus are "additive" (the set "sum" or else "union" will be in effect). This is easy to find out, just set Building:Landmark in the cohort and the rest (desirable) groups in the exemplar, and then see if it works as desired. If not (script not working) this means that the Occupant Groups definition in the exemplar completely replaces (rather than adds to) the one in the cohort.

[Diggis]

  Yeah got it.... kinda.   

Thanks for all your help, I've managed to try and test quite a few things, like Custom UI's over the weekend, and will be looking at the Parent cohorts (although not sure if they might be a tad unnecessary for the MML's as there aren't all that many shared properties) during the week.

[Diggis]

OK, whenever I change the parent cohort of one of my MML's from what it is to anything, (including 0x000...etc) I lose the lot from my menus. 

[wouanagaine]

by 'one of my MML' you mean the lot examplar or building examplar ?

make sure that you still have the correct examplar type when you remove the cohort

[Diggis]

Building Exemplar... there is already a parent cohort there...0x05342861,0x07bddf1c,0x00000002

And when I change it to either zeros, or the numbers for the cohort I want it to use it dissapears from the menus.  It still seems to be working as the lots don't appear, but nor does the MML.

[wouanagaine]

0x05342861,0x07bddf1c,0x00000002 is for Park, which itself point to Civic Building cohort (0x05342861,0x07bddf1c,0x00000001)

If you switch to 0,0,0, make sure your building examplar have the ExamplarType ( 0x10 ) property set to 0x2 and the OccupantGroup property ( 0xAA1DD396 ) contains at least 0x1005,0x1006  ( civic, park )
and make sure you have an occupantsize property also

[Diggis]

Thats possibly the problem.  I'll have a look tonight.  Thanks Wou!