Topics

1

OXCE Suggestions NEW / [Suggestion] Alternative craft loadout: Hide items

« on: April 21, 2024, 10:20:29 pm »

I like the "Alternate craft equipment management" feature, however, changing equipment can become unwieldly when the variety of items on the base increases, since all the base items are included in the Inventory screen.

I suggest the following QoL feature: Allow players to mark or grey-out items that they don't wish to appear in the craft soldier's Inventory screen.

2

OXCE Support / [Suggestion] Make percentageOutsideUfo work for mission sites

« on: April 21, 2024, 03:02:43 pm »

When a deployment for a mission site (alien mission with objective: 3) uses customUfo setting and then uses an addUFO mapscript command, the added ufo is currently not recognized as an actual ufo, so in the deployment data, the percentageOutsideUfo setting of the deployed units is ignored when placing units on the map.

I suggest that the functionality of "percentageOutsideUfo" be extended to work for mission sites that had a custom ufo placed on them. This would make it easier for modders to control how enemy units are deployed on such missions.

3

OXCE Support / Reduce enemy suicides

« on: February 19, 2024, 08:07:54 pm »

When enemies are wielding explosive or incendiary weapons, it seems they don't care if they're standing within the blast radius. This is problematic because, well, from time to time they suicide this way. Note that this is not a problem in vanilla games, since enemies don't really get a large variety of such weapons there.

I'm not looking for a complicated solution, but:
If an enemy has a choice of using two weapons, they should prefer to use the one with which they won't cause substantial damage to themselves.

It recently happened to me that an enemy had a knife and a molotov cocktail. I was standing in melee range of them. So what did they do? They blasted me and themselves with molotov, instead of killing me with a knife lol. So a simple solution would be to prefer a melee weapon in melee range, if the other choice is a weapon with a blast radius.

A more complicated solution would involve blast radius and damage calculation on all the units caught in the blast radius, and to only use the blast radius weapon if the damage on friendly units would be a factor lower than the damage done on enemy units (either because of resistances, or radius damage dissipation). Could also include a random chance to just go and blast anyway.
An even more complicated solution would also involve moving away from the target until the calculation would be favorable enough.
But yeah, I think the first simple melee solution is good enough.

4

OXCE Suggestions Archive / [Suggestion] Rotating Craft Maintenance

« on: February 24, 2023, 01:22:26 am »

If you have the "Force craft launch" game option enabled, you're able to use the craft even if it's not yet ready. That is nice and all, but there's a few issues.

1. If the craft is damaged and out of fuel, then the craft is unusable until the repairs finish, which can take a long time.
2. If the craft is damaged and out of ammo, then the craft is useless (as an interceptor) until the repairs finish, which can take a long time.

The first problem could be solved if the order of maintenance was changed so that refuelling is done before the repairs finish.
The second problem could be solved if the order of maintenance was changed so that at least some ammo is loaded before the repairs finish.

So what I'd like to suggest is to change how the crafts are maintained when the "Force craft launch" option is enabled:
Instead of doing all the repairs first, all three parts of the maintenance should be done at the same time in a rotating fashion:
- Spend 1 hour repairing
- Spend 1 hour refuelling
- Spend 1 hour rearming
- Spend 1 hour repairing
- Spend 1 hour refuelling
- Spend 1 hour rearming
- etc...

This can easily be achieved, for instance, by preferring one action over another based on the result of "current hour of the day" modulus 3

5

OXCE Suggestions Rejected / [Rejected] Research Progress based on actual project cost

« on: August 16, 2022, 12:38:06 pm »

Rejection reason: after long discussions, it was decided that this is an unwanted feature (not even as optional feature!)


Currently, the research progress of a research project can show 6 values:

NONE - no scientists are assigned to the project
UNKNOWN - the scientist-days spent on the research project is less or equal to 33.3% of base research project cost
POOR - the amount of assigned scientists is less or equal to 7% of the base research project cost
AVERAGE - the amount of assigned scientists is over 7% and less or equal to 13% of the base research project cost
GOOD: Shown if the amount of assigned scientists is over 13% and less or equal to 25% of the base research project cost
EXCELLENT: Shown if the amount of assigned scientists is over 25% of the base research project cost

Note that the "base research project cost" isn't the same as "actual research project cost", which is base cost modified by RNG (+/- 50%).

This is how it's always been, however, I have a reason to believe that this is actually a bug in the original game. I believe that the original developers intended for the progress to be based on the actual cost, but due to a bug (perhaps a late addition of the rng element), the progress uses base cost instead.
The reasoning is obvious: the progress shown is more or less useless because of how incorrect the information it provides is. A project with "poor" progress can finish in 1 day, and a project with "excellent" progress can take forever to finish. It's impossible to use it to predict how long the research will take, so any player trying to rely on it has only ever ended up confused. Players that try to be efficient are forced to split research into several projects.

