Allow More Building Styles - DLL Plugin

[Null 45 3,041]

1 hour ago, Kel9509 said:

Even more interesting - when you drag to create a W2W building, it will only add the Occupant Groups with W2W, but the W2W exemplar will be added yet set to "False".  But I can't find the reason for that in new_properties.xml. 

It looks like a few of the residential buildings that have Building Is Wall-to-Wall set to false still have a W2W occupant group, but that wouldn't affect the DLL's behavior.
I am not familiar with PIM-X, so I don't know what its limitations may be with regards to building styles.

[Kel9509 1,363]

13 hours ago, Null 45 said:

I am not familiar with PIM-X, so I don't know what its limitations may be with regards to building styles.

Yes, I didn't mean to imply there was anything wrong with the DLL, as it works great.  Like I said it's likely a PIM-X issue entirely.  @Ulisse Wolf, have you seen this behavior in PIM-X?  I'll try taking a closer look when I have a moment to see what might be going on.  

Ideally, what would be great is if PIM-X can filter according to W2W types either by Occupant Group, or W2W exemplar, or both.  And dragging a lot to a W2W style would add both the Occupant Groups as well as the W2W exemplar. 

I was also looking into whether PIM-X could have additional checkboxes for new building styles, but I don't think that is possible. Building styles appear to be hard-coded outside of new_properties.xml.

[Ulisse Wolf 4,412]

26 minutes ago, Kel9509 said:

Yes, I didn't mean to imply there was anything wrong with the DLL, as it works great.  Like I said it's likely a PIM-X issue entirely.  @Ulisse Wolf, have you seen this behavior in PIM-X?  I'll try taking a closer look when I have a moment to see what might be going on.  

Ideally, what would be great is if PIM-X can filter according to W2W types either by Occupant Group, or W2W exemplar, or both.  And dragging a lot to a W2W style would add both the Occupant Groups as well as the W2W exemplar. 

I was also looking into whether PIM-X could have additional checkboxes for new building styles, but I don't think that is possible. Building styles appear to be hard-coded outside of new_properties.xml.

I have the same problem and it is constrained by program code. The only solution is to create from scratch a new PIM-X

I performed several experiments that looked promising but ultimately turned out to be a failure

[Kel9509 1,363]

On 10/17/2024 at 7:41 PM, Null 45 said:

@CorinaMarie needs to update her UI template to add that check box.

I understand that the latest "test" version of the UI template doesn't have the No Kickout checkbox option, because as I recall it was one of several "extra" controls that were still being considered.  Now that the DLL supports this, it'd  be nice if there was a UI for it.  But perhaps a UI hasn't been released because there are 7 additional "reserved" controls that might seem ugly in the UI if they didn't do anything.

I have an idea for additional controls in the UI, if possible.  I don't know if it's possible but I wanted to throw it out there to see if perhaps it could be done.  The only other possible control related to building styles that I can think of, and which would be awesome to be able to turn on and off inside the game, are Maxis building blockers.

I use the BSC Maxis blocker for high-wealth Commercial Offices and Commercial Services, as well as high-wealth Residential.  BSC's blocker structures them so that for Commercial and Residential, each development type can be blocked by wealth level.  For Residential, you can block R$, R$$, and/or R$$$.  For Commerical, you can block CO$$, CO$$$, CS$, CS$$ and/or CS$$$.  For Industrial, it's a bit more complicated, as it's by Stage instead.  You can block I-R, I-D1, I-D2, I-D3, I-M-1, I-M2, I-M3, I-HT1, I-HT2, and/or I-HT3.  The point is, there's lot of options.

If it were possible to add a Maxis blocker to the UI, does anyone think that'd be worth it?

[CorinaMarie 29,605]

5 minutes ago, Kel9509 said:

But perhaps a UI hasn't been released because there are 7 additional "reserved" controls that might seem ugly in the UI if they didn't do anything.

That is part of my delay, yes. The other part is how it works in the latest DLL release.

Right now it's a Kick Out option if set and "No" is the default unchecked "off" setting. I have a feeling that'll come as a surprise to many. While NKO is quite useful for those of us who love it, my guess is its adoption rate is prolly 10% or less. So how do we make it ideal for both? Maybe the DLL looks for either the .dat for NKO (or the NKO DLL) and if either of those are present it sets the NKO to true and let that be the checked option. But, if neither are present in plugins then the default should likely be false as the game shipped. Or if that is too cumbersome in the code then an INI option for the preferred default when establishing a new city.

