[SUGGESTION]Custom Hangar/Craft types

[0xEBJC]

I have already said in this thread that I don't need help with the implementation of this feature.

Reviewing your code, learning how it works, changing it to my liking and testing it will take me longer than doing everything myself.

It's a valiant effort, but this is a critical feature that I want to do right and want to understand every detail so that I can support it long-term.

Please don't send pull-requests, they will just be closed.

I just posted a new Facility Expansion Pack Mod that has custom hangar facilities using BRUTAL-AI currently until when you release your version into the main OXCE branch.

One suggestion for your consideration when you look at implementing this would be to have an option for a default hangar to accept any crafts. 

For example if:
   hangerType: 1 = (cars)
   hangerType: 0 = (Aircrafts)

Then have the option for something like:
   hangerType: -1 = (anything)

Example scenario:
   All automobiles = craftType: 1
   Garage = hangarType: 1

   All Aircrafts = craftType: 0
   Hangar = hangarType: -1

That way a hangar can store both aircrafts and automobiles, but a garage can only store automobiles.  Then the logic would check if there is a hangarType and craftType match first, then a craftType to universal hangarType second when determining facility space available.  The crafts would always count against the matching hangarType first before a universal one.  So if you had 2 cars, 1 garage and 1 hangar (with hangarType: -1) and one of the cars was sold, then the second car would be counted against the garage first so that any craft could be placed into the hangar.


Currently, the implementation in BRUTAL-AI has explicit matches both craftType and hangarType have to match so an automobile could not be placed into a hangar.

 

[Flaubert]

My implementation of Hangar mods, had this "-1" wildcard already. If rules for crafts didn't have an entry for hangar type, they were automatically assigned a "-1" Id, which corresponds with the default id for vanilla hangar.
This way my OXCE engine version didn't break mods made for official OXCE+ branch.
I'm sure Meridian has special care with compatibility for previous mods, so probably he has in mind a similar mechanism.

[0xEBJC]

My implementation of Hangar mods, had this "-1" wildcard already. If rules for crafts didn't have an entry for hangar type, they were automatically assigned a "-1" Id, which corresponds with the default id for vanilla hangar.
This way my OXCE engine version didn't break mods made for official OXCE+ branch.
I'm sure Meridian has special care with compatibility for previous mods, so probably he has in mind a similar mechanism.

First I just want to say thank you! for implementing this as a short term solution! I really appreciate all your work!

The capability I'm looking for is if I have a hangar type -1 (the original 2x2 hangar), automobiles are craft type 1 and aircrafts are craft type 0, I want both to be able be able to go into (the original 2x2 hangar) with a hangar type -1, and if I have a different hangar that is hangar type 0 then only aircrafts could go in there and not automobiles and hangarType 1 only automobiles.  Currently the issues I'm having is where I have a hangar type -1 (the original 2x2 hangar), then I have to set aircrafts to craftType -1 for them to be stored there, if I set aircrafts to craftType 0 then they won't go into hangarType -1.

The code implementation I think would work would be to crate a sum of hayngar types and crafts types

Example:
Garage               = (size 1x1) capacity (1) hangarType (1)
Original Hangar   = (size 2x2) capacity (1) hangarType (-1)
Aerodock            = (size 2x2) capacity (3) hangarType (0)

Base has (0 crafts), (2 garages), (1 original hangar)
Space:
  hangarType 0  = (1 spaces)
  hangarType 1  = (2 spaces)
  hangarType -1 = (1 spaces)

1.) add craftType 1,
       - check hangarType 1 spaces available,
       - if available then count against hangerType 1
       - if no spaces left in hangarType 1, then check if hangarType -1 spaces available
       - if available then count against hangarType -1
       - if no spaces left in hangarType -1, then present GUI error "no craft spaces available"
 2.) add craftType 0
       - check hangarType 0 spaces available,
       - if available then count against hangerType 0
       - if no spaces left in hangarType 1, then check if hangarType -1 spaces available
       - if available then count against hangarType -1
       - if no spaces left in hangarType -1, then present GUI error "no craft spaces available"
