[OLD] Old OXCE discussion thread

[Solarius Scorch]

I can do that... but isn't it a bit harsh on the player?

Why would anyone shoot an unconscious enemy, and expect to be rewarded for this to boot?

Have you ever done this? I probably haven't. And if I had, I certainly wouldn't have expected to get exp for this. It's just... weird.

[Meridian]

Yes, I would.

It's a simple rule... you hit enemy => you get exp... simple to explain, simple to remember... simple is good, why make it complicated?

[Solarius Scorch]

It's a simple rule... you hit enemy => you get exp... simple to explain, simple to remember... simple is good, why make it complicated?

I dunno, it's matter for perception. For you it is obvious that you should get XP, and would be surprised if you don't. For me it is obvious that you should not get XP, and would be surprised if you do.

We could theorize on why our perceptions differ, but I don't think it matters. For me it's just weird that you get XP for something that does not involve any kind of challenge. I certainly wouldn't give XP to my players in an actual RPG session, that's probably self-evident.

I don't really care either way at all, just musing.

[Meridian]

For me it's just weird that you get XP for something that does not involve any kind of challenge.

Then I would need to remove exp for blindly using blaster launcher across the map, remove exp for blindly throwing grenades around, remove exp for randomly placing proxies and so on and so on... there's tons of ways and situations where you get xp for nothing, I just don't see why there should be particularly this one exception... especially since it happens so rarely (getting a live alien is preferred over killing them no?).

[Solarius Scorch]

Which is exactly why I don't think it's an issue.

[Meridian]

Clip in weapon do not belongs to any inventory, it would be strange if ammo is in "hand" but weapon is in backpack.
In 3.8 I add clearing inventory slot when item is loaded to weapon.

I will look on this bug, probably my change expose place where game check slot for this that should not have a slot.

OK, one more thing that was just found, maybe related to this.

Inventory copying doesn't work with loaded guns.

E.g. inventory copying with unloaded rifle works fine, but with loaded rifle it says "not enough items to copy template".
Reproducible without any mods.

[Yankes]

OK, one more thing that was just found, maybe related to this.

Inventory copying doesn't work with loaded guns.

E.g. inventory copying with unloaded rifle works fine, but with loaded rifle it says "not enough items to copy template".
Reproducible without any mods.

Fast test show that this work partially fine, if you have only weapon (with ammo) in layout is work without errors.
This is why I miss this bug last time I fix bugs in coping.

[ps]
When saving again layout its behave different.

[Dioxine]

It's a simple rule... you hit enemy => you get exp... simple to explain, simple to remember... simple is good, why make it complicated?

The same reason why throwing on empty tile doesn't... simply put, firing blindly if hits, is a matter of luck; shooting unconscious enemy is using fallen Merc to train xp by the whole crew taking turns emptying an smg clip into him (yes one player did boast of such a 'tactic'). If you don't think such behaviour shouldn't be rewarded, I don't know what to tell you. Also I won't take the usual 'you cannot completely stop players from abusing the system'. It is obvious that it is impossible, but increasing their suffering at every turn is a just goal

But I have come here with another question/request. There is an option to have a facility require items to be built. When not enough items are present, a message STR_NOT_ENOUGH_ITEMS displays. Is there a magical yaml trick to make this message display what items are needed? Because without this, there is a problem of communicating this to the player.

[Eddie]

shooting unconscious enemy is using fallen Merc to train xp by the whole crew taking turns emptying an smg clip into him.

This can never be prevented. If shooting the unconcious merc doesn't give xp, simply use a medpack to get him back up.

I was thinking some time about another way to award XP that is more realistic/less abuseable. What I came up with is this:
You get no XP in combat. What you get is "participation" XP, like it is done now for health and stamina gain. If you "participated" in a mission, you then get a boost to stat gains from the gym of say 200% for the next 10 days. Because the stress of the mission really motivated you to work out harder. A new mission during that time extends the time of the bonus. You can train above training caps only if you have the bonus. So you can get to the statcaps.

