A ruleset disallows a whole composition group

[Mathias]

If a ruleset dis-allows everything within a certain composition group, there has to be a better way of hiding all those units than the member expression, but I can't seem to find it.

[rob]

At 07:23 PM 3/3/2007, you wrote:

If a ruleset dis-allows everything within a certain composition group, there has to be a better way of hiding all those units than the member expression, but I can't seem to find it.

Unfortunately, there is no way to cause a unit to be hidden as an exception other than via the Member tagexpr. So you'll need to add the Member tagexpr to all the units impacted by the ruleset.

I take it that the list is rather long, else you wouldn't have flagged this as a problem. In general, the list of exceptions is short, which is why AB does things the way it does. How would you recommend we modify this in the future?

-Rob

[Mathias]

Unfortunately, Aeronautica Imperialis lists 18 scenarios in the rulebook (usually with different force compositions for each side), and I'm trying to include them all. There are actually only around 5 rulesets to implement for all those (for example, around a third of the scenarios give one side or the other only fighters), so I'm trying to assign everything to base rulesets and rely on inheritance. So, if the ruleset expression in the member tag could check on the base ruleset, that would be useful.

Around half to 2/3 of the units can be affected by the rulesets (bombers and ground defenses). Although, I can see the next book for AI including a scenario that gives one side only ground defenses, which would mean that all the fighters need to be restricted, giving everything a member expression.

I may have to go with only the 5 force organizations that actually exist, and include a long note section for which scenarios they belong to, since the rule choices don't support cascading menus.

I'm planning to accomplish things with a couple of global tags, to note whether each composition group is currently available.

The other option might be to modify the rules for profiles - allow someone to set a maximum limit of 0 - and have the composition profile then exclude everything in that composition group.

[rob]

At 09:17 AM 3/6/2007, you wrote:

Unfortunately, Aeronautica Imperialis lists 18 scenarios in the rulebook (usually with different force compositions for each side), and I'm trying to include them all. There are actually only around 5 rulesets to implement for all those (for example, around a third of the scenarios give one side or the other only fighters), so I'm trying to assign everything to base rulesets and rely on inheritance. So, if the ruleset expression in the member tag could check on the base ruleset, that would be useful.

I don't understand this request. Can you give me a detailed example of what you have in mind?

Around half to 2/3 of the units can be affected by the rulesets (bombers and ground defenses). Although, I can see the next book for AI including a scenario that gives one side only ground defenses, which would mean that all the fighters need to be restricted, giving everything a member expression.

That's not very maintainable. :-(

I may have to go with only the 5 force organizations that actually exist, and include a long note section for which scenarios they belong to, since the rule choices don't support cascading menus.

Cascading menus? How would you use cascading menus? Please outline how this would all work and maybe there's an alternative approach that could achieve the same net result.

I'm planning to accomplish things with a couple of global tags, to note whether each composition group is currently available.

Using just a few global tags that are assigned by various rulesets sounds like a good approach.

The other option might be to modify the rules for profiles - allow someone to set a maximum limit of 0 - and have the composition profile then exclude everything in that composition group.

This won't eliminate the units from being selectable, but it will definitely achieve the goal of proper validation. So this might be a much simpler solution that yields the desired net result.

-Rob

[Mathias]

1) Since there are actually only around 5 rulesets, although they end up having around 30 different names, I was hoping to have the ruleset.? tag expression look up the base ruleset that was in use. I realized there's a better way to do this - use a tag expression to look for ruleset.FtrOnly? - all the rulesets based on the same rules will be named in a pattern.

3) I'm thinking in terms of a windows pulldown menu sort of thing:
Small Games
Large Games
Campaign Games Scenario 1 Attacker
(tab)(tab) Defender
(tab) Scenario 2
(tab) Scenario 3
(tab) etc.

The scenarios have names, and each of the three game types has 6 scenarios, each of which can have different compositions for attacker and defender.

