[Suggestion] Craft Weight Limits for Units

[ohartenstein23]

Based on a discussion with Yankes here on the 40k mod subforum, I'd like to propose a method for limiting the number of soldiers/units on a craft based on more than just their number and size.  Player craft get an optional ruleset paramter for unit weight limit and the sum of the defined weights for the armors on each unit has to be under this limit.  This would not completely replace the crew limit on craft as that has to be in place as a maximum limit for spawning units on the map, but it would allow for defining a "quality" of a unit or simulate a light craft not being able to carry as many soldiers in heavy power armor as soldiers in jumpsuits.

This could be accomplished by two parameters:

Code: [Select]

crafts:
  - type: STR_SOME_LIGHT_CRAFT
    unitWeightLimit: 220 # <-- This defines the weight limit for the craft, have a default of -1 to mean no limit
    soldiers: 10
    vehicles: 1

armors:
  - type: STR_POWER_SUIT_UC
    weightOnCraft: 44 # <-- This defines how much a unit in this armor 'weighs' for the sake of the limit

  - type: STR_NONE_UC
    weightOnCraft: -1 # <-- For an easily-defined default, -1 would mean look up the weight of the first item defined by "corpseBattle"
    corpseBattle:
      - STR_CORPSE # from xcom1 ruleset, STR_CORPSE has a weight of 22

  - type: TANK_ARMOR
    weightOnCraft: 88

  - type: HOVERTANK_ARMOR
    weightOnCraft: 110
In this example, the craft could take 220 / 22 = 10 soldiers wearing no armor but only 220 / 44 = 5 soldiers wearing either power suits or flying suits.  Any combination of soldiers in these armors would be allowed as long as they stay under this limit.  The limit would also apply for any tanks/HWP/auxiliary units loaded onto the craft - in this case it's set so that regular tanks weigh as much as 4 soldiers, the usual cost for loading a tank instead of soldiers, but the hovertank would take as much weight as 5 un-armored soldiers.  Note that if you had a unit with a weightOnCraft value of 20 or less that you would not be able to carry more than 10 units, that limit defined by "soldiers: 10" would still be respected.

Does this system make sense?  Are there ways it could be improved?  Would it bit a useful feature?

[Yankes]

Alternative implementation is only for unit is define number of spot unit take form solder limit (minimum 1 for normal and 4 for vehicles).
One benefic of this is simplicity of implementation because most of code needed is already present.

Now question is what would be useful for modders.

[Tekamthi]

another recent discussion re: FMP reached this conclusion here https://openxcom.org/forum/index.php/topic,6462.0.html

in my own context, i'm back to using item limits for the constraints this imposes on missions, as I find this a significant added difficulty factor, but craft weight limit overall would be far preferable.

Is there a reason that OP is only focused on units? ie does this already exist for items? from my perspective, ideally such a system would integrate overall craft loadout, and might have two 'limits':  a lower weight limit at which craft speed begins to be reduced, and an upper limit at which the craft just can't take off anymore.  With some existing oxce+ stuff like HK, and maybe xcom craft crash sites eventually, this would have interesting player-choice implications

[ohartenstein23]

Doing this for items would be a separate feature; not being able to bring a full compliment of soldiers just because you brought an extra rifle doesn't seem right to me.  However, Solarius Scorch would definitely be interested in seeing an item limit by weight of the items implemented as a feature, that's just not the discussion we're trying to have here.

[Tekamthi]

gotcha -- well i imagine you'd be doing most of the work that you'd need for an item model anyway, in order to accomplish the OP specs -- if the unit part were implemented, seems the item part would be a couple lines more of code?  this would be a nice add

on the other hand, Yankes' suggestion does sound like it'd be mostly on point for unit constraint, and maybe a lot less dev work

[Yankes]

Weight for units have one drawback it need some changes to UI, my version will reuse already available UI.
Another is that if we use values as `22` or `41` you could end up with situation that you left only `20` and you could not fit easy another unit.
On another hand my version is more abstract and bit less realistic, you have only choose between normal (1), superfat (2) and elephant (3) and nothing else in between.

[Yankes]

Because I was in middle of implementing this feature I pushed out implementation:
https://github.com/Yankes/OpenXcom/commit/bec2dec5882fa0c4d301cb615809d52ca5c6c4d4

If  ohartenstein23 version will get better traction and modders will prefer it, I will scrap my version before releasing 4.0

[Tekamthi]

took a glance at your code -- i'm hardly qualified to be a critic, but I think I 'get it' high-level at least

seems to me that there's substantial code required to narrow this feature to just tanks?  strikes me on 2nd thought that OP spec might be simpler in some ways.. or merge the two ideas... ie convert every unit/item's weight into a rounded item-limit integer, tallying these against the craft's existing item limit framework. Let modders adjust the weights/craft limits from there. W/ an optional weight override variable for limit purposes as per OP spec, but available on all items and units (ie if you want just one or other, override the unwanted category with 0 craftWeights), you could effectively hit everyone's wishlist here so far i think.

this might raise this issue from above re: weird item numbers and frustrations trying to fill the available # left over.. on an even more wishful version of my list, you might solve this with a "soft" limit where you start reducing craft speed and range for limit overage, rather than having a binary on/off condition.  I know I'm probably dreaming though

