Messages

1

OXCE Bugs / 'buildOverFacilities' bypasses country/region 'forbidden/provideBaseFunc'

« on: April 11, 2024, 11:30:54 pm »

If a facility has 'buildOverFacilities' defined it will bypass any checks on 'forbiddenBaseFunc'/'provideBaseFunc' as assigned to a country/region when placing the facility.
Or at least .. that is what it looks like to the player.

This was verified on the 7.12 linux release from: https://openxcom.org/forum/index.php?topic=5258.0
Using the mod and save attached to this post (save is in the root of the zip).

To reproduce:
* Start OXCE with the attached mod active.
* Load the save from the attachment (or start a new game, but then you have to position your 1st and 2nd base correctly)
* Observe the following (for both bases):
  + One can place both the "Living Quarters" and "Small Radar System" even though it should be forbidden by the country (1st base) / region (2nd base).
     With place I mean: Click on basegrid is honored and we are presented with a "under construction" image.

Expected behavior:
 The game should forbid the placement at the moment the player places it.

To test if the ruleset was setup correctly one can disable the ´buildOverFacilities` parts in the ruleset.
In that case the game recognizes those facilities are not allowed to be build (albeit it does it slightly earlier when it creates the list of possible facilities).

2

OXCE Support / Re: Difficulty installing on Pop!_OS 22.04- but I think I'm close.

« on: March 18, 2024, 06:07:17 pm »

You've somehow managed to install the GOG version of UFO defense under the "~/.local/share/openxcom/mods" folder.

This is a location where the engine (e.g. openxcom) only expect user mods.
For the actual *required* data files it looks under "~/.local/share/openxcom/UFO" and/or "~/.local/share/openxcom/TFTD" (those are default locations which suffices for the majority of users).

Judging from this discussion the best advice I can give you is to run the following command in a terminal.

Code: [Select]

mv ~/.local/share/openxcom/mods/* ~/.local/share/openxcom/
This will move the contents of your current mod folder, which happens to contain the correct folders, to the main openxcom folder.

Yes ... this will leave you with a lot of (harmless) noise files in the openxcom folder but it should suffice to get a working version.
If necessary you can decide to clean up those noise files at some later time.

As for the remark in the first post (not being able to find the "tmp/.mount_OpenXCJIOwQs" folder).
This is to be expected. Due to the way AppImages work this 'folder' only exist while you're running the AppImage (e.g. play the game).
It is a folder that an user (e.g. someone that is only interested in playing the game) can safely ignore.

3

Troubleshooting / Re: how to change user folder game folder etc

« on: March 10, 2024, 11:50:50 pm »

In the new location create a folder called "user".
Move anything from the new location to this new folder, with the exception of the next folders
- TFTD
- UFO
- standard
- common
Those should stay in the folder root of the new location.

This should suffice to create a portable installation (from your description that is what I assume you desire).

For completeness:
This is assuming you've also copied the executable (OpenXcom.exe) to this location, otherwise you have to start fiddling with scrips/commandline arguments.

4

OXCE Suggestions NEW / Re: [Workaround] Error: No X-com Installations Found (Linux Mint, OXCE ver 7.11)

« on: March 02, 2024, 11:41:43 pm »

If that test version was based on the 'test' branch commit `f2edbd196b` I can confirm that a Linux compiled version works for both scenarios now (e.g table row 2 becomes 'works' 'works').

5

Translations / Re: HELP: Windows Installer translation completion

« on: February 26, 2024, 11:36:06 pm »

Did my part for the Dutch language.

Opted for a bit more of a descriptive translation since that felt more natural.

Funny though, when it comes to openxcom (and software in general) my natural language feels kinda ... alien.

6

OXCE Suggestions NEW / Re: [Workaround] Error: No X-com Installations Found (Linux Mint, OXCE ver 7.11)

« on: February 22, 2024, 07:57:14 pm »

No problem, thank you for recognizing it as (possible) unwanted behavior.

If you need any more information, help testing, or other ways I can contribute:
Feel free (for the triple of you) to contact me on any known communication channel that best fits your preference.

7

OXCE Suggestions NEW / Re: [Workaround] Error: No X-com Installations Found (Linux Mint, OXCE ver 7.11)

« on: February 19, 2024, 10:42:46 pm »

Since I vaguely remembered this error did not manifest on OXC appimage I decided to do some comparison tests.

Using the following setup:
* A fully operational folder structure on the game default path (``~/.local/share/openxcom`` for linux)
* A test folder for the binaries (``~/oxce``)

With the following binaries
1) OXCE AppImage: ``OpenXCOM_Extended-v7.11-x86_64.AppImage``
   Using OP's download (wget) link.
2) OXCE Binary: ``OpenXcomEx, v7.11-8e9fdfc...``
   From https://openxcom.org/forum/index.php/topic,5258.0.html
3) OXC AppImage: ``OpenXcom_20210611_8d45159bf_x86-64.AppImage``
   Using download link from website (https://openxcom.org/git-builds/)
4) OXC Binary
   Compiled from commit "f2e509c4" since I could not find a binary only download.

And the following test scenarios:
A) test folder contains **only** the binary.
B) test folder contains binary and **empty** folders ``UFO`` & ``TFTD``.

The results are summarized in the table below.

Binary	Scenario A	Scenario B
1	fails (I)	fails (I)
2	works	fails (II)
3	works	works
4	works	works

(I)  Message: No installations found
(II) No message, but got presented with a black screen (no crash).

From this i would conclude that OXC and OXCE differ in behavior in that:
OXC seems to test if the required folders (UFO & TFTD) have some content and if not keeps searching.
OXCE seems to test only for existence of those folders, where the first one wins.
-> Kinda weird since ``OpenXcom::Options::_gameIsInstalled()`` suggests OXCE does actually test.

Hope this helps.

P.s.
The installation instructions for the appImage as seen when following the docker link from forum topic mentioned before are still technically correct.
It states that one has to create (and fill with correct data) the UFO and TFTD folders in the **same** directory as the AppImage.
It does not mention that the AppImage does not work with the default data folder (~/.local/share/openxcom). Even though one might assume it does.

P.p.s.
Logs for the 8 tests performed are available as attachment.

8

OXCE Suggestions NEW / Re: Error: No X-com Installations Found (Linux Mint, OXCE ver 7.11)

« on: February 16, 2024, 11:21:40 pm »

...

Code: [Select]

...
[16-02-2024_21-57-43] [INFO] Scanning user mods in '/home/beng/oxce/'...
...
...

This tells me that OXCE looks in a different place "~/oxce/" instead of "~/.local/share/openxcom".
As to why i have no idea.

One possible solution is to copy the content of "~/.local/share/openxcom" to "~/oxce/".
Or move the appimage to ¨~/.local/share/openxcom".

I tried both methods on xubuntu, both worked. Before that i got the same error as you did.

9

OXCE Suggestions NEW / Re: [Suggestion] fixed weapon firing mode

« on: February 05, 2024, 08:39:08 pm »

Let me first say that that i have no strong objection against a weapon board.
After all, one can argue this creates another opportunity for a mod author to add a personal touch.

This post is just to point out an alternative if one wants to reduce the amount of necessary clicks for firing a weapon.
---

How about letting the game remember the last action type as chosen by the player (e.g. snap, auto, aimed, melee) in the current battle?
And use that one as the default for all subsequent fire clicks until a new one is chosen (which in turn becomes the new default).

And if some visual feedback is needed:
Perhaps use the same system as "this weapon is used for reaction" e.g. a dot overlay on top of the appropriate "reserved action" button? In this case kneel could represent melee.

Would that work @bulletdesigner?

10

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

« on: January 02, 2024, 10:41:50 pm »

Most likely scenario: You are on the first day of the new month.

This graph shows the monthly score, *not* the cumulative score. Hence the reset to zero.

11

OXCE Support / Re: Fixed width font for numbers

« on: December 12, 2023, 01:42:06 am »

That is something (fixed width characters) one can already reach using mods.

It might require some maths and/or some fiddling.
See:
- https://www.ufopaedia.org/index.php/Ruleset_Reference_Nightly_(OpenXcom)
For the definition of the font collection.
and:
- https://www.ufopaedia.org/index.php/Font_collection_(OpenXcom)
For the fine tuning, take special note of the `spacing` variable.

12

Troubleshooting / Re: Sudden Crash after months end in enemy unknown without mods

« on: September 16, 2023, 01:00:01 am »

In your save you have to do a search for the snippet.

Code: [Select]

    pact: true
If you want the country to 'rejoin' delete this line.

13

Help / Re: Mods not showing up on list

« on: August 26, 2023, 05:41:49 pm »

Try the answer from the following post:
https://openxcom.org/forum/index.php/topic,11439.msg157080.html#msg157080

14

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

« on: July 22, 2023, 12:37:03 pm »

... Maybe caused by German translations?

It seems you are right.

Perhaps there was some error involved in the publishing process, assuming "https://mod.io/g/openxcom/m/the-x-com-files" holds the latest versions.
In the download "openxcom_xfiles_3.0.3-4nte.zip" there is still one language reference to 2.0 (all other languages from that download refer to 3.0).

Code: [Select]

openxcom_xfiles_3.0.3-4nte/XComFiles/Language/de.yml:  STR_OPENXCOM: "The X-Com Files: v. 2.0"

15

OXCE Suggestions DONE / Re: [Suggestion] Only reserve Workshop-space-requirement when at least one engineer

« on: April 30, 2023, 11:27:42 pm »

Personally I think this would indeed be a nice QoL feature (especially for a manufacture heavy mods).

The description from the original post leaves me with an additional question though:
1) Some manufacture projects might require an input item that gets destroyed upon starting (or completion?) what would be the desired action in the following cases:
 A) Player has queued the project, never assigned an engineer and now wants to stop the project. What should happen with the input item?
 B) Player has started a project that should run 20 times. After project has run 15 times player decides to cancel production (but some hours were already put in for round 16), what should happen with the 16th input item.
 C) Similar to B, but player decides to stop between finish of 15th round and 1 hour later (e.g. no man hours were put into round 16 yet).

I must admit, B and C might be outside the scope of the original question (since it is something that could happen already).
Reason i asked them anyway is because I believe it is important from a player perspective the behavior between A-C is consistent.

As for Meridian's question on the lack of workspace behavior.
I would rate them in the following order:
1> Show an error message, something akin to:
     "This project requires X workspace to start, only Y is available".
     Where X is required workspace + 1 and Y is the amount available.
2> Whenever entering a GUI, or hovering over a project in overview screens, where one can assign engineers to a project:
     Subtract the required workspace from available as is visible on screen (and thus allow negative numbers for "workspace available").
3> Ignore (do not like that one but I went for an ordered list ... so ...)