Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Delian

Pages: [1]
1
OpenXcom Extended / [Suggestion] Game Startup Cache
« on: August 02, 2022, 12:22:04 am »
Quote
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).

2
OpenXcom Extended / [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 value
can 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.

3
OpenXcom Extended / [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).

4
OpenXcom Extended / [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.

5
OpenXcom Extended / [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.

6
OpenXcom Extended / [Bug] Melee reaction priority
« 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.

7
OpenXcom Extended / [SOLVED][Suggestion] 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.

8
OpenXcom Extended / [Suggestion] 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.

9
OpenXcom Extended / [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.

10
OpenXcom Extended / [Solved][Suggestion] 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.

11
OpenXcom Extended / [DONE][Suggestion] Split aimAndArmorMultipliers
« on: September 07, 2021, 01:04:52 pm »
I suggest that two new difficulty rule settings be added: aimMultipliers and armorMultipliers. These two would function the same as the existing aimAndArmorMultipliers, except each would control its own individual difficulty feature.

This way, it would be possible to increase difficulty with enemies having more armor, but not necessarily having better aim. And vice versa.

12
OpenXcom Extended / [Suggestion] Medikit Priority
« on: April 30, 2021, 03:50:41 pm »
Currently, if there are multiple units that are stunned on the ground on the same tile, you are unable to choose which one you wish to use a medikit on. This is problematic because, if there's one unit bleeding and about to die, you are unable to save them because, well, the medikit decided that it wants you to heal a perfectly healthy unit instead.

So, I'd like to suggest to either customize the medikit target selection, or fix the way in which the medikit prioritizes its target. I can think of several possible solutions, ordered by difficulty of implementation:
1. Add a button to the medikit usage screen that would allow the player to cycle through the targets, similar to how you can cycle between units in the inventory screen.
2. If the target is ambiguous, first show a dialogue that would allow the player to choose which unit to use the medikit on.
3. Use the medikit on the unit that is closest to dying. Calculate how many turns it would take for each unit to die and choose the one that has the lowest number.
4. Use the medikit on the first bleeding unit (if it exists, otherwise default behavior).

13
OpenXcom Extended / [BUG] lowAccuracyHitCounter
« on: September 06, 2020, 10:27:27 pm »
There is a soldier statistic called lowAccuracyHitCounter that is used for commendations. It doesn't seem to work.

I've checked the code in ProjectileFlyBState.cpp, and it looks like this counter was supposed to increase if you hit your target when your accuracy is less than the distance from the target. I've tried debugging the code a little and I've noticed the following:
The BattleUnit::getFiringAccuracy() call returns base accuracy instead of distance-reduced one.

For instance, I'm using a shotgun with a range of 6 and 6 reduction/tile to fire at a target 19 tiles away. At close range, the soldier has 92% accuracy with this shotgun, but due to the distance, the accuracy gets reduced to 14%. I shoot and hit the target, but this statistic doesn't increase. Obviously, since the accuracy value being used in the above check is "92" instead of "14".

I'm using X-PirateZ v.L3 with OpenXcom Extended 6.6 (v2020-08-22).

Pages: [1]