Author Topic: [SUGGESTION] Complex LOFT collider for BattleUnit  (Read 1925 times)

Offline Finnik

  • Colonel
  • ****
  • Posts: 492
  • Finnik#0257
    • View Profile
[SUGGESTION] Complex LOFT collider for BattleUnit
« on: May 15, 2022, 09:36:28 pm »
I'm considering if there is a way to define more complex shape for units, like we can define it for tiles. AFAIK, now it's just a cylinder with height, defined with property. But I think there can be a way to define voxel model with yaml ruleset in unit or soldier property
Code: [Select]
units:
  - type: STR_SECTOID_SOLDIER
    race: STR_SECTOID
    rank: STR_LIVE_SOLDIER
    stats:
      tu: 60
      stamina: 90
      health: 30
      bravery: 80
      reactions: 63
      firing: 54
      throwing: 58
      strength: 20
      melee: 12
      psiStrength: 60
      psiSkill: 20
    armor: STR_SECTOID_STANDARD_ARMOR
    standHeight: 16
    value: 15
    standingLOFT: [2, 2, 2, 3, 3, 4, 4, 4, 3, 0, 0]

Numbers define LOFT id's from LOFTEMPS.DAT file (see attachment)
In this case, we can fix some common problems when default collider does not reflect image asset completely. I'd also suggest in this case to keep weapon handob image offset to be still calculated with `standHeight`.
For Instance, that can solve problem, that is highlighted here https://openxcom.mod.io/reavers-fixed-hitboxes
I would also suggest ignore unit rotation for more simple solution. Still, it would help to make new enemies more interesting and help in terms of visual improvement of the game in terms of displaying projectile hits.

Online Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 8616
    • View Profile
Re: [SUGGESTION] Complex LOFT collider for BattleUnit
« Reply #1 on: May 15, 2022, 09:43:18 pm »
Honestly, I am not interested.

Maybe Yankes is...

Offline The Reaver of Darkness

  • Commander
  • *****
  • Posts: 1510
    • View Profile
Re: [SUGGESTION] Complex LOFT collider for BattleUnit
« Reply #2 on: May 15, 2022, 11:55:15 pm »
Very interesting concept and looks entirely doable, however it would require individual modders to create LOFTs for their units. I suspect most mods would simply not use the feature, or just copy LOFTs from other mods.

I propose an easier solution: simply disassociate the unit height into two separate heights: one which determines the height at which they carry their weapon, and the other which determines the height of their LOFT pillar. Nine times out of ten you wouldn't be able to tell the difference between the two solutions during gameplay, short of taking LOF screenshots. Even with Sectoids, the iconic extreme example, a player won't typically feel like anything is wrong when a shot heading to brush past its meager body collides with it instead, or passes through the edge of its large head and keeps going. The sprite is too small to easily notice these things without playing the footage back in slow motion.

Offline Finnik

  • Colonel
  • ****
  • Posts: 492
  • Finnik#0257
    • View Profile
Re: [SUGGESTION] Complex LOFT collider for BattleUnit
« Reply #3 on: May 16, 2022, 12:30:35 am »
My initial motivation was to make cyberdiscs hitbox in form of actually a floating disc, that is much harder to hit with horizontal fire line, than, let's say, a Reaper hitbox. But if you will hit it from above or below - it's an easy target as well. Considering it's a flying unit - it makes a lot of tactical gameplay meaning.
Also, if we take iconic example with sectoid hitbox, on fixing like @Reaver is proposing, we will get its hitbox not that different from muton's. But they are very different in sizes, judging ufopadia and battlescape images… Making muton is a target, that is much easier to hit, compared to smaller enemies, would make interesting balance options, considering its high armor value.

I can go on with more examples like that.

Offline The Reaver of Darkness

  • Commander
  • *****
  • Posts: 1510
    • View Profile
Re: [SUGGESTION] Complex LOFT collider for BattleUnit
« Reply #4 on: May 16, 2022, 05:27:28 am »
My initial motivation was to make cyberdiscs hitbox in form of actually a floating disc, that is much harder to hit with horizontal fire line, than, let's say, a Reaper hitbox. But if you will hit it from above or below - it's an easy target as well. Considering it's a flying unit - it makes a lot of tactical gameplay meaning.
Also, if we take iconic example with sectoid hitbox, on fixing like @Reaver is proposing, we will get its hitbox not that different from muton's. But they are very different in sizes, judging ufopadia and battlescape images… Making muton is a target, that is much easier to hit, compared to smaller enemies, would make interesting balance options, considering its high armor value.

I can go on with more examples like that.

Sectoids already use a smaller column (2) while snakemen use a larger column (4) and the rest (floater, muton, ethereal) use a "medium" column (3). My hitbox mod fixes this by boosting them all to 3 for sectoids, 5 for snakemen, and 4 for the rest.

You can already make the cyberdisc hitbox match its model simply by making it shorter, but it causes a bug in which if it is standing on elevated ground, melee attacks can't hit it. The hitbox height it has is the bare minimum to avoid the bug; shrinking it by even one voxel will make it commonly unhittable in melee. But soldiers have no significant difficulty in hitting the smaller hitbox with ranged weapons, so aside from the melee bug it works great.

I think we'd have no major issues with hitboxes if the hitbox bugs were fixed:
1.) Small units have their weapon height based on hitbox height, and it is correct only for soldiers, and wrong for ALL other alien races.
2.) Large units must have a minimum hitbox height in order for melee weapons to function correctly (unless they never stand on inclined terrain).
3.) Shot angle has a very high odds of hitting almost exactly dead center where the soldier is aiming, roughly equal to their list chance to hit in most cases. Then if it doesn't go dead center, it goes straight to stormtrooper accuracy more or less regardless of the shot's list accuracy (and this can still happen at 110%+). This means their odds of hitting a bee off your nose at 100 tiles is not significantly different than their odds of hitting a snakeman at 5 tiles, and no that is not an exaggeration.
4.) This might be the most difficult one to fix, or maybe it isn't: sometimes a soldier simply aims along a trajectory which does not intersect with the target's hitbox. This is most common with: diagonal shots esp. with elevation differences (which can be mitigated by making perfectly orthogonal shots); strange target hitboxes esp. against terrain or if target hitbox is very small/off center; having tile hitboxes in between the shooter and the target (occurs differently but not necessarily less commonly with OXCE's off-center shooting, can be mitigated by using OXCE's alt-fire). I don't know much about how this stuff works but I think it was either SupSuper or Warboy who showed me the function in the base code. There was a list of tile positions it seeks to find an eligible trajectory, and perhaps fixing it is as simple as expanding the list.
        If a soldier aims along a missing trajectory, the most noticeable thing is that the shot will ALWAYS miss UNLESS it is a stormtrooper accuracy shot which gets lucky. All bee-off-the-nose shots will take nearly the exact same path and miss their target. This means that the higher a soldier's accuracy is, the lower their odds of hitting the target. The only way to fix it is to move either the shooter or the target to a different position.
« Last Edit: May 16, 2022, 05:42:48 am by The Reaver of Darkness »

Offline Yankes

  • Commander
  • *****
  • Posts: 3207
    • View Profile
Re: [SUGGESTION] Complex LOFT collider for BattleUnit
« Reply #5 on: May 16, 2022, 12:21:29 pm »
I would be interested :)
But as Reaver said it probably require some fixes on hitbox aiming as we already have some corner cases.

In theory hitbox could be more complex than tile hitbox as there is lot less processing of units as on average there is less than one unit encountered per trajectory.
But I would keep it very simple as it could introduce even more corner cases.

I think Finnik `standingLOFT`is acceptable solution.