Messages

1

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

« on: November 21, 2023, 01:48:35 pm »

I have set up a test to build OXCE AppImage whenever a new OXCE is released. This should theoretically make it very easy to run OXCE on any linux distro (and WSL?), although I've only tested it on Ubuntu 20.04 & Fedora 38 myself.

The source can be found here: https://github.com/pedroterzero/oxce-docker/tree/deb7d72c4b24b0743443501a7e39e9911830f17e

Releases can be found here: https://github.com/pedroterzero/oxce-docker/releases

For me these steps sufficed to run OXCE from this AppImage (for v7.9.8 ):

Code: [Select]

mkdir oxce && cd oxce
# move your TFTD/UFO assets in here, see https://www.ufopaedia.org/index.php/Installing_(OpenXcom)#All_platforms
wget https://github.com/pedroterzero/oxce-docker/releases/download/v7.9.8/OpenXCOM_Extended-v7.9.8-x86_64.AppImage
chmod +x OpenXCOM_Extended-v7.9.8-x86_64.AppImage
./OpenXCOM_Extended-v7.9.8-x86_64.AppImage

It has all the required libraries bundled, you can check what is included with the following command:

Code: [Select]

./OpenXCOM_Extended-v7.9.8-x86_64.AppImage --appimage-extract

2

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

« on: June 29, 2022, 01:35:43 am »

Hi Meridian,

I hope I'm posting this in the right place -- I am trying to cross compile both OXCE and FtA from Linux using your instructions, but it seems I am probably doing something wrong. Can you point me in the right direction, or by any chance, does it fail for you in the same way currently? To clarify, I've tried this for both OXCE and FtA and neither are successful.

