Messages

16

Troubleshooting / Re: X-com files: Missing clip STR_HUMAN_SONIC_SHOTGUN on pop_os!

« on: April 08, 2023, 11:17:20 pm »

I tried downloading the linux version of open x-com extended, pasted and replaced the files into my xcom folder, but the openxcomextended executable won't run.

In order to help, some more info is needed.
* With "won't run" you mean: "Nothing happens when trying to start" or "It always shows some error" ?
* Could you check if the executable has the permission "executable" set (the latest download seem to have it set, but this is just to be sure).
* Are you trying to run it via the GUI (e.g. clicking an icon) or via terminal commands?

17

Open Feedback / Re: TFTD crash at 5120x2160

« on: March 29, 2023, 12:40:43 am »

I am kinda wondering, are you using full-screen or windowed/borderless?

Reason for asking:
Full-screen requires a display that actually supports such a resolution. On some systems it is allowed to define windows that are larger than supported by the display.
If the crash occurs in windowed mode there might be no (or less) need for any hacks/workarounds.

Forcing the reported window size of 5120x2160 (on my 2560x1440 screen) i was not able to reproduce (e.g. game made it to the geoscape when starting a game).
Unfortunately i am using a different OS which makes such a 'cannot reproduce' kinda weak.

On a sidenote:
Even if able to run at this resolution you might not like the result though.
It seems that such a resolution is approaching the limit of numerical calculations (see attached '5120x2160globe_cutout.png').

For reference: the settings i used are shown in the 'settings.png' attachment.
Some further observations (valid for "being able to run" and "resulting image"):
* Displayfilters *raw/disabled/scale gave identical results
* Option "letterboxed" did not influence the result
* Globe returns to normal when using any geoscape scale bigger than "1x" (for this resolution)

18

OXCE Suggestions OK / Re: [Suggestion] Statstring Enhancements

« on: March 15, 2023, 11:08:07 pm »

My bad, you are, of course, right. No duplicate keys. However, with the alternate design that uses a different key for percent-based conditions, it would be allowed. This is the one I'm moving forward with at the moment.

However, I should also note that conditions are inherently and based, so if you have a percent condition and an "absolute" condition active on the same attribute (which would be allowed), you would have to satisfy them both to trigger the stat string. This probably limits the usefulness of such an approach, but changing the logic to be or based is well beyond the scope of what I'm doing here.

The "no duplicate keys" allowed was actually the reason why i've asked question D. In order not to pollute my questions with made-up parameters i decided to keep the parameters close to the original post (as to reduce confusion).
The behavior i was trying to convey is show in the comments after the parameters.
For this scenario the default AND logic is actually beneficial (someone being considered a marksman if the stat is at least 60 AND at >75% of the max).


I do not think you need to add OR logic, it is a different kind of extension.
The whole point is providing a player with a means for global definition of statstrings without the need to know beforehand the limits of each specific soldier type in a mod.
Besides that: any OR logic is already possible using existing (fixed) statstrings rules, albeit one has to use some convoluted parameter combinations that can very easily escalate into very complex (and big) rulesets. If such advanced specifications are needed I suspect Y-script is indeed the better approach.
I have yet to see mods going that route, most likely since OR logic is only needed if someone wants to be extremely specific about their designations. My suggestion would be to keep it simple. If OR is desired it will be requested in the future. No need to make your current endeavors harder than strictly necessary.

19

OXCE Suggestions OK / Re: [Suggestion] Statstring Enhancements

« on: March 14, 2023, 11:59:14 pm »

Always nice to see people sharing the same ideas on quality of life features.

I can see it's usefulness for those mods with a lot of soldier types and a broad spectrum of stats (and regular updates that add/change).
It reduces the need for ruleset dives in order to keep one's (personalized) statstrings up to date (granted one is OK with less optimized versions).

Had a go of it myself, but it never got past a (barely) functionally concept.
Got sidetracked and haven't found the time to solve some of the challenges / bring it into a state that was useful for others [1].

Since you are actively working on it you might be interested in those challenges as to come up with solutions (or deem them inconsequential).


A. Base value
===========
Percentages need a base value as to what constitutes as 100%, there are multiple candidates one can chose:
1) Max of soldier 'statCaps'
2) Max of soldier 'trainingStatCaps'
3) Max of current soldiers on craft
4) Max of current soldiers on base
5) Max of all soldiers still alive on the globe (e.g. all bases)
6) Something else ...
Based on your post I suspect you've chosen '1' but it would not hurt to specify which one (or multiple?) you want to support.


B. Stat overflows
=============
It is possible for soldiers to slightly overflow a stat (e.g. percentages > 100), at least for the fixed base values.
Will you cap the values at 100 or recognize percentages above 100?


