Post by: krautbernd on November 10, 2022, 07:02:59 pm
Something like
Code: [Select]
crafts:
- type: STR_VAN
requires:
- STR_LOGISTICS
sprite: 829
fuelMax: 9999
damageMax: 25
speedMax: 75
hangarType: garageCode: [Select]
facilities:
- type: STR_HANGAR
spriteShape: 9
spriteFacility: 9
size: 2
buildCost: 200000
buildTime: 25
monthlyCost: 25000
hangarType: garage
crafts: 1If a craft has no defined hangar type default to vanilla behaviour and ignore hangarType entry on facilities. If a craft definition includes a hangar type check for free hangar of that type. If free hangar of that type exist assign craft to first free hangar of that type. If no free hangars of that type exist throw "no free hangars" error.
That way vanilla craft treat all facilities with craft slots the same, while proper implementation requires all craft to have an assigned hangarType.
Would it be possible to implement something along these lines?
Post by: Meridian on November 10, 2022, 07:58:54 pm
The feature is still planned, but it is very difficult to implement (in a backwards-compatible way).
Also, I'm not sure what exactly do you mean by hangar sizes... but whatever it is, the custom hangar types are more difficult to implement than custom hangar sizes... so if you wanted to propose an easier solution, I'll have to disappoint you there.
Post by: krautbernd on November 10, 2022, 11:14:01 pm
My suggestion is to drop and simplify this. No "default" craft types, no multiple different "craft types" per hangar. Just one craft type per hangar (or one hangar type per craft, however this is implemented).
Require all crafts to have an assigned hangar type (if a mod implements the feature) or no crafts have an assigned hangarType (i.e. vanilla). Alternatively assign crafts with no hangar type first, ignoring hangarType restrictions. That way any mod not implenting the feature as well as vanilla should default to vanilla behaviour.
Maybe I am missing something here in regards to backwards-compatibility.
Post by: Meridian on November 10, 2022, 11:52:09 pm
However, I will still likely go for the full solution.
I feel some modders will not accept just one type, and "force" me to implement multiple types later anyway... and it's better for me to do it that way from the start. Splitting it into two phases will again likely make it more complicated around backwards-compatibility (I'd have to be backwards-compatible not only with vanilla but also with phase 1 solution).
As for solving the "sorting/assigning mini-game", I already have a solution for that... it will be purely manual, the player will be forced to do it :)
Real-world mini-games are going to be much less complicated than a generic algorithm I'd have to do for worst cases.
And the manual mini-game GUI is necessary anyway for when the player wants to move craft within available hangars to allow buying/manufacturing more craft.
Post by: mutantlord on February 07, 2023, 11:47:39 am
Post by: Meridian on February 07, 2023, 11:56:50 am
Post by: mutantlord on February 07, 2023, 02:49:58 pm
Post by: Flaubert on February 22, 2023, 10:28:07 pm
It might help, I'm not sure, I'll have to look at it again.
However, I will still likely go for the full solution.
I feel some modders will not accept just one type, and "force" me to implement multiple types later anyway... and it's better for me to do it that way from the start. Splitting it into two phases will again likely make it more complicated around backwards-compatibility (I'd have to be backwards-compatible not only with vanilla but also with phase 1 solution).
As for solving the "sorting/assigning mini-game", I already have a solution for that... it will be purely manual, the player will be forced to do it :)
Real-world mini-games are going to be much less complicated than a generic algorithm I'd have to do for worst cases.
And the manual mini-game GUI is necessary anyway for when the player wants to move craft within available hangars to allow buying/manufacturing more craft.
Hello,
are you considering a lot of different types of crafts? Or just big/small? If it's the later, I've developed a variation of your code in which every craft has an "assigned" variable, so it's possible to know if that kind is already allocated in the next facilities to draw. Sadly, it's necessary to check for all the crafts when drawing every hangar facility -and its crafts-, until you find the more apropriate, but as vector-of-crafts it's not expected to be large, I think it works well.
Facilities for small-crafts-only are allocated at the front of the facilities vector when created, so "smallcrafts" are assigned first at small slots, and then, when all small slots are busy, all types of crafts are allocated at big slots.
In craft rules you must use a key for big/small craft (no key=big); in facilities rules (hangar type), you should use another key for "allow_only_small_crafts/allow_any_craft" (no key = any craft).
I also added to hangars rules, when they can contain more than 1 craft, a list of positions for the crafts sprites in the hangar tile (offsets with respect to the center of the tile). This way you can allocate more than 1 craft in a Hangar, and see the crafts in the BaseEscape.
I've made some tests, and draw routine works well, though there are a lot of changes to do -and mainly, to test- yet, regarding rules of acquisitions/manufcaturing/transfers and so on. At now purchase-of-crafts seems to work well too, observing rules of which-crafts-can-be-purchased depending of free (big/small) slots; manufacture of crafts seems to work also; I've not touched transfers yet, but I think it could be done using similar structures than in purchase/manufacture.
I must work also on what happens when an hangar is destroyed, as if there is more than 1 craft, current rules of craft destruction (based on the sprite at the hangar tile) must be reworked.
I'm sure that changes you are doing towards this feature will be better, but I don't know if I could be any help towards the introduction of this feature. If so, please let me know.
Finally, thanks a lot for your work with this engine. Xcom was one of mi favourite games when I was a child, and it was a big-pleasant surprise when I found this great port. Not only to play again, with better and polished mechanics, but also for the opportunity to learn about how it works.
Post by: Meridian on February 23, 2023, 09:27:32 am
are you considering a lot of different types of crafts? Or just big/small?
Many different types, not just big/small.
I'm sure that changes you are doing towards this feature will be better, but I don't know if I could be any help towards the introduction of this feature. If so, please let me know.
Not sure, probably not (with the coding).
I still have my old attempt and Yankes' old attempt available, I don't really need more code for inspiration.
The complexity is in the save backwards-compatibility (both old saves in new version and new saves in old version), and in a multitude of functional corner-cases.
I could use help with thorough testing though (from someone who can also read the code), maybe I can publish a beta version in a separate branch when ready and ask for help there.
Finally, thanks a lot for your work with this engine. Xcom was one of mi favourite games when I was a child, and it was a big-pleasant surprise when I found this great port. Not only to play again, with better and polished mechanics, but also for the opportunity to learn about how it works.
Thanks.
Most of your gratitude should however be pointed at SupSuper (for starting and for finishing this project) and at Warboy (for all the "how it works" stuff).
Many others helped too of course, but without these two gentlemen, it would not happen.
Post by: TBeholder on February 27, 2023, 06:14:51 am
but it is very difficult to implement (in a backwards-compatible way).Why would it cause any more backwards-compatibility problems that requiresBaseFunc?
Hangar would have functionality property (much like provideBaseFunc, but affecting only this facility) set (or maybe even tag?). Craft has property that requires a hangar with certain functionality, which defaults to empty string. If a given craft has this requirement set, the required functionality is matched when available hangars are checked, so they are ineligible unless it’s present, much like they were full. Otherwise, all hangars remain good for this craft.
Then any mod not using this feature would be unaffected.
Post by: Meridian on February 27, 2023, 08:38:32 am
Post by: Yankes on February 27, 2023, 12:03:01 pm
At least in my try code automatically tried assign crafts to hangars and only there were no space/valid combination (3 big and 2 small hangars will not fit 4 big crafts)
game report missing space for given craft.
One problem is that in theory it could be 36 hangars and unlimited number of crafts, and this in naive implementation could take eons to decide what is best fit
(as there 3.7199333e+41 possible combination of putting 36 crafts in 36 hangars). We can cut corners to reduce this insane number like allowing only 16 or 32 crafts (for 16! we have less than day to naive check every combination),
ignoring similar combinations (like in case default game you have 3 crafts and 6 possible combinations but you can use first one as all are equivalent).
And many other, and there is chance to reduce this time to less than second in even more extreme case.
Post by: Flaubert on March 01, 2023, 08:52:43 pm
You can see it working at this video, in the discord channel:
https://discordapp.com/channels/292085473890009088/330653502693179394/1080189519426490560
Code is in my public repository at github: https://github.com/NHerreroReder/OpenXcomPruebas/tree/MultipleHangar
Feel free to use or modify it; I have no intention to make a fork, as OXC, OXCE authors have planned to add a similar feature in the future (which probably will be better/more complete). I just though it could be a funny way to learn more about the game engine.
I tested this feature with XcomFiles MOD (v2.8 and 2.9) and a modified XFCHangar_Expansion_Pack SUBMOD. In order to use the new features:
- Hangars with small slots must have the "smallCraftsOnly: true" tag in their rule definition.
- Hangars with more than one craft must have a list of "craftSlots:" with their positions [x,y,z] in their rule definition:
...
crafts: 2
craftSlots:
- [11, -11, 0]
- [-11, 11, 0]
where x, y are distance respect the center of the hangar sprite; z is not used
- Crafts to be allocated in such slots must have a "isSmallCraft: true" tag in their rule definition
Of course you can avoid using those tags if your craft is not considered small and/or your hangar facility doesn't differentiate big and small crafts. This way I think backward compatibility will not be a problem.
I attached to this message a modified version of XFCHangar_Expansion_Pack SUBMOD which include two new types of hangars (2x2 for 2 small slots and 3x3 for 4 big slots). It modifies also craft rules to include required tags at some of the Xcom Files vehicles (Van, Cars, Hummer,...)
Post by: DoxaLogos (JG) on March 01, 2023, 10:41:34 pm
Post by: Yankes on March 01, 2023, 11:25:48 pm
Hello. I (think I) finished my attempt of OXCE modification to allow hangars with small and big crafts (but only "small" or "big", not a mix). I've tested (but not exhaustive testing) all but hangar destruction. All crafts are shown at baseescape, and you can select them with mouse right button.Ok, but its very limited, effective only two types of craft available, if I recall correctly Meridian target fro multiple hangar types, not only two.
You can see it working at this video, in the discord channel:
https://discordapp.com/channels/292085473890009088/330653502693179394/1080189519426490560
Code is in my public repository at github: https://github.com/NHerreroReder/OpenXcomPruebas/tree/MultipleHangar
Feel free to use or modify it; I have no intention to make a fork, as OXC, OXCE authors have planned to add a similar feature in the future (which probably will be better/more complete). I just though it could be a funny way to learn more about the game engine.
I tested this feature with XcomFiles MOD (v2.8 and 2.9) and a modified XFCHangar_Expansion_Pack SUBMOD. In order to use the new features:
- Hangars with small slots must have the "smallCraftsOnly: true" tag in their rule definition.
- Hangars with more than one craft must have a list of "craftSlots:" with their positions [x,y,z] in their rule definition:
...
crafts: 2
craftSlots:
- [11, -11, 0]
- [-11, 11, 0]
where x, y are distance respect the center of the hangar sprite; z is not used
- Crafts to be allocated in such slots must have a "isSmallCraft: true" tag in their rule definition
Of course you can avoid using those tags if your craft is not considered small and/or your hangar facility doesn't differentiate big and small crafts. This way I think backward compatibility will not be a problem.
I attached to this message a modified version of XFCHangar_Expansion_Pack SUBMOD which include two new types of hangars (2x2 for 2 small slots and 3x3 for 4 big slots). It modifies also craft rules to include required tags at some of the Xcom Files vehicles (Van, Cars, Hummer,...)
Xcom Files could for example use submarine subpen or dedicate rocket launch bay.
Post by: Flaubert on March 02, 2023, 12:47:52 am
Ok, but its very limited, effective only two types of craft available, if I recall correctly Meridian target fro multiple hangar types, not only two.I really can't see the point in many specialized hangar types, where each one can only fit a limited range of crafts (you should destroy/build hangars every time you advance in crafts), but I suppose it could make sense for 'thematic modding'.
Xcom Files could for example use submarine subpen or dedicate rocket launch bay.
Perhaps giving each hangar an "id", so crafts should fit that "id" to be allocated....but you should do a lot of "id" comparisons between craft and facility vectors.
I will check if my version can be adapted this way.
Enviado desde mi Mi A2 Lite mediante Tapatalk
Post by: Yankes on March 02, 2023, 02:55:09 am
I really can't see the point in many specialized hangar types, where each one can only fit a limited range of crafts (you should destroy/build hangars every time you advance in crafts), but I suppose it could make sense for 'thematic modding'.I do not think you should spend your time on it as is very small chance it will be used, as I previously said Meridian aim for proper solution for this and we both will probably prefer one over partial solution like yours.
Perhaps giving each hangar an "id", so crafts should fit that "id" to be allocated....but you should do a lot of "id" comparisons between craft and facility vectors.
I will check if my version can be adapted this way.
Enviado desde mi Mi A2 Lite mediante Tapatalk
Post by: Flaubert on March 02, 2023, 08:48:58 am
Post by: TBeholder on March 03, 2023, 07:44:02 pm
For example because right now the crafts don't belong to any hangars, just to a base. After this change, they will have to belong to particular hangars.Total space of <all hangars with given functionality> could be checked just as well… But this would only build up on top of a workaround, of course.
Facility does have association with craft used for GUI, however (via _craftForDrawing/getCraftForDrawing/setCraftForDrawing).
What more complicated would be required for a straightforward designation back and forth, at this point?
I really can't see the point in many specialized hangar types, where each one can only fit a limited range of crafts (you should destroy/build hangars every time you advance in crafts), but I suppose it could make sense for 'thematic modding'.In near-vanilla, maybe only basic VTOL vs spacecraft. In expanded and hybrid mods — garage for cars, hangar for aircraft, and dock for mini-subs probably should not be the same thing.
Post by: Meridian on March 03, 2023, 09:43:02 pm
Facility does have association with craft used for GUI, however (via _craftForDrawing/getCraftForDrawing/setCraftForDrawing).
And how does that help us?
It would be even easier (not by much tho) if that (unreliable and incomplete) association didn't exist.
What more complicated would be required for a straightforward designation back and forth, at this point?
Sorry, but what exactly do you want to hear from us?
It is complicated to design, it is complicated to implement, and it is also complicated to explain what's complicated. I'm not going to write a 20-page essay about it here. I do have better things to do.
You are obviously not new to programming, if you are so puzzled by my statements, give it a try and see for yourself.
I promised I will do this feature eventually (unless I retire first), but I do need enough time and enough motivation to try again. We had already 2 failed attempts and I'm not going to start a third one before I'm confident it's going to be a successful one.
Post by: mutantlord on March 04, 2023, 04:34:23 pm
If the general modders wanting only something basic and not the more ambitious parts of the feature, then it is not necessary for the Dev to enable of something the modders don’t use.
The most basic of this hanger feature that I as a modder would want is
1x1 hanger for small general
2x2 Already exist for medium general
3x3 for large general type
1 size and 1 craft per hanger. No specialisation or multiple craft hangers.
Post by: Flaubert on March 07, 2023, 05:18:30 pm
So here it is. Now you can assign a "type" to hangars and crafts, so only crafts with the same "type id" than hangars can be allocated there.
I maintened some of the former features: having more than 1 craft per hangar; giving coordinates to draw crafts over hangar sprite (mandatory only if more than 1 craft), and select different crafts at the same hangar in Baseescape.
Backward Compatibiity is obtained giving a default type id (-1) to hangars and crafts, so they can be allocated as in vanilla.
https://www.youtube.com/watch?v=VfurPl50nHs
(also in discord: https://discordapp.com/channels/292085473890009088/330653502693179394/1082046483538399392)
https://www.youtube.com/watch?v=pC5SpVJSljQ
(also in discord: https://discordapp.com/channels/292085473890009088/330653502693179394/1082361576146882570)
In final version, hangar info in UFOPEDIA entries can be des/activated via an Advanced Option. I've added hangar type info in "Stats for Nerds" in both crafts and facilities.
(example of new rules entries)
Code: [Select]
- type: STR_UPGRADED_HANGAR
spriteShape: 534
spriteFacility: 538
size: 2
buildCost: 1000
buildTime: 1
monthlyCost: 37500
hangarType: 1
crafts: 2
craftSlots: # mandatory if crafts > 1; optional otherwise
- [11, -11, 0] # Distance to the
- [-11, 11, 0] # central point
mapName: XBUH_01
workshops: 10
storage: 50
aliens: 20
prisonType: 4
listOrder: 7261
canBeBuiltOver: true
buildOverFacilities:
- STR_HANGAR
Code: [Select]
crafts: # Modify default XCom Files rules with just an hangarType
# Not modified crafts have a default "-1" hangarType
- type: STR_OPSCAR
hangarType: 0
- type: STR_VAN
hangarType: 0
- type: STR_HUMMER
hangarType: 1
- type: STR_CIVILIAN_CAR
hangarType: 0
- type: STR_LUXURY_CAR
hangarType: 0
- type: STR_DRAGONFLY
hangarType: 2
I didn't test facility (hangar) destruction yet. I need an enough advanced save for strong aliens retaliation with missile attack.
If anyone wants to peek changes I've done, they're at this public repository:
https://github.com/NHerreroReder/OpenXcomPruebas/tree/Basescape-hangars-reworked
(if you find errors/bad-implemented things, please let me know! ;) )
And if it finally neither goes anywhere nor is useful for anybody....well it was fun and let me learn a lot about OXCE source code.
Post by: mutantlord on March 12, 2023, 06:09:25 pm
Post by: Finnik on March 17, 2023, 06:39:40 pm
So here it is. Now you can assign a "type" to hangars and crafts, so only crafts with the same "type id" than hangars can be allocated there.
I maintened some of the former features: having more than 1 craft per hangar; giving coordinates to draw crafts over hangar sprite (mandatory only if more than 1 craft), and select different crafts at the same hangar in Baseescape.
Nice work (although I judge only demo video, as I have not looked through the code yet)!
The minor issue with that is a base info state with only one bar for crafts, the player would not be able to know how many slots of what type he or she has used/free. Btw, the same problem with prison type. But I don't have a solution here except overhauling base info state UI, so just saying.
Post by: MaxMahem on March 17, 2023, 07:45:03 pm
Btw, the same problem with prison type. But I don't have a solution here except overhauling base info state UI, so just saying.
I have an idea for this (clicking on the name to cycle the prison type) or maybe something else but I haven't had a chance to poke at it yet.
Post by: Flaubert on March 17, 2023, 11:40:35 pm
Nice work (although I judge only demo video, as I have not looked through the code yet)!In order to follow the "rules" of pul-request, I want to separate both features:
The minor issue with that is a base info state with only one bar for crafts, the player would not be able to know how many slots of what type he or she has used/free. Btw, the same problem with prison type. But I don't have a solution here except overhauling base info state UI, so just saying.
- the one for different types of hangars with just 1 craft each.
- and the one to have more than 1 craft in the only type of hangar in vanilla, allowing to give coordinates to show all crafts in Basescape -and selecting each craft with the mouse-
At current version if you consider more than one craft in the hangar :
1. Only one craft is shown over hangar at baseEscape view.
2. If hangar is destroyed, I think that only the shown craft is destroyed, as it uses a single pointer to Craft class to manage which craft is affected by destruction.
So, for now only 1 craft per hangar works right
Finally, I think that combining both features gives the most flexibility for modders regarding crafts/hangars management.
Enviado desde mi Mi A2 Lite mediante Tapatalk
Post by: Flaubert on March 17, 2023, 11:42:47 pm
I have an idea for this (clicking on the name to cycle the prison type) or maybe something else but I haven't had a chance to poke at it yet.That sounds good
I was considering also use different colors for different hangar types/slots at the hangars bar. Perhaps giving another "yaml" entry to hangar definitions.
Enviado desde mi Mi A2 Lite mediante Tapatalk
Post by: Flaubert on March 19, 2023, 06:24:01 pm
I know some of the OXCE developers told me that this have a very small chance to be used....but I was thinking about it when getting sleep the other night and though a (not very difficult to change) solution based in my previous attempt, and decided trying to do it next day
....
In order to follow the "new features pull-request rules", I've separated the two main novelties at my attempt related to hangar and crafts management:
1. Many Crafts in just one (type of) Hangar.
Thought you can define more than one craft for an hangar facilities, current behavior at OXCE+ is somehow broken: 1)you cannot show/select more than one craft in basescape; 2) and management for hangar with more than 1 craft is not totally working (I think it only considers the craft shown at basescape when destroying an hangar facility, for example)
You can see a video of the new suggested feature here:
https://youtu.be/0wmmdvmLTJE
I've uploaded a branch of my OXCE+ fork with this feature in this public respository:
https://github.com/FlaubertNHR/OpenXcomPruebas/tree/MultipleCraftsxHangar
2. Different classes of hangars with just one craft each (but you can choose also that different classes of crafts could be allocated in the same hangar type if you want)
Video testing this feature: https://youtu.be/hahxQA6T-nM
Branch with the code for this feature: https://github.com/FlaubertNHR/OpenXcomPruebas/tree/Multiple-Hangar-Types
At now I'm revorking another branch with both features at the same time, as I think these would give the most flexibility to modders and users, while mods which don't want to use them will continue working.
(so the URL to github repository at the former message is not valid; the new URL is
https://github.com/FlaubertNHR/OpenXcomPruebas/tree/Basescape-hangars-reworked )
Hope this would be considered enough interesting to be add at main repository. I will try to send a pull-request for these and see what happens.
Any suggestion or error found at the code or the feature is welcome!! :D
Post by: Meridian on March 19, 2023, 06:39:15 pm
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.
Post by: Flaubert on March 19, 2023, 07:29:40 pm
Post by: 0xEBJC on February 21, 2024, 12:36:26 am
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.
Post by: Flaubert on February 21, 2024, 10:10:57 am
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.
Post by: 0xEBJC on March 25, 2024, 05:38:47 pm
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 (https://openxcom.org/forum/index.php/topic,11590.0.html)
Post by: WarStalkeR on April 04, 2024, 08:12:48 pm
The code implementation I think would work would be to crate a sum of hangar types and crafts typesThis 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.
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)
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
Post by: 0xEBJC on April 05, 2024, 01:54:55 am
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
Post by: zee_ra on August 17, 2024, 08:34:37 pm
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
Post by: zee_ra on August 17, 2024, 08:42:18 pm
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.
Post by: zee_ra on August 17, 2024, 11:54:09 pm
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.
Post by: zee_ra on August 18, 2024, 12:16:01 am
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.
Post by: WarStalkeR on August 18, 2024, 09:55:41 pm
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.
Post by: zee_ra on August 19, 2024, 12:55:40 am
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.
Post by: rkagerer on September 08, 2024, 02:18:23 pm
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!
Post by: WarStalkeR on January 12, 2025, 03:04:31 pm
Could you please elaborate in detail on this? Does the player make decisions to allocate crafts to hangars?Similar to how current craft equipment system works. Modder decides to what group number weapon/equipment belongs. Then modder defines in craft what group numbers it can 'use' and then its already up to player what compatible module to equip there. I.e. completely opposite of my automatic approach.
Post by: Flaubert on January 31, 2025, 10:33:07 pm
I would define an id type for every craft; a vector of allowed IDs of crafts for every hangar; and a number of slots -which should allow ANY of the crafts at the vector IDs. If you want a Hangar with two slots and DIFFERENT crafts in each slot, I would use another approach and you should define one vector of allowed crafts for every slot at the hangar..
This approach seems easier to code, but I've feelings that some players wouldn't like the "puzzle game" of craftsallocation....but a "logic" ruleset of crafts and hangars could make it more intuitive.
Post by: Meridian on February 01, 2025, 04:22:44 pm
Post by: Flaubert on February 02, 2025, 05:57:16 pm
Do you think a "uniqueID-perBase" should be given to hangars , to make easier the task for the player? Similar to "whole-game" uniqueIds per soldiers or crafts. Not essential for feature but it would be easier for players to know they're allocating "CraftX" -e.g. "Submarine1" in "BaseZ.HangarTypeA.NumberY" -e.g. "Base Penguin- SubmarinePen-2" -than just show a list of "actually-free-allowed" hangar/slots, with no identification. Though the last could work, it would be more confusing for players IMHO.
It could be implemented in a similar fashion that uniqueIDs -"STR_SOLDIER: N" "STR_CRAFT: M"- but with similar entries per base definition.
Thanks for your work!