This is what is, I think, the relevant bit from the logs (I've also attached the full build logs for both OXCE/FtA below):

Code: [Select]

[ 41%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/State.cpp.obj
[ 41%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/Surface.cpp.obj
[ 41%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/SurfaceSet.cpp.obj
[ 41%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/Timer.cpp.obj
[ 42%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/Unicode.cpp.obj
[ 42%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/Zoom.cpp.obj
[ 42%] Building CXX object src/CMakeFiles/openxcom.dir/Geoscape/AlienBaseState.cpp.obj
/app/src/Engine/Unicode.cpp: In function 'bool OpenXcom::Unicode::naturalCompare(const string&, const string&)':
/app/src/Engine/Unicode.cpp:607:100: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'WinStrCmp' {aka 'int (*)(const wchar_t*, const wchar_t*)'} [-Wcast-function-type]
  WinStrCmp pWinStrCmp = (WinStrCmp)GetProcAddress(GetModuleHandleA("shlwapi.dll"), "StrCmpLogicalW");
                                                                                                    ^
[ 42%] Building CXX object src/CMakeFiles/openxcom.dir/Geoscape/AllocatePsiTrainingState.cpp.obj
In file included from /app/src/Engine/Zoom.cpp:51:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:217:1: error: redefinition of 'unsigned int __get_cpuid_max(unsigned int, unsigned int*)'
 __get_cpuid_max (unsigned int __ext, unsigned int *__sig)
 ^~~~~~~~~~~~~~~
In file included from /opt/mxe/usr/x86_64-w64-mingw32.static/include/intrin.h:70,
                 from /app/src/Engine/Zoom.cpp:46:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:217:1: note: 'unsigned int __get_cpuid_max(unsigned int, unsigned int*)' previously defined here
 __get_cpuid_max (unsigned int __ext, unsigned int *__sig)
 ^~~~~~~~~~~~~~~
In file included from /app/src/Engine/Zoom.cpp:51:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:272:1: error: redefinition of 'int __get_cpuid(unsigned int, unsigned int*, unsigned int*, unsigned int*, unsigned int*)'
 __get_cpuid (unsigned int __leaf,
 ^~~~~~~~~~~
In file included from /opt/mxe/usr/x86_64-w64-mingw32.static/include/intrin.h:70,
                 from /app/src/Engine/Zoom.cpp:46:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:272:1: note: 'int __get_cpuid(unsigned int, unsigned int*, unsigned int*, unsigned int*, unsigned int*)' previously defined here
 __get_cpuid (unsigned int __leaf,
 ^~~~~~~~~~~
In file included from /app/src/Engine/Zoom.cpp:51:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:289:1: error: redefinition of 'int __get_cpuid_count(unsigned int, unsigned int, unsigned int*, unsigned int*, unsigned int*, unsigned int*)'
 __get_cpuid_count (unsigned int __leaf, unsigned int __subleaf,
 ^~~~~~~~~~~~~~~~~
In file included from /opt/mxe/usr/x86_64-w64-mingw32.static/include/intrin.h:70,
                 from /app/src/Engine/Zoom.cpp:46:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:289:1: note: 'int __get_cpuid_count(unsigned int, unsigned int, unsigned int*, unsigned int*, unsigned int*, unsigned int*)' previously defined here
 __get_cpuid_count (unsigned int __leaf, unsigned int __subleaf,
 ^~~~~~~~~~~~~~~~~
make[2]: *** [src/CMakeFiles/openxcom.dir/build.make:2462: src/CMakeFiles/openxcom.dir/Engine/Zoom.cpp.obj] Error 1
make[2]: *** Waiting for unfinished jobs....


3

Tools / Re: VSCode OpenXcom Modding Tools

« on: March 21, 2022, 02:31:42 pm »

I have just released the v1.0.0 (first "stable") version of my extension has been released on the marketplace. It includes the new CSV/spreadsheet editor and many fixes/corrections. Many thanks to all the testers/users of this exntesion that helped me get it over the line. Visual studio code should auto update you to this latest version.

Here is a demo of the new spreadsheet editor:

4

Tools / Re: VSCode OpenXcom Modding Tools

« on: March 21, 2022, 01:02:57 pm »

Just to say that I've tried pedroterzero's tool recently and I'm completely sold to it just for parsing the rulesets and fixing bugs I had no idea they were there.

For large mods, this is a must have if just to periodically check your rulesets and increase mod stability. And it will save you a lot of pain and time lost from bugs not to easy to find.

Thank you! That is very high praise indeed coming from one of the most experienced modders out there. I appreciate it very much.

5

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

« on: February 17, 2022, 05:54:03 pm »

That would be awesome. But even if the vanilla game files are required, it would still be useful, but I would have to expand the pipelines to allow providing those files somehow. Making it a bit more complex to set up.

The most important bit would be the checking then exiting (with 0/1 exit code). If it wasn't dependent on vanilla files it would just be a bonus.

Overall it would be preferred to add special mode for this only, some kind of new command line parameter that allow only loading `Mod` and return 0 or 1 depend if it throw exception.

If this gets implemented, I would be very interested in it.

6

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

« on: February 15, 2022, 08:34:31 pm »

I have a question because I want to set up some CI/CD for some IDT mods (everyone would be free to use it though, of course);

- would it be possible to run JUST the OXCE validation and exit immediately (preferably with non-zero exit code if validation failed, but it could also be scraped from logs)
- if so, would this validation require the vanilla [UFO] assets to be present? It would make the pipeline a bit more involved in that case, but not impossible.

If this can be achieved, when committing to GitHub, using GitHub Actions, I can set up a pipeline that does some basic sanity checking automatically.

Thanks for any insights

7

OXCE Builds & Ports / Re: OXCE docker container

« on: February 10, 2022, 05:49:22 pm »

dear pedroterzero, thanks for your willingness! But it needs docker to be installed to run? Please could you explain? Would't be better to build an appimage?

That's a good point, and I did consider this, but I work with docker daily and I've never used AppImage myself. It's [my choice of docker] kind of based on my own usage patterns

8

OXCE Builds & Ports / Re: OXCE docker container

« on: February 10, 2022, 05:22:11 pm »

permission given

Thank you! I published the image and it (and its instructions) can now be found here https://hub.docker.com/r/pedroterzero/oxce

I'll try to keep this updated with every new OXCE build, it should only take 1-2 minutes to create a new image. The most limiting factor is probably my awareness of when a new version gets published

9

OXCE Builds & Ports / OXCE docker container

« on: February 10, 2022, 04:50:45 pm »

I placed my instructions to 'build' and use an OXCE docker container here: https://github.com/pedroterzero/oxce-docker

If I get permission, I could publish the built images to docker hub so any interested end user can skip the 'build' stage.

I have tested this on Ubuntu 20.04, the container itself is Ubuntu 18.04. It seems to work perfectly.

If one has docker installed this allows to run OXCE with just a few commands and no extra dependencies on the machine.

10

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

« on: February 08, 2022, 02:52:24 pm »

Hi Meridian,

I have managed to create a build of OXCE inside Docker for my own purposes. It saves me having to install the sdl1.2 dependencies on my main Ubuntu install.

Would you mind if I published the build tools & instructions for the docker image to GitHub, and the docker image & run instructions itself to docker hub for others (probably no-one ) to use?

Just to be clear, of course the image would only contain the OXCE ubuntu binary build, and none of the assets (UFO/TFTD). They still need to be provided to the docker app (mounted) before it will run. Just like always.

It would make it a bit more convenient for me to run OXCE over multiple systems, and possibly for others, too.

11

Tools / Re: VSCode OpenXcom Modding Tools

« on: June 04, 2021, 03:10:25 pm »

I just published 0.8.2 to vscode marketplace. Not a very exciting release with many new features, but a great number of fixes/tweaks.

On the roadmap currently:

• Ruleset spreadsheet editor (allows two-way editing of .rul files as spreadsheets either in vscode itself or using Excel)
• Y-script syntax validation
• Missing translation detection
• Missing files detection (sprites/sounds)
• other stuff/li]
  

This is the changelog for 0.8.2:

• Added missing vanilla armor sprites
• Fix sprite index checking with subX/subY for more sprite types (INTICON)
• Do not retrieve keys from aliases (they only need checking once), fixes problems
• Store logic data for vanilla assets (but don't check them), prevents false positives when checking them
• Improved message in case of mapblock that does not cause segfault but will just cause block to be ignored
• Fix autocomplete for line that is also start of an array entry
• Improve duplicate error message (use related information, #35)
  
• Fix relatedlogic fields overwriting existing typeLinks
• Added missing type link for alienMissions.waves[].ufo
• Added missing lt & le in y-script highlighting
• manufacture.requiredItems add crafts as valid type
• Added missing stringType (alienDeployments.objectiveFailed)
• Combine alienMissions data from multiple files
• Ufopaedia image no longer required for type 3, apparently
• Parse comments in extraSprites/extraSounds (so duplicates can be ignored)
• Enable subX/subY for BIGOBS and FLOOROBS
• Add hitMissSound vanilla ids
• No longer check ufopaedia.weapon (it's a translatable string)
• Properly handle refNodes in logic checkers may need to add in other positions)
• Reload Language/*.yml on changes, so translations get picked up #26
  

12

The X-Com Files / Re: [Tool] Script to read items data into .csv, for analysis with Excel.

« on: May 21, 2021, 11:45:59 am »

Yep, it's here: https://github.com/pedroterzero/oxce-yaml-helper

I had to pick a license first, I had not done so yet

13

The X-Com Files / Re: [Tool] Script to read items data into .csv, for analysis with Excel.

« on: May 18, 2021, 03:18:32 pm »

A couple of weeks ago I was working on including this feature in a future version of my vscode extension. I have an alpha that does two way (rul => csv and csv => rul), it's not out yet though:

14

Tools / Re: VSCode OpenXcom Modding Tools

« on: May 18, 2021, 10:45:49 am »

Indeed, upon next open the rules were loaded in about 10 seconds. Awesome! I underestimated your implementation, sorry!

I totally see how this can be a highly nontrivial issue. As the saying goes, there are three hard problems in software engineering: cache invalidation and off by one errors

15 minutes, and then 10 seconds cached is still too long, obviously I still hope to be able to do something about it sometime.

Nevertheless, I think that with fast reload without edits this works quite well already. For example, if I need to make edits to one of these humongous files, I could batch them and don't reopen VS Code until I am done, then reload.

Good to hear. You could try to see how long saving a single file works. The moment you save is the moment it parses the file again. Differential parsing could help in this matter, but I'm not sure how to approach that (yet). The yaml library I use offers no such functionalities, I'd have to find something generic, or set it up myself.

Also, it is an argument for splitting these files into smaller ones (I do hope OXCE supports reading rules of one type from multiple files).

Yes, that is very possible. You can basically split things anyway you like (as far as I'm aware), and that would certainly help the problem. It's a workaround and it obviously doesn't directly address the core problem, but it will help.

I think your tool adoption would benefit from being more explicit about this caching. I think some people might give up before the 15 minutes for initial load are up. If the tool would somehow report how long it will take, and clarify it will be fast without edits, and reload only specific files upon edit, that would motivate people to give it a proper try.

I think the larger problem is that not too many people are aware of it, and secondly that people are quite content just using notepad++ for their modding. That said, I could drop it in the README somewhere. For most mods that I've tried it with, it's not really a problem though. It's the really large ones (there's only XCF, FMP and X-Piratez that are like that I think?) that are causing the long load times. There is something in my parser that does not scale, clearly 

15

Tools / Re: VSCode OpenXcom Modding Tools

« on: May 17, 2021, 11:58:31 am »

Is there a way to speed up this loading process? E.g. cache it, and later diff and update incrementally? If I reopen VS Code I believe it will try to load everything anew.

Thanks for the kind words! There is already cache on a file basis, once a .rul file has been parsed, it should not have to be parsed again unless it changes (or the extension gets an update). However one change means that entire file needs to be parsed again, due to my current implementation.

I need to take a look at why it's taking exponentially long to deal with larger files like in XCF, I am not sure. But I would probably need to do a pretty big overhaul on the main parsing bit of the code. It's one of the first things I wrote for this extension, and knowing what I know now I would have done it differently. It's not the easiest bit for me to work in though.

I'll try to have a look when I can if there's any quick band-aid fixes I can apply, I'll let you know here if I do.