C. Behavior for base values != 100
===================================
From experience most (max) stat values tend to not align neatly with 100, meaning any percentage based range will lead to gaps or duplicates.
For reference, given the following statstring definition:

Code: [Select]

statStrings:
 - string: "x"
   firing: [~, 50, p]
 - string: "M"
   firing: [51, ~, p]

If the base value is < 100 one could end up with:

Code: [Select]

"SoldierName/xM"If the base value is > 100 one could end up with the following naming scheme when a soldier levels up:

Code: [Select]

"SoldierName/x" -> "SoldierName" -> "SoldierName/M" (e.g. missing statstring when a number falls between 50% and 51%).

How would you tackle this?


D. Allow both fixed and percentage for the same stat.
========================================
Although you've already touched this subject it is a bit unclear if you want support "one OR the other" or "both at the same time".
E.g. is the following example supported?

Code: [Select]

statStrings:
 - string: "x"
   firing: [75, ~, p] # Percentage based but it could map to a value of [40, ~] if base value is pretty low.
   firing: [60, ~]    # We only consider soldiers that can identify: "the business end of a gun".

E. Backwards compatibility.
=====================
When using any new definition one probably want to prevent errors (or undefined behavior) when a user tries to load it into an older OXC(E) version.
Worst case the application could choke (crash) on the ruleset. More likely it could lead to unexpected designations (percentages being treated as fixed values).
Any idea how to approach this?


My personal vision on those challenges:
===============================
A. Option (1) seemed to be the most logical one. Certainly more stable than 3-5 (not depending on RNG and not varying during the course of a campaign).
    Should prevent situations where: "One-eye would become *the* marksman in the land of the blind".
B. I believe this is less of an issue since I suspect most users will opt to use something akin to '[90, ~, p]' instead of '[90, 100, p]' but it is something to consider.
    My (weak) preference would be allowing percentages > 100. So one could designate: "the best of the best of the best ..." (e.g. '[100, ~, p]').
C. Never found a good way to solve this (yet), currently I tend toward the solution that does extra calculations:
    - If value is at upper boundary (e.g. '[~, 50, p]') calculate the next one up (e.g. '[~, 51, p]').
      + Use the midpoint for a decision if base value > 100.
      + Use floating point rounding for a decission if base value < 100.
    - If value is at lower boundary (e.g. '[51, ~, p]') calculate the next one down (e.g. '[50, ~, p]').
      + Use the midpoint for a decision if base value > 100.
      + Use floating point rounding for a decision if base value < 100.
D. Due to the nature of some stats a fixed minimum might be desired, hence my preference to support both at the same time.
    Again: "one-eye ... land of the blind".
E. Not a strong one since 'metadata.yml' value "requiredExtendedVersion" could prevent this situation, something to consider though.


Sidenote (since you are open to suggestions).
+++++++++++++++++++++++++++++++++++
Instead of adding an option to the range array, why not use specialized value definitions (like for example 'firingPercentage: [~, 66]')?
In my opinion that would make the desired use case stands out a bit more in the ruleset.


As for the statstring divider
++++++++++++++++++++
Although I do not deem it that important, percentage based statsrings deliver more QoL, I do believe it could be beneficial to personalize OXC(E) behavior.
However, there are as many opinions for separators as there are users (for example, "/", "\", " ", "|", etc...).

This means a translatable string (e.g. 'STR_STATSTRING_SEPERATOR' or something akin) has the best potential to cater for user wishes.
Since i understand bringing 'state' into 'soldier.cpp' might be hard (or nearly impossible) you might want to consider the following alternatives:
+ Add a new statstring top-level attribute e.g (replacing the current hard-coded one).

Code: [Select]

statStrings:
 - divider: "|"
 - string: "x"
   firing: [75, ~, p] # Percentage based but it could map to a value of [40, ~] if base value is pretty low.
   firing: [60, ~]    # We only consider soldiers that can identify: "the business end of a gun". 
 
+ Add a divider before each individual statstring (so one can end up with something akin to "Soldier|9|6|8|1|5")

Code: [Select]

statStrings:
 - string: "x"
   divider: "|"
   firing: [75, ~, p] # Percentage based but it could map to a value of [40, ~] if base value is pretty low.
   firing: [60, ~]    # We only consider soldiers that can identify: "the business end of a gun". 

Hope this post was of any use.

[1]_ Plus my soldiers rarely tend to age that well for it to actually becomes important for my play style :-)

20

OXCE Support / Re: Path preview bug

« on: March 04, 2023, 11:59:00 pm »

You're correct,

It is not the ground tile but the tile itself that controls whether or not path preview is drawn.

