Messages

1

OXCE Builds & Ports / Strange problem cross-compiling OXCE+ in Linux

« on: December 03, 2024, 11:11:12 pm »

Hello,
   I've tried crosscompiling OXCE+ under Linux-Ubuntu22.04 following instructions given here: https://openxcom.org/forum/index.php?topic=7048.0

I installed and built MXE -with minor issues; I've to include a #ifndef "guard" to mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.5.0/include/cpuid.h, to avoid including that header twice-

Then I followed instructions to build OXCE+:

git clone https://github.com/MeridianOXC/OpenXcom.git
cd OpenXcom
mkdir build
cd build
export PATH=/opt/mxe/usr/bin:$PATH
/opt/mxe/usr/bin/x86_64-w64-mingw32.static-cmake -DCMAKE_BUILD_TYPE=Release -DDEV_BUILD=OFF -DBUILD_PACKAGE=OFF ..
make -j4

And I got a lot of " fatal error: SDL.h: No such file or directory". It seems that x86_64-w64-mingw32.static-cmake considers a CMAKE_SYSTEM_NAME as Windows, and in the "recipe" at OXCE+ CMakeLists.txt, there are some parts "if ( WIN32 )" (l37) and if(NOT UNIX AND IS_DIRECTORY ${DEPS_DIR})" (l84), that cause building process look for yaml-cpp and SDL includes&libs inside of OpenXcom-oxce-plus/deps  -which is empty- instead of inside /opt/mxe/usr/x86_64-w64-mingw32.static/ where you can find them.
I managed to "fix" CMakeList.txt nullifying conflictive parts in CMakeLists.txt recipe -if ( WIN32 ) --> if ( 0 ) , if(NOT UNIX AND IS_DIRECTORY ${DEPS_DIR}) --> if(0) -
In this state, it correctly crosscompile and build OXCE+ either for x86_64-w64-mingw32.static (64bits EXE) or i686-w64-mingw32.static (32bits EXE).
But this is just a "dirty patch" and I would like to know what I'm doing wrong or what is failing in the process.

So if anyone (Meridian?) can give me some light about this, I'd be very grateful.

Thanks in advance
 
 

2

Brutal AI / Re: [Request] Graphics improvemt - fix for hangar craftSlots displayed

« on: December 01, 2024, 10:20:35 pm »

Low Priority Request:
Would really appreciate an update when having multiple crafts in hangars to show only one craft where there is only one craftSlots defined?


(This one works correctly)
I have a hangar with 4 crafts spaces and to display 4 craftslots defined:
    craftSlots:
      - [-17, -17, 0]
      - [17, -17, 0]
      - [-17, 17, 0]
      - [17, 17, 0]

(This is the one with the issue)
I have another hangar that has 3 craft spaces and to display only 1 craftSlot defined: (This hangar is supposed to be 3 levels deep which is why it has 3 crafts and only one slot)
    craftSlots:
      - [1, 1, 0]

Instead of "only" showing one craft graphic, it overlays the craft graphics.  The desired result would be to only show the most recent craft added to the hangar or most recent craft that returned from a mission as the icon to display in the hangar.

Hello. I coded the original hangar features that Xilmi added to BOXCE+. You can't define an hangar with X crafts, without defining X positions to show. The reason is the way OXCE+ deals with hangar destruction, specifically with crafts allocated at the hangar. It only "destroys" visible crafts so, if you consider several crafts but only display one over hangar, game logic could fail allowing you to maintain crafts that were stored at that hangar. It could sounds good, but if means you will have then more crafts than slots ti store them.
(At least that was the "destroying hangar " behaviour at OXCE+ when I implemented the multiple crafts feature; I don't know  whether Meridian changed that )

3

OXCE Support / Re: Folders UFO/MAPS and standar/xcom1/MAPS

« on: November 22, 2024, 12:18:38 pm »

Ok, thank you. I had a UFOv1.4 versión (already patched MAP files, so I didn't see differences in most files but 4-5)
Also, RMP files inside xcom1/MAPS are needed there?  Because some are there (i.e. XBASE_01.RMP)  and some others (i.e. XBASE_00.RMP) are also under xcom1/ROUTES folder. In UFO folder they have similar distribution.
Is somehow confusing having so many copies in different sides. For example, XBASE_00.RMP have 4 differently files, but -in my installation with OXCE+ 7.15 and UFOv1.4- only xcom1/ROUTES/ versión is different  to the other 3.

4

OXCE Support / Folders UFO/MAPS and standar/xcom1/MAPS

« on: November 21, 2024, 07:36:00 pm »

Hi,
  tinkering with MAP files I noted that they are both in those two directories (they are the same files, at least in names). And I would like to know why, and which one has precedence over the other. Can any of them be deleted safely?

Thanks in advance.

(the same happens partially with some files at /RMP and /TERRAIN folders; and of course for TFTD similar folders)

5

OXCE Suggestions OK / Re: [SUGGESTION]Custom Hangar/Craft types

« on: February 21, 2024, 10:10:57 am »

My implementation of Hangar mods, had this "-1" wildcard already. If rules for crafts didn't have an entry for hangar type, they were automatically assigned a "-1" Id, which corresponds with the default id for vanilla hangar.
This way my OXCE engine version didn't break mods made for official OXCE+ branch.
I'm sure Meridian has special care with compatibility for previous mods, so probably he has in mind a similar mechanism.

6

OXCE Builds & Ports / Re: Using a gamepad to play

« on: October 08, 2023, 08:54:19 pm »

Purest get triggered, but I would like it if openxcom ufo defense could be controlled with a gamepad instead of a keyboard and mouse input. I play the Playstation one for this feature alone more because of it. I personally think it is more comfortable, probably because I am more a console gamer than PC.

Is it possible to have an option for a Playstation gamepad layout to have its buttons mapped for certain functions? For example:

If you're going to play with a PC, there are a lot of applications which maps keypad buttons to keyboard keys so, when you use your keypad, programs receive the corresponding mapped keyboard entries.

In Windows, STEAM has an integrated Controller configuration feature.  If you don't use Steam, you can try some other like Antimicro (https://github.com/AntiMicroX/antimicrox). And there are many others out there.

7

OXCE Suggestions OK / Re: [Suggestion]Self-Destruction at will on dogfighting (kamikaze drones/missiles)

« on: October 08, 2023, 08:46:01 pm »

As a DEV, I don't see a problem with this feature.
It's isolated, compatible and optional.
If it gets enough attention from modders, it can be merged into OXCE.

As a player, I find it mildly intriguing.
The (manned) kamikaze use case sounds valid, probably even desirable in some mods.
The base-launched guided missiles use case however less so (IMO). Shooting ICBMs at UFOs sounds rather... strange Aren't ICBMs also more expensive than an average fighter jet with a bunch of air-to-air missiles? (don't know, I never bought one)

I'll leave that to the modders to discuss.
(It's them who'll be implementing it in their mods after all. My opinion is irrelevant here.)

If I had to use ICBMs in a mod they should be very expensive/difficult to produce, and perhaps need an special facility (silo?) and a very expensive maintenance. And as a player I wouldn't use them against a scout, but the bigger & more powerful UFOs, as my last resource. Just as nuclear weapons in all those sci-fi films -in which, at the end, missiles don't are very useful against UFOs  -

On the other hand, unmanned drones shouldn't do a lot of damage, leaning on number & maneuverability and having the handicap of being  -normally- destroyed when hit. they would be a help to weaken UFOs till big crafts come; or to shot down weaker/smaller UFOs.

But, as you said, modders are the ones who should decide how to use this -and help to define what they need-

8

OXCE Suggestions OK / Re: Multi-Craft Hangars, Craft Sizes, Custom Craft Classifications & More...

« on: October 08, 2023, 08:09:32 pm »

When craft becomes TRANSFER_CRAFT, slot on the receiving side is allocated and it is unavoidable. Anyway, making it possible will require major refactoring of original code and how item transfer is handled.

I'm pretty sure Meridian and Yankes wouldn't want me to touch something that works already perfectly fine.

Yes, I know about TRANSFER_CRAFT management, but it's true that it seems "somehow silly" needing to have 3 hangars to manage 2 crafts going from one base to another -and note hangars take a lot of space in bases-. At original/current code I think it can be done ( a double check at the hangar allocation rules at both bases, discounting the transferred crafts, then a TRANSFER order for boths craft at the same time). With modified hangar rules  -mine, your's, Meridian's-  which allow more classes and felxibility, that check will be a lot more difficult for sure.

9

OXCE Suggestions OK / Re: Multi-Craft Hangars, Craft Sizes, Custom Craft Classifications & More...

« on: October 08, 2023, 01:18:52 pm »

When I was working on my version of this feature, some people asked me about the possibility to add another -so
mehow related- feature to exchange two crafts at different bases. At the moment, if you have 2 crafts at 2 hangars in different bases, you need a 3rd hangar to be able to do that exchange -- transfer craft1 to free hangar; transfer craft2 to -ex-craft1 hangar; transfer craft1 to ex-craft2 hangar --

Do you think this could be implemented with your version or would be very difficult due to allocation-rule checking?

10

OXCE Suggestions OK / [Suggestion] Self-Destruction at will on dogfighting (kamikaze drones/missiles)

« on: October 08, 2023, 01:09:13 pm »

Hello, I'm working on a new feature to allow players to self-destruct its craft at will, when in dogfighting.
At the moment there are some features on OXCE+ to allow self-destruction when your craft is defenseless and you don't have any chance to disengage due to velocity - self-destruct which deals no-damage to enemy crafts; it's just to avoid endless dogfighting-; but I'd like to add a second button which allowed to activate self-destruct at will. This is not really directed to "current "crafts -interceptors and carriers-, but I think this could be interesting to add things as "unmanned kamikaze drones" or even "missiles". Of course that would be optional to ensure proper compatibility with current dogfight behavior -the only difference for current behavior would be a second deactivated button at the interface-

I'm looking for some advice/opinions about how to program the behaviour of this feature:

1. About WHEN this self-destruct would take effect -providing it has been activated-:
  a. Only when crafts are at the/a "minimal" range. This could give target craft a chance to destroy drone/missile while it's approaching to be in range.
   b. At any moment when dogfighting screen appears...but the more distance between crafts, the less damage self-destruct would do.

2. About HOW MUCH damage would kamikaze-craft inflict to target craft.
   c. At first I proposed giving a fixed damage equal to the max-damage supported by the kamikaze craft, or twice that damage.
   d. Also we could use a RNG number between 50%-200% of that damage, to add some uncertainty to self-destruct feature.
   e. Modders could add another value to "crafts" definition to set self-destruct damage. If not added, this value would be 0 -no self-destruction damage to enemy craft-, or one of the values at 2c.

3. If we only want to add new kamikaze crafts/missiles, pushing a self-destruct button sounds useless, so I could add another flag to craft ruleset -self-destruct?- so, when entering dogfighting self-destruct is automatically activated.

4. If 1b option is not implemented....should we give the chance to cancel self-destruction? -for regular crafts, not drones/missiles-

What are your thoughts about this? Could this be an interesting feature?

11

Programming / Re: Change dogfight graphics in INTERWIN.DAT

« on: October 03, 2023, 02:02:58 pm »

Internally INTERWIN.DAT is represented as one big image.
So you also need to override it as just one big image.

OpenXcom then crops just the needed part from the big image at runtime.

Finally I could do It. Thanks a lot for your help.
Now, I need to add an Interactive Surface for button action, at the corresponding positions.

12

Programming / Re: Change dogfight graphics in INTERWIN.DAT

« on: October 03, 2023, 10:35:19 am »

Thanks! But, what if the file has many images inside?(like this one).
Should I load  0: image one, 1: image two....
Also, accesing to images in DogfightingState uses indexes inside INTERWIN.dar, so I'm not sure this should be also changed. I'll try and see.
Thanks again!

13

Programming / Re: Change dogfight graphics in INTERWIN.DAT

« on: October 03, 2023, 09:10:19 am »

Hello,
  I would like to change doghfight main interface (Interwin01.gif) to add a second button similar to minimizeButton. I found that graphic is inside /Geodata/Interwin.dat, but I dont know how to approach this:

1. Find some way to read/unpack INTERWIN.DAT, then change Interwin01.gif interface, and PACK all again in a new INTERWIN.DAT modified. I don't know which program(s) could unpack/pack this DAT files.

2. Find a ruleset which could load another InterwinMod01.gif instead, for dogfight interface; but I don't know if such a rule exists.

Could anyone give me a hint about this? Thanks in advance

I finally found an online Python tool (thanks to Buscher) to convert/from to SCR. I think that finally I will make an alternative dogfight interface and put it on SCR format into GEOGRAPH/GEOSCAPE folder, so I can load It to a surface.

14

Programming / Change dogfight graphics in INTERWIN.DAT

« on: October 02, 2023, 11:14:58 pm »

Hello,
  I would like to change doghfight main interface (Interwin01.gif) to add a second button similar to minimizeButton. I found that graphic is inside /Geodata/Interwin.dat, but I dont know how to approach this:

1. Find some way to read/unpack INTERWIN.DAT, then change Interwin01.gif interface, and PACK all again in a new INTERWIN.DAT modified. I don't know which program(s) could unpack/pack this DAT files.

2. Find a ruleset which could load another InterwinMod01.gif instead, for dogfight interface; but I don't know if such a rule exists.

Could anyone give me a hint about this? Thanks in advance

15

OXCE Suggestions OK / Re: Multi-Craft Hangars, Craft Sizes, Custom Craft Classifications & More...

« on: October 02, 2023, 09:00:37 am »

I already resolved it. As for how, you can see code itself in latest commit to my repository.

Great news!!! Congratulations!!
I'll look your solution at your Code. I'm very interested! I thought heurístics would be too difficult to implement.
Hope we finally have this hangar feature at oficial repo soon!!