Topics

1

OXCE Suggestions Y-script / [Suggestion/Y-Scripts?] Custom Ways to grant Commendations?

« on: April 02, 2023, 03:38:36 pm »

I started playing around with combat drugs a bit.
One thing I try to solve is to show in geoscape who has a drug addiction and who doesn't. A clear contender is a (temporary) commendation/soldierBonus.
My suggestion right now would be to add a tagCriteria to the commendations:

Code: [Select]

commendations:
  - type: STR_DRUG_ADDICTION
    ...
    tagCriteria:
      -
        - [10, ["GEOSCAPE_SOLDIER_TAG_DRUG_ADDICTION"]]

Then I could determine via scripting to increment/decrement that geoscapeSoldier tag's value and therefore make it visible to the player who is currently addicted and will suffer a stat loss at the beginning of the mission till either cold turkey is successful or another combat drug is consumed.

There are probably more elegant solutions than having to click multiple buttons in the soldier screen or recolor/selectUnitSprite which only work in battleScape. If you got completely different ideas, I am all ears.

2

40k / [STORY MOD] Rosigmunda (not compatible with ROSIGMA)

« on: March 19, 2023, 11:02:00 pm »

This has been on my stove for a while now.

Rosigmunda is a mod designed explicity with the Adeptus Arbites in mind. It's designed for low-tier weapons against low-tier opposition so even Autoguns can shine throughout the game. Also stunning enemies is much more important now as it should be with Space Cops TM.

INCOMPATIBLE WITH ROSIGMA. DO NOT RUN Rosigmunda with ROSIGMA !!!

Features:
- Small Story Campaign
- New Missions (Prison Break, ...)
- Missions and Enemies where Autoguns and similar weapons get to shine
- Turn captives into penitents
- Riot shields which can be equipped on anyone and they can be shot to pieces
- Mastiff Tackling
- and probably much more

You can download it here.

3

OXCE Support Y-scripts / [Solved][Suggestion/Y-Scripts] setSpawnItem

« on: February 17, 2023, 11:05:11 pm »

My latest plaything is trying to create some kind of flare launcher for HWPs.

Right now I added a grenade launcher to a HWP which is set up with spawnUnit to create a unit which is supposed to drop an electric flare. The unit is supposed to be insta-killed using the createUnit: hook and setting its health to 0. The game doesn't update the state of said unit from alive to dead. The state will be updated once another shot is taken or the turn is ended. I experimented with another bunch of options (skills which aren't available to units:, setSpawnUnit using inside the createUnit script and a few other things).

When talking about my fun experiences in Matrix, Yankes suggested that maybe this can be solved with setSpawnItem. A setSpawnItem next to setSpawnUnit would be really cool.

As always thank you for looking at the suggestion.

4

OXCE Suggestions Y-script / [Suggestion/Y-Scripts]setDeathFrames

« on: February 17, 2023, 11:36:38 am »

For Gibs of Gory it would be helpful if scripting allowed to set the number of DeathFrames. I would like to keep the default 3 for the standard death while being able to extend the more messy ones to 8. For the standard death creating the missing 5 frames or extending the 3 to 8 is a bit prohibitive for mods which have a lot of spritesheets already. 3 DeathFrames for the messy ones works okay but it could look a lot better with 8.

Currently getDeathFrames is attached to RuleArmor which makes sense and of course limits a setDeathFrames as this information can be read-only. Would it be viable to add an override with BattleUnit.setDeathFrames?

Thanks for possible considerations.

5

Released Mods / [UFO][OXCE][Graphic(al Violence)] Gibs of Gory

« on: February 14, 2023, 07:07:23 pm »

I wanted to try that for a while now.

Gibs of Gory (word play on Wings of Glory) is a little graphical mod that exchanges the death Animations depending on used damage type and remaining weapon power.

Whenever the damage past setting health to 0 exceeds maxHealth, the target will turn to gibs, scorch marks (Plasma, Incendiary) or goo (Acid).

You can download it here.