Additionally if we go with the 7 other reserved options I'll need to know what IDs to give them internally in the UI.

I also want to show examples of why I'm hoping Null could split the Keep Lot Zone Sizes into No Aggregation and No Subdivision as separate options. There are many times I would want one, but not the other and the current method is all or none. My idea was to show examples each way and discuss why I feel both as separate choices would be good. I've had to try to build a full region to have a place to create nice examples and then I've gotten sidetracked with other projects in other threads too.

[Null 45 3,041]

1 hour ago, Kel9509 said:

I have an idea for additional controls in the UI, if possible.  I don't know if it's possible but I wanted to throw it out there to see if perhaps it could be done.  The only other possible control related to building styles that I can think of, and which would be awesome to be able to turn on and off inside the game, are Maxis building blockers.

I don't think that could be done.

40 minutes ago, CorinaMarie said:

So how do we make it ideal for both?

I read the NKO value from the game code after the NKO DLL or DAT plugin set it, so it will pick up the correct default value. Once the check box is toggled and the game is saved, that city save data will be used instead of SC4's default.

49 minutes ago, CorinaMarie said:

I also want to show examples of why I'm hoping Null could split the Keep Lot Zone Sizes into No Aggregation and No Subdivision as separate options. There are many times I would want one, but not the other and the current method is all or none.

How would that work, as 2 new check boxes?

[CorinaMarie 29,605]

3 minutes ago, Null 45 said:

I read the NKO value from the game code after the NKO DLL or DAT plugin set it, so it will pick up the correct default value. Once the check box is toggled and the game is saved, that city save data will be used instead of SC4's default.

Yay! This sounds very good. I'll test again with this in mind. My first test in the UI was to make the NKO checkbox and I played for a while then clicked it on and it seemed my Sims were getting kicked out. That's why I felt it was backwards. Maybe I need to load the city, save it, and then the checkmark would appear from your code?

 

5 minutes ago, Null 45 said:

How would that work, as 2 new check boxes?

Yes.

• Do not Aggregate Lots
• Do not Subdivide Lots

[Null 45 3,041]

Just now, CorinaMarie said:

• Do not Aggregate Lots
• Do not Subdivide Lots

I would be flipping that to Aggregate Lots and Subdivide Lots with a default value of checked. Negative-sense check boxes (where you check the box to disable something) are confusing. https://devblogs.microsoft.com/oldnewthing/20070314-00/?p=27623

[CorinaMarie 29,605]

7 minutes ago, Null 45 said:

I would be flipping that to Aggregate Lots and Subdivide Lots with a default value of checked.

Sure, that'd work fine for those.

