Messages

46

Suggestions / Re: Night combat improvements

« on: September 26, 2019, 11:53:22 am »

There's a fun way you can already play night vision games in openxcom...

In general, if you mod the AI to not have a night vision advantage, you can play all sorts of games with lighting. The lighting tactics in vanilla are so simple purely because aliens aren't hurt by the darkness.

This would also show the inherent value of NV gear over torches - the illumination point of a handheld torch stems from the wielder, and will make you very vulnerable to ambush from the very foes you're searching for. Like life. Of course, to truly make use of this, you would need a patrol AI that takes lighting into account and throws flares at you.

47

Released Mods / Re: Recovery time revamped [OXCE]

« on: September 25, 2019, 12:32:57 am »

I don't want to sound negative... but why are you doing this? What's the motivation?

I mean, an average player will never even notice any of these changes.

Also, I feel like you're mostly solving non-issues, like excessive micromanagement for example... whoever micromanages this really needs to think about their priorities in life.

In the last 5 years, I've barely heard any complaints about game mechanics such as this one... you get hurt => you need to spend some time in the infirmary... who cares if it is X days or Y days.

I could legitimately see the benefit of percentage-based recovery times for mods with hero units that might have hundreds of hit points (EG: if someone made a 40k Chaos campaign with Daemon Princes that might need to heal after big fights or something), but honestly, even for my setup it's not necessary for average soldiers - I like to play UFO with TFTD damage RNG, but it makes the endgame armours OP (the option warns you about Sectopods, but it should also warn you about Flying Suits!), so I reduce their effectiveness slightly, but up my soldier's HP values by a good chunk (max 100 rather than 60) to compensate for increased single-shot lethality. The increased infirmary stays from losing 90 hit points rather than 50 (or, you know, 10 rather than 0) just add to the simulationist charm in my book. If you want all of your soldiers to be heroes rather than just skilled and lucky normal people, that's the speciality of the new XCOM games.


I don't think my little balance tweak is everyone's cup of tea, but I actually rather like how it punishes endgame recklessness while also making the beginning less of a meat grinder. Haven't tested it religiously, however.

48

Released Mods / Re: Chryssalid tweaks [OXCE]

« on: September 25, 2019, 12:17:03 am »

1. Originally, Chryssalid's zombifying attack succeeds even if it inflicts no damage. Yes, it fails if they miss completely (i.e. melee accuracy check is failed), but if they hit, then the victim is zombified even when all damage is negated by armor. It makes no sense to me: how are they supposed to inject their venom and plant an egg if their ovipositor (or whatever) didn't pierce the armor? Actually, on this forum there was a suggestion even to make their zombification work only after the damage they inflicted has killed the victim, but I prefer to think that even if they made just a scratch of 1 HP, it's enough to inject the venom. Let's suppose it's potent enough to kill the victim instantly. Still, if there is no scratch => no venom is injected or egg planted => no zombification. So the first change is that the attack should reduce the victim's health by at least 1 HP for zombification to happen.

2. Originally, Chryssalids hatch instantly. If you kill a zombie in the exact same turn in which it was zombified, a Chryssalid is gonna spawn from its remains. This also makes no sense to me. Even though the UFOpaedia mentions Chryssalid's high metabolism, there is a difference between high metabolism and developing a human-size organism from a small egg (Chryssalids carry about twenty of them, according to the same entry in UFOpaedia) in a second. It would be okay in a fantasy setting ("it's magic", and that's it), but not in a sci-fi setting.

OXCE has an MP stat for soldiers now Give me that man-portable Sister Ray to shoot holes in battleships with magical firepower!

I mean, I know you stated your preference, but I always liked the way that XCOM 2012 handled 'lids more - big, sharp, venomous claws, but a biologically sensible ovipositor located in the mouth. Or, in gameplay terms, a Chryssalid would actually need to subdue (kill/KO, and if a kill, immediately implant alien wing-wong before the whole body dies) a human in order to get a zombie, not just nick the poor fellow. The lethality of the venom could be argued, though. Turns out that bodies don't do a very good job of not dying with a bloodstream full of chemicals telling them to die. Given the presumably quick time-frame of Battlescape turns, however, that would seemingly be better simulated by slapping the poor victim with a whole lot of fatal wounds.