Credits go to Brain_322 for sprites and Yankes for showing me the wonderful value of RuleList.current.

6

OXCE Suggestions Y-script / [Suggestion/Y-Scripts]Make Craft Information available in battleScape?

« on: February 11, 2023, 10:35:47 am »

There are currently two ideas floating around in my head:
- Change turrets of the craft vehicle depending on a specific craftweapon slot (battleScape maptile, spawner grenade, createUnit script with setSpawnUnit, etc.)
- Some kind of battleScape auto-resolve item/craft ammo (for example something like a tactical nuke, singularity bomb)
The latter can probably be resolved differently with an item in the craft inventory that when primed before the battle starts a script will do some magic or with a unit like the orbital beacon. So I am going to focus on the first one.

Essentially my suggestion is to add

Code: [Select]

BattleGame.getCraft [ptr/ptre Craft]
Craft.getCraftWeapon [int (slot)] [ptr/ptre CraftWeapon]
CraftWeapon.getType [text]
CraftWeapon.getAmmoQuantity [int]
CraftWeapon.setAmmoQuantity [int] # optional

Side possibilities for ptre are missions that
- cost craftWeapon ammo and therefore money to deploy specific turrets/close air support.
The ammo would be reduced by a script and it wouldn't matter whether the battleScape ammo is used up on battleScape or not.
... Thinking about it some more, this will probably also create an edge case that in a dogfight the craft will try to expend ammo for the battleScape related craftWeapon.
Could a craftWeapon with range: 0 and ammoMax: 1 create strange behaviour?

- damage/repair hull, etc. (Craft.getFuel/setFuel/getHull/etc.)
for modifying the craft's fuel etc, there are concerns that fuel is modified in such a way that the craft could technically not return to base. This might already be covered  with a sanity check forcing the craft to return to base. Also hull should not be set-able to zero or above the total health.

For this suggestion it's completely sufficient if the type of equipped craftWeapon can be obtained and maybe that the ammo count can be set between 0 and ammoMax.

Thanks for all possible considerations.

7

OXCE Support Y-scripts / [Solved] Difference between some scripting hooks in group bonuses

« on: January 14, 2023, 08:20:34 pm »

We were looking at the scripting hooks such as energyRecoveryBonusStats and energySoldierRecoveryBonusStats. I didn't really get smart looking at them in the source code. BonusSoldierStatsRecoveryParser and BonusStatsRecoveryParser inherit from BonusStatsBaseParser but I don't really see a difference the two.

What is the difference between these hooks?
Thanks.

[Spoiler]

8

OXCE Bugs / [Potential Bug?] reactionWeaponAction triggers on moving after shooting

« on: January 07, 2023, 12:40:53 pm »

In the mod I have a gun which simulates a way to call in an airstrike (battleType: 1, arcing, ... essentially a grenade launcher). Enemies shouldn't react on the action_unit.
So I wrote a script that looked exactly like in the first code block here

Spoiler:

Code: [Select]

items:
  - &STR_GUN
    type: STR_PISTOL # test item only # battleType: 1, not arcing

    scripts:
      reactionWeaponAction: |
        debug_log "====================";
        debug_log "reactionWeaponAction";
        debug_log "====================";
        debug_log "action_target" action_target;
        debug_log "action_unit" action_unit;
        debug_log "arc_to_action_unit" arc_to_action_unit;
        debug_log "battle_action" battle_action;
        debug_log "distance" distance;
        debug_log "move" move;
        debug_log "reaction_battle_action" reaction_battle_action;
        debug_log "reaction_chance" reaction_chance;
        debug_log "reaction_unit" reaction_unit;
        debug_log "reaction_weapon" reaction_weapon;
        debug_log "weapon" weapon;



        return 0;


