[OLD] Old OXCE discussion thread

[Meridian]

I have another crash/freeze for you: https://openxcom.org/forum/index.php/topic,4058.msg83575.html#msg83575

I found the difference in: https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/UnitWalkBState.cpp#L331

...where _parent->checkReservedTU() returns different values in vanilla and OXCE

Going deeper in: https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/BattlescapeGame.cpp#L1174

...vanilla returns true, because "return tu <= bu->getTimeUnits();" is 0 <=72
...however OXCE returns false, because "return cost.haveTU();" always returns false when Time == 0

One possible fix is to change it to "return tu <= 0 || cost.haveTU();" ... in which case the freeze doesn't happen anymore and AI works as in vanilla.
... but maybe the whole haveTU() method is not correct?

I mean

Code: [Select]

bool BattleActionCost::haveTU(std::string *message)
{
if (Time <= 0)
{
//no action, no message
return false;
}
...

This condition looks very weird... surely when Time == 0, you have enough TUs to perform the action (since it doesn't cost anything) and the method should return true, not false.
However just changing the condition would mean other conditions below it (for energy, etc.) won't be checked... so maybe better is to remove this first condition completely?

I don't know what the purpose of this condition is, so I would prefer if you had a look at it... and made a proper fix... so that I don't make it even worse than it is now.

[Yankes]

0 mean there is not action at all, if weapon do not have TU is impossible to use it in vanilla:
https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/ActionMenuState.cpp#L292

Because I unify nearly all tu spending in some cases inconsistent behavior for base game surfaced causing bugs in OXCE.

In case of reserved tu I think your suggestion of fix is correct, because if `tu <= 0` then there is no need for checking for cost because there is no action at all to reserve for.

btw other bug with light is near fixing, I only need double check that everything work as excepted.

[Solarius Scorch]

Yankes, when is the next version coming up? Not trying to put pressure on you or anything, but the truth is, we need it.

[Yankes]

some writer block/lack of time/lack of focus caused that final touch (and testing) get delayed. Main reason was that I was forced to made changes in places I do not wanted to changed. I will try made push in this weekend and release finally new version.

[Solarius Scorch]

Fight, Yankes!

[Yankes]

New version 3.8 is finally ready, primary change is multi ammo weapons, each weapon can have secondary ammo types (like grenade launcher).
With this some small changes like: change name of attack, auto shot of not auto shots, access attack action type in damage script.

[Meridian]

Merge newest vanilla please? It has some stuff I wanna use, plus a good bunch of fixes.

[Yankes]

I will merge with next version, this time I will choose simpler thing to implementing :>

[Meridian]

0 mean there is not action at all, if weapon do not have TU is impossible to use it in vanilla:
https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/ActionMenuState.cpp#L292

Because I unify nearly all tu spending in some cases inconsistent behavior for base game surfaced causing bugs in OXCE.

In case of reserved tu I think your suggestion of fix is correct, because if `tu <= 0` then there is no need for checking for cost because there is no action at all to reserve for.

btw other bug with light is near fixing, I only need double check that everything work as excepted.

Is this solved in 3.8?

[Dioxine]

New version 3.8 is finally ready, primary change is multi ammo weapons, each weapon can have secondary ammo types (like grenade launcher).
With this some small changes like: change name of attack, auto shot of not auto shots, access attack action type in damage script.

The primary change seems a bit underwhelming, unless I'm missing something. If we want to have combi-weapons, would need separate stat sets for each weapon (multiple weapons per item); ammo alone makes this a marginally useful gimmick as you can't change TU costs, accuracies, arcing/flat shot etc., so eg. a rifle with a grenade launcher is still unfeasible (as far as I understand these changes)
Secondary changes, very interesting.

[Yankes]

Is this solved in 3.8?

this with light? yes.

The primary change seems a bit underwhelming, unless I'm missing something. If we want to have combi-weapons, would need separate stat sets for each weapon (multiple weapons per item); ammo alone makes this a marginally useful gimmick as you can't change TU costs, accuracies, arcing/flat shot etc., so eg. a rifle with a grenade launcher is still unfeasible (as far as I understand these changes)
Secondary changes, very interesting.

There is probably small misunderstanding how it will work.


First you can define additional "compatibleAmmo" and separate "tuLoad" and "tuUnload" for each new slot.
With this now weapon can have multiple different ammo items loaded at once, aside of that weapon work exactly same as normally.
After that you can choose in each attack type with ammo slot to use for that attack (or attack can work without any ammo and use "weapon" as "bullet" like in lasers).

This mean TU and accuracy is already configurable for each attack type. arcing/flat is not but I could add this as bug fix.
Any other properties you would like have configurable per attack type?

[Meridian]

this with light? yes.

No, the endless loop during alien turn: https://openxcom.org/forum/index.php/topic,2915.msg83582.html#msg83582

[Yankes]

ups.. I thought you will do it, ok I will release bug fix version with this fix.

[Dioxine]

First you can define additional "compatibleAmmo" and separate "tuLoad" and "tuUnload" for each new slot.
With this now weapon can have multiple different ammo items loaded at once, aside of that weapon work exactly same as normally.
After that you can choose in each attack type with ammo slot to use for that attack (or attack can work without any ammo and use "weapon" as "bullet" like in lasers).

This mean TU and accuracy is already configurable for each attack type. arcing/flat is not but I could add this as bug fix.
Any other properties you would like have configurable per attack type?

OK now I understand this better.
So what properties we need to make this fully functional?
1. arcing shot
2. bullet sprite
3. fire sound
4. snap/aimed/auto ranges

That is all I can think of for now.

Another question, and a rather crucial one, how are the additional ammo types handled by the GUI?

[Yankes]

in battle screen you have additional numbers per ammo slot (visible only when used).
for inventory is it bit lacking, I did not made yet how best to display it, one solution is add loop in ammo popup that will show all loaded ammo in sequence (1s -> first slot showed, 3s -> second slot showed, 5s -> third, etc.)
another is add postfix to display name of weapon based on loaded ammo, something like that: "pistol (with explosive)".
other solution could be adding ammo count to each weapon in inventory (not in stack on ground) similar to battle scape.