Messages

1

Brutal AI / Re: [SOURCEMOD] Brutal-OXCE 7.6.3

« on: September 20, 2023, 11:55:24 pm »

No, it doesn't. I can't even think how it could work.

@Solarius Scorch, my bad! I just assumed it does, given it appears to use a lot of the TFTD assets. Hence I thought one has to copy the TFTD folder from original TFTD installation, per usual installation instructions: https://github.com/MeridianOXC/OpenXcom#installation

@jnarical thanks for sharing and very quick bugfix! Very interesting analysis.

2

Brutal AI / Re: [SOURCEMOD] Brutal-OXCE 7.6.3

« on: September 20, 2023, 10:42:26 am »

jnarical, big thx for looking into my bug reports! I found one more problem in the same file as in my previous post [1].

See the attached screenshot. 95% to hit, but in reality 0%. In fact the agent never hits.

Note I have teleported the agent using debug mode. He is not standing there in the save file.

Note the save file is from X-COM Files, which requires the original TFTD data.

[1] https://openxcom.org/forum/index.php/topic,10967.msg157774.html#msg157774

3

Brutal AI / Re: [SOURCEMOD] Brutal-OXCE 7.6.3

« on: September 19, 2023, 11:14:26 am »

Reporting two bugs with accuracy in release 7.6.4 [1]

Bug 1: Have a look at the attached screenshot. You can see the debug log saying my agent (standing on the right) hit the deep one (standing one the left) but it is not true - the shot actually hit the tree. Right in the middle.

Bug 2: when I aim at the deep one, the agent (Rafael Silva/Snpr) has 86% accuracy with aimed shot. But once I make the shot, the next one is 95%, without any terrain getting damaged.

I also attach the save file.

[1] https://github.com/Xilmi/OpenXcom/releases/tag/v_7_6_4

4

Brutal AI / Re: [SOURCEMOD] Brutal-OXCE 7.6.3

« on: September 15, 2023, 06:10:08 am »

I agree, something other to turn it on or off would probably be good.

I think the request here is something like a button to just run AI for the currently selected soldier instead of having it controlled by a human. I think that would be nice. Would also be neat for debugging, so you can move soldier after soldier. I shall look into that.

Awesome, much appreciated! And yes, you interpreted my asks correctly

5

Brutal AI / Re: [SOURCEMOD] Brutal-OXCE 7.6.3

« on: September 13, 2023, 10:22:50 am »

Hey folks, first off, huge thanks for Brutal-OXCE! I am stunned by what it has achieved. I am tremendously enjoying auto-combat, instant priming and the new accuracy system. Exquisite!

Two questions:

- Is it possible to rebind the auto-combat key from Ctrl+A to something else? I bound WSAD keys to camera panning, hence doing Ctrl+A causes my camera to constantly pan left. Sometimes this problem doesn't trigger, but I am unsure yet how to prevent it.
- Is it possible to say "do auto-combat only for this soldier, only for this turn" ?

I would like to avoid having to modify the source code, as I would have to recompile each new release.

If these are not possible, I kindly ask for these to be added to Brutal-OXCE! If there is a better place to ask or submit a feature request, please do let me know. Thx!

6

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

« on: June 05, 2021, 08:56:51 am »

I encountered a crash to desktop blocking game progress. I worked around it by figuring out there is one specific UFO that is triggering it, and deleting that UFO from the save game. But I don't really want to do that, as that UFO was going to terrorize some civilians, and they deserve to die (either by the hand of the aliens, or as a collateral damage by the hand of X-COM, trying to prevent the aliens from killing the civilians).

I attach the save with the crash. Run the game for 4 hours in-game to have it crash. If you open the save file and search for "# This ufo causes the crash." you will find the UFO that, if commented out, will unblock the game.

I also attach the log of the crash.


Edit:

Looks like changing the missionSiteZone of the UFO from
missionSiteZone: 23
to
missionSiteZone: 0

fixes the problem.

Looks like at some point the game somehow generated an alien mission with broken missonSiteZone. Specifically, this is terror mission and to my understanding such missions need to have missionSiteZone of 0.

7

The X-Com Files / Re: The X-Com Files - 1.8: The Shores of Hell

« on: May 30, 2021, 01:23:52 am »

A couple good points.

I decreased the chances for subsequent Syndicate Monster Lab. Now it shouldn't appear remotely as often. (Perhaps it should only appear once, but I'd rather save some chances for multiple instances.)

Awesome! I think you can get the "Monsters Inc. Files" [1] only from that lab, so probably it should continue appearing until the player has researched it. So they don't get blocked if they sell all of them instead.

[1] https://xcf.trigramreactor.net/master/article/STR_MONSTERS_INC

Zombie Infectors are relatively common. Not finding some is a particular quirk of your campaign. Such things help make each playthrough different

Yeah, I suspected that. I guess that's the reason why it can be obtained from the Syndicate scientist.

The Welder may be a more serious problem. Not sure what to do about it yet, though. Just distribute more welders among alien crews?