This system would deal with two issues:
- Many missions in a short time for a soldier don't give huge stat increases. You would be encouraged to rotate your crew so everyone sees regular action.
- No worrys about spreading kills between soldiers so all get xp. No more micromanaging "I need to train throwing on this guy"

This system would need training to be enabled without the facilities. A gym would then just give a bonus or increase the training caps. Also, the right now non-trainable skills like reactions and bravery need to be handled somehow.

[BTAxis]

You realize that the "gain through performance" aspect of X-COM's stat system is an integral part of what made the game great in the first place. Replacing it with something else is not going to go over well with purists.

[Meridian]

Hi Yankes,

2 more bugs reported by karadoc on discord for v3.8.

Here's the fixes: https://github.com/karadoc/OpenXcom/commit/1dc1e7d192a922b81885493b940cfefd2403b445
I didn't check them, just forwarding.

Attached also 2 piratez saves where it crashes.

[Meridian]

But I have come here with another question/request. There is an option to have a facility require items to be built. When not enough items are present, a message STR_NOT_ENOUGH_ITEMS displays. Is there a magical yaml trick to make this message display what items are needed? Because without this, there is a problem of communicating this to the player.

Use {0} in the translation of STR_NOT_ENOUGH_ITEMS.

Only first missing item will be communicated.

[Yankes]

For exp, I think best solution would be adding scripts (tm) :>
Best part would be that source code will not be pouted with every possible version how it should work (no exp from stunned/no exp for indirect fire/no exp for unarmed etc.).
Another this would be that you could create non combat enemy units what will not grain exp or some or some elite enemies what will give you more exp or enemy will have limited exp to give (only first couple of hits will grain exp).


@Meridian I will check it.

[karadoc]

Here's another crash for you:

In the attached save, the game crashes after ending turn due to an 'unsupported action'.

I've looked into it, and found the problem is in `AIModule::psiAction()`
In particular, this part is causing the crash:

Code: [Select]

if (_visibleEnemies)
{
auto ammo = _attackAction->weapon->getAmmoForAction(_attackAction->type);
if (ammo && ammo->getRules()->getPowerBonus(_attackAction->actor) >= weightToAttack)
{
return false;
}
}
The `getAmmoForAction` crashes in this cause because the _attackAction is BA_RETHINK, which doesn't have associated rules, and hence causes a crash.

This seems easy enough to fix, but the best way to fix it depends a bit on coding style and on what you are actually trying to achieve with this bit of code.

For example, I personally think it's a bit weird that `const RuleItemAction *BattleItem::getActionConf(BattleActionType action) const` throws an exception when the result is NULL. If the result is never allowed to be NULL, then the return type should be a reference, not a pointer. So I'd probably fix the problem by not throwing the exception in `getActionConf`, and instead checking for NULL elsewhere. In this case, if `getActionConf` returns NULL, then `getAmmoForAction` should also return NULL.

If `getActionConf` no longer throws, then it would probably be wise to check for NULL every time it is used. But since no one is trying to catch the exceptions anyway, it won't really make any difference even it does return NULL an no one checked. It will just seg-fault instead of having a uncaught exception.

Anyway, as I said, the best way to fix this crash depends on how you like your code to behave. I'll leave it up to the people in charge. But I will say that in my view, `getAmmoForAction` should not crash no matter what 'action' is given to it. So I suggest that the bug should be fixed in that part rather than in the AI.

--
[edit]
On closer inspection, the code already has a function called `getActionConfNullable`, which is the same as `getActionConf` except that it returns null instead of throwing. As I said before, no one is trying to catch these exceptions... so I really don't know why the exception throwing version of the function even exists. In any case, here's a simple patch for the bug. Enjoy.

https://github.com/karadoc/OpenXcom/commit/0b1a95322c15ef61d40e2b6cc9a0499191bb5f2d

[Yankes]

Right, fast fix is to not throw in `getActionConf`, but what point is then checking for ammo in that weapon then if always it will return `null`?
I added this throw to catch logic bugs like this situation when code ask for ammo for some unrelated action.
Proper fix would be check correct action type (aim/auto/snap/hit) otherwise we could remove this check completely.