Once the gun is fired, the reactionWeaponAction script continues running for battle_action == 0 (BA_NONE) && move == 0 (walking) || move == 1 (running, didn't test flying) as observed in the openxcom.log. This means that once the gun is fired, you can use up all your TUs for movement and not be fired at. Once you shoot another gun which isn't using this script, things work normal again. See the attachment for a mini mod and savegame to test with.

Knowing that I can solve the problems in the script (see below).
My question is: Is it intended that reactionWeaponAction continues to trigger on movement after the script was called the first time?
Thanks for looking at it.

Spoiler:

Code: [Select]

items:
  - &STR_GUN
    type: STR_PISTOL # test item only

    scripts:
      reactionWeaponAction: |
        # was return 0;


        if neq battle_action BA_NONE; # or compare to specific shooting related battle actions
          return 0;
        end;

        return reaction_chance;


9

OXCE Suggestions Y-script / [Suggestion] ptr for getInventoryItem.(size)

« on: April 15, 2022, 01:26:16 pm »

Currently I try to recolor sprites depending on items in the inventory. The script command getInventoryItem only works with ptre BattleUnit which isn't accessible in the recolorUnitSprite script hook. In this hook only ptr BattleUnit is available. I can imagine that iterating through the inventory every cycle might considered a waste of CPU and therefore ptr isn't allowed there. If this is not a problem I would like to suggest that a ptr version for getInventoryItem(.size) is made available.

Thanks for reading and possible consideration.

10

OXCE Suggestions Y-script / [Suggestion] Let scripted HP/Stun changes trigger damageSpecialUnit Hook

« on: April 15, 2022, 01:03:26 pm »

Currently I try to write a script for the Dune mod that does the following:

If anything with Laser damage type hits a unit with a personal shield equipped, the game rolls a chance to either explode the attacker, the target or both. Target works well as I use specabs together with damageSpecialUnit ("explode on Death"). Right now I am trying to kill the attacker with script commands including setHealth 0, setStun 999 or setSpawnUnit and neither trigger damageSpecialUnit (or damageUnit for that matter). Maybe there is a different solution but right now I feel like it would help if scripted based HP/stun/damage changes would also trigger damageSpecialUnit.

Could scripted HP changes be introduced and appended to this list from the Changelog for 7.4.2?

Thanks for reading and possible consideration.

11

Troubleshooting / Unintended Slit in Avenger Cockpit?

« on: April 10, 2022, 02:02:51 am »

There was a complaint on the XCF Discord that a turret on height L2 could shoot inside the Avenger and kill their agents.

After taking a look I found that there is a slit in the Avenger Cockpit. I also checked the OpenXCOM UFO Patch if it would have fixed it. This is not the case.

Would you consider this slit to be 'part of the window' or more of an oversight that should be fixed?

Proposed fix: For MCD Index 24 and 25 turn loft 12 from value 12 to 14 (see AVENGER.MCD)

12

OXCE Suggestions DONE / [DONE][Suggestion] Statistical bullet saving for craft weapons

« on: March 28, 2022, 10:40:42 pm »

Edit by Meridian: original title was: [Suggestion] Add 'reloadingDisabled' to Craft Weapons

Motivation:
When using craft weapons that use clips (for example STR_CANNON using clips with 50 shots), entire clips will be reloaded even if only one shot has been fired. For example ammo count 199 will turn to 200 using a x50 item. Currently it's possible to click on the weapon in the craft screen to disable a weapon. This will do two things: It will disable the weapon by default for dogfighting and needs to be enabled on a per dogfight basis. Also it will stop the weapon from reloading. This suggestion is about turning the disabled state for weapons in dogfights as well as the reloading part into two different things.

---

Proposed Solution:
By adding a bool called 'reloadingDisabled' the currently existing bool 'disabled' will be limited to enable/disable weapons in the dogfight screen. Similar to the dogfight screen the weapon icon will change its palette (preferably looking 'inverted' or better said as it looks in the dogfighting screen). The 'reloadingDisabled' flag will take care of the reloading part and use the already existing *.

This will create four states:
Load in Base and Enabled for Dogfight (Standard Behaviour - * is not shown & Icon is not swapped)
Load and Disabled (Preferred use case for Missiles - * is not shown & Icon is swapped)
Don't load and Enabled (Preferred use case for Cannons with ammo packs x50 or other numbers - * is shown & Icon is not swapped
Don't load and Disabled (Previous second Behaviour - * is shown & Icon is swapped)

I have tried to implement this. See the commit.
The palette swap does not use the correct palette/color combination as of now. Maybe you know which one to use. If not I can play around with the values.

The commit will turn the single clicking action into a left and a right click. Left click alters the disabled bool, right click the reloadingDisabled one.

I have played with it for a few days and it seems to work alright and as intended.
As a side effect the window "Not enough {ammo} to rearm {craft} at {base}" will not pop up, if one decides to keep the base inventory empty to prevent reloads.
Another side effect is that special missiles can be disabled by default and only used against specific UFOs. The player will not have to remember reloading the special missile weapon assuming they use the 'disabled' flag. Of course the player will have to remember the reload of the cannons.

---

Alternative solution would probably to only load full clips or keep the remainder stored as information in each base for each ammo type.

13

OXCE Suggestions DONE / [DONE][Suggestion] Ability to hide Pedia articles (by players)

« on: February 13, 2022, 02:56:45 pm »

Playing a mod with a lot of clutter such as XCF or any other mod with huge amounts of contents it would be helpful for comparing items/armors/etc. if a 'hidden' flag for Ufopaedia articles would be introduced. Right now when looking through the ufopaedia one has to click through many possibly obsoleted articles. Also when trying to compare two specific, the articles inbetween could be hidden so you don't have to click x times the next/previous buttons due to how the listOrder is set up.
This feature would help me to clean up the Ufopaedia so only items are displayed that I actually use and it would be easier to compare items with each other.

Similar to hidden manufacture projects a right click would turn the Ufopaedia article from 'new' over 'read' to 'hidden'. Hidden articles would be skipped when pressing the next or previous button. If no next or previous unhidden article is found, the game will stay at the current article. The "show only new" button will probably become a listbox similar to the one in the manufacture screen. The ufopaedia in the battlescape would be unaffected and/or middle clicking in battle ignores the hidden flag. Ufopaedia articles with multiple pages would be treated as one.

Thanks for reading and possible consideration

14

OXCE Suggestions DONE / [DONE][SUGGESTION] Show remaining Energy next to TU for Path Preview Arrows

« on: March 28, 2021, 02:31:12 pm »

Considering the alternate movement methods as well as mods (such as 40k) that use energy for special actions, it would be great if the path preview arrows could also display remaining energy next to TU. This should prevent that a player has to calculate and/or save/load to get the unit as far as possible while also having sufficient energy left to do a special action.

Attached is a small mockup how it could look. For reference bottom is Index 48 (a2e386) for remaining TUs and index 16 (ffd300) for remaining Energy. Of course any other color works too.

15

Tools / Merge 2x2 Spritesheet Tool

« on: March 24, 2021, 10:20:51 pm »

This is the opposite to the HWP Build helper. It's compatible with the split spritesheets from the HWP Build helper. In fact it was tested with them.
I wanted to merge split spritesheets for 2x2 units back into complete ones, so it's easier to edit them.
This works for all drawingRoutines relevant to 2x2 units (2, 3, 5, 11, 12, 20 and 21)
For drawingRoutine 2 and 11 this tool expects 5 turrets each.
For drawingRoutine 2 and 3 there are a few artefacts for the propulsion. I haven't found out why yet. But they should be easily removed by hand.

Usage:
At this stage it is a command line tool (no fancy GUI yet)
You will need to path to the location of this python file and type

Code: [Select]

python merge_2x2_spritesheet.py file_to_be_merged.png drawingRoutineNumber

For example:

Code: [Select]

python merge_2x2_spritesheet.py split_hwptemplate_21.png 21

Of course it would be great if this Python script could be implemented on Falko's PythonAnywhere page

If you find any issues or got any other feedback, feel free to post.