Therefore, I suggest that a new option is added to the game that would change how research progress is shown:
"Actual Research Progress"
"Show progress of research projects based on actual (RNG-modified) research costs"

I've already made the required code changes, but I have a few questions:
1. Should I make a pull request for OXCE, or for OXC? (Option under Geoscape or Extended?)
2. What to do with localization?

6

OXCE Suggestions Rejected / [Rejected] Game startup cache

« on: August 02, 2022, 12:22:04 am »

Rejection reason: this is beyond/outside the scope of OXCE

If the YAML files don't change, why parse them every time you run the game?

Currently, when you start up the game, the majority of loading time comes from loading the YAML files and from using that data to produce Rule objects.

I suggest this be optimized using a simple cache. Here's the preliminary idea's process:

1. Start up the game
2. Produce a hash from the YAML files that the game intends to load. The hash is created from the YAML file names, file sizes, and modification dates, plus from the exe file
3. Compare the hash to the cache hash
4a. If the hashes don't match (YAML files changed):
- Clear the cache
- Start up the game normally. Parse the YAML files and load the Rule object
- Create a new cache. Serialize all the Rule objects into a binary format cache file, and save the hash as a new cache hash
4b. If the hashes match (YAML files didn't change):
- Deserialize all the Rule objects from the cache file

For de/serialization, I suggest using FlatBuffers due to its deserialization speed.

Depending on the mods used, this approach could reduce the game startup time by up to 90% (+5% if a similar cache is used for the language files).

7

OXCE Suggestions DONE / [DONE][Suggestion] Compact save file formatting

« on: July 27, 2022, 01:05:36 pm »

- Save file formatting less verbose in selected cases (functionally same, no performance gain or loss, smaller file size, easier to read by humans)

I really like the recent change of making .sav files more compact. So I'd like to suggest a few more ideas to achieve better formatting in the .sav files.

There are two types of ideas here.
The first is to not save properties that have default values. If the game knows what the default value of an object property is, then there's no need to save this property in a file.
The second is to increase readability by formatting certain very common objects/arrays into single lines.

There can be thousands of items in a battlescape game, so it would be a good idea to both format these into a single line and remove default value properties

Code: [Select]

    - id: 961
      type: STR_SMG_CLIP
      owner: 1000043
      inventoryslot: STR_QD_SLOT
      inventoryX: 0 # default value
      inventoryY: 0 # default value
      ammoqty: 36
      ammoItemSlots: ~ # default value
      tags: ~ # default valuecan be reduced to:

Code: [Select]

    - { id: 961, type: STR_SMG_CLIP, owner: 1000043, inventoryslot: STR_QD_SLOT, ammoqty: 36 }Reducing 187 to 94 bytes.

Battlescape units have a lot of default values saved and could also use some compacting

Code: [Select]

    - id: 1000043
#create a new object "genUnit", add the next 2 properties to it, and format it to a single line
      genUnitType: STR_BANDIT_RATMAN_LEADER
      genUnitArmor: BANDIT_ARMOR_P5
      faction: 1
      status: 0
      wantsToSurrender: false #default value
      isSurrendering: false #default value
      position: [24, 13, 0]
      direction: 3
      directionTurret: 3 #default value - should only be saved if it differs from direction
#create a new object "battleStats", add the next 6 properties to it, and format it to a single line
      tu: 74
      health: 36
      mana: 145
      stunlevel: 0
      energy: 70
      morale: 100
      kneeled: false #default value
      floating: false #default value
      armor: [6, 6, 6, 6, 6]
      fatalWounds: [0, 0, 0, 0, 0, 0] #default value
      fire: 0 #default value
#create a new object "experience" with the next 8 properties and format it to single line. If all the property values are 0, then we probably don't need to save this object either
      expBravery: 0
      expReactions: 0
      expFiring: 0
      expThrowing: 0
      expPsiSkill: 0
      expPsiStrength: 0
      expMana: 0
      expMelee: 0
      currStats: #format to single line
        tu: 74
        stamina: 70
        health: 36
        bravery: 80
        reactions: 109
        firing: 79
        throwing: 55
        strength: 33
        psiStrength: 67
        psiSkill: 0
        melee: 72
        mana: 145
      turretType: -1 #default value
      visible: false #default value
      turnsSinceSpotted: 255 #default value
      turnsLeftSpottedForSnipers: 0 #default value
      turnsSinceStunned: 255 #default value
      rankInt: 7
      moraleRestored: 0 #default value
      AI: #format to single line
        fromNode: 16
        toNode: -1
        AIMode: 0
        wasHitBy:
          []
      motionPoints: 0 #default value
      alreadyRespawned: false #default value
      activeHand: STR_RIGHT_HAND #default value?
      tempUnitStatistics:
        wasUnconcious: false #default value
#create new object "murderer" with the next 7 properties and format it to single line.
      killedBy: 1 #default value
      murdererId: 0 #default value
      fatalShotSide: 0 #default value
      fatalShotBodyPart: 0 #default value
      murdererWeapon: "" #default value
      murdererWeaponAmmo: "" #default value
      mindControllerID: 0 #default value
      summonedPlayerUnit: false #default value
      pickUpWeaponsMoreActively: true #default value -> it's default if it matches ai.pickUpWeaponsMoreActively
      tags:
        UNIT_RECOLOR_DESYNC: 25
to

Code: [Select]

    - id: 1000043
      genUnit: { type: STR_BANDIT_RATMAN_LEADER, armor: BANDIT_ARMOR_P5 }
      faction: 1
      status: 0
      position: [24, 13, 0]
      direction: 3
      battleStats: { tu: 74, health: 36, mana: 145, stunlevel: 0, energy: 70, morale: 100 }
      armor: [6, 6, 6, 6, 6]
      experience: { bravery: 0, reactions: 0, firing: 0, throwing: 0, psiSkill: 0, psiStrength: 0, mana: 0, melee: 0 }
      currStats: { tu: 74, stamina: 70, health: 36, bravery: 80, reactions: 109, firing: 79, throwing: 55, strength: 33, psiStrength: 67, psiSkill: 0, melee: 72, mana: 145 }
      rankInt: 7
      AI: { fromNode: 16, toNode: -1, AIMode: 0, wasHitBy: [] }
      tempUnitStatistics: {}
      murderer: {}
      tags:
        UNIT_RECOLOR_DESYNC: 25
Reducing 1595 to 758 bytes and making it a lot more readable.

Next, after playing the game for a while, the missionStatistics section of the .sav file can grow to be quite large, so object entries in this list should be formatted to a single line each.

Only slightly effective, but base facilities, transfers, research, and production list entry objects could also be formatted to a single line.
Similarly for graph data numbers of funds, maintenance, researchScores, incomes, expenditures, country funding and country/region activityXcom, activityAlien.

I think most of the .sav files will grow large due to soldier diary killLists. The list object entries are already formatted to a single line there, but I have a couple of questions regarding these entries.

Code: [Select]

killList:
  - {type: STR_ZOMBIE_STERILE_TERRORIST, rank: STR_LIVE_TERRORIST, race: STR_ZOMBIE, weapon: STR_SHOTGUN_LT, weaponAmmo: STR_SHOTGUN_SHELLS, status: 7, faction: 1, mission: 9, turn: 2703, side: 0, bodypart: 1, id: 1000004}Could the property "race" be removed? It seems to me that in most cases, race can be obtained from the unit type itself and there's no need to save it.
Could the properties "side" and "bodypart" be removed? I don't know of any mods using these for commendations. There's an idea that, oh, a soldier could get commended for how many headshots they've made, but then you realize that aiming in the game isn't possible, so any such commendation would be based on random luck.

8

OXCE Suggestions DONE / [DONE][Suggestion] Monthly purchase limit

« on: July 20, 2022, 04:40:18 pm »

A feature that would allow limiting the amount of certain items/craft/soldiers that the player can purchase per month would open many doors for the mod authors.

Among other things, the mod authors could then also limit the amount of items the player can manufacture per month (by requiring a material with monthly purchase limit).

9

OXCE Suggestions Archive / [Suggestion] Counter civilian stunning exploit

« on: July 13, 2022, 12:56:48 am »

It often happens that "pro" players use a tactic where, in missions that involve civilians, like terror missions, they stun civilians so that aliens wouldn't attack and kill them.

I suggest modifying, or adding an option to modify alien AI in the following way: If the player stunned any civilians (check the battlefield if there exists any unconscious civilian units where the last his was from the player), it triggers a change in alien behavior in a way that they (the ones with ranged attacks) start attacking downed civilians. Not sure about the AI priorities, but attacking the bodies should become an option for the AI.

In other words, if aliens shoot a civilian and the civilian lives, then all is good and the behavior stays the same. But if player does that, then aliens start cheating and attacking downed civilians.

Hmm. Maybe it would also be a good idea to change the civilian AI so that it would be a bit more fearful of aliens. So that this counter wouldn't be too detrimental to the normal gameplay.

10

OXCE Suggestions DONE / [DONE][Suggestion] Remember the Light

« on: June 27, 2022, 01:05:37 am »

I'd like to propose two QoL features.

1. When toggling Personal Light, I'd like it if game remembered the setting. This would make the game experience better because:
- players wouldn't have to keep turning it off every time they start a night mission
- players wouldn't have to turn it off every time they load the game
- it's strategically detrimental; a spotter can see your units because of light, but you can't start a mission with your lights immediately off, so you get wrecked by the cheating snipers

2. When using Night Vision or Toggle Brightness, I'd like it if the game remembered the setting.
Most of the battles I do are night battles. I don't like playing with Night Vision because monochrome colors make environments look bad. So, I much prefer using Toggle Brightness (visual only). The problem is, again, that I have to toggle it all the time, so it would make my life easier if the game simply remembered what the Night Vision/Toggle Brightness setting was. Technically, the "Auto Night Vision threshold" setting could be removed if the game remembered what light setting the player uses in night battles.

11

OXCE Suggestions DONE / [DONE] Highest reaction priority for preferred weapon

« on: June 24, 2022, 02:25:46 am »

I have a soldier that has two weapons: A melee weapon, and a firearm (specialWeapon with specialUseEmptyHand: true) with a melee attack.
I right-click on the firearm to give its hand reaction priority.
An enemy walks into melee range. The soldier reacts with a melee attack.
Expected behavior:
The soldier should react with the preferred hand - the melee attack of the firearm.
Actual behavior:
The soldier reacts with the melee weapon.

In practice, I'm playing xpz and I have a soldier with built-in kung fu and a shield. The soldier reacts with the shield instead of kung-fu.

12

OXCE Support / [Answered] Overloaded stat bars

« on: April 04, 2022, 06:26:08 pm »

In a battle game GUI, you have a HUD showing some of the soldier's current stats, such as TU, energy, HP, morale, and mana. Four of them have numbers and bars, while mana has only a bar. Each bar shows two pieces of info, the current stat value (lighter color inner line), and the maximum (darker color outline).

There's several limitations here, the numbers don't display maximum/missing stats, while the bars are limited to a maximum value of 100, after which they go off screen, so to say.

I suggest these bars be enhanced so they're able to display values above 100. I suggest the usage of color overloading, like on the second attachment.

This would be useful because it would allow users to see values (and what's missing) even with values above 100.
A practical example would be, in xpz I have peasants which usually have freshness above 150. Due to the bar limitations, I can't easily see how much they're missing (even detailed stat screen only goes up to 150), to know whether I need to restore any or not.

An alternative solution would be to simply normalize the bars to 100 if the maximum is above 100.

13

OXCE Support / [Answered] Auto sale of random manufacture

« on: March 30, 2022, 11:53:35 am »

When you complete manufacturing a project which can produce random items (randomProducedItems), you're presented with a window showing a list of these random items that were produced. I think it would be a great QoL improvement if this list allowed direct sale of these items. Similar to how you're allowed to sell the items at the end of every battle, I'd like it if the same autoSales rules would be applied when selling the randomly produced items.

14

OXCE Suggestions DONE / [Bug] Damage display when holding alt key

« on: March 20, 2022, 01:43:18 pm »

When you're aiming at an enemy and have a crosshair shown, you can hold the alt key to display the possible damage range. It's possible that the displayed damage is incorrect if the weapon has a "Power reduction/tile" rule. This probably happens because the calculated distance is rounded precisely, instead of rounded up, like the game normally does with distances.

For instance, let's say a weapon has a powerRangeThreshold of 10 tiles and you're x=10 and y=1 distance away from the target. Normally, the game would consider this as a distance of 11m (10.05m rounded up). If you hold the alt key, the displayed damage will be reduced by 1x powerRangeReduction. However, according to my tests, the actual damage is not reduced.

I'm assuming that the distance is rounded correctly so that melee weapons with 1 range can function correctly on targets vertically (x=1,y=1) 1 tile away. That's fine, but then, the displayed crosshair damage should take this correct rounding into account, which it currently does not.

15

OXCE Support / [Answered] oneHandedPenalty but for damage

« on: September 21, 2021, 09:44:46 pm »

I suggest adding a new item rule setting, for instance, oneHandedDamagePenalty, which would allow the modders to specify a simple percentual damage penalty for two-handed weapons when they're worn in only one hand, similar to how oneHandedPenalty currently works for accuracy penalty.