I think that would be a good start. Another idea I have is to provide some alternative source if the player is not getting it for a long time - perhaps some event if the player is late enough in the game and/or researched specific topics. Maybe - an event that has a chance of appearing once the player interrogated 3 alien engineers. And the chance increases the more engineers have been interrogated. Just an idea.

As for your craft acquisition sequence: it sounds just crazy.

I see that Kitsune research becomes available after Promotion III [2], which I understand is expected to be done by the time invasion starts, yes?

Maybe Kitsune should not be available until the player researches Skymarshall? Say, it cannot be repaired without this tech.

Ravens [3] primarily require alien alloys, which can be obtained if the player gets at least one UFO, e.g. in the Gertrude mission. (btw I know you recently made that mission harder to get, so that should help).

Basically: if I get Promo III by invasion start and at least one UFO, I am set to have Kitsune and Ravens, making all the previous crafts obsolete.

[2] https://xcf.trigramreactor.net/master/article/STR_LOST_ALIEN_SHIP_DATA
[3] https://xcf.trigramreactor.net/master/article/STR_RAVEN

[Spoiler]

8

The X-Com Files / Re: The X-Com Files - 1.8: The Shores of Hell

« on: May 29, 2021, 12:07:11 am »

Playing XCF and loving it as always. Some inputs on balance from me:

Spoiler:

- The Syndicate Monster Lab mission, for the frequency it appears, is a bit boring and unbalanced. Boring, because the base layout is always the same, not very interesting (primarily long tunnels), and the randomized caves end up mostly in dead ends without enemies. Unbalanced, because one can rack up 3 millions from the Monsters Inc. files, which is a lot of money given the mission difficulty, especially on repeated raids.

That mission would be excellent if it would have to be done only once, or the base was more randomized, and the items were worth less money.

I would suggest to make it stop appearing earlier. Not when the syndicate HQ is defeated, but when the most critical research from it is obtained. For reference, here is the mission randomization logic: https://github.com/SolariusScorch/XComFiles/blob/7f3e1de7a6502ef24ddeabed5ea190eb56a7b3d5/Ruleset/missionScripts_XCOMFILES.rul#L7030-L7044

- I had plenty of zombie infestations, but I never got one with even a single zombie infector. I had to get the zombie infector research from interrogating many syndicate scientists, primarily captured during the Syndicate Monster Lab missions. This research gates a lot of progress, including M.A.G.M.A. storyline, Zombie storyline and neural implant.

Perhaps (not sure) a good fix would be to increase the frequency of investations with infectors, at least compared to the basic infestations:
https://github.com/SolariusScorch/XComFiles/blob/7f3e1de7a6502ef24ddeabed5ea190eb56a7b3d5/Ruleset/missionScripts_XCOMFILES.rul#L4827-L4870

- The Alien Alloy Welder is perhaps a bit too hard to get. I raided several UFOs already, including a very large one, and still no luck. At least I finally got the multitool. Huge amounts of research are gated because of that, and I am stuck on Heavy Titanium Suits. I think I might end up unlocking multiple tiers of research at the same time. I mean that by the time I will have the prerequisites for personal armor research, I will be already most way through to higher tiered armors and other items.

- I got Kitsune and Ravens way too early. Before the invasion started. This made everything before them obsolete, including Skyranger, Arrow, Interceptor, etc. I think Kitsune perhaps should come significantly later, around the tame of Skymarshall or later.

9

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

« on: May 23, 2021, 03:12:47 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

Awesome, thx!

10

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

« on: May 19, 2021, 12:54:50 am »

Whoa, looks awesome!

Btw is your VSCode extension available to fork and edit?

11

OXCE Support Y-scripts / Re: [y-script] Handcuffs

« on: May 18, 2021, 10:04:30 am »

Folks, I was grokking the handcuffs scripts and I think I found up to three possible problems, or I don't get the intent behind the logic. Can you help me understand?

I am talking about these handcuffs scripts:
https://github.com/SolariusScorch/XComFiles/blob/4f8e083df57eeca3a3a1b2dcd455a8ddc30b0cfa/Ruleset/scripts_XCOMFILES.rul#L2150-L2167

               
              else gt RandomValue StrengthLevel;
                unit.getStun CurrStun;
                unit.getStunMax NewStun;
                unit.Stats.getHealth UnitStatHealth;
                unit.getHealth UnitHealth;
               
                muldiv NewStun UnitHealth UnitStatHealth;
                # debug_log "newTurnUnit: unit.Stats.getHealth = " UnitStatHealth ", unit.getHealth = " UnitHealth ", NewStun = " NewStun;
               
                sub CurrStun NewStun;
                add PrevStun CurrStun;
                if lt PrevStun 0;
                  set PrevStun 0;
                end;
                unit.setTag Tag.VIRTUAL_STUN_LEVEL PrevStun;
                unit.setStun NewStun;
                # debug_log "newTurnUnit: if RandomValue (" RandomValue ") > StrengthLevel (" StrengthLevel ") then unit.setTag.VIRTUAL_STUN_LEVEL: " PrevStun ",   unit.setStun: " NewStun;
              end;