Still an improvement over "ignore all armour values, accuracy and evasion checks, and Just Make A Zombie" vanilla behaviour that might have even been a glitch, given what happens in vanilla when a soldier survives (in terms of HP) zombification.

49

Released Mods / Re: [STAT TRACKING] Soldier Diaries 1.0

« on: September 24, 2019, 11:46:43 pm »

For the Security Detail commendation to work as it seems to be intended, you would not only have to ignore Base Defence missions as previously mentioned, but also wounded days, unless you're playing some sadistic ruleset that lets you send those poor Purple Hearts out on actual missions. Even with the vanilla health cap of 60-but-really-61, it's not impossible to get knocked down to a single hit point and then get waylaid in the infirmary for 1.5x that amount of time.

50

Released Mods / Re: UFOpaedia-friendly Celatid [UNIT] [OXCE]

« on: September 24, 2019, 11:31:20 pm »

A further lore-friendliness problem rears its head from the limitations of psiVision: Namely, the inability (unless the Wiki needs updating) to define specific units that can or can't be spotted by specific armour's psiVision at all, or by it in general other than through fearImmune. Celatids can detect human brainwaves according to the 'pedia, but would also be able to psisee dogs, Sectoid hybrids, Tau, elves, or whatever other player units you have in your modpack that are subject to morale rules. (and as an aside, that also means you'd have a harder time of making heroes who are immune to panic but can still be psi sensed, but I'm pretty sure that's possible by tinkering with bravery formulae)

But that is/was a limitation of OXCE, not a problem with this mod. Just wanted to mention it.

51

Released Mods / Re: Decreased TUs for aliens on your first turn [OXCE]

« on: September 24, 2019, 11:11:33 pm »