(this forum apparently won't let me put in large numbers of spaces or tabs, which is why things look odd in my display)

5) I was already going to set the profiles to allow no units from specific composition groups when the scenario doesn't allow it. What I'm suggesting is a change to the way Armybuilder works, so that if the profile for the ruleset allows no units of that composition, Armybuilder considers those units to have failed their member expression.

[rob]

At 07:08 PM 3/12/2007, you wrote:

1) Since there are actually only around 5 rulesets, although they end up having around 30 different names, I was hoping to have the ruleset.? tag expression look up the base ruleset that was in use. I realized there's a better way to do this - use a tag expression to look for ruleset.FtrOnly? - all the rulesets based on the same rules will be named in a pattern.

That's exactly the sort of situation we added the wildcards for! Excellent!

3) I'm thinking in terms of a windows pulldown menu sort of thing:
Small Games
Large Games
Campaign Games Scenario 1 Attacker
(tab)(tab) Defender
(tab) Scenario 2
(tab) Scenario 3
(tab) etc.

The scenarios have names, and each of the three game types has 6 scenarios, each of which can have different compositions for attacker and defender.

(this forum apparently won't let me put in large numbers of spaces or tabs, which is why things look odd in my display)

While it's not quite as nice as cascaded menus, you can come pretty close using rule contexts. Start with having on rule context where the user chooses one of the main categories (e.g. small, large, etc.). Require the user to pick exactly one ruleset from the context. Then have seaprate rule contexts for each of the categories, and have those categories enabled based the selection of the corresponding category ruleset. The net effect is that only the rule context for the selected category appears, and the user can pick an appropriate ruleset for that category.

5) I was already going to set the profiles to allow no units from specific composition groups when the scenario doesn't allow it. What I'm suggesting is a change to the way Armybuilder works, so that if the profile for the ruleset allows no units of that composition, Armybuilder considers those units to have failed their member expression.

This may seem easy, but it's just the opposite. The problem is that membership handling controls what entities can be selected, which occurs BEFORE everything else. Meanwhile, composition profiles are tied into the validation engine, which is process AFTER everything else. So what you're asking for is a very fundamental change that would have significant ramifications throughout the AB engine.

So this is going to require a lot of thought to figure out a different solution that avoids the nasty implications.

-Rob

[Mathias]

While it's not quite as nice as cascaded menus, you can come pretty close using rule contexts. Start with having on rule context where the user chooses one of the main categories (e.g. small, large, etc.). Require the user to pick exactly one ruleset from the context. Then have seaprate rule contexts for each of the categories, and have those categories enabled based the selection of the corresponding category ruleset. The net effect is that only the rule context for the selected category appears, and the user can pick an appropriate ruleset for that category.

I tried this originally, but it required me to leave the rule selection screen and re-enter before the correct context became enabled. Do I put the legality on the rules themselves, instead of the context?

[rob]

At 07:20 PM 3/15/2007, you wrote:

Quote:

While it's not quite as nice as cascaded menus, you can come pretty close using rule contexts. Start with having on rule context where the user chooses one of the main categories (e.g. small, large, etc.). Require the user to pick exactly one ruleset from the context. Then have seaprate rule contexts for each of the categories, and have those categories enabled based the selection of the corresponding category ruleset. The net effect is that only the rule context for the selected category appears, and the user can pick an appropriate ruleset for that category.


I tried this originally, but it required me to leave the rule selection screen before the correct context became enabled. Do I put the legality on the rules themselves, instead of the context?

That sounds like a bug within AB. Every time you change rules, all of the inter-dependencies should update themselves properly. If that's not occurring, then something is wrong within AB - possibly just a UI refresh not occurring after the engine update, but still a bug.

-Rob

[harkan]

this is the same behaviour we reported a while back, I think you had added it to the list of stuff for the next AB release?

[rob]

At 02:36 AM 3/18/2007, you wrote:

this is the same behaviour we reported a while back, I think you had added it to the list of stuff for the next AB release?

This is different from what I have on the todo list. At least, I *think* there is a difference here. I'm referring to the thread entitled "Feature request - Selecting multiple items in a context" that started on 4/18/06. Is that the thread you're referring to as well?