Since it is kinda hard for a player to determine if an air tile has been discovered I was trying to describe a quick check one can perform as to why this happens.
One that only works for this specific case (missing preview and fog of war visible on the lowest terrain with a 'floor').
In that case it is pretty safe to assume the preview is missing due to the most of the tiles in the column itself never passed visibility checks.

Sorry if my description caused confusion, i should have used better wording.

21

OXCE Support / Re: Path preview bug

« on: March 04, 2023, 07:28:36 pm »

In this case it is the ground tile that counts when it comes to being discovered.

Look at the black triangle just above the "next soldier button", this is a strong indicator those tiles are not yet discovered.

22

The X-Com Files / Re: Nothing from the mod seems to use its proper name

« on: March 03, 2023, 04:42:47 pm »

Since your description hints at the base game and mod working ok by themselves, my first suspect would be the display language you've set under Options:Video.

Can you try with EN-US and see if that fixes the problem.

23

The X-Com Files / Re: Bugs, crashes, typos & bad taste

« on: February 27, 2023, 03:38:29 pm »

From the looks of the image i'd suspect the reporter is missing the yellow preview squares containing the numbers "21" and "17".

Going even further.
Judging from the black triangle just above the "next soldier button" this is because the ground tiles have not yet been discovered.

24

The X-Com Files / Re: Bugs, crashes, typos & bad taste

« on: February 24, 2023, 03:40:38 pm »

...
I guess I misunderstood how rounding works.

It is not your 'misunderstanding' of rounding that is at fault here. The assumption that C++ uses normal rounding rules in this scenario on the other hand ... ;-)

I would not be surprised if the code responsible for recovery uses integer math: That will always round towards zero, unless special provisions are taken.

25

Brutal AI / Re: Small Git-Question about pull-requests

« on: February 12, 2023, 10:26:20 am »

From my experience.

Automatic merges usually fail if there are changes on the same line for both sides.
Since the algorithm does not know what the truth should be a conflict is the safest approach.

26

OXCE Support / Re: Save / Load equipment template doesn't work properly

« on: February 11, 2023, 12:00:56 pm »

...
Also, it is not possible to save a template when all soldiers have no items on their person. I wanted to do this to have an easy way to clear all inventories, but it won't save it.
...

Just in case you were not aware.
It is possible to work around this problem in the following way:
* Assign soldiers to craft.
* Make sure craft contains no items (shortcut "x" in craft item equip screen, if i remember correct).
* Click the inventory button.

Since the game cannot assign any previously assigned items anymore it will reset the load-out of all soldiers on board of that craft to be empty.

Keep in mind that this does not work when the new "apoc style" soldier equipment is active (the option called: "oxceAlternateCraftEquipmentManagement") since that one was specifically designed to prevent these 'accidents'.

27

OXCE Suggestions DONE / Re: Can items generated from geoscape events appear instantly

« on: January 28, 2023, 11:12:59 pm »

...
(@TBeholder - the difference is that if the items don't arrive straight away, then you can't get rid of them when you run out of space.)

Are you sure about this one? To me it looks like the code allows sale of in-transfer items if the sell screen is opened from the base menu.

...
If some minimum is needed, maybe 5 seconds tick would do?

Currently the code only checks base storage limits at the one-hour mark (as part of production updates). Not sure if moving such a check to every 5s-mark is something that is wanted (performance wise).

28

OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2

« on: January 21, 2023, 01:48:39 am »

Thank you for the kind words.
I do  believe my concept is very close to your "option 2" proposal (without the automation or protection).

Any new text (like "!!!") is actually translatable (choose your own poison ).

As for the difference between "equipped" and " claimed". It also took me a while to grasp the former. For your info:
- Equipped means: items assigned to craft inventory
- Claimed means: items claimed by soldiers.

As for the concept of soldiers claiming.
It does not really exist in my concept (other than that it made sense for variable names). It just makes use of something that was already tracked by OXC (e.g. latest stored soldier equipment, in the code it is called "game managed layout").
This concept only works in the confines of the mentioned screen.

As for implementation.
Even though it sounds nice to have any idea implemented, in the end it has to be maintained by the (main) devs.
A multitude of options is detrimental in that regards, hence why I put it up as a possible idea.
If it gets traction I'm willing to discuss how it can be merged with existing ideas / change my code to make it conform. But I can understand if the proposed change is deemed to invasive for inclusion.
That is one of the reasons i did not propose it earlier, too uncertain if it did not deviate too much from vanilla.

29

OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2

« on: January 20, 2023, 10:54:23 pm »

Since this seems to be the place about putting up (new) ideas for the craftEquipment screen I'd figured why not show the system I currently use.
It has evolved over time but is currently in a state for which i believe could benefit others as well.


