[OLD] Old OXCE discussion thread

[Ethereal]

There is a proposal for a more radical implementation of the script of energetic shields in armor https://openxcom.org/forum/index.php/topic,5435.msg83644.html#msg83644. Ie - as one of the parameters of the armor (not in the "tags:" section), with the imagery (in the lower left corner) of the number of absorbed damages, with the imagery in Ufopedia in the characteristics of the armor/unit.

[Meridian]

There is a proposal for a more radical implementation of the script of energetic shields in armor https://openxcom.org/forum/index.php/topic,5435.msg83644.html#msg83644. Ie - as one of the parameters of the armor (not in the "tags:" section), with the imagery (in the lower left corner) of the number of absorbed damages, with the imagery in Ufopedia in the characteristics of the armor/unit.

And where is that proposal?
I see only the script there... don't see any suggestions for parameters or imagery...

[Ethereal]

And where is that proposal?
I see only the script there... don't see any suggestions for parameters or imagery...

The proposal comes from me. Based on the script from ohartenstein23 to do what I described the post above. Only shields not with a single actuation, as in this script, but as on ships - with a certain amount of absorbed damage.

[Meridian]

My bad, I mess one condition here is bug fix commit:
https://github.com/Yankes/OpenXcom/commit/2d6906a8659e23d3353ae796b754df099c1259c5

It crashes on hit animation now... I have a fix (see attached), but probably a deeper review is needed... the use of (_hit || _psi) and _targetPsiOrHit seems inconsistent.

[Yankes]

It crashes on hit animation now... I have a fix (see attached), but probably a deeper review is needed... the use of (_hit || _psi) and _targetPsiOrHit seems inconsistent.

indeed, special psi attack need `_targetPsiOrHit` to calculate hit chance but after that it should behave as normal hit. My fix should revert this test to previous ones as you suggest. previously it was only set when this condition was true, now is not true in all cases.

There is a proposal for a more radical implementation of the script of energetic shields in armor https://openxcom.org/forum/index.php/topic,5435.msg83644.html#msg83644. Ie - as one of the parameters of the armor (not in the "tags:" section), with the imagery (in the lower left corner) of the number of absorbed damages, with the imagery in Ufopedia in the characteristics of the armor/unit.

Whole point of scripts was to not implements this in code, if I implements this it could work different what you wan. Another thing is that if code would support multiple cases/versions it will create big mess.
Your request should be different, you should ask for new features in scripts that could fulfill your goals.
e.g. When I will have some time I will add option for creating custom descriptions to ufopedia articles, this will allow displaying values of all tags in way you want.

[Meridian]

@Yankes: if you find some time... there is an older bug that keeps coming back randomly... and I can't track and isolate it easily: https://openxcom.org/forum/index.php/topic,5047.msg87564.html#msg87564

Maybe you'll spot immediately, what could be causing it?

[Yankes]

No, at least not in my version, maybe some your changes with more aggressive aliens cause it?

[Ethereal]

Can you make a miniature version of the statistics of soldiers, a separate option, with the excision of the memory of each specific mission? To just how many killed, who and what weapons.
Example -

        diary:
          killList:
            - STR_FLOATER_SOLDIER: 4
            - STR_GILLMAN_NAVIGATOR: 2
            - STR_SECTOID_COMMANDER: 1
          killWeapon:
            - STR_GRENADE: 3
            - STR_PROXIMITY_GRENADE: 1
            - STR_SHOTGUN: 3

Ie - without indicating which specific mission and when each enemy was killed. And any successful action against the opponent, whether psionic, murder, stunning, or killing "improvisation", is saved only for the current battle and until its end, and then recorded in a common heap, as indicated above.

Simply, the current system very slows down the Save / Load process. When you have 250-300 soldiers who have committed 7-10 missions and killed 20-30 opponents each, the Save or Load process can take up to a minute.

[Yankes]

I think this is outside of scope of my branch, I focus on new game play mechanics that improving overall game. Maybe Meridian or SupSuper would be interested in implementing this?

[ohartenstein23]

Found the issue with the fix I posted earlier; item->getUnit() was for getting the unit from a corpse item, getOwner() was what I intended to use.  Also added a check to make sure the loaded ammo item is marked as recoverable.  I'm assuming that the modder will set recover: false for ammo items that are built in on armors.  Here's the updated commit.

[mumble]

Any chance you could remove the requirement to face south to fire directly down at ones feet? Its often used to execute downed people, but needing to turn makes it cost extra TU's, and it makes no sense why you would need to turn to shoot down.

Also, is there any chance you can make TU usage change based on other stats, like larger melee weapons swinging faster with a stronger person, or odd guns firing faster with better reactions?

[Yankes]

This is not requirement, this is consequence of direction calculation. Because you cant calculate correctly angle between two points in same tile it always return same value. I will look on this when I will have some free time but it possible that fixing it will need lot of work to do it correctly.

For item use cost. Biggest problem is that game engine assume that use cost do not change, this is case in AI and reaction shoots. Engine calculate cost and using it plan sequence of actions, if in between this action execution cost will change, whole chain will break.
This is primary reason why I do not allow weapon to change it cost on things that could change between actions.

In next version you could hack it, I will adding script event that will be call after each shoot, you could alter stats of unit in any way you want. This mean you could refund some TU. But still this will be able to break AI if not used carefully.

[Meridian]

In my opinion... a lot of work, for close to no benefit.

[Nord]

Also, is there any chance you can make TU usage change based on other stats, like larger melee weapons swinging faster with a stronger person, or odd guns firing faster with better reactions?

This is allready implemented in vanilla game by flat ant percentage tu costs.
Look at it as: one turn is a fixed time length (a 3-5 seconds of real time). If you swing a melee weapon, you can train to do it faster. So lets say 25 tu for unit who has 50tu will be a 2seconds, but for faster unit with 100tu it will be only 1 second.
While shooting count in percent, because machinegun will not shoot faster in the hands of faster man.
Of course, all this is simplified, because this is a game.

[ohartenstein23]

Hey Yankes, looking into some of the multiple ammo slots features, I noticed that the ufopaedia still uses the strings for Aimed, Snap, and Auto instead of having new strings based on the confAimed, confSnap, and confAuto definitions - can you add a parameter for picking the ufopaedia name of the shot type?

Edit: Also, if a weapon uses itself as ammo for some shot types (ammoSlot: -1) but has a shot type using a separate clip, the ufopaedia article does not show the power and damage type of the 'built-in' ammo.  The alternative, making ammo slot 0 have compatibleAmmo: ~ and putting the alternative ammo type in slot 1, means that only the 'built-in' ammo is shown in the article.