[ohartenstein23]

I'd rather not use this option, as in order to use this in the 40k mod, we'd have to increase the number of soldiers allowed on certain craft when there isn't more room to place spawn points.  If the player decides to put 24 normal soldiers on a craft that is supposed to hold 12 space marines and only has spawn tiles for those 12, then the rest of the units don't spawn and this can cause crashes when the player loses the craft during a mission.  Proper use of this feature shouldn't encourage doing something that would cause crashes, hence why I wanted a solution that didn't increase the total number of soldiers allowed on a craft and have to make maps with more spawn tiles just to prevent a crash.

[Dioxine]

Weight for units have one drawback it need some changes to UI, my version will reuse already available UI.
Another is that if we use values as `22` or `41` you could end up with situation that you left only `20` and you could not fit easy another unit.

Unless you already have proper weight set for all corpses, like I do : )

EDIT:
I just don't think trying to repurpose soldier number limit will work here. We plainly need a separate limitation (like weight), due to soldier spawn points being immutable. Weight limit makes a craft take a designed number of soldiers or less; tweaking the number of slots a soldier takes makes a craft take a designed number of soldiers, or less, or more (if it was designed for "large" units), which will cause trouble.
As for the GUI, the equipment pile indicator (the little "guns" that appear in the craft menu), can be repurposed to show weight if that option is used. As in, 100% weight is represented by all slots filled (make it dynamic instead of linear).

[Yankes]

Right, I simply take case when you have craft with 2*X guardsmen and try fit X marines, but I do not consider marine only crafts that should not allow more places for guardsmen.

took a glance at your code -- i'm hardly qualified to be a critic, but I think I 'get it' high-level at least

seems to me that there's substantial code required to narrow this feature to just tanks?  strikes me on 2nd thought that OP spec might be simpler in some ways.. or merge the two ideas... ie convert every unit/item's weight into a rounded item-limit integer, tallying these against the craft's existing item limit framework. Let modders adjust the weights/craft limits from there. W/ an optional weight override variable for limit purposes as per OP spec, but available on all items and units (ie if you want just one or other, override the unwanted category with 0 craftWeights), you could effectively hit everyone's wishlist here so far i think.

In reality only 3 lines contributed to this feature, rest is refactor, bug fix and unification of some code.

As Dioxine and ohartenstein23 points out my version is less practical because can only "remove spots", I will remove from this commit this "3 lines" and leave rest as is.

[Meridian]

In reality only 3 lines contributed to this feature, rest is refactor, bug fix and unification of some code.

As Dioxine and ohartenstein23 points out my version is less practical because can only "remove spots", I will remove from this commit this "3 lines" and leave rest as is.

If you don't release soon, I will be unable to merge and will have to abandon merging OXCE completely.

There's 8 months of vanilla changes, renormalization of all files, tons of OXCE refactoring (as far as I can say from bits you share with us occasionally), new OXCE features and a crapton of OXCE+ features (that I will need to painfully refactor according to OXCE refactorings... I'm already having nightmares about how will I do that in one big commit).

I cannot merge your branch in small steps, I have to take it in one batch (because I already merged OXC)... and it's getting ridiculous in size...
... please, we don't need a perfect 4.0, there's really no practical need to wait... it only makes things worse... you don't get any feedback, any testing and my work on merging grows exponentially.

Have mercy.

[davide]

Some time ago I tried to merge an very old feature made by Volutar on OXCE+.
Recompile it was a pain for all the difference and refactoring that were made on source code after the branch.
After a lot of efforts, when I recompiled it, the new feature did not work ...
Why ? ... too many change from the beginning ...
I abort the task.

Github did not help us to work in this away.

I suggest to you to read this model to use it:
https://datasift.github.io/gitflow/IntroducingGitFlow.html
SuppSuper and Warboy are welcome about this topic...

[Meridian]

Some time ago I tried to merge an very old feature made by Volutar on OXCE+.
Recompile it was a pain for all the difference and refactoring that were made on source code after the branch.
After a lot of efforts, when I recompiled it, the new feature did not work ...
Why ? ... too many change from the beginning ...
I abort the task.

That's absolutely normal... that's why we should merge often.

PS: "very old features" won't merge regardless of what tool, model or methodology you use.

[Yankes]

If you don't release soon, I will be unable to merge and will have to abandon merging OXCE completely.

There's 8 months of vanilla changes, renormalization of all files, tons of OXCE refactoring (as far as I can say from bits you share with us occasionally), new OXCE features and a crapton of OXCE+ features (that I will need to painfully refactor according to OXCE refactorings... I'm already having nightmares about how will I do that in one big commit).

I cannot merge your branch in small steps, I have to take it in one batch (because I already merged OXC)... and it's getting ridiculous in size...
... please, we don't need a perfect 4.0, there's really no practical need to wait... it only makes things worse... you don't get any feedback, any testing and my work on merging grows exponentially.

Have mercy.

I probably wanted too much to include in "big" 4.0 version. Because of this I work on this too long, I will wrap up all development and if something is not ready for 15th then I will scrap this and push it to next version.