I'm not interpreting the same thing you are!
Before landing it is logical that the pilot should look for two things:
- a flat, unobstructed place to land
- a relatively isolated place where the number of ENIs is the least important (in reality landing 1 or 2 km from the area will be feasible but we are [b[talking about UFOs[/b] so we do what we want from reality).

Tactical landings are made in a matter of seconds. Meanwhile, the few ENIs who had seen the aircraft were approaching the assault point. So it's normal that they used part of their TU!

Yeah, in real life they're officially called UAP's! (Unidentified Aerial Phenomena)

But yeah, if this was more realistic, we wouldn't have the dropship on the Battlescape map at all, because X-Com would be either crawling through the brush to get to the UFO undetected, or at the very least landing in such a way that the Skyranger can be used as cover, after raking the enemy position with heavy firepower to force the ayys into cover.

With the terror missions, the same: the aliens would be busy chasing civilians, civilians busy running away from aliens stupidly walking here and there, as they do So from the "realism" point of view it also makes sense that the aliens would have only their normally reserved TUs during the first turn, not the full amount.

Or, if they have weapons (such as fists), running towards the militarily-trained/biologically engineered aliens spoiling for a fight. The implementation of civilians really is more like the Green Units in Fire Emblem than actual civilians, even the vanilla version. In OXCE especially, "civilian" in-engine is just defined as "allied AI" in a very broad sense.

52

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

« on: July 16, 2019, 09:06:20 pm »

I was under the impression that most people, especially veterans, used the TU reserve buttons. I use them frequently, usually to move several soldiers quickly without overspending their TUs. It's a great timesaver at times, but sometimes I turn it off because the amount I want to reserve isn't an available option.

I would probably use them a lot more often if it wasn't for OCX's route indicators. Sure beats having to remember the exact TU costs for every type of terrain in the game, for both vanilla jogging and OCX sprinting and strafing. Also misclicks. Misclicks are the work of T'Leth.

While we're on the subject of the movement and indicators, I have noticed another bug quite a few times: When a soldier with 8-11 time units tries to walk through a closed door, they open the door (spending 4 time units) and then stop, giving you the error that they do not have enough time units to proceed. You have to issue the order a second time to get them through the door. I suspect that what's happening is the game deducts the 4 TUs for opening the door without going through it, then incorrectly tests for 8 time units remaining for going through a closed door. It may be failing to update the door's status on the time unit checker.

The route indicators aren't perfect, you usually still do have to eyeball things like getting up from a crouch and opening automatic doors. (Countless rookies have been spared horrible death from tactical suicide by the humble right click-to-strafe combo emulating real life breaching techniques.) Guess it's just like vanilla, given how you always had to factor in TU costs for turning when reserving for shots. It would make sense that the route indicator's displayed cost is what the game internally uses for checking if you have enough TUs to keep moving, as opposed to how many TUs you currently actually have.

53

Released Mods / Re: Self Medkit Heal [OXCE]

« on: July 16, 2019, 04:51:29 pm »

I don't have plans to include any more built-in (standard) mods.

Actually, I am thinking (for a longer time) about removing some of the currently available.

The default pack-in mods should all either be nice and simple, or accommodate for pre-OpenXcom stuff like Util and Extender. There's no sense in overwhelming people either new to OXCE or to old X-Com in general with a whole battleshipload of second wave options right in the menu. (We already have a Skyranger full of them!)

Of course, if people want the old options that get axed, they could always be collated into one big modpack (one zip, multiple mod folders of course) and put onto the site. I volunteer in advance for my five seconds worth of troubleshooting, typing, and screenshotting to be shoved into any modpacks. I don't need kudos and credit for enabling a feature - thank the people who implemented it.

54

Released Mods / Self Medkit Heal [OXCE]

« on: July 16, 2019, 04:03:01 pm »

It is as it says. This mod allows the vanilla medkit in both UFO and TFTD to use the allowSelfHeal feature of OXCE. It's a simple enough change that nobody's thought to make an actual downloadable for it I guess, but here it is anyway.

55

Released Mods / Re: Vanilla TFTD translation questions

« on: July 16, 2019, 03:32:15 pm »

I know I'm not the guy writing the language code, but it seems like it would make more sense to me to have en-GB fall back to en-US and vice versa, than do what's being done now. (Especially considering that en-US doesn't exist in vanilla)

But I suppose most modders were slacking off on including English text in their language sets, not American text. Even so, it's an odd special case where American English speakers have to debug their mods a little differently from people who speak, say, French. Ah well, if it bothers you that much, fork a new executable as a proof of concept or something. Doesn't bother me that much.

56

Released Mods / Re: [SOLDIERS] Celebrate Diversity: more nationalities and names

« on: July 08, 2019, 07:22:50 pm »

Kato is working on some significant improvements right now.

Ooo, nice. Of course, I'm one of those guys who would be like "oh could you also add in modern versions not just 1999 ones for people who need them, oh and TFTD and XPiratez lore versions and the kitchen sink and _{change the name to not sound like a political dogwhistle}" (nah, I do that myself. It's called Expanded Nationalities in my modlist. Honestly, I think it's more descriptive too)

Bah, I just like the increased pool of random names. Thanks, Kato! Makes getting a guy called Patrick Fitzpatrick by chance all the cooler. (Especially since he raided Cydonia in my most recent playthrough - no casualties there aside from the tanks too, and even they survived)

57

Released Mods / Re: [WIP][Beta][MegaMod]Equal Terms 2.0++

« on: July 08, 2019, 07:06:58 pm »

Since the different camos for the armours have no statistical difference (given that only OCXE supports camo, and only by day/night as opposed to tile) wouldn't it make sense for them to be identical store items? (I know OCXE supports this at least) Rather than buying Jungle Kevlar, Arctic Kevlar, and Urban Kevlar, you could just buy Kevlar, and then equip Jungle, Arctic, Urban, ecetera on your soldiers from the same generic Kevlar pile. The same thing could go for Tactical and Coverall (even though coveralls are infinite anyway ) and all that. Given that the different camos exist purely for customisation, said customisation shouldn't really be tied to having to buy separate camo items. Sure, it's realistic, but then why are there aliens? We don't know what sapient aliens are or aren't out there!

Hell, I might just try and kitbash support for this out myself (in lieu of an official mod update), but I didn't make this mod so I might accidentally break something :/.

58

OXCE Suggestions Rejected / Re: [Suggestion] Turn-based air combat

« on: July 06, 2019, 12:02:10 am »

Just reading this, it honestly looks like a waste of time. I could make a better argument for being able to run two Battlescape scenarios at once using the same turn cycles (that argument being mods with units that can teleport great distances through supertech/magic being able to swap between fronts) than for completely overhauling the interception mechanics to use the Battlescape. And even that would likely be a huge waste of time to implement compared to its limited use.

Yeah, the interception mechanics kind of stink. Even OCXE's additions don't do much to make them suck less - even Enemy Within has more strategic punch than vanilla UFO and TFTD thanks to consumable items, and that game's Geoscape is way simpler! It's just a reminder that the main focus of the game is in the tactical Battlescape, not the strategic Geoscape. Remember that item capacity limits didn't work right in vanilla! (nor did loading a save file's difficulty, and that was one byte!) Plus, it's old. The original engine creaks under its own weight, requiring two different executables for both Geoscape and Battlescape. It's likely that fancy dogfights just weren't possible. Yes, OpenXcom/OCXE could have fixed it (like Quest for Glory II VGA did the combat system up nicely, making swordfights actually interesting when you weren't just throwing OP fireballs at everyone) but OpenXcom was meant largely as a reimplementation of the original engine, while OCXE is based on it. Clue's in the name.

Go ahead and implement this crazy idea yourself if you like, but personally, if I were to do it, I would keep it real time. Turn-based combat works best when there's enough tactical/strategic depth to consider or characters to control that doing it in real time wouldn't work. Like X-COM. Making a dogfight turn-based when it's a matter of "shoot the bad thing and dodge boolet" is just a boring, slogged down version of autoresolve. If, however, you make it real time, you're telling the player that "you can gain an advantage by performing the right actions at the right time" - and even if you can't really do that, it's usually inoffensive and quick.

You already spend most of the game on the Battlescape - having to do it twice for most battles would just be terrible.

59

OXCE Bugs FIXED / [FIXED] A problem with switching to OpenGL? [OXC]

« on: October 22, 2017, 06:55:46 pm »

So, after a while of playing this beautiful little program (yes, I am using the v2017-10-10 Windows version of OpenXcomExtended+ v3.9c on Windows 7 Ultimate, aka the latest one unless the stickied OP is lying - so this should be the right topic, as this may not apply to the vanilla OpenXcom - which I have no interest in because this one's better ) on my absolute junker of a laptop with an embedded GPU which can't handle OpenGL well at all, I decided to switch to my desktop computer, which - while old - is quite capable for it's time. (some of the filters in this game make it puke, but most still clock a smooth 60fps)

But therein lies my problem. I wanted to up the resolution to the maximum my monitor can handle (1280 x 1024) and use hardware rendering (just the Raw filter, otherwise known as no filter) but while it works just fine (at least with the original Geoscape and Battlescape scaling, it runs at ~90% GPU at 60 FPS) the game keeps trying to boot me to the horrible xBRZ software renderer. In fact, once I switch to Raw and go back to the Options menu, the game is thumbing its nose at me by showing xBRZ as the renderer. This is despite the fact that OpenGL rendering is enabled in the raw YAML settings file and xBRZ is disabled. In fact, the string in the settings for the currently used shader is being deleted automatically by the game, and this is being interpreted as xBRZ mode. To clarify, my game and settings are all on the desktop in a self-contained folder for portability, and nothing is read-only. (My first boot was via cmd to make sure of this)

This snippet from the verbose log stuck out to me.

Code: [Select]

22-10-2017_16-25-04] [INFO] requested file not found:
[22-10-2017_16-25-06] [ERROR] OpenGL shader link failed "Link called without any attached shader objects."

[22-10-2017_16-25-06] [INFO] requested file not found:
[22-10-2017_16-25-06] [ERROR] OpenGL shader link failed "Link called without any attached shader objects."I know the filters are there, and I know that they work. I didn't change the shader folder at all, and when I turn it on (Raw), the GPU usage spikes (to ~90% as previously stated) whereas the software renderer (Disabled) provides the expected result of running entirely via the CPU.  This is annoying, because while the software renderer lets me play the game, doing any screen capturing stuff is out of the question. (even if I would potentially have to lower my resolution/FPS for OBS to work decently)

I was hoping for my first post to be a little different, a warm greeting after my first modern playthrough where I (hopefully) kick some grey backside, but alas, technical support called first. Hopefully it's not something stupid like "oh hey you made FLAC versions of those WAV files in the PS1 SFX pack so you can see if FLAC is properly implemented and you can save a little space but you didn't get around to actually making a new mod yet so imma mess up your OpenGL kthxbaiiii!"