The first possible issue I see is that the NewStun, aka "stun-with-handcuffs" aka "stun as understood by the game", is not capped at 200, the same way it is done here:
https://github.com/SolariusScorch/XComFiles/blob/4f8e083df57eeca3a3a1b2dcd455a8ddc30b0cfa/Ruleset/scripts_XCOMFILES.rul#L1860-L1863

This might cause problems for units that have more than 50 base health, because maxStun is base health * 4, as can be seen here:
https://github.com/MeridianOXC/OpenXcom/blob/19449159c806c9e3e57e6907e3580812ff9bacf9/src/Savegame/BattleUnit.cpp#L5224

Thus, for example, if a unit with 100 base health loses 20 hit points, this script will compute its new stun to be (100*4) * (100-20) / 100 = 400 * 0.8 = 360. Ouch.

The second potential problem I see is that the "stun-without-handcuffs" aka "virtual stun" gets set to 4 * (baseHealth - health). Meaning: the more badly wounded the unit, the larger the virtual stun.
This virtual stun is used to compute if the unit will even try to escape the handcuffs. If it is > 0 it won't. This can be seen here:
https://github.com/SolariusScorch/XComFiles/blob/4f8e083df57eeca3a3a1b2dcd455a8ddc30b0cfa/Ruleset/scripts_XCOMFILES.rul#L2134-L2139

For the third problem: this virtual stun sometimes will end up dropping by 1 or 2 by turn, or not at all. Not sure why, but I think these are some rounding errors, as sometimes maxStun is 4*baseHealth-1 or -2.
Thus, some units will never try to escape the handcuffs while some of them will when the stun gets to 0. This is dependent on rounding error.

I deduced the formula for virtual stun from this code fragment:

                sub CurrStun NewStun;
                add PrevStun CurrStun;
                if lt PrevStun 0;
                  set PrevStun 0;

Here CurrStun is initially set to the "stun-including-handcuffs" which is at first MIN(maxStun, 200) which is MIN(baseHealth * 4, 200)
NewStun is maxStun * health / baseHealth

So CurrStun becomes, ignoring he MIN function:
CurrStun = CurrStun - NewStun
which is
maxStun - (maxStun * health/baseHealth)
which is
baseHealth * 4 - (baseHealth * 4 * health/baseHealth)
which is
baseHealth * 4 - (health * 4)
which is
4 * (baseHealth - health)

This now ends up being added to PrevStun which is the "stun-without-handcuffs" a.k.a. virtual stun.

Note that the numbers stabilize in repeated computations in following turns.
Next turn CurrStun will have the value of previous turns' NewStun

Applying to the formula above we get:

CurrStun = CurrStun - NewStun
=>
CurrStun = NewStun - NewStun
=>
CurrStun = 0

As I mentioned, sometimes there are rounding errors and instead CurrStun is -1 or even -2, decreasing the virtual stun by 1 or 2 each turn. But not the "stun-with-handcuffs" aka "stun as understood by the game".

12

Tools / Re: VSCode OpenXcom Modding Tools

« on: May 18, 2021, 02:19:36 am »

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.

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

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. 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).

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.

13

Tools / Re: VSCode OpenXcom Modding Tools

« on: May 16, 2021, 11:45:18 pm »

This is an awesome extension, thank you!

I have a suggestion re performance.

I loaded X-COM Files with this extension and it took, I think, over 15 minutes to load all rulesets, and my laptop fan was going bonkers during this entire time. X-COM Files has some massive rulesets, e.g. research_XCOMFILES.rul is over 24000 lines long, and the loading progress was stuck on it for the majority of the time it took to load.

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.

14

OXCE Suggestions OK / [Suggestion] Switch bases in purchase/sell screens while retaining filter

« on: May 16, 2021, 10:06:26 pm »

Desired behavior, by example:

1. Open "Sell" screen of base 1.
2. Select the filter, say "Outfits".
3. Press "2" to switch to base 2 "Sell" screen while retaining the "Outfits" filter.

The ask here is to make step 3 possible. Also for "Purchase" screen and also for custom search filters (via "q" hotkey).

My use case is: I am trying to understand what is my supply level of different items across all my bases, while understanding how many items of given type are in each base.

I know I can do Base information -> Stores -> All bases.
But this won't let me understand which base has how many items, it doesn't have filtering by category, doesn't show ammo in nice indented & colorized text rows, and doesn't allow me to purchase/sell on the spot.

I attach an example of a screen from which I should be able to jump between bases with number hotkeys, without losing the filter.

15

OXCE Suggestions DONE / Re: Melee dodge and CQC: true percentile indicators displayed

« on: May 16, 2021, 12:48:57 pm »

Since this commit [1], made on May 1, 2020, one can view the melee chance by pressing F1 when in the paper doll view. Note that debug has to be enabled in options.cfg.

[1] https://github.com/MeridianOXC/OpenXcom/commit/6ebd4c0d76c09338445eca185e424f3dfd15afc6