The basic premise for this design was to allow for GUI adaptions but not for any changes to the underlying logic related to item allocation to soldiers.
New query methods were allowed if needed for numbers (but thanks to then new apoc-style equipment those are no longer necessary).

The main goal was to make item allocation a bit easier.
The true power lies in those situation where a mod provides a huge number of battleItems but stock is (always) limited.

See attached image-collage to get an ideas of how those changes look and the sections below for a description.

If interested in (part of) those ideas I can put up a demo branch rebased upon latest oxce-plus (9a90fab43).
The code gates most changes behind an user option but there are some refactors.
Reason for the gating is to let impacted code stand out while minimizing changes to existing logic and UI.


Major visual changes (A-C).
===========================
(A)
Changes the info line **if** the craft has a limit on item amount and/or size.
All fields (except for "Soldiers>##") are running numbers responding to list changes.

Intention behind this change:
Make player aware of the limitations before any error pops up.


(B)
Introduces buttons that operate on the list as visible (e.g. after filter has been applied).
They accept the same input as existing list button (e.g. respond to LMB, mouse-wheel and RMB).

There are two important things to note about the usage of those buttons though:
1) Those buttons use a 2-step approach when changing numbers.
   - The first click tries to balance claimed items in the direction chosen
     + Pressing ">" only operates on items that have less assigned to craft than claimed by soldiers.
     + Pressing "<" only operates on items that have more assigned to craft than claimed by soldiers.
   - Only when the list is fully balanced the buttons will operate on the full list again.
2) When using these buttons any error message related to craft limits is suppressed.
   - Allows to (temporarily) assign all items to craft in order to assist equipping via inventory button.
   - Even though errors are suppressed they are still enforced, see [F] how that is handled.

Intention behind this change:
Make item allocation easier but have some safeguard against accidental removal of claimed items (without enforcing a minimum).
(and visual AMSR while holding down LMB. But that is pure coincidence ... or is it?


(C)
Adds an extra column to show if (and how much) of a soldier claim exist on a item.
This new column uses a (translatable) indicator to convey the status, more_than/exactly/not enough, followed by the claimed amount.
The extra column approach was chosen because I did not want to change the meaning of the "on-craft" column.

Intention behind this change:
Inform player there are claims on certain items.

Side-note:
Image as shown still has an old alignment for the 'on-craft' and 'claimed' columns
Since the creation of the image those are shifted to the right (closer to original location of on-craft).
There still is an offset to the left of ~1 character (6px) though, to account for "more than reasonable" numbers.


Other changes (D-F).
====================
(D) Combobox.
-------------
This button now responds to RMB-clicks, when that happens the behavior changes into:
+ Show the inverse of the selected category (anything not belonging to ...).
+ Change combobox text to reflect this inverted list display.

The second change is that the default filter categories learned a new one.
- A filter to only show items claimed by soldiers.

(E) Visit inventory button.
---------------------------
This button changes appearance if it is detected that some claimed item is missing on the craft.
If that is the case any inventory visit would mean that some soldiers lose said item(s).

When the button is in this warning state an LMB click will show a warning.
This warning tells why it is not a good idea to visit inventory at this moment (and how to forcefully visit anyway).
A visit to inventory can always be enforced using 'CTRL+click' or 'RMB'.

(F) Return to base (ok) button
------------------------------
This button changes appearance if it is detected that some craft item limit has been exceeded.
A click on this button will replay any stored warning messages and it is not allowed to exit this screen.

To prevent players getting stuck on this screen a shortcut has been provided (CTRL+ALT+click) for forced exit.
This forced exit will restore craft inventory to the state from before entering this screen (to prevent erroneous craft state).


Relation with 'oxceAlternateCraftEquipmentManagement`
=====================================================
The original intent of this redesign was to provide extra info (and QoL operations) using existing data.
Since apoc-style predates this suggestion care has been taken as to not interfere with it's logic (only it's visuals).

This means that any protection provided by apoc-style is not overridden by this redesign (e.g. very unlikely to see "< ##").

It also means some gratitude is in order. This functionality allowed me to reuse some logic and thus made life easier.

30

OXCE Suggestions DONE / Re: Can items generated from geoscape events appear instantly

« on: January 20, 2023, 08:08:00 pm »

Interestingly, the event items can be sold instantly if there is not enough storage space possible.
...

Being able to sell "in tranfser" originates from OXC (perhaps even original, not sure though). Probably to prevent base overflow situations due to excessive amount of transfers.
That is also the reason items in transfer count toward base stores.

Think of it this way:
 At time of acquire you allocate/reserve the space they are going to take up the moment those items arrive at base.
 When you no longer wish those in-transfer items, you just undo the reservation and return back to sender anything that arrives at the base.