Topics

1

OXCE Bugs FIXED / [FIXED] Crashes related to ruleset file load order

« on: December 14, 2024, 11:34:40 pm »

Currently we're loading files in the order of... newest to oldest (last write time descending order).
Usually this means z to a, because when users extract mod zip files (or clone a repository), these files are created on the hard drive in alphabetical order (the order in which they're downloaded, or order in which they appear in the zip file, which is usually alphabetically), so the z file is created last, and thus it's loaded first because it is the newest file.

This is both confusing (a normal user would expect the order to be a-z), and problematic, because if someone manually edits one of the rul files, even if they simply resave it without any changes, it changes the order in which the files (and folders) are loaded.

Currently we're loading files in the order of... z-a (descending case-sensitive alphabetical order).

This is both confusing (a normal user would expect the order to be case-insensitive a-z), and problematic, because if someone renames one of the files/folders, it changes the order in which the files are loaded.
And currently the majority of mods crash (or have other issues) if files are loaded in the wrong order.

Why is loading files in the wrong order problematic?
1. Wrong rule values. If a Rule object is defined in two .rul files, then the Rule object properties in the last file processed get to overwrite the properties of the first one.
2. Crashes due to erroneous error checks. If a Rule object is defined in two .rul files, then loading the wrong one first could throw due to object temporarily being in an invalid state.
3. Failed script parsing. Tag names need to be defined before Rule objects are allowed to set values for those tags. So the ruleset with tag names needs to be loaded first.

The 2nd problem could be solved by moving the error check to the afterLoad() function.
The 3nd problem could be solved by loading all the rul files and processing their "extended:" nodes before processing any other yaml nodes.
The 1st problem however cannot be solved. Even if we forcefully sort the files in a specific order, there's no guarantee that the modder won't rename them and thus cause a crash. It would also be inconvenient to modders if we forced a certain sort order.

Basically, what we need is to allow modders to specify which rul files to load first. That would solve all 3 of the problems. Perhaps something in metadata.yml or vars.rul.

2

OXCE Suggestions NEW / Research History

« on: November 30, 2024, 01:46:49 am »

I suggest adding a Research History feature.

This would be useful both for:
- players themselves, because they'd be able to check what path they took through the research tree in their current game or some other past game
- community, because they'd be able to check the path that some player took through the research tree and compare it to their own
- modders, because they'd be able to check what path the players of their mod took through the research tree, to get various insights, such as whether a certain topic was too easy or too difficult to reach

The suggestion would require creating a new window where the research history would be presented.
I'm not sure what would be the best place for the button to access this window and the history.
I'm also unsure about what features such a window should have (search / sort / filtering).


Technically, I suggest adding "discoveredHistory" sequence to a .sav file, where each element is a mapping containing information on how, when and where a discovery was made.

Code: [Select]

discoveredHistory:
  - { name: STR_BOWS_SUMMARY,   time: {second: 0, minute: 0, hour: 0, ...}, sourceType: 0, sourceName: "MyResearchBase" } //sourceType = Directly from a research project in a base
  - { name: DARK_TROOPER_ARMOR, time: {second: 0, minute: 0, hour: 0, ...}, sourceType: 1, sourceName: "Darktrooper" } //sourceType = Free after completing a different research topic
  - { name: STR_POLAR_OUTFIT,   time: {second: 0, minute: 0, hour: 0, ...}, sourceType: 4, sourceName: "Location: Arctic" } // sourceType = event reward
  - ...

3

OpenXcom Extended (OXCE) / Converting OXCE to rapidyaml

« on: October 21, 2024, 09:41:19 pm »

Everyone knows that saving and loading games in OXC and OXCE gets progressively slow as the game goes on. Well, it's not much of a problem in OXC, because vanilla games aren't large and don't last that long, so the issue doesn't become super noticeable. Since this isn't an OXC issue, it doesn't make much sense to fix it there.

Anyway, the main culprit is the yaml-cpp library that the game uses. The simplest solution is to ditch that library and use a faster one. So, I've decided to take on a monumental task of converting OXCE from yaml-cpp to rapidyaml.

I'll use this thread to document some of the observations and pitfalls I've encountered during the coding.

4

Suggestions / Modify a couple of icons of the default forum theme

« on: September 29, 2024, 07:08:00 pm »

Personally, I find it a bit hard to distinct the two icons (both are just shades of grey), so I suggest that the default forum theme (Insidious) be modified:

Change the "No new posts" icon from the current to
Change the "New posts" icons (on.png and on2.png) from the current / to

Change the "No new posts" legend icon from the current to
Change the "New posts" legend icon from the current to

5

OXCE Suggestions NEW / [Suggestion] Less repetition when craft pilots missing

« on: September 23, 2024, 04:18:13 pm »

1. In geoscape click on a UFO
2. Select the option to launch craft
3. Select a craft
4. Click Ok
5. Get an error message that the craft is missing pilots. Select the option to add pilots to the craft
6. Add crew (pilots) and click OK
7. Repeat step 1
8. Repeat step 2
9. Repeat step 3
10. Repeat step 4

Currently, if the user adds missing pilots, they have to repeat steps 1-4 before they're able to launch a craft.
I'd like to suggest that this be changed so that, after the player returns from the craft window, the window state remains, and they only need to click Ok (step 4), to finish launching a craft.

Edit: Removed the auto-launch craft requirement

6

OXCE Suggestions DONE / [DONE][Suggestion] Don't shuffle discovered section in sav file

« on: September 14, 2024, 10:58:58 pm »

Whenever you save your game (after passing a bit of time), the "discovered" section (string list of discovered research topics) gets randomly shuffled, making it impractical when trying to compare differences of two save files.

It would make my life easier if this shuffling didn't occur. Either by sorting this list on game save, or if the newly researched topics were always added to the bottom of the list and then remained in the order they were added.

7

OXCE Support / Rank inconsistency

« on: September 11, 2024, 01:45:44 am »

In ground battles, unit's rank is represented by a single number, rankInt. For friendly units, this rank starts with 0 for rookies, and goes up to 5 for commander. However, for the enemies, this number does not represent a unit's military rank, but is instead the unit's race member index (limited to 7), which usually has the opposite order. So this number has two different meanings, depending on which faction the unit belongs to.

This creates a problem with formulae which contain rank. Some mods have items where damage scales with rank. If you put such an item in the hands of a common enemy soldier, the item will suddenly do very high damage, because the race member index of such a soldier has a high rankInt number.

So, I think that for better consistency, the number used for rank in formulae should always come only from unit's military rank:
STR_LIVE_SOLDIER = STR_LIVE_TERRORIST = STR_ROOKIE = 0
STR_LIVE_NAVIGATOR = STR_SQUADDIE = 1
STR_LIVE_MEDIC = STR_SERGEANT = 2
STR_LIVE_ENGINEER = STR_CAPTAIN = 3
STR_LIVE_LEADER = STR_COLONEL = 4
STR_LIVE_COMMANDER = STR_COMMANDER = 5

8

OXCE Bugs / [Bug] Melee attacking friendly unit doesn't ignore meleeDodge

« on: September 09, 2024, 10:27:25 pm »

If you shoot a friendly unit at point blank range, the friendly unit will not trigger CQC mechanics, so your weapon will never get deflected. That's normal and okay.
But, if you melee attacking a friendly unit, it does trigger evasion, causing your otherwise 100% accuracy melee attack to miss it.
I believe this is a bug, because:
1. It's inconsistent with the gun deflection CQC mechanics
2. It doesn't make logical sense - the player intends to hit a friendly unit, so the friendly unit should cooperative with this intention, the same way they cooperate with any other command, and not dodge
3. Mind-controlled enemies will evade melee attacks, despite being under your complete control

9

OXCE Suggestions Archive / [Suggestion] Can't use Medi-Kit on a mind-controlled unit

« on: August 29, 2024, 12:32:49 pm »

In some cases (item medikitTargetMatrix = 31), when the player tries to use a medi-kit on a mind-controlled enemy unit, they're unable to do so, despite this unit technically being "friendly". What could be the problem?

10

OXCE Bugs / [Bug] Melee attack hits terrain instead of unit

« on: August 15, 2024, 11:29:29 am »

1. Load the .sav
2. Fist the enemy unit
3. Keep fisting

Current behavior: Enemy doesn't get hit, and the hit log registers misses (terrain hits normally don't register)
Expected behavior: Enemy should get hit, and the hit log should registers hits

