[OLD] Old OXCE discussion thread

[ohartenstein23]

Ah sorry, my mistake.  Didn't catch the NOTs.

[Meridian]

@Yankes:
Forwarding a bug report I got from karadoc twice already... I think it is probably caused by OXCE (and the fact that ammo has no slot, unlike in vanilla).
Can you please have a look?
I am attaching a picture with how to reproduce without mods.

And here's original bugreports from karadoc

1. "equipment templates don't always copy the correct loaded ammo.
I'm not sure what the cause is yet. Maybe it isn't even checking the loaded ammo at all...
eg. if I load up a soldier with rubber shotgun ammo, then copy the template and apply it to another soldier; I tend to get ordinary shotgun shells instead of rubber ones.
But if I manually load up the rubber ammo, then apply the template again, it stays as rubber."

2. "Re-reporting a bug which has existed for awhile: copying soldier item templates does not always copy the correct loaded ammo.
In particular, if I use a template to copy shotguns loaded with rubber bullets, I end up with shotguns with ordinary shells -
unless the soldier is already holding a gun with the correct ammo in the first place."

[ohartenstein23]

Hey Yankes, have you had a chance to review fixing ammo recovery from fixed weapons on soldier armor? I wrote a commit to fix losing ammo loaded into fixed weapons - would this work without breaking other things?

For background, we reported this problem here.

[Yankes]

@Meridian I will check it

@ohartenstein23 if I recall correctly I have some issues with this, because it will start recovering fixed ammo too (ammo that was defined in armor to fill weapons).
Now if Piretez and XFiles or other mods use ammo like that then they will need change how they use it. If they do not then probaby we can apply this patch

[ohartenstein23]

I talked to Dioxine, and he doesn't have any ammunition as built-in items on armor, and I know that X-Com Files doesn't use this.  The commit also checks to make sure the clip item is not fixed and is recoverable, so that should prevent bugs with extra clips being recovered when they shouldn't be.

[Yankes]

Merge Change Notification:
isRecoverable should be moved from Geoscape item to BattleScape item, because how now work in OXC.

--- posts merged ---

@Yankes:
Forwarding a bug report I got from karadoc twice already... I think it is probably caused by OXCE (and the fact that ammo has no slot, unlike in vanilla).
Can you please have a look?
I am attaching a picture with how to reproduce without mods.

Found and fixed. One check use invalid iterator instead of pointer.

Probably today or tomorrow I will release bugfix version.

[Yankes]

New bug fix release 3.10a ready. It is up to date with nightly.

[Meridian]

New bug fix release 3.10a ready. It is up to date with nightly.

Thanks.
OXCE+ is updated too.

2 questions:

1. https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/ProjectileFlyBState.cpp#L584

What does this mean? What exactly is not working yet?

2. https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/ProjectileFlyBState.cpp#L596

Why would a check for (_projectileImpact == 4) be necessary?

Also, I have activated this nerfing in OXCE+ too, for all experience variables: https://github.com/MeridianOXC/OpenXcom/commit/bbbd0c529fbb3863d16197cafa25f3d9545a52fc

[Yankes]

First commented because https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/ProjectileFlyBState.cpp#L537 Already disable this in OXCE
And I dislike current solution that look for me as hack not proper solution, when I will have time to refactor this (move this to explosion state) I will enable this again.

This second point is probably garbage, in old version was test for `if (_projectileImpact == 4)` that current look like `if (_projectileImpact == V_UNIT)` and some code was move around. Probably during merge I left this as comment for myself to check for some changes and do not remove it after I finished merge.

Your nerf code look better than vanilla one but did you not allow +2 for some cases?

btw update you profile description :>

[Meridian]

Your nerf code look better than vanilla one but did you not allow +2 for some cases?

Yes, it allows for +2 when many bullets hit and don't kill... I actually like that too... if you're punished by useless shotgun with no damage, you should at least get exp from that

This is the description I gave on discord, hopefully accurate.

