Topics

1

The X-Com Files / EMP equipment and its damage

« on: February 29, 2024, 10:17:33 am »

On another note, the dependencies for EMP weapons are somewhat strange.

In real life, the existence of EMP has been well-documented for a long time, although I admit I do not know how and if it has been miniaturized for use of EMP grenades, for example. But I suppose being able to obtain or manufacture EMP weapons after Promo III in 1998-1999 timeframe should not really be a major issue.

In XCF getting EMP is gated through Jarhead investigation, which is dependent on Jarhead autopsy.The only two ways for you to initially get Jarheads is either through Jarhead terror mission (7 % chance starting month 20) or by raiding at least level 2 Dagon manor (the best chance, if you let one grow, but upgrades are also RNG-dependent). So all in all, without good RNG, you might be stuck for a long time without access to EMP. Which would make many things a lot more straightforward and also eventually enables capturing and repurposing sectopods, for example.

How to fix this? If the dependencies are not completely restructured, my other suggestion would be to create two mission scripts: jarheadTerrorEarly and jarheadTerrorLate, like with many other similar instances. The first would have a higher trigger rate, like 20 or 25 % with STR_JARHEAD_INVESTIGATION: false. The latter would have lower percentage, such as 5 % or less, with STR_JARHEAD_INVESTIGATION: true. That way, like in numerous other instances, the probability of initial jarhead encounters would be increased until you have gone forward with the jarhead research.

2

OXCE Suggestions NEW / [Suggestion] PSI training behavior wrt. wounded soldiers; should it be moddable?

« on: February 27, 2024, 08:09:44 am »

Continuing from a side comment from here: https://openxcom.org/forum/index.php?topic=11808.msg161801#msg161801

Regular soldier transformations can be configured with 'transferTime' (the soldier "leaves the base") or 'recoveryTime' (the soldier gets "wounded" for a certain time, the time is always affected by Medbays). With the latter option, the soldier gets kicked out of PSI training, but you can manually put him immediately back to the training. Getting wounded on the battlescape, however, AFAIK does not kick the soldier off PSI training (but I didn't test to confirm this). On the other hand, you cannot gym train wounded soldiers, though they get or can be queued for training automatically when they recover (shows with '+' or '-' sign),

PSI training while wounded seems inconsistent in a number of ways compared to gym training.

I suppose there is no big demand for modders to be able to gym train wounded soldiers (though I suppose some could perhaps argue that being able to do physical exercises should fasten your recovery). But I suppose modders might want to have PSI training wrt. wounded soldiers configurable.

- For example, in TFTD PSI training is explained as inserting a surgical MC implant on the soldier. It would make sense that such surgical implantation could be applied even to wounded soldiers (= not requiring any or at least major active training from the aquanaut). [A modder might actually also want a behaviour that inserting the implant causes wounding for some time, i.e. not able to go on battlescape missions.] On other implementations, PSI training (before or after you learn the first bits of PSI skill), you might require the soldier to be healthy to conduct all the mental or molecular exercises.

So in summary, what I'd like is that:

1) the default behaviour of kicking soldier off PSI training after having applied a transformation with 'recoveryTime' is changed either so that you can
 a) continue PSI training while wounded and you don't need to insert him back manually ('allow smooth PSI training while not requiring manual re-insertment'), or
 b) not by default PSI train wounded soldiers ('change behavior by removing the manual re-insertment loophole and also make it consistent so that battlescape wounding would take the soldier off PSI training')

2) if you no longer can PSI train wounded soldiers, add a similar +- queuing GUI to PSI training as currently exists with gym training

3) major modders to comment on whether they would like the various aspects of PSI training of wounded soldiers be configurable. I can think of at least three scenarios that might all be the same but one could possibly want to treat in a different manner:
 a) can the initial PSI training be applied also to wounded soldiers [note also OG PSI training mode of being able to start training only on a monthly basis],
 b) can initial PSI training continue and produce results (= get closer to obtaining the first PSI skill) even though the soldier gets wounded (whether by transformation or in the battlefield) and
 c) after you have obtained your first PSI skill, can you improve your PSI skill while being wounded.