11

OXCE Suggestions DONE / [DONE][Suggestion] Ground Page Numeration

« on: August 14, 2024, 05:06:34 pm »

For people who always want to bring everything with them on a mission (not me), in soldier inventory, if there's more than 1 page of items on the GROUND, it would be helpful to show page numeration (for instance, like on the screenshot).

Similarly, the Scroll Right button should also only appear if there's more than 1 page of items on the ground.

12

OXCE Suggestions DONE / [DONE][Suggestion] Don't waste excess craft fuel

« on: August 10, 2024, 04:12:24 pm »

QoL of certain players would be improved if they didn't have to worry about micromanaging craft refuelling of crafts with expensive refuel items.

13

XPZ Strategy/Tactics / The best place to shoot down enemies

« on: May 04, 2024, 11:25:00 pm »

Sometimes, it's possible to choose where you down a shipping. This can be important because it allows you to avoid negative environments like hot and cold.

The terrain texture on the globe decides what kind of a map the ground battle takes place on. So a good idea is to either wait until a shipping is over a particular kind of texture, or possibly direct the shipping there.

I've attached an image which shows all the possible terrain textures, the ones on top are zoomed in, the ones on bottom are zoomed out. Underneath is a description and a chance of temperature-related environment effect. As you can see, if you down a shipping on the right terrain, you can be safe from having to bring gear to counter these environments.
Note that, even if you shoot down the shipping on a safe terrain, you can still get a bad roll and get a Nuke Zone map, which drains freshness unless your armor and plasma resists are high.

There are also further benefits. Some terrains can spawn rare magazines, even gold bars, but I'd argue the most rewarding are orchards with Apples. Terrains with a relatively good chance to get apples on are: The three Habitation terrains and Steppe, while Desert, Arid and Tropic have a small chance. Other terrains won't yield apples, but they have a small chance to spawn a crashed Necroplane, which would yield some Necroplane Parts. In terms of rewards, I think the best terrain is Medium Habitation, while the worst is Swamp.

14

OXCE Suggestions Archive / [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.

15

OXCE Suggestions DONE / [DONE][Suggestion] Option to force percentageOutsideUfo on any mission

« 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.