Meridian - Yesterday at 5:11 PM
more details about the shotgun experience:
1. "first" bullet is generated, but not used yet
2. current experience is remembered
3. extra bullets are generated and processed one by one... experience for each bullet is awarded normally
4. after all extra bullets are processed, any experience gained is nerfed to 1
5. first bullet is processed... if it hits (and target is still alive) experience is awarded normally
...
meaning standard shotgun, which hits all bullets will award:
- 2 firing experience if the unit stays alive
- 1 firing experince if the unit dies before the "first" bullet is processed ("first" is actually last for all our intents and purposes)

btw update you profile description :>

Done

[Meridian]

@Yankes: a question... I found one difference between OXC and OXCE, see attached picture

The difference would cause different radius for a HE weapon with low damage (e.g. Heavy cannon HE rounds)... either by defining fixed low damage or by damage reduction over distance.

In OXC the radius would be 0 (zero) and in OXCE the radius would be 1 (one).
This will then have effect on various places to determine if the damage is AOE or not... and other side effects...

Is this a feature or a bug?

[Yankes]

Feature, I made clear cut between single target and aoe damage. This will return same answer as `RuleDamageType::isDirect`.

[Meridian]

Found a small visual bug with multiple ammo (both on 3.9 and 3.10)

1/ Use this mod:

Code: [Select]

items:
  - type: STR_RIFLE
    confAimed:
      ammoSlot: 1
    confSnap:
      ammoSlot: 2
    confAuto:
      ammoSlot: 3
    ammo:
      0:
        compatibleAmmo: [ STR_RIFLE_CLIP ]
      1:
        compatibleAmmo: [ STR_HC_HE_AMMO ]
      2:
        compatibleAmmo: [ STR_AC_I_AMMO ]
      3:
        compatibleAmmo: [ STR_SMALL_ROCKET ]

2/ Go to New Battle GUI and equip:
1x STR_RIFLE
1x STR_RIFLE_CLIP
1x STR_HC_HE_AMMO
1x STR_AC_I_AMMO
1x STR_SMALL_ROCKET

3/ Now take the weapon in your imaginary hand (left click) and you will see the loaded ammo... all 4 of them, changing regularly with a frequency of about 1 second.

4/ Then, unload the first clip (STR_RIFLE_CLIP), three clips will remain in the gun... however only 2 of them are visible and the change frequency is not regular... about 75% of the time we see STR_HC_HE_AMMO, 25% of the time we see STR_AC_I_AMMO and we don't see STR_SMALL_ROCKET at all.

[Meridian]

Hi Yankes, there is an issue with armor "calculation", reported here: https://openxcom.org/forum/index.php/topic,5957.msg91692.html#msg91692

Issue is here: https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/BattleUnit.cpp#L1241
(the upper boundary is not multiplied by the difficulty coeficient)

Maybe instead of:

Code: [Select]

setValueMax(_currentArmor[side], - std::get<toArmor>(args.data), 0, _armor->getArmor(side));

it should be:

Code: [Select]

setValueMax(_currentArmor[side], - std::get<toArmor>(args.data), 0, _maxArmor[side]);

Or some other solution...?

PS: proposed fix: https://github.com/MeridianOXC/OpenXcom/commit/fa91ce19a19fb5a6a7aced035911fdc06ef8bcbc

[Meridian]

Hi, me again,

looks like this fix was never merged into OXCE: https://github.com/SupSuper/OpenXcom/commit/eaf884863bb21718b2a7b526962c9b241e0ec7f0

It causes NPE when people mod their own globe markers.

Something like this:

Code: [Select]

extraSprites:
  - type: GlobeMarkers
    width: 3
    height: 3
    files:
      9: Resources/AbandonedBaseMarker.png
      10: Resources/ShipwreckMarker.png

Here's my temporary fix, but I think we need something nicer, could you have a look pls?
https://github.com/MeridianOXC/OpenXcom/commit/682da0775f522ed73d9b0d77319cdd0700d312ca