Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - spawarotti

Pages: [1] 2
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.


Looks like changing the missionSiteZone of the UFO from
missionSiteZone: 23
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.

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.


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. :D

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.


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:

- 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:

- 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:

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

Yep, it's here:

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

Awesome, thx! :)

Whoa, looks awesome!

Btw is your VSCode extension available to fork and edit?

OpenXcom Extended / 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:

              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;
                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;

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:

This might cause problems for units that have more than 50 base health, because maxStun is base health * 4, as can be seen here:

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:

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

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.

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.

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.

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.


Programming / Re: Auto-Battle
« on: May 16, 2021, 07:02:38 am »
Oh yeah, don't get me wrong, I know it is a lot of work. But this can be developed iteratively. My goal was to brainstorm some ideas, to maybe make Meridian et al. see more potential in this line of thinking. But of course, just an idea :)

OpenXcom Extended / Re: [Suggestion] Medikit Priority
« on: May 15, 2021, 12:07:06 pm »
+1 for this feature. Not so infrequently I end up piling up stunned enemies in one tile, with my soldier standing guard. Note I also use the handcuffs script, as I play X-COM Files.

Sometimes one of the stunned enemies wakes up, I over-stun him, and now I want to apply medikit, but I cannot do it easily due to the discussed restrictions.

Gladly, but first I need to find the time and motivation ;)

Programming / Re: Auto-Battle
« on: May 14, 2021, 01:51:19 am »
+1 for automating tedious battles. The more the outcomes resemble actual battlescape session, the better. However, some very simplified abstract formulas would also work; at least at first. As to soldier loses in such battles: I expect some tweaking / configuration would solve this. Plus self-imposed half-ironman, i.e. only for automated battles. I really, really don't want to spend time equipping 12 of my soldiers only to arrive, search, find, shoot and kill 1 zombie that was hiding in the closet on the opposite end of the map. 1 zombie vs 12 soldiers should (almost?) never result in a soldier being lost (wounded is fine). But 12 soldiers vs 30 zombies is a different story.

There are so many cool things one could do with such a feature. E.g.:
- allow to decide if the player wants to do auto-battle upon arrival, when enemy type and count is better known.
- allow the player to order retreat, if the auto-battle is not going well. This might still incur loses, but possibly less.
- decide how careful the soldiers should be, willing to risk their life to capture a live specimen. More risky mission orders could result in bigger payoffs (more enemies captured, less destruction, less civilian deaths) but also result in possibly bigger loses, due to the ordered restraint.
- limit the amount of missions player can command manually; e.g. one per week max. The rest has to be auto-resolved.
- make the ability to auto-resolve a mission be unlocked as a reward, if the player previously won 5+ of missions of given type, or against given enemy type, or both.
- allow to auto-resolve given mission only if the player has crushing advantage, given some formula. Like at least 2 to 1.
- decide which soldiers are on the front-line (rookies, naturally) and which are hanging out in the back and thus at lesser risk.

I think this has huge potential to make the game more streamlined and enjoyable.

One thing that would greatly help my soldier inventory management woes are additive equipment templates. That is, I would like to be able to load an equipment template without removing items in slots that given template doesn't use. I often find myself equipping soldiers like that, for example:
- main weapon: Rifle + clip;
- secondary armament: psi weapon;
- accessories: incendiary and stun grenades + medi-kit.

Then, for different soldier, I would use the same set, but swap out psi weapon with pistol, as the other soldier is not a psyker.

I originally posted this on X-COM files discord #suggestions channel:

Pages: [1] 2