Messages

1

OpenXcom Extended (OXCE) / Re: OXCE (OpenXcom Extended) main thread

« on: March 02, 2024, 04:01:35 pm »

Switching to gcc-13, I can indeed compile OXCE.

I gather I could report this to Gentoo, as it is a compiler bug?

2

OpenXcom Extended (OXCE) / Re: OXCE (OpenXcom Extended) main thread

« on: March 02, 2024, 03:35:40 pm »

Hi,

I'm having trouble compiling OXCE on Gentoo (albeit a chroot). I've reproduced the problem on an i686 (32-bit) environment and an amd64 environment.

Steps I've taken:

Code: [Select]

git clone https://github.com/MeridianOXC/OpenXcom.git
cd OpenXcom
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DDEV_BUILD=OFF -DBUILD_PACKAGE=OFF
make -j 22
I'm using gcc 11 (I could try gcc-13):

Code: [Select]

# LANG=C gcc --version
gcc (Gentoo 11.4.1_p20240111 p12) 11.4.1 20240111
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And the failure:

Code: [Select]

LANG=C make -j 40
[  0%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/Script.cpp.o
...
[a bunch of suiccesfully build files]
...
/root/oxce/OpenXcom/src/Engine/Script.cpp: In lambda function:
/root/oxce/OpenXcom/src/Engine/Script.cpp:2616:84: internal compiler error: Segmentation fault
 2616 |                         updateReserved<ScriptText>(pos, ScriptText{ charPtr(start) });
      |                                                                                    ^
0x1745408 internal_error(char const*, ...)
        ???:0
0x7c8ec7 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
        ???:0
0x78015e c_parse_file()
        ???:0
0x8556dd c_common_parse_file()
        ???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
make[2]: *** [src/CMakeFiles/openxcom.dir/build.make:2232: src/CMakeFiles/openxcom.dir/Engine/Script.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:116: src/CMakeFiles/openxcom.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

Is this some obscure compiler bug or any idea what is going on?

3

Open Feedback / Re: Improving MIDI music support (ALSA MIDI) on Linux?

« on: February 28, 2024, 01:14:45 pm »

I'm not familiar with SDL2 (nor 3). However I believe there is in principle nothing preventing using MIDI outside SDL part in any game using SDL in other parts. Not having coded any games or audio related stuff - so take this with a big grain of salt - I might say that MIDI (as in accessing an external port/driver) might not be the job of SDL. It seems like native MIDI was an afterthought even in SDL(1), and they focused on some way to render it internally.

I might take a look at this at some point as a coding exercise, but don't hold your breath .

4

Translations / Re: How to use translations (in nightlies / git)?

« on: February 27, 2024, 07:42:25 pm »

Ok, by trial-and-error I found out that (on GIT version) from latest.zip:

• openxcom.openxcom/*yml goes into [DATADIR]/common/language and
  
• openxcom.x-com-[12]/*yml does into [DATADIR]/standard/xcom[12]

; presumably the root .yml only works with the latest release  .

5

Translations / How to use translations (in nightlies / git)?

« on: February 27, 2024, 07:32:33 pm »

Hi!

OpenXCOM does not come with any translations (at least the Linux version doesn't). I'm using the GIT version.

It seems the instructions in https://openxcom.org/downloads-extras/ and https://www.ufopaedia.org/index.php?title=Translations_(OpenXcom) are out of date (what on earth does for_use_openxcom_x-com-1 -part even mean, how does one get this file, why is it mentioned twice???).

First, it seems the game does not look for translations at all in the user home directory, or if it does, I don't know which folder I should use. This would be kind of mandatory when testing translations or pulling the most recent translation zip. I could not get the release nor the git version to find translations from there.

... which brings us to the folder structure and discrepancies in the latest.zip and the installation.

In /usr/share/openxcom I have:

• ./common/Language
• ./standard/xcom1/Language
• ./standard/xcom2/Language

Out of which all contain only en-GB.yml and en-US.yml;

but the latest.zip contains a [countrycode].yml files in:

• . (the root)
• openxcom.openxcom
• openxcom.x-com-1
• openxcom.x-com-2

I.e. four files per translation. Now where is a user supposed to put these files? Is one of them for the release and the rest three for the nightlies / GIT?

I can get it to load translations but only partially, by extraction the zip in common/Language -folder (there is no data/Language -folder), but only menus and options are translated, while all other parts of the game are not. The translations do seem to work correctly in the release, however.

6

Open Feedback / Improving MIDI music support (ALSA MIDI) on Linux?

« on: February 27, 2024, 04:57:47 pm »

Hi!

Now I gather most users will either use Adlib emulation or some OGG/MP3/wav soundpack floating out there. MIDI is a thing of the past.

But then there are the outlier like me who may have HW MIDI synths (old soundcards), or just want to try out different SW synths =). I can see the feature to implement ALSA midi ports in SDL Mixer has been requested, but never implemented. It would shift the burden off implementing SW MIDI off from any project using SDL, and open up a lot (well, any) possibilities to the users.

Seems like currently the MIDI music options are quite limited in OpenXCOM. Both GM and MIDI (only in GIT/nightlies, release has only MIDI) do the same thing (but, from a few threads, they are different on Windows?). This stems from the fact that SDL_Mixer has always been limited and can only use the bundled timidity or fluidsynth =(. There used to be a native-MIDI support in SDL_Mixer, but it is obscure and not well documented. It seems it relies on OSS /dev/sequencer support which is not a thing anymore (I skimmed trough the source of the latest 1.2.12-12, and actually could not see how it is supposed to work; I'm not even sure the current package on Arch even has native MIDI compiled in).  It seems like SDL_NATIVE_MUSIC=ANYTHING should make SDL_Mixer relay MIDI data to ... something, but at least this is not ALSA. It would be cool if it (for example) open an output port in OpenXCOM and (optionally) try to connect to any input port it can find, but it seems SDL_Mixer knows nothing about ALSA MIDI.

EDIT: Oh, btw just in case someone comes along here wishing to use SW MIDI music: even using Fluidsynth on Linux in OpenXCOM is also a bit obscure and not well documented. Scouring the net I found out setting

Code: [Select]

SDL_SOUNDFONTS=/usr/share/soundfonts/SGM-V2.01.sf2 (or any other soundfont of your choice) makes and SDL_Mixer application use the internal Fluidsynth with this soundfont. I.e. run openxcom like this:

Code: [Select]

SDL_SOUNDFONTS=/usr/share/soundfonts/SGM-V2.01.sf2 openxcom Internal Timidity is broken with any modern timidity config files on any modern distribution, but could be worked around by editing this file, while breaking the more modern config in the process - but luckily, there is little reason since Fluidsynth should be superior. But as already stated, the crux of the problem or limitation  is there seems to be no way to relay the MIDI to an external SW or HW synth.

Now, enough of the chatter! To the questions:

• Anyone got native MIDI working on Linux?
• Any plans to add ALSA Midi support into OpenXCOM?

I'm not sure, but point 2. could be a low-hanging fruit. I may make an attempt later when I have the time (I have some rudimentary programming skills).

7

Translations / Re: Finnish Translation

« on: June 05, 2014, 04:48:42 pm »

Thanks winterheart!

I agree, this is really just small cosmetics and can be done later. It might not be as straightforward as just translating the month names (even if done in both a short and a long form), however, but I believe still quite easy / trivial, if the requirements of different languages are known.

I wanted to tell about it here, since maybe there are other languages that don't have a way to display dates properly currently, too (that being said, if I'm not mistaken, the original date format in geoscape is not correct for either US or UK english???); hopefully devs find my message here, maybe I should have started a new thread to help in gathering the details for all languages .

For summary, the acceptable date formats in finnish are: "D.M.Y", "D.M." or "D. XXXXXXkuuta" (MARRASKUUTA is the longest month name). But the space will limit things, so for finnish, the choices are:

• in charts/graphs  the number of month (maybe followed by a dot): "M."
• in geoscape "D.M.", with the year on the next line
• in savegame details: "D.M.Y" or "D. Xxxxxxkuuta Y". I prefer the former, but it's a matter of taste really.

(Sometimes finnish month names truncated to the first three letters are seen in use, but that's just because of computers and bad localization. At least by my gut finnish language feel I find them utterly ugly, but they are understandable and some might not find them that ugly. Officially, they are an incorrect way of displaying the monts.)

Cheers!

8

Translations / Re: Finnish Translation

« on: June 04, 2014, 10:25:37 pm »

Oh, also, there should be no space between "." and digits (i.e. it's D.M.YYYY, D.M. YYYY or D. M. YYYY are not correct). But there should be a space in the form "D. XXXXXkuuta YYYY".

9

Translations / Re: Finnish Translation

« on: June 04, 2014, 10:10:57 pm »

Hi,

I've been polishing the translation here and there where I've found something to polish =)

There's still a little nit to pick in the finnish translation which might require some coding for a properly polished fix - the dates.

In finnish, there is no 3-letter abbreviations for a month name (instead there is abbreviations missing the ending "kuu" or "kuuta", i.e.: tammi, helmi, maalis, huhti, touko, kesä, heinä, elo, syys, loka, marras, joulu). Even those abbreviations are NOT used in dates - but outside of date context only. For example, it would be OK to use them in a graph monthly columns. So, for example, for 1st of January the correct forms are "1.1." or "1. tammikuuta" (and there's a bunch of grammatically even longer possibilities. Here's some more in depth explanation (in finnish))

So, the abbreviations above could be used in the graph, but they won't fit (and there's no room to enlarge the text boxes there). The long month names (tammikuuta, helmikuuta, maaliskuuta) do not fit in the geoscape date window, and the short form seems awkward to me in finnish (and, is by no means correct).

So, I've concluded we should use the number for the month since that's the only form actually in use in finnish, and also in the graphs. But, it leaves a huge space between the day and month numbers currently (also, save game details have a space between month and date but it is much smaller in there i.e. just a space character). The easiest fix would be to make the justification / spaces right for the D.M. form.

For the "D. XXXXXkuuta" form, I believe there should be enough space in geoscape, but then the textbox for the date should be combined and justified as one string, instead of D and M separately (theres no problem in the save game details for 2. XXXXXkuuta form currently). EDIT: Scratch that. The longest month name is MARRASKUUTA. There no way that would fit, even if not written in capitals - I tried.

Just something to consider. I'm not sure it would be worth the effort to fix for 1.0 (a language specific adjustement of the text boxes would be needed, I think) - and also, there could be other languages that could require some polishing here - or maybe it's just Finnish that has difficult forms for dates 

Cheers!

10

Translations / Re: Finnish Translation

« on: June 04, 2014, 08:11:33 pm »

Hi Mehukannu, and welcome!

I'd say that the translation is quite finished, as you can see 

However, it is mostly made by two users (myself and Esrael) as you can see: https://www.getlocalization.com/openxcom/stats/

So, to make the quality better, we need more finnish speakers to go trough the translations for validation and to make more proposals (in places where we may disagree) and to vote. I'm not saying that we've made bad work, but I think the more opinions we get the better the quality will be.

Also you can test the overall quality of the current translation quite easily from here (as the wiki says, updated hourly).

11

Builds & Ports / Re: Makefile for Dingoo A320

« on: December 21, 2013, 11:21:23 am »

Hi Shin-NiL!

How is it going with the OpenXCom port for GCW-Zero?

I was thinking about taking a look at it, and maybe see if we can get it to a releaseable state. You might want to share your work so we don't need to do the same work. If you don't want to make it public jet, pm me.

I need to state though, I'm not a programmer (though I may be able to learn some, if I have time) so probably we'll need some external help in some parts. From the top of my head, for a release to GCW-zero we'll need:

1) Disable all display filters and resolution changes (this device has only a 320x240 display, so they are useless - well, in the future it will also have HDMI support, so in a later release, maybe they could be re-enabled... the newest firmware already does have openGL capabilities).

2) We need some kind of virtual keyboard for A) Save game naming (or, we could workaround this by auto-naming; the saves already have the in-game time stamped on them, so naming is no obligatory. Maybe we could have at least GEOSCAPE or BATTLESCAPE as an autoname?) and B) Base naming and C) (optional) soldier naming. Most of the game works without a keyboard, but some parts do use it.

3) The current d-pad emulation of the mouse on the GCW-zero is borderline-unusable (at least it is not comfortable). We need to A) wait for GCW-Zero devs to tell us if there is a analog-nub mouse emulation planned (I'd presume it is, it's just more work than the D-pad one, which is why it is not done yet) or B) Make the cursor moveable by an analog joystick in OpenXcom.

3) (OPTIONAL / lesser priority) We could make a sensible default bindings for some of the keys - but the UI already enables users to make their own in any case.

12

Open Feedback / Re: Observations: UFO activity and zombies

« on: October 12, 2013, 10:49:38 am »

terror sites generate with 0-16 civilians, --

I thought this was a bug, but it is intentional?

I don't recall ever havin a terror mission with so few civilians in the original as I sometimes get in OpenXCom (I've had several with only 2-3 civilians). IMHO I think terror missions are a lot more fun when there are some actual civilians to protect ;-)

13

Open Feedback / Re: New AI feedback

« on: October 08, 2013, 10:38:33 am »

Hmm., when was the AI overhaul exactly? I compiled just a few days ago.

I recently boarded a crashed very large UFO (a battleship I believe it is called), with 3 intact power sources =).

The sectoids were quite vicious when fighting, though still had no change against my troops. *But*, they never ever even tried to use psionics, which could have helped them a little - byt just my thought maybe it's an oversight in the new AI? Or, maybe by chance, my soldiers just happened to be resistant, and the sectoids noticed it and gave up. Poor sectoids, I almost feel like I shuold not have killed them. Maybe I'll go pacifist in the next game ;-)

Need to retest with the most recent GIT I guess...

14

Translations / Finnish Translation

« on: October 02, 2013, 07:38:52 pm »

Hi,

I've started a Finnish translation. I'm not sure if it is a good idea, as some things are very difficult to translate (and, as a final result, may sound quite stupid). Also there's a few (weird) translation jokes in there currenty . It is in terrible shape in other ways too, since currently I'm the only contributor, and also quite unfinished.

I may see if I'll ever finish it, but contributions are wellcome. I wuold first like to see how the currently done translation fits in the game, to see if there's any oversights made by me in the way I'm translating - but there's no wasy way to test the translations yet. But that might change.

I believe a good place for any discussion about the translation would be here. But if I'm alone with this idea, this will be a monologue ;-)

Luulen että suomenkielinen keskustelu ei haittaa, kunhan se pysyy tämän ketjun sisällä ;-)