follow this same logic for additional hangar types, you's also have to key track of what crafts types are stored in hangar type -1,
for example base has hangarType -1 (space available = 3)
1.) store craftType 0 in hangarType -1,             hangarType -1 (stored spaces = craftTypes [{0, 1}]
     next store craftType 1 in hangar type -1,     hangarType -1 (stored spaces = craftTypes [{0, 1}, {1, 1}]
     next store craftType 0,                               hangarType -1 (stored spaces = craftTypes [{0, 2}, {1, 1}]

when removing crafts from the base, sell or transfer, logic would always check hangerType -1 first and remove the craft from that hangar 1st before removing craftType 0 from hangarType 0 where 2 craftType 0 are being stored, one in hangarType 0, and one in hangarType -1

For backwards compatibility would be that if a hangarType is unspecified for a hangar then it's -1, and if a craftType for a craft isn't specified, then it's -1, and craftType -1 can only go into hangarType -1.


Related Posts
------------------------------
https://openxcom.org/forum/index.php/topic,11590.0.html

[WarStalkeR]

The code implementation I think would work would be to crate a sum of hangar types and crafts types

Example:
Garage               = (size 1x1) capacity (1) hangarType (1)
Original Hangar   = (size 2x2) capacity (1) hangarType (-1)
Aerodock            = (size 2x2) capacity (3) hangarType (0)

Base has (0 crafts), (2 garages), (1 original hangar)

This implementation has one big issue: sorting and allocation. Lets assume that your two hangars. One allows types {0,1,2,3} and another allows types {0,1,3,4} and here you encounter issue - which craft type should be placed first? Basically, you might end up with issue: you've bough type 3 craft and it was placed in first hangar, the second hangar is still empty. And if you're trying to buy type 2 craft, you can't because the only compatible hangar is occupied, whilst 2nd hangar is unused.

In my case, to avoid this issue, I implemented craft size parameter, allowed granulation of craft size ranges to a craft class and only then implemented multi-craft hangars support that rely on craft size to sort crafts via heuristic approach into craft slots provided by hangars.

You can take a look at my approach here:
https://github.com/WarStalkeR/OpenXcomExMore/commit/41d4bd5395ad8327cda2008c4da191300bbba3ef
https://github.com/WarStalkeR/OpenXcomExMore/commit/7a661b2b5fea8a13a2fa4b738206f76ebe48b897

[0xEBJC]

This implementation has one big issue: sorting and allocation. Lets assume that your two hangars. One allows types {0,1,2,3} and another allows types {0,1,3,4} and here you encounter issue - which craft type should be placed first? Basically, you might end up with issue: you've bough type 3 craft and it was placed in first hangar, the second hangar is still empty. And if you're trying to buy type 2 craft, you can't because the only compatible hangar is occupied, whilst 2nd hangar is unused.

In my case, to avoid this issue, I implemented craft size parameter, allowed granulation of craft size ranges to a craft class and only then implemented multi-craft hangars support that rely on craft size to sort crafts via heuristic approach into craft slots provided by hangars.

You can take a look at my approach here:
https://github.com/WarStalkeR/OpenXcomExMore/commit/41d4bd5395ad8327cda2008c4da191300bbba3ef
https://github.com/WarStalkeR/OpenXcomExMore/commit/7a661b2b5fea8a13a2fa4b738206f76ebe48b897

I see your point.

I was thinking that when adding a new craft, the logic would check total available slots and move crafts accordingly if needed to other hangars automatically, so if a crafttype 3 was in one specific hangar and blocked another craft then crafttype 3 would just be moved to the other hangar.


i'll look at your PR and see what your approach looks like

[zee_ra]

This implementation has one big issue: sorting and allocation. Lets assume that your two hangars. One allows types {0,1,2,3} and another allows types {0,1,3,4} and here you encounter issue - which craft type should be placed first? Basically, you might end up with issue: you've bough type 3 craft and it was placed in first hangar, the second hangar is still empty. And if you're trying to buy type 2 craft, you can't because the only compatible hangar is occupied, whilst 2nd hangar is unused.

In my case, to avoid this issue, I implemented craft size parameter, allowed granulation of craft size ranges to a craft class and only then implemented multi-craft hangars support that rely on craft size to sort crafts via heuristic approach into craft slots provided by hangars.

You can take a look at my approach here:
https://github.com/WarStalkeR/OpenXcomExMore/commit/41d4bd5395ad8327cda2008c4da191300bbba3ef
https://github.com/WarStalkeR/OpenXcomExMore/commit/7a661b2b5fea8a13a2fa4b738206f76ebe48b897

The problem arises from having multiple types per hangar.  Now, we may have just one possible type per hangar.  It may either be a numeral or a wildcard.  For most practical purposes it is sufficient.

• There could be one huge space port for e.g. Avenger.
• There could be regular hangars for airplanes.
• There could be garages for cars.
• There could be a wildcard aerodock for 2-4 planes.

Now, the only practical difficulty that occurs with this specification is that it's undesirable for space planes to be fittable into aerodock.  That could be solved by forbidding the wildcard matching in the craft specification.  In fact, we could do differently:

• Crafts could only be matched with their specified hangar type.
• For some crafts, wildcard matching could be enabled.

Given that, we actually don't need the wildcard matching, but rather an ability to specify an alternate default match for some crafts.  For crafts without a hangar type set, we might as well assume a zero value, which would be a default one.

Thus, we have the following approaches for craft definitions:


hangarType: 1
defaultHangarTypeEnabled: true



hangarType: 1
defaultHangarType: 0

[zee_ra]

With the second approach, where we specify the default type specifically, we could have a repair dock, which would be able to accommodate some of the relevant craft types.  For example, we may want certain airplanes and vehicles to be able to undergo modifications.  Then, we just specify for them


defaultHangarType: 4


Where 4 is the type of the repair dock (where modifications to the craft could be made).  This allows us to have a special type of hangar at a production base, while keeping the crafts completely segregated otherwise.

[zee_ra]

This implementation has one big issue: sorting and allocation. Lets assume that your two hangars. One allows types {0,1,2,3} and another allows types {0,1,3,4} and here you encounter issue - which craft type should be placed first? Basically, you might end up with issue: you've bough type 3 craft and it was placed in first hangar, the second hangar is still empty. And if you're trying to buy type 2 craft, you can't because the only compatible hangar is occupied, whilst 2nd hangar is unused.

In my case, to avoid this issue, I implemented craft size parameter, allowed granulation of craft size ranges to a craft class and only then implemented multi-craft hangars support that rely on craft size to sort crafts via heuristic approach into craft slots provided by hangars.

You can take a look at my approach here:
https://github.com/WarStalkeR/OpenXcomExMore/commit/41d4bd5395ad8327cda2008c4da191300bbba3ef
https://github.com/WarStalkeR/OpenXcomExMore/commit/7a661b2b5fea8a13a2fa4b738206f76ebe48b897

I think there's an even simpler solution that exists.  Even the idea of wildcards discussed earlier today would not be necessary.

We need not sizes, but rather an ordered sequence of hangar types.  We could think intuitively of this sequence as a sequence of sizes, of course.  The numeral order provides a natural relation for ordering the chosen hangar type values, without explicitly specifying an ordering relation anywhere.

The hangars are filled with the smallest (i.e. earliest in sequence) size of a vehicle.  This way, we would never run into a counter-example of the type you have proposed earlier.

[zee_ra]

This implementation has one big issue: sorting and allocation. Lets assume that your two hangars. One allows types {0,1,2,3} and another allows types {0,1,3,4} and here you encounter issue - which craft type should be placed first? Basically, you might end up with issue: you've bough type 3 craft and it was placed in first hangar, the second hangar is still empty. And if you're trying to buy type 2 craft, you can't because the only compatible hangar is occupied, whilst 2nd hangar is unused.

In my case, to avoid this issue, I implemented craft size parameter, allowed granulation of craft size ranges to a craft class and only then implemented multi-craft hangars support that rely on craft size to sort crafts via heuristic approach into craft slots provided by hangars.

You can take a look at my approach here:
https://github.com/WarStalkeR/OpenXcomExMore/commit/41d4bd5395ad8327cda2008c4da191300bbba3ef
https://github.com/WarStalkeR/OpenXcomExMore/commit/7a661b2b5fea8a13a2fa4b738206f76ebe48b897

Another way we may eliminate this counter-example is if we allow only one class of hangars that allow multiple vehicle types per base.  All the rest of hangars might as well be strictly class-specific.

I think this is an even better approach than ordering by size or sequence.  If we proceed with ordering, then we would be in a situation where vehicles could be distributed among different hangar types.  This may not be desirable lore-wise, since aircraft hangar, vehicle hangar, and space hangar are rather different.

We should always have the ability to have at least one hangar type that admits multiple vehicle types, because such hangar is necessary for a production base.  However, would it really make sense for a space hangar to admit cars?  In general, a space hangar should admit only one vehicle type, which is a spacecraft.  If a hangar admits more than one vehicle type, then it is either because it is a production dock (producing Interceptor and Avenger), or maybe a spacedock that could receive airplanes.  In general, the use case for more than one type of hangar that could admit more than one type of vehicle is at best rare.

Thus, I think that the logic should be as follows.

• Keep the current logic with allowing only one vehicle category per hangar with hangar types specified.
• Allow only one type of hangar (that is, there could be two or more, but they must admit the same set of vehicles) per base that could admit more than one vehicle types.

An extension of this approach is possible.

• Implement an index-ordering (basically, ordering by index that represents an idea of greater or lesser size) logic discussed in my previous message.
• Allow vehicles to specify a flag that would make them exclusive to their size (as a boolean value).
• Allow only one type of hangar that could admit multiple vehicles.

[WarStalkeR]

Another way we may eliminate this counter-example is if we allow only one class of hangars that allow multiple vehicle types per base.  All the rest of hangars might as well be strictly class-specific.

I'll tell you from the get go that any solution that requires to limit modding capacity of the game is horrible solution (from modding perspective). Because for example, if somebody wants to implement a hangar that can only house aircrafts and submarines and one more hangar type that can house tanks and aircrafts - it won't be possible to implement with your approach.

Your approach will limit modder to:
1) Normal hangar can only house aircraft, submarine or tank.
2) Unique/special hangar that can house aircraft, submarine and tank.

Alternative approach to what I implemented is simple brute-force: let modder assign, what crafts exactly can be housed in the specific hangar and push onto player the decision which craft will be put in which hangar and which other slots to block.

[zee_ra]

Alternative approach to what I implemented is simple brute-force: let modder assign, what crafts exactly can be housed in the specific hangar and push onto player the decision which craft will be put in which hangar and which other slots to block.

Could you please elaborate in detail on this?  Does the player make decisions to allocate crafts to hangars?

If the decision to allocate is automated, then we are back to your counter-example.

[rkagerer]

I'm progressing through my first playthrough of X-Com Files, and like a few others who posted in this thread, I'd really like a "Garage" facility - i.e. a 1x1 hangar for vehicles.

I really appreciate the work Flaubert did in this respect.  Is there any chance of it being adopted into stock OXCE anytime soon?

In the meantime I looked at the older Garage mod, as well as the Facility Expansion Pack mod.  Unfortunately both require Brutal-OXCE, which hasn't been compiled for Android.  I'm playing on both Windows and Android (syncing savegames back and forth), so don't want to introduce content that would break my game on that platform.  I'm not interested in the other Brutal-AI features at this point, I just want a 1x1 vehicle hangar.  Once you reach midgame and base space is at a premium, it becomes a bit frustrating that one tiny little vehicle takes up a whole aircraft hangar.  I need to keep a Land Rover around for undercover missions, and prefer it at the same base as my primary soldier pool.  The 1x1 garage would enable this and make my game much more fun!