Multi-Craft Hangars, Craft Sizes, Custom Craft Classifications & More...

[Meridian]

Very clever way of sneaking in a second dimension, and even without increasing (computational) complexity by much, I have to give you that.

And it MIGHT just be enough, I honestly don't know, I'll need to think about it more and weigh all the cons and pros.

Pros (same as before):
- much better computational complexity than my solution
- guaranteed solution (if it exists)
- no manual craft allocation (although having manual craft allocation isn't necessarily a con, it could be useful as a parallel feature for all of us "OCD" guys)

Cons:
1. not the most intuitive syntax for modders
2. mental gymnastics needed to design the number ranges for craft classes
3. easy to fail the mental gymnastics, e.g. too small ranges, resulting in overflow between ranges caused by added weight/size (from weapons)
4. only 2 dimensions... yes, I know, with even more mental gymnastics, you could encode any number of dimensions into natural numbers, but that's honestly too much to ask for
5. inability to define arbitrary/custom combinations, e.g. if land=1-99, water=100-199, space=200-299, I can't make a hangar for land+space crafts

Cons severity (for me):
Low: 1
Mildly annoying: 2, 3
Questionable: 4
Possible deal-breaker: 5

Unless I'm mistaken, point 5 is where flexibility is lost, but computational complexity is capped at pleasant levels.
Not an easy choice.

[WarStalkeR]

1. not the most intuitive syntax for modders

It always can be altered. You can decide on better syntax. It's just I got used to '- [A, B, C, D, E]' so much that went along with it. Yankes suggested to go with '{x:, y:, min:, max, hide:}' - but I didn't had enough time to analyze similar code in order to implement it.

2. mental gymnastics needed to design the number ranges for craft classes

Well, this code is pretty much carbon copy from 'monthlyRatings' and 'missionRatings' - I didn't want to make something even more complicated and I couldn't see any simpler solution.

3. easy to fail the mental gymnastics, e.g. too small ranges, resulting in overflow between ranges caused by added weight/size (from weapons)

That's only if modder decides to go along with weapons/systems increasing craft size - then it is unavoidable deep dive. If modder decided to stick to the craft size only for craft classification and hangar slots, then it isn't complicated. Also, overflow won't happen as long as default 'craftsCanChangeClass: false' isn't changed.

4. only 2 dimensions... yes, I know, with even more mental gymnastics, you could encode any number of dimensions into natural numbers, but that's honestly too much to ask for

The more dimensions there are, the more computational complexity increases. I already was horrified how complicated 'Base::getFreeCraftSlots(craftSize)' became. If before I was easily handling everything via 'int freeSlotsNum', with min/max I had to switch to 'std::vector<std::pair<int, int>> freeSlots'.

5. inability to define arbitrary/custom combinations, e.g. if land=1-99, water=100-199, space=200-299, I can't make a hangar for land+space crafts

Yeah, in the same slot you won't be able to put ranges 1-99 and 200-299. You will need to define two different slots for it. On the other side, I can add another facility variable `craftCap` (or 'craftOptionGroups') that will allow you to use only one of two slots - it won't be even that much complicated, compared to refactor I already did in order to implement min/max.

EDIT: Now that I think... The 'craftOptionGroups' might be even simpler solution than I thought and it will allow you to achieve the effect you want and almost without increasing computation complexity.

[Flaubert]

It always can be altered. You can decide on better syntax. It's just I got used to '- [A, B, C, D, E]' so much that went along with it. Yankes suggested to go with '{x:, y:, min:, max, hide:}' - but I didn't had enough time to analyze similar code in order to implement it.
Well, this code is pretty much carbon copy from 'monthlyRatings' and 'missionRatings' - I didn't want to make something even more complicated and I couldn't see any simpler solution.
That's only if modder decides to go along with weapons/systems increasing craft size - then it is unavoidable deep dive. If modder decided to stick to the craft size only for craft classification and hangar slots, then it isn't complicated. Also, overflow won't happen as long as default 'craftsCanChangeClass: false' isn't changed.
The more dimensions there are, the more computational complexity increases. I already was horrified how complicated 'Base::getFreeCraftSlots(craftSize)' became. If before I was easily handling everything via 'int freeSlotsNum', with min/max I had to switch to 'std::vector<std::pair<int, int>> freeSlots'.
Yeah, in the same slot you won't be able to put ranges 1-99 and 200-299. You will need to define two different slots for it. On the other side, I can add another facility variable `craftCap` (or 'craftOptionGroups') that will allow you to use only one of two slots - it won't be even that much complicated, compared to refactor I already did in order to implement min/max.

EDIT: Now that I think... The 'craftOptionGroups' might be even simpler solution than I thought and it will allow you to achieve the effect you want and almost without increasing computation complexity.

Why don't you use bit groups for every sub-decision category? Computationally IS not much burden, as bit masks/bit shifts are computationally easy to manage.
This way every craft/hangar would be made of a "single number" which is actually composed of it's several subgroups classification. One-on-one assignation would be on that number basis. And one-to-many on comparing just the meaningful bits.

My only concern with this approach is about allocation management when you buy/transfer/produce crafts but, with a "disciplined"code, sure It can be achieved.

(Of course, I'm talking about internal representation/management; on the modder side they would just need a enumerated list of characteristics as you proposed; conversion would be done when reading ruleset and just for i ternal rep/management)

[Meridian]

Maybe I understand something incorrectly, or maybe I'm simply wrong, but:

1/ we don't have a problem with space constraints, there is nothing forcing us to use bit maps, we can easily use numbers or even strings... and all 3 internal representations will have similar complexity (on the same order of magnitude)

2/ I assume your "single number" representation would allow all value combinations in all dimensions... in which case WarStalkeR's quick allocation algorithm wouldn't work, his algorithm poses constraints on the allowed combinations in order to not have to brute-force
(or if your representation poses same constraints, then I don't see the advantage over the solution he already implemented)

[WarStalkeR]

Why don't you use bit groups for every sub-decision category? Computationally IS not much burden, as bit masks/bit shifts are computationally easy to manage.

Why complicate things, when 'std::vector<>' handling in C++ already does everything for you?

Maybe I understand something incorrectly, or maybe I'm simply wrong, but:

1/ we don't have a problem with space constraints, there is nothing forcing us to use bit maps, we can easily use numbers or even strings... and all 3 internal representations will have similar complexity (on the same order of magnitude)

2/ I assume your "single number" representation would allow all value combinations in all dimensions... in which case WarStalkeR's quick allocation algorithm wouldn't work, his algorithm poses constraints on the allowed combinations in order to not have to brute-force
(or if your representation poses same constraints, then I don't see the advantage over the solution he already implemented)

I already partially implemented slot grouping in my code (still not in the repository, as it is work in progress). And frankly, I feel like it is very, very, very bad idea already. And I will explain why.

Using this code, it is possible to group slots.

Code: [Select]

  - type: STR_THAT_FANCY_HANGAR
    crafts: 3
    craftOptions:
      - [-12, -12, 20, 49, false]
      - [-12, -12, 2, 9, false]
      - [14, -12, 20, 49, false]
      - [14, -12, 2, 9, false]
      - [1, 6, 20, 49, false]
    optionGroups: [2, 2, 1]
It will group 1st and 2nd 'craftOptions' into group #1, 3rd and 4th into group #2 and 5th into group #3. When slots are grouped, only one of them is allowed to store craft. If craft is stored in 1st of group #1, 2nd slot won't be accessible.

All sounds great, until code attempts to sort them. For example, let's assume I already have one Jetbike (size 25) and one Bicycle (size 5). Despite logically being obvious that there is place for either new Jetbike or Bicycle, code will allow you to get only new Jetbike, because sorting code isn't that smart (it looks sorts by looking for a smallest slot for biggest ship). In addition, once you'll get another Jetbike, game will throw warning message that there are no free slots for Bicycle, because group #1 and group #2 are occupied Jetbikes.

Right now I'm looking into replacing this sorting function with one that utilizes heuristic-based approach, but it might be a little bit complicated and requires more testing, although it shouldn't increase computing complexity by much.

P.S. Meridian, please join Matrix chat, because some code discussions can accelerate process by much.

[Flaubert]

Maybe I understand something incorrectly, or maybe I'm simply wrong, but:

1/ we don't have a problem with space constraints, there is nothing forcing us to use bit maps, we can easily use numbers or even strings... and all 3 internal representations will have similar complexity (on the same order of magnitude)


Maybe I understand something incorrectly, or maybe I'm simply wrong, but:
2/ I assume your "single number" representation would allow all value combinations in all dimensions... in which case WarStalkeR's quick allocation algorithm wouldn't work, his algorithm poses constraints on the allowed combinations in order to not have to brute-force
(or if your representation poses same constraints, then I don't see the advantage over the solution he already implemented)

To avoid a lot of nested if-elses, for example. Though I admit that a numeric range representation could be very similar, considering number positions (hundreds, tens, units)  the same role as group bits. Masking and shifting bits is a lot faster than divisions/mod operations, but probably execution speed is not a problem in this game, so perhaps you're right.

[Flaubert]

Why complicate things, when 'std::vector<>' handling in C++ already does everything for you?
I already partially implemented slot grouping in my code (still not in the repository, as it is work in progress). And frankly, I feel like it is very, very, very bad idea already. And I will explain why.

Using this code, it is possible to group slots.

Code: [Select]

  - type: STR_THAT_FANCY_HANGAR
    crafts: 3
    craftOptions:
      - [-12, -12, 20, 49, false]
      - [-12, -12, 2, 9, false]
      - [14, -12, 20, 49, false]
      - [14, -12, 2, 9, false]
      - [1, 6, 20, 49, false]
    optionGroups: [2, 2, 1]
It will group 1st and 2nd 'craftOptions' into group #1, 3rd and 4th into group #2 and 5th into group #3. When slots are grouped, only one of them is allowed to store craft. If craft is stored in 1st of group #1, 2nd slot won't be accessible.

All sounds great, until code attempts to sort them. For example, let's assume I already have one Jetbike (size 25) and one Bicycle (size 5). Despite logically being obvious that there is place for either new Jetbike or Bicycle, code will allow you to get only new Jetbike, because sorting code isn't that smart (it looks sorts by looking for a smallest slot for biggest ship). In addition, once you'll get another Jetbike, game will throw warning message that there are no free slots for Bicycle, because group #1 and group #2 are occupied Jetbikes.

Right now I'm looking into replacing this sorting function with one that utilizes heuristic-based approach, but it might be a little bit complicated and requires more testing, although it shouldn't increase computing complexity by much.

P.S. Meridian, please join Matrix chat, because some code discussions can accelerate process by much.

Of course, allocation of NEW crafts is the main problem here. If a craft has several possible slots on different hangar types, you don't have only to search for possible free slots but also consider how it affects allocation of the existing crafts. As you could end using a slot which stops acquiring/allocating another craft that, with a different allocation for the in itial, could be acquired.
In my first attempt "Big/small hangars", in which small crafts could be allocated also into big hangars, I solved this forcing allocation of Big crafts first, by ordering array of crafts at bases by size, when a new craft was bought/produced/transfered. But with all different combinations you propose (several different sizes; underwater/aerial; earth/space...) this problem is more complicated  (if you consider hangars which could allocate more than 1 type of crafts, and crafts that could be stored in more than one type of hangar)

[WarStalkeR]

Meridian, I have a piece of great news. Beside implementation of slot grouping (with modding syntax examples above), I've succeeded with code refactor for allocation and sorting functions through heuristic-based approach, and without increasing computing complexity by much.

You can take the look at the code here: https://github.com/WarStalkeR/OpenXcomExMore/commit/9e61c36934c6e318bfb6d48282cb1e74293dbfa6

Sadly, heuristic-based approach isn't perfect and only perfect will be method with backtracking, but it might have huge performance impact. For the most cases, like 99.9% of them, heuristic-based approach should be more than enough.

Although I tested core features (allocation, syncing & etc) for all potential issues. Code still requires polish/update in some other parts that not yet reflect 'optionGroups' change (Analysis and Ufopaedia for sure), but this is less of an issue.

Of course, allocation of NEW crafts is the main problem here. If a craft has several possible slots on different hangar types, you don't have only to search for possible free slots but also consider how it affects allocation of the existing crafts. As you could end using a slot which stops acquiring/allocating another craft that, with a different allocation for the in itial, could be acquired.

I already resolved it. As for how, you can see code itself in latest commit to my repository.

[Flaubert]

I already resolved it. As for how, you can see code itself in latest commit to my repository.

Great news!!! Congratulations!!
I'll look your solution at your Code. I'm very interested! I thought heurístics would be too difficult to implement.
Hope we finally have this hangar feature at oficial repo soon!!

[WarStalkeR]

1. not the most intuitive syntax for modders
2. mental gymnastics needed to design the number ranges for craft classes
3. easy to fail the mental gymnastics, e.g. too small ranges, resulting in overflow between ranges caused by added weight/size (from weapons)
4. only 2 dimensions... yes, I know, with even more mental gymnastics, you could encode any number of dimensions into natural numbers, but that's honestly too much to ask for
5. inability to define arbitrary/custom combinations, e.g. if land=1-99, water=100-199, space=200-299, I can't make a hangar for land+space crafts

Let's return to issues you've mentioned here.

Unified diff for turning my previous 1-dimensional hangar slots turning into 2.5-dimensional ones: https://github.com/WarStalkeR/OpenXcomExMore/compare/e23a5a0..19b8aa0?diff=unified

Unified diff for implementing slot grouping, heuristic sorting & etc: https://github.com/WarStalkeR/OpenXcomExMore/compare/7aa49dc..19b8aa0?diff=unified

Low: 1

Syntax will be changed for sure. I will do it closer to the weekend.

Mildly annoying: 2, 3

2 - completely avoidable, if modder will decide to allocate only single value to each craft size. 3 - completely avoidable, if modder doesn't add weapons/systems that increase size. In addition, default safety measure 'craftsCanChangeClass: false' is implemented to ensure that craft can't change class. It can be disabled through the modding, if modder has such desire.

Questionable: 4

Pretty much resolved. Now there are 2.5 dimensions without ramping up amount of required mental gymnastics.

Possible deal-breaker: 5

Resolved. Beside slot min/max size, you can group slots (so only one slot from group is used). In addition, all of that is supported by heuristic sorting algorithm that makes sure for 99% that no potential slots or groups are wasted, and all of that without intense or very complex calculations. Analysis screen, Ufopaedia screen, craft refitting screen (and some other parts) also received relevant updates.

[WarStalkeR]

Added fix: multi-craft hangar destruction now also results in loss of all housed crafts. Do note that if hangar instead of destruction gets only damaged or ruined (without destruction), crafts are transferred to damaged/ruined hangar.

Added feature: in base view, while hovering over multi-craft hangar you can use mouse wheel up/down to switch between crafts that you open in refit screen via right mouse button.

Multi-craft hangar damage/destruction is a little bit dumb right now, it either transfer all crafts to the damaged/ruined version (even if doesn't have same amount of slots) or destroys all crafts if multi-craft hangar doesn't have ruined version.

I will implement smarter version this weekend, where it only moves crafts to slots that "survived" (i.e. available in ruined variant) and destroys all other crafts that didn't have replacement slot for them.

[Flaubert]

When I was working on my version of this feature, some people asked me about the possibility to add another -so
mehow related- feature to exchange two crafts at different bases. At the moment, if you have 2 crafts at 2 hangars in different bases, you need a 3rd hangar to be able to do that exchange -- transfer craft1 to free hangar; transfer craft2 to -ex-craft1 hangar; transfer craft1 to ex-craft2 hangar --

Do you think this could be implemented with your version or would be very difficult due to allocation-rule checking?

[WarStalkeR]

Do you think this could be implemented with your version or would be very difficult due to allocation-rule checking?

When craft becomes TRANSFER_CRAFT, slot on the receiving side is allocated and it is unavoidable. Anyway, making it possible will require major refactoring of original code and how item transfer is handled.

I'm pretty sure Meridian and Yankes wouldn't want me to touch something that works already perfectly fine.

[Flaubert]

When craft becomes TRANSFER_CRAFT, slot on the receiving side is allocated and it is unavoidable. Anyway, making it possible will require major refactoring of original code and how item transfer is handled.

I'm pretty sure Meridian and Yankes wouldn't want me to touch something that works already perfectly fine.

Yes, I know about TRANSFER_CRAFT management, but it's true that it seems "somehow silly" needing to have 3 hangars to manage 2 crafts going from one base to another -and note hangars take a lot of space in bases-. At original/current code I think it can be done ( a double check at the hangar allocation rules at both bases, discounting the transferred crafts, then a TRANSFER order for boths craft at the same time). With modified hangar rules  -mine, your's, Meridian's-  which allow more classes and felxibility, that check will be a lot more difficult for sure.

[WarStalkeR]

Yes, I know about TRANSFER_CRAFT management, but it's true that it seems "somehow silly" needing to have 3 hangars to manage 2 crafts going from one base to another -and note hangars take a lot of space in bases-. At original/current code I think it can be done ( a double check at the hangar allocation rules at both bases, discounting the transferred crafts, then a TRANSFER order for boths craft at the same time). With modified hangar rules  -mine, your's, Meridian's-  which allow more classes and felxibility, that check will be a lot more difficult for sure.

You need to understand shipping/transfer algorithm of the game. OXCE doesn't have simultaneous transfer between two sides, like X-COM Apocalypse does. All transfer orders/menus are one-sided only. In order to implement the logic you're speaking about, you need to completely rework shipping/transfer code, especially part when you select what to transfer, since it does checks when you change amount and not when you click the "ship/transfer" button. And this is very huge amount of work, which isn't really a priority, not even in the very long run, as there are other more interesting features that are waiting for implementation.

If you're eager, you're welcome to completely rework the transfer/shipping screen and handling, and maybe it can make into OXCE.