For No Kick Out that should be the exception because it's how Maxis named it all those years ago and it's how it's been referred to by the entire community after I found someone else's discovery and then CB and I popularized it.   (We even named it after me since I adopted it and was it's sole proponent initially.)

[Null 45 3,041]

2 hours ago, CorinaMarie said:

For No Kick Out that should be the exception because it's how Maxis named it all those years ago

Maxis named it Kick Out Lower Wealth and set the default value to true. My Kick Out Lower Wealth check box behaves the same way, uncheck it to stop the game from kicking out lower wealth groups.

[Kel9509 1,363]

20 hours ago, Null 45 said:

I don't think that could be done.

Yeah I thought it might be hard or not possible.  The way those BSC blockers work is basically an exemplar override for each applicable lot, and setting its growth stage to 255.  Dusktrooper's version, at least prior to this DLL mod, I think set the styles of Maxis lots to 2005.  It was recently updated to use a different method but I'm not sure how it works.  

Is it because the lots are already "loaded" in the game memory, so not using them with a controller is too hard?  Or that it's too hard to program in the DLL the control to block a certain lot or group of lots?  

[Null 45 3,041]

33 minutes ago, Kel9509 said:

The way those BSC blockers work is basically an exemplar override for each applicable lot

The game caches the building exemplar data, so you wouldn't be able to undo a loaded blocker from within the game. IIRC the update to DuskTrooper's mod sets the style id to 0, which I treat as invalid/reserved.

36 minutes ago, Kel9509 said:

Is it because the lots are already "loaded" in the game memory, so not using them with a controller is too hard?

What do you mean by 'controller'?

38 minutes ago, Kel9509 said:

Or that it's too hard to program in the DLL the control to block a certain lot or group of lots?  

I don't know what it would take to identify the Maxis lots, I haven't investigated that. As for controls, the easiest would be a check box for each of the 12 RCI groups. But that would take up a lot of space.

[Cyclone Boom 16,875]

@Null 45

I see where you're coming from in terms of having the property true by default. It does make sense from a programming perspective based on the exemplar. Also as you say for Aggregate and Subdivide, that is logical. We've never had mods for that aspect of the simulation as far as I'm aware.

However for NKO, let's just focus on the community aspect here, as I agree with Cori it's a key consideration what people are used to.

Players expect to enable the "No Kick Out" behaviour, not disable it. Since "No Kick Out" has been accepted as the common term, I suspect most see NKO as a mod to install (and thus enable). As the Maxis default behaviour is to allow wealth kickouts, I believe the natural assumption is checking a box is needed to override this.

 

20 hours ago, Null 45 said:

Maxis named it Kick Out Lower Wealth and set the default value to true. My Kick Out Lower Wealth check box behaves the same way, uncheck it to stop the game from kicking out lower wealth groups.

If we follow the programmatic approach as "Kick Out", we're asking players to uncheck the box to prevent kickouts. This creates a subtle but important reversal in how they'd expect it to work. Players might wonder if they need to "disable" NKO instead, which could break the pattern they're familiar with. I feel that's only going to cause confusion. When people install mods to alter game functions, I think they're typically seen as being enabled (irrespective of being true/false value at exemplar level).

Keeping it as "No Kick Out" (where checking the box prevents kickouts) respects the standard expectation. This then conforms to the most probable choice for players. It would also avoid the negative-sense checkbox scenario you mentioned. Since "No Kick Out" is understood as what players enable, requiring an uncheck to activate would reverse that expectation. A positive-sense checkbox keeps it consistent how players interpret NKO as a gameplay simulation parameter.

Summary

You're right, it's technically correct when named "Kick Out Lower Wealth" in terms of the programming logic.

Although instead, considering the known action to install NKO, I feel it'd be highly beneficial for the UI side to function like this:

  =  Kick Out Lower Wealth: false  (Cori's NKO Default)

  =  Kick Out Lower Wealth: true    (Maxis Default)

This is just a concept I quickly made. NKO could be named "No Kick Out" if worth being more verbose.

A possible benefit to the action word "Enabled" is to clearly instruct what the checkbox does.

[Null 45 3,041]

12 minutes ago, Cyclone Boom said:

You're right, it's technically correct when named "Kick Out Lower Wealth" in terms of the programming logic.

Changing the existing check box would break the DLL's documented behavior for that control, but I could add another optional checkbox that uses the opposite logic.

[Cyclone Boom 16,875]

28 minutes ago, Null 45 said:

I could add another optional checkbox that uses the opposite logic.

Sure, that'll be fine. Just let us know when you have the IDs Cori needs in the UI and she'll work on those when she can.

[Kel9509 1,363]

2 hours ago, Null 45 said:

The game caches the building exemplar data, so you wouldn't be able to undo a loaded blocker from within the game. IIRC the update to DuskTrooper's mod sets the style id to 0, which I treat as invalid/reserved.

What do you mean by 'controller'?

Yeah, I figured that the exemplars (including a blocker), once loaded, could not be switched on or off.  By "controller" I meant the ability to turn a blocker on or off.

Other than the NKO UI, is there anything else in terms of reserved functions?

[Null 45 3,041]

1 hour ago, Kel9509 said:

Other than the NKO UI, is there anything else in terms of reserved functions?

No.

[Null 45 3,041]

21 hours ago, Cyclone Boom said:

Sure, that'll be fine. Just let us know when you have the IDs Cori needs in the UI and she'll work on those when she can.

I added the following new check boxes for the next version:

1. No Kick Out, default=false, id=0x101.
2. Disable Lot Aggregation, default=false, id=0x102.
3. Disable Lot Subdivision, default=false, id=0x103.

[Null 45 3,041]

Release version 3.2.0, which has the following changes:

• Added an optional No Kick Out check box.
  • This check box uses the reserved id value 0x101.
• Added an optional Disable Lot Aggregation check box.
  • This check box uses the reserved id value 0x102.
• Added an optional Disable Lot Subdivision check box.
  • This check box uses the reserved id value 0x103.
• Added an optional Prevent Cross-Style Redevelopment check box.
  • This check box uses the reserved id value 0x104.
• Added a CandidateLots debug logging option to SC4MoreBuildingStyles.ini.
  • This option logs information about the existing lots or empty RCI zones that the game picks
    to (re)develop.

[Kel9509 1,363]

I think there may be an issue with the auto-Growify feature in this DLL.  While converting some diagonal landmark lots into new Growify residential buildings, in testing them I decided to try the auto-growify feature.  I've used the auto-Growify option in the past and haven't had an issue with it. However, I noticed that on the diagonal road, the lots did not see the residents finding jobs.  Eventually, they abandoned due to the commute time.  Plopping them again (with auto-growify still on), I tried the regular Growify command.  The regular growify command worked (it found them and said all 6 lots were growified, despite auto-growify already being on).  Once I did that, the residents instantly found jobs.

I'm not sure how else to explain it.  I took a lot of screenshots but I'm not sure there's much else other than what I just said.  I also did another test of the auto-growify feature on a straight road instead of a diagonal road, and residents and commercial service lots worked fine (residents found jobs and the services had workers).

EDIT: I figured it out.  The Auto-growify feature works fine with the buildingplop command.  But if you use a Ploppable Residential building (like these or these, or even a new one made for a straight road) then it doesn't work, whether on a diagonal road, FA2 or FA3 road, or straight road.  Auto-growify only works with the buildingplop cheat.  Is there a way to make it work with other residential ploppable buildings, as the regular growify command handles those fine?

  Edited November 15, 2024 by Kel9509  

[Null 45 3,041]

27 minutes ago, Kel9509 said:

Is there a way to make it work with other residential ploppable buildings, as the regular growify command handles those fine?

The issue is that the lot configuration LotConfigPropertyZoneTypes property is set to Plopped instead of the desired RCI zone density.

The Growify cheat works because it requires the user to specify the zone density instead of reading it from the lot configuration. But as the More Building Styles DLL growifies items without user interaction, it is dependent on the lot configuration for the zone density information.

[Kel9509 1,363]

17 hours ago, Null 45 said:

The issue is that the lot configuration LotConfigPropertyZoneTypes property is set to Plopped instead of the desired RCI zone density.

I see.  I tested a Ploppable Residential building I made in PIM-X by editing the LotConfigPropertyZoneType in reader from 0x0F (Plopped lot) to 0x03 (Residential High Density Zone).  With the auto-growify feature on, it worked.  The regular Growify cheat worked as well.  In comparing the two, it seemed that the Residents found jobs a lot faster using the regular Growify command than the Auto-Growify, although I'm not sure if that's just a fluke of the simulator or if something else is involved.

Anyway, there seems to be no way in PIM-X to configure Ploppable lots to be other than 0x0F.  It's not editable in PIM-X unlike some other lot features, and the only way to edit it is in Reader.

I'd like to ask everyone what the right approach should be in creating Ploppable Residential lots.  Should I code with the LotConfigPropertyZoneType for use with Auto-Growify (as well as regular Growify, since it also works) which would specify their zone density?  Or should I just leave that alone but edit my readme files and the lot description that only the regular Growify command will work?  I'm not really sure which approach to take, but I think the auto-Growify feature will probably be very popular.  It's unfortunate that this cannot be done in PIM-X and requires extra work in Reader, but I think I might go with that route.

[Null 45 3,041]

2 hours ago, Kel9509 said:

I'm not really sure which approach to take, but I think the auto-Growify feature will probably be very popular.

I can also update the DLL to use some kind of fallback if the LotConfigPropertyZoneType is set to Plopped lot.

Probably the most user friendly would be a new Building Exemplar property (BuildingAutoGrowifyZoneDensity?) that the DLL will read if the LotConfigPropertyZoneType is set to Plopped lot, possibly with an AutoGrowifyDefautZoneDensity section in the INI file for buildings that do not have new new property.

It may also be possible to guess the zone density based on the lot size or other attributes, but I can't think of an algorithm for that. Suggestions would be welcome.

[Kel9509 1,363]

2 hours ago, Null 45 said:

I can also update the DLL to use some kind of fallback if the LotConfigPropertyZoneType is set to Plopped lot.

Maybe, but there is a lot of sense to the way things are structured now.  Auto-Growify does seem to work well based off of the zone density from the LotConfigPropertyZoneType.  I'm not sure if it's wise to default to a particular density, now that I think about it.

2 hours ago, Null 45 said:

Probably the most user friendly would be a new Building Exemplar property (BuildingAutoGrowifyZoneDensity?) that the DLL will read if the LotConfigPropertyZoneType is set to Plopped lot, possibly with an AutoGrowifyDefautZoneDensity section in the INI file for buildings that do not have new new property.

If I'm going to edit a lot in Reader, it's pretty easy to just edit the ZoneType from Plopped Lot to a particular density and type, especially since I'm making custom residential lots.  I don't know if a new exemplar is needed yet.  Switching the ZoneType is less a problem with Residential lots that I make to Growify (mostly diagonal or fractional angled lots) than it is with the hundreds or thousands of ploppable commerical and industrial lots out there, which also don't work with Auto-Growify.  I'm faced with a lot of editing already to incorporate new building styles, but I didn't count on the possibility of editing the existing hundreds of commercial plopped lots.  So maybe the standard Growify command still has a lot of value.  While I would like auto-growify to work with existing Ploppables, I'm not sure it can absent some assumptions that might be hard to make.

2 hours ago, Null 45 said:

It may also be possible to guess the zone density based on the lot size or other attributes, but I can't think of an algorithm for that. Suggestions would be welcome.

That might be difficult.  There are 5x5 commercial lots that are basically McDonalds restaurants with parking lots, drive throughs, etc.  The only way I can alternatively guess zone density would be the Growth Stage.  Stages 1-3 might be low density, 4-6 medium, and 7-8 high.  But of course, Ploppable lots don't even have a stage (most are at 255), so this doesn't really solve the problem either.

[CorinaMarie 29,605]

I've started work updating the UI for the 3.2.0 DLL.

Since we have more options now than can possibly fit in the lower control area, I've moved on to the one I showed a while back with 8 Reserved buttons and text. Using that, it looks like this in English:

^ Oops. Ignore the pt-br "anos(s)" for "years" as I made that a separate override when testing.

 

That's all well and good as far as it goes, however I've also been working with the LText @carlosmarcelo created and I've added Google translations for the four new items. Ofc, I don't know if they are even remotely correct as I don't speak his language.

1. No Kick Out Lower Wealth shows as:
   1. Não há como expulsar a menor riqueza
2. Disable Lot Aggregation shows as:
   1. Desativar agregação de lote
3. Disable Lot Subdivision shows as:
   1. Desativar subdivisão de lote
4. Prevent Cross-Style Redevelopment shows as:
   1. Impedir o redesenvolvimento de estilo cruzado

So a couple of those are much longer than the UI has room for:

 

One option is to move the lower Não há como expulsar a menor riqueza into the upper section. Then vertically re-space the 3 Wall to Wall options so they look good again. And also remove the remaining 5 Reserved options so there is more room to the right of the the buttons's text. That does mean there wouldn't be any room in the UI for possible new checkbox (or radio button) options later on.

The other (preferred) idea is if Não há como expulsar a menor riqueza and Impedir o redesenvolvimento de estilo cruzado could be shortened enough to fit. And, additionally, I have no idea about any other translations and how well they will adapt to the space available.

Note: Where the above shows "LText Reserved" vs "UI Reserved", that's just my way of indicating there is an actual LText reference set up and it is pulling in the verbiage as opposed to hard coded English text in the UI. (The latter will all get LText references if we keep the 5 extra reserved control spots.)

So, at this point, I'm not sure which way to proceed. I'm leaning towards keeping the reserved options and suggesting other languages might have to abbreviate (or use English) so we retain the ability to handle up to five more selections sometime in the future. Also, when I first started on this project CB suggested we should have hover over tips added and I believe that will be very good now since the choices are becoming nicely more esoteric compared to the vanilla game.

[carlosmarcelo 975]

5 hours ago, CorinaMarie said:

The other (preferred) idea is if Não há como expulsar a menor riqueza and Impedir o redesenvolvimento de estilo cruzado could be shortened enough to fit. And, additionally, I have no idea about any other translations and how well they will adapt to the space available.

Don't worry: I can adjust in this space. Can you send me interface file and ltext file to translate and to avaliate? 

I prefer have both because I can changing and viewing result. But, if you prefer, I can translate here in other post or PM.

5 hours ago, CorinaMarie said:

Also, when I first started on this project CB suggested we should have hover over tips added and I believe that will be very good now since the choices are becoming nicely more esoteric compared to the vanilla game.

Yes, it is very important in this moment. Concepts like NKO, W2W etc is not "simple"...  I burned my mind to translate "auto-historical" and "auto-growify" to simple words and the concept is broader. 

So, I would like share a question with all: the NKO, or better, the "kick out lower wealth", is the same of gentrification? 

PS: If tips idea will be possible, I can starting create.

  Edited November 16, 2024 by carlosmarcelo  
added PS

[CorinaMarie 29,605]

3 minutes ago, carlosmarcelo said:

Can you send me interface file and ltext file to translate and to avaliate? 

Sure thing. It's a work in progress atm, but it's usable. I have not yet created LText entries for the last 4 reserved controls and none of them have the "tipres" (hover over) fields set. I'll send it in a PM as it's not ready for release.

 

6 minutes ago, carlosmarcelo said:

So, I would like share a question with all: the NKO, or better, the "kick out lower wealth", is the same of gentrification? 

Yes. Those are the same things. NKO is just the shorter acronym for "No Kick Out Lower Wealth".

[carlosmarcelo 975]

I translated the new and long sentences and now the interface looks like this:

Some comments below:

1. "(controle reservado 04)" or just "= reservado =" or empty are suggests to this reserved spaces.
2. "Não remembrar lotes" and "Não desmembrar lotes": in my city, theese are formal and techinical words to, respectively, "Disable lot aggregation" and "Disable lot subdivision"; I thought "Não juntar lotes" and "Não dividir lotes" excessive shorts, letting very blank space in interface.
3. I can't write short, complete and compreensive sentence to NKO, so I used gentrification and added "NKO" because both terms already famous in community SC4 and urbanists. I believe that with tips we will be able to explain with accurate to new users what means each control of UI.
4. "Prevent Cross-Style Redevelopment" was the challenge. I did some options, but I changed some words and I choiced the underlined sentence: 
   • Impedir o redesenvolvimento de estilo cruzado (original)
   • Evitar troca de estilo no redesenvolvimento
   • Preservar estilo ao reconstruir
   • Fixar estilo ao redesenvolver
   • Manter estilo ao reconstruir
   • Fixar estilo ao reconstruir
5. I update dll and I haved impression that "Disable lot aggregation" is not working properly. In late, I will do precision tests.

If you need adjusts or you want to comment about this sentences, feel free. 

[Null 45 3,041]

9 hours ago, CorinaMarie said:

Also, when I first started on this project CB suggested we should have hover over tips added and I believe that will be very good now since the choices are becoming nicely more esoteric compared to the vanilla game.

I agree with the tool tip idea.

"Prevent Cross-Style Redevelopment" was the name in this post which suggested the feature, and I couldn't think of anything shorter. There probably are real-world analogues in some places to preserve the architectural styles of certain city districts. But I would expect that to be described as anti-gentrification and/or historical preservation, which already have existing in-game meanings in other contexts.

[TheMurderousCricket 5,055]

15 hours ago, CorinaMarie said:

I've started work updating the UI for the 3.2.0 DLL.

Since we have more options now than can possibly fit in the lower control area, I've moved on to the one I showed a while back with 8 Reserved buttons and text. Using that, it looks like this in English:

I'm sorry but I'll just have to say it... Downvote me if you have to, sorry.

I don't think it is the right idea to chuck all possible options and ideas into a single .dll like you do in this mod.

Although your efforts at trying to "contain" this are remarkable, I don't think it is feasible to add so many controls, even beyond the scope of building styles, into just one UI and just one mod. Despite all the work involved, I still consider this interface to be confusing, clogged and unfriendly for a near-ADHD like me...

If it was up to me (and it isn't obviously...) I would just leave out key options that are indeed essential to the style choice and management rather than add a whole, long list of checkboxes.

• Disable aggr.
• Disable subdiv.
• Prevent x-style redevelopment
• W2W and standard
• W2W only
• W2W blocked

Would be (and are) the only options I care about in this mod. There are already just too many ideas put together here...