3

OXCE Suggestions DONE / [DONE][Suggestion] Shortcut from soldier list to stats (R-click)

« on: February 11, 2024, 09:47:04 pm »

I'd like to see one or two QoL-improvements to the soldier lists when applying transformations or special trainings.

1) Some way to get into a particular soldier's own stats and inventory (at least the armor selection) from those screens. This could be useful to verify all the stats before choosing a transformation/training. Another very useful thing would be to remove the armor from the soldier (to prevent it getting destroyed in transformations, or getting blackholed in those trainings where the soldier leaves the base and is transferred back to the base X hours later (e.g. in XCF martial arts training).

For example MMB or RMB would be ideal.

Currently I have to figure out which soldiers I want to apply a transformation/training on, then get out of the screen and go find the soldier from soldier list again to remove the armor. Sometimes you have to go back and forth multiple times if you're unsure which soldier would be the best candidate at the moment.

2) Once you have 30-40+ soldiers or other units on a base, being able to Q-search on the agent list might be useful, so that you wouldn't need to change the sort order or scroll down the list manually to find the soldier you're looking for. If the shortcut 1) is implemented, I suppose this wouldn't be all that useful. So just having QoL improvement 1) would be adequate for me at least for now.

EDIT:
Now that I'm at it, is there a reason why a person who undergoes some special training (in XCF for example 'Install TNI' that results in him getting wounded for X days), he gets kicked out of PSI training and gym training (can be inserted back - PSI training doesn't consider being wounded, at least in a visible manner, while you can queue the gym training with +)? It would be nice if this didn't happen if the person doesn't leave the base.

4

OXCE Bugs FIXED / [FIXED] crash when transferring currently opened craft

« on: February 09, 2024, 10:42:43 pm »

I got the following crash with 7.11.4 with XCF 3.3-snap. I was equipping my soldiers in India base OSPREY (I suppose I removed some armors and then the base storage was overflown). Then while still in basescape I tried to transfer the OSPREY to another base (Cuba). Then I got the following crash. I suppose this was somehow related to the base storage overflow.

[09-02-2024_22-08-11]   [FATAL] A fatal error has occurred: vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)
[09-02-2024_22-08-11]   [FATAL] ./OpenXcomEx(OpenXcom::CrossPlatform::stackTrace(void*)+0x36) [0x55ce1b2810f6]
[09-02-2024_22-08-11]   [FATAL] ./OpenXcomEx(OpenXcom::CrossPlatform::crashDump(void*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0x477) [0x55ce1b281c9
[09-02-2024_22-08-11]   [FATAL] ./OpenXcomEx(exceptionLogger()+0x75) [0x55ce1b063155]
[09-02-2024_22-08-11]   [FATAL] /lib64/libstdc++.so.6(+0x9654c) [0x7fa62ac9f54c]
[09-02-2024_22-08-11]   [FATAL] /lib64/libstdc++.so.6(+0x965a7) [0x7fa62ac9f5a7]
[09-02-2024_22-08-11]   [FATAL] /lib64/libstdc++.so.6(+0x96808) [0x7fa62ac9f808]
[09-02-2024_22-08-11]   [FATAL] /lib64/libstdc++.so.6(+0x9206b) [0x7fa62ac9b06b]
[09-02-2024_22-08-11]   [FATAL] ./OpenXcomEx(OpenXcom::CraftSoldiersState::initList(unsigned long)+0xad5) [0x55ce1b0a2ef5]
[09-02-2024_22-08-11]   [FATAL] ./OpenXcomEx(OpenXcom::CraftSoldiersState::init()+0x38) [0x55ce1b0a5f18]
[09-02-2024_22-08-11]   [FATAL] ./OpenXcomEx(OpenXcom::Game::run()+0x464) [0x55ce1b2a0a04]
[09-02-2024_22-08-11]   [FATAL] ./OpenXcomEx(main+0x175) [0x55ce1b040035]
[09-02-2024_22-08-11]   [FATAL] /lib64/libc.so.6(__libc_start_main+0xe5) [0x7fa62a2d37e5]
[09-02-2024_22-08-11]   [FATAL] ./OpenXcomEx(_start+0x2a) [0x55ce1b0478da]

As I suspected, there was probably something wrong with CraftSoldiersState.

I tried to replicate what I did but I suppose I couldn't get it exactly right because I couldn't trigger the crash again.

I hesitate to open a BUG thread on this because I couldn't reproduce it myself. But good luck if this is sufficient to find the problem via code analysis. I'll attach a save just in case.

5

OXCE Suggestions DONE / [DONE][Suggestion] Longer search strings with 'Q'

« on: February 04, 2024, 02:25:14 pm »

Searching with 'Q' seems to be capped to 9 or 10 characters, depending on how wide the characters you type are (try with 12345689A and 1234567891 to see slightly different results). It could be useful to have some more, ideally at least 12 or 15 *). However, in some contexts there isn't enough space in the GUI for a much longer field.

Would it be feasible to implement the search field either as:
 a) the displayed width is fixed, but the text keeps rolling to the right as you type it longer (and the start vanishes from sight). Then the search string could be essentially of infinite length.
 b) like a) but as you keep typing, it still shows only the first 9-10 characters (no rolling), but you just have to write the rest of the string 'blind'.

Either of these would work for me, but a) would be more user-friendly.

*) For example, in XCF with a big tech tree, I just wanted to search for 'syndicate security', preferable I'd have typed 'syndicate sec' to find just that, not everything else related to the syndicate.

6

OXCE Bugs / bug(?): build-over of research space leads to negative research space used

« on: January 03, 2024, 05:29:37 pm »

When playing XCF and building an Advanced Intelligence Center over Intelligence Center (which provides space for5 researchers), with all the researchers full at work, I got to -5 available research space. So I suppose the scientists can continue working on their on-going projects in the living quarters even if the lab goes under construction.

I recall seeing this before as well. If you reassign scientists, you can no longer go negative. But I do have a recollection that some others things are checked in other build-overs (IIRC for example building over a facility that provides storage capacity requires reducing the used storage capacity first).

I wonder if it's intentional that this is not checked at build-over phase, and prevented - requiring you to de-assign the scientists first?

7

The X-Com Files / Synthmuscles availability

« on: January 02, 2024, 07:45:41 pm »

Another note inspired by Stone Lake's SH/IM run. If you get lucky and obtain synthmuscles (and later alien surgery from somewhere else) early in the game, this can dramatically change the game, even change the game balance. It's a completely different early and mid-game experience to have a number of synthsuits versus having to do without. You can even go through most of the campaign without seeing any of them.

There is about 4 % to get one or more synthmuscles out of an osiron crate. This is a very high chance (among the highest of what you get from osiron crates). If you wanted to rebalance the game to avoid these "extremely lucky runs", I'd remove synthmuscles completely from osiron crates or decrease their chances. On the other hand, the chances to get them from MIB crates could be increased. Given that MIBs actually use synthmuscles themselves in their armors it should be reasonably likely to find them there (currentl it's possible but it's actually more likely to find them in osiron crates rather than in MIB crates).

8

OXCE Suggestions DONE / [DONE][Suggestion] display craft's estimated flight time (ETA)

« on: January 02, 2024, 10:47:29 am »

It would be very useful to display the estimated flight time of crafts somehow, especially in mods which have slow crafts and missions with despawn timers counted in hours or days (and missions which despawn even if targeted).

This would make it easier to try to figure out if the craft will get there in time. (You can return to base immediately if you're not happy with the result.) This might also help if you're trying to figure out whether it's day or night on the other side of the globe when you arrive there, depending on which you prefer for the mission.

While the speed of craft is not linear due to different values of craft acceleration, for simplicity the estimate could ignore the acceleration and be based on a simpler linear calculation t=s/v (remaining distance over maximum velocity). Especially for missions where this would be most useful this would be a very good estimate.

Without bigger changes to GUI I don't see an easy way to display this information when you're selecting the destination, so I'm not proposing that - but rather an easy way to check it afterwards. So, I have two specific suggestions where to place this information.

1) in craft interception overview.  Where it now says "EN ROUTE", there's some space to add a few bits of information. This could say for example "EN ROUTE (13.7 h)". I would propose using only the hours here, and the accuracy of 0.1 or 1 hour (how it's rounded up/down doesn't really matter). I suppose the estimate is close enough so that you don't need a "~" there. Omit brackets and use just hours without decimals if you need to conserve space. So the most minimal way to display this information would be, for example, "EN ROUTE 2h".

2) in craft destination details. Where it now says "STATUS>(...)", if the craft has a destination, add a row below saying "ARRIVAL IN: 13.7 h.", with yellow and indented to the same level as DESTINATION. If you want, this could also show days, hours and minutes instead of just showing it in hours. ("ARRIVAL" or some other term instead of "FLIGHT TIME" to use a neutral term that applies to all kinds of craft.)

Instead of a new row, it might be possible to add the information at the end of the destination string like in 1), but this might lead to problems if the destination string is long. And because there is lot of free space in this dialog, I'd propose adding a more detailed information as a separate row.

9

OXCE Bugs FIXED / [FIXED][Bug] Needed item coloring issue

« on: January 01, 2024, 08:39:56 pm »

Another change or regression in the screenshot. Previously an unresearched topic would show up in 'ITEM DESTROYED' as pink-ish. Now everything is in white, whether new or already researched. With this change there is no longer (AFAIK) a handy way to check if you have already researched the items recovered from a mission (depending a bit on how what the research gives you is structured - at least those ones that don't open up any new researches but give you a few points).

10

OXCE Bugs / Bug: unit visibility stacking dark&smoke since 7.9.17 -> too potent

« on: December 06, 2023, 07:53:35 pm »

There have been recent changes to how smoke might or might not stack with other visibility modifiers, see e.g. Yankes earlier fix with camo: https://github.com/MeridianOXC/OpenXcom/commit/e1f5d582df1ae071d4a441e62c92076c49643e38

This still seems to cause major issues. I just noticed with XCF that in 7.9.20 if you use smoke in darkness, you need to be in an adjacent square to see the enemy unit (without any camo) - one square off and there is no sight anymore. I reproduced this in 'New battle'. See the screenshot (when two agents don't see the enemies).

FWIW, the normal night visibility in suits in XCF is 9 squares, personal light 5 squares.

When I added a flare and so eliminated the impact of darkness, the agent could see the enemy from 4 squares off, from 5 squares no visibility. This seems normal.

I also tested several versions of 7.9.19 and 7.9.18 and all were bugged. When I rolled back to a version of 7.9.16, the visibility in dark & smoke was again the same as in light & smoke.

So I think the unit visibility change refactoring introduced for 7.9.17 in https://github.com/MeridianOXC/OpenXcom/commit/e35c669db14f170adc5b37e609861fb923574b19 is still buggy in this respect.

I don't think a game-changing feature of dark and smoke stacking at all, let alone in this manner, has or at least should have been intentional. This would be a major change from OXC and OG behaviour.

11

OXCE Suggestions DONE / [DONE] QOL: escorts redirected to the base after the escorted craft's mission is over?

« on: November 26, 2023, 03:41:17 pm »

When a craft is returning from a ground mission, it cannot be attacked by the alien craft. Thus there is never any need for escorts (but the escorts themselves may be in danger of hunter-killers and at any rate, it would make sense to get them back for refueling etc,). Because the escorts are usually much faster than the transports, they should always return home immediately after the craft which had a mission is on the return journey (unless the player wants to give them some other target).

Would it be feasible to make a small QOL improvement: the escorts would automatically be redirected to the base after the craft they're escorting is on its return journey (obviously, the player could redirect the escorts to do something else if needed). This would avoid all the clicking after each mission.

I'm assuring the game is aware that an escort is escorting a craft that is returning from a mission (_craft->getMissionComplete(), I suppose) and actually requires no escort.

12

OXCE Bugs FIXED / [FIXED] multistage mission proceeding to the next stage if enemies surrender

« on: November 12, 2023, 08:31:13 pm »

If the final enemies surrender or get under MC in a former part of a multistage mission, the game proceeds to the next stage as if you aborted the mission on exit squares (= you don't get the equipment on your craft). This should be similar to 'pure' victory.

I noticed this with XCF here:

In UAC Aerospace Lab mission, the final enemy(ies) surrendered and I was moved to the underground phase. However, no equipment (either on the craft or from the enemies) transferred on that stage, so even though I got the chance re-equip the squad, the pool to choose from was empty. There was also no loot pile to equip from anywhere on the floor, as there always has been on multistage missions.

This is likely a bug, but it seems so strange that I have no idea where. Sorry, I didn't save before the first part ended.

When reposting, zRrr was kind enough to reproduce this and provide a save (see on the thread).

This is something for Meridian and Yankes, currently oxce only tests, if all remaining aliens are under mind control, else game treats it as if player moved soldiers on exit tile and aborted. MiB Lunar Base or any other multistage mission with surrendering enemies will have same issue. Probably should be reported under OXCE Bugs.

Anyway, here is save from quick battle. Hit the scientist to get your stuff, press "next turn" to not.

13

OXCE Suggestions DONE / [DONE] more debug logging for mission scripts processing?

« on: October 22, 2023, 12:16:44 pm »

I've had several campaigns where mission scripts have had really strange RNG, like a mission with 0.33 probability not occurring for 12 months in a row even though the requirements are met (the mathematical probability for something like this being less than 1 %).

Would it be possible to include a debug log, for example before this check in GeoscapeState::determineAlienMissions()? If the debug log showed which potential missions proceeded to the RNG check, at least you might be able to rule out any bugs before that? (Looking at the RNG code it would be far more intrusive and spammy to add debugging there.)

                                // level three condition check: does random chance favour this command's execution?
                                if (triggerHappy && RNG::percent(eventScript->getExecutionOdds()))
                                {
                                        relevantEventScripts.push_back(eventScript);
                                }

14

The X-Com Files / Tamed Minotaur

« on: October 19, 2023, 09:40:55 pm »

Minotaur taming appears to be less useful than I had hoped. In base defense, they wake up from the corpses after turn 1. The "corpses" spawn in some random square with equipment. This is probably due to engine limitations on how it is achieved. This means that they have no useful equipment, and it is essentially impossible to find anything they could actually use (like an axe) from all the loot. Their weaponless attack is puny (about 50% chance). I suppose they could only work to some extent on bases which have very limited amount of loot or storage. Or for scouting. Or your agents will need to prepare by being equipped with a spare weapon that can be given to the minotaur(s) in later turns.

15

The X-Com Files / Weak UFOs

« on: October 19, 2023, 06:56:31 pm »

Now, in the work-in-progress 3.2 tree, hybrid convoys move. However, they do not appear to land, but rather just despawn eventually. And the convoys are so weak (e.g. medium convoy takes 50 damage) that almost any weapon one-shots and often destroys them utterly (for example, Kitsune with either a missile or gauss cannon).

Either the convoys should "land" and the mission could be undertaken that way and/or their damage capacity should be rebalanced. Or is it really intended that you preserve a really weak craft with puny weapons to deal with such things that start occurring only in the middle game?

Essentially the same thing, by the way, with syndicate retaliation missions. For example, medium 'Scarab' can apparently transport almost a dozen minotaurs and 40 human troops, yet only takes 80 damage and you one-shot destroy it with essentially any weapon except the puny useless early-game ones (e.g. regular craft cannon)..