Topics

1

OXCE Suggestions WIP / Can items generated from geoscape events appear instantly

« on: January 20, 2023, 10:37:57 am »

When a random event creates items, those items are currently set to transfer to the base arriving at the next hour.

I think this is a bit confusing, and sometimes annoying and frustrating. It's confusing because many things could happen in between the event and when the item arrive on the next hour - which might make it harder for the player to connect the two ideas. Immediately after the event, the player might wonder where the items are. And when they arrive, the player might be confused about what the items are for or where they came from. It can also be annoying / frustrating if the items take up a lot of storage space - triggering the base-overfull forced sell screen. This is bad because the forced-sell screen is set to appear immediately after the event. The space requirements of the new items are counted, but those items haven't arrived yet - and so they cannot be sold / transferred on the force-sell screen.


In my opinion it would be much better if the new items arrived immediately after the event, rather than at the usual 1-hour for items transferred. A secondary less-good option would be to just remove the immediate storage space check on the event screen - leaving only the normal 1-hour storage after the items actually arrive.

2

OXCE Suggestions WIP / [SUGGESTION] Alternate loadout system #2

« on: January 03, 2023, 01:53:11 am »

The new system is working pretty well. It requires some changes of playing habits, but it is an improvement overall.

I think the only significant inconvenience is this business of disembarking all the crew so that you can equip them in the base, then putting them back on the craft again. It's a lot of easy messing around, and remembering / finding the crew you want. For me personally, I think the ideal case would be if the 'inventory' button from the craft equipment screen did a bit of magic to make it easier... I'd like it to show only the soldiers on the craft, but with all base equipment - including equipment that might be held by other crew who aren't on the craft.  And when this inventory screen is closed, changes to soldier equipment are reflected in the craft equipment.  I think most of this would be achieved by what you (Meridian) talked about in another thread. i.e. if you automatically take the crew off the ship for the inventory screen, then put them back on the ship when the screen is closed. I think that would achieve almost exactly what I'm asking for - except that I always want the inventory screen to not show any soldiers who aren't on the ship.

By the way, on a semi-related note, on my own personal OXCE version I've implemented a way to load craft equipment without removing current equipment. Here. I'm not sure if this is interesting to anyone else. The main use-case is when you have a template saved for general additional craft gear that you want to add after you've already put your soldier on-board. (I went for the easiest implementation I could think of. Holding ctrl when clicking the template makes it add rather than replace the equipment; but maybe a 'nicer' implementation would have a toggle button on the load window.)

Maybe later I'll try implementing the stuff about soldiers in craft that I described above. But that's a lot harder, and my vision might not agree with everyone else's needs anyway, so I'm a bit worried that would be wasted effort.

3

Programming / Fixed bug in TileEngine::voxelCheck related to stairs / slopes.

« on: February 17, 2018, 12:22:42 pm »

Melee attacks against units standing on slopes would often fail to do any damage. This was a long standing and well known bug. Today I tracked it down. It turns out to be a mistake in TileEngine::voxelCheck.


The gist of the problem is that the voxel check wasn't finding the unit to deal the damage because it wasn't including the terrain height of the unit. It wasn't including the terrain height of the unit because it was instead including the terrain height of the tile above the unit... which was unhelpful.

The fix is easy, and I've posted it here (along with a description of the problem).

I suspect a side effect of this will be that units on slopes will be hit more often in general; because voxelCheck is used for many things, and this problem would affect all of them. Nevertheless it is a bug fix.

4

OXCE Suggestions DONE / [DONE] [Suggestion] Pilot auto assigning ideas

« on: July 11, 2017, 12:10:33 pm »

I still think it's pretty awkward to get thrown out of an intercept action due to lack of pilots. It's not as bad now that there is a button to take you to the ship screen to assign a pilot, that was a big improvement, but it's still a bit cumbersome to have to go through a few menus for something that usually doesn't matter.

I don't think the 'auto assign' option in the options menu is as useful or as intuitive as it could be. Currently the auto assign option forces all ships to use whoever is last on the list as their pilots. This is ok for most situations, but sometimes it just isn't what I want to do - and I certainly don't want to have to go in and out of the options screen whenever I want to change tactics. In general, I care about who pilots my interceptors, but I don't care who pilots the troop transport ships. The tricky part is that some troop transport ships are also interceptors. I think it would be better if auto assign only tried to assign pilots when there aren't enough already.

Here are a few other approaches which I think would work well. (Any one of them would be good. Not all three!)

• Whenever the player puts any unit in a craft, the game checks if the craft has enough pilots; if it doesn't yet have enough pilots, the unit being added to the craft becomes a pilot. I think this would be good default behaviour, and it would remove the need to even have an option to 'auto assign' pilots.
• Alternatively, when an intercept is told to launch, if there the ship doesn't have enough pilots, it could then (and only then) automatically assign whoever was available as a pilot. This would be the functionality of the 'auto assign' option. If 'auto assign' was turned off, or if the craft still doesn't have enough pilots even after auto-assigning, the game would do exactly what it does currently. ie. tell the player that there isn't enough pilots and offer to go to the ship screen.
• There could be an additional button on the 'not enough pilots' screen which effectively says "auto-assign and go!" The button would try to automatically assign pilots, and continue the intercept command without the player having to reissue it.

As I said, I reckon the current system is still a bit awkward. I also think it's potentially confusing for newer players who are less comfortable with the UI. I think it would be much better if one of the suggestions I've offered was implemented. I like the first option best.

5

XPiratez / Reusable (and painful) deep 'surgury' kit RENDers mushroom beer redundant

« on: January 01, 2017, 04:11:55 am »

I just discovered that a wand of rending is very useful tool for restoring lost health.

Using the wand on one of the gals tends to do low damage, but creates lots of open wounds. The wounds can then be fixed up with a a field surgery kit or a nano surgery kit to restore significantly more health than the wand took away. (Just be careful to test it on someone with plenty of health first to bit sure that you're not going to kill someone!)

6

XPiratez / The effect of difficulty level

« on: December 23, 2016, 08:12:52 am »

I've been thinking a bit about how different difficulty levels change the game, and how they don't just make it harder - but change which bits of it are hard; and how it distorts strategy and tactics a bit. In particular, I'm not sure that higher difficulty levels always make the game harder.

Changing to a higher difficulty improves the stats of enemies; so that they have more health, more action points, better accuracy, and more dangerous AI (better 'memory', etc). All that stuff makes the game more difficult, no doubt - however, higher difficulties also have more enemies; and in some ways that actually makes the game easier.

• More loot
• More slaves (and slaves are extremely valuable)
• More opportunities for high rank captures

Ultimately, those things are the reasons we choose to do missions in the first place. For example, we are never forced to do a landed ufo mission. We choose to do it because it will give us prisoners and loot. So we the number of enemies is increased, we're going to get more value from our missions. More enemies does make the mission harder in most cases; but the difficulty certainly isn't proportional to the number of enemies. Eg. a landed Extractor having a few extra enemies with low powered weapons does not make it harder. It just makes it more valuable.

In short, higher difficulty level makes the ground game more difficult, but it makes the economic game easier. It allows the player to expand faster and research faster; and gives the player a surplus of fancy weapons and ammo much faster than they'd otherwise get. On higher difficulty levels, ground tactics are more important, but base management is less important - because resources are more plentiful.

I'm interested in people's thoughts about this. In particular, do you agree with what I've said? And is this a good way for the game to be, or should the effects of difficulty be changed a bit? (I've got a few ideas for how it might be changed, but nothing that I'd like to advocate right now.)

7

XPiratez / Large barracks and large vaults are too weak.

« on: December 12, 2016, 11:20:12 pm »

In my first play through, I put a bit of effort into designing my bases in such a way that I could build large barracks and large vaults in the hope that their efficiency would make it worth the effort and initial cost...   and I was punished for it. Since then, I haven't built them every again and I don't intend to. They are cumbersome, and not very effective.

In the early game, the up-front cost and build time makes them an unattractive option. You rarely need that much living space or storage space all in one shot, and it logistically difficult to 'upgrade' from the smaller building to the larger ones. The larger buildings are more efficient in terms of base squares and monthly cost; but the base squares doesn't matter much until the late game, and the monthly cost difference is not great...  If you crunch the numbers, you find that it takes almost 2 years of full usage for a large barracks to match the cost of an an equivalent number of small barracks; and after that you'll be making around 14k profit per month - which is essentially insignificant 2 years into the game.

So, in the early game - they are a poor choice. The upfront costs are too high, the payoff is too low. But that's ignoring what is probably their biggest draw card: base size efficiency. They take up less base space than small barracks / small vaults. ... But in the late game, when base size actually matters, the luxury barracks and armoured vaults are superior. And furthermore, it is far easier to replace the smaller buildings than it is to replace the large ones. So if you build your base with large barracks and large vaults, then you end up losing out on base size as well.


So... for me it is pretty clear that the large barracks and vaults are a waste of time/money/space...   Does anyone have any other thoughts on this? I'm thinking they should probably be buffed so that they are as space efficient as the end-game buildings. After all, it really does take some additional planning to use them at all. They need to be good to justify their use! (Or just remove them from the game and replace them with something else.)

8

XPiratez / Sometimes you just have to run

« on: November 23, 2016, 12:47:10 pm »

I often find it hard to make myself retreat, even when things look really bad.

In my current game, I just recently bought a Pachyderm, and so I'm finally able to follow ships long enough to see them land. 



Unfortunately, this is the first ship I was able to follow...



But hey, one of my gals has a boarding gun... maybe if I play it safe I can at least get a little bit of loot, right? Lets just open the door and see what we're facing:



     I think this is going to be the first time I retreat without having even taken a step off the ship!

9

XPiratez / Traing bravery

« on: September 20, 2016, 04:18:41 am »

Since the implementation of pilots, bravery has become a much more important stat. It's very useful to have a team of high bravery pilots for every base, and so training soldier for bravery is more important than it use to be.

The thing is, training bravery is not as easy as training other abilities. Most stats can be casually improved to high levels just by doing ordinary things in missions, without any special effort. (There are ways to accelerate the improvement of any stat, but generally it's enough to just equip gear that will help with the stat you want to improve... eg. carrying a couple of boom fruit can give you the opportunity to improve your throwing without too much effort. Carrying a fast weapon (particularly a fast melee weapon) can give you plenty of chances to improve reactions, etc.

But bravery, in my experience, doesn't improve much beyond ~60 through normal play. The only way I know of to reliably improve bravery is to keep a soldier's moral low for several turns; and that tends to only happen if I'm doing something special to deliberately keep their moral low - such as making them wear a slave outfit and shooting them myself; or doing lots of psi attacks with the witch outfit; or taking combat drugs (and using smokes to boost moral if moral isn't high enough to take the drugs to drop the moral!)


However, I'm pretty sure I've seen soldiers get bravery increases without their moral having been low. So I'm thinking that there must be some other way to train it. Maybe something to do with healing things? Or some particular weapon? I don't know.

I'd prefer to be able to train bravery with just a few tweaks to normal play (such as using a particular weapon), rather than having to do weird stuff like shoot my own soldiers. So I'm wondering, what are the best ways to train bravery?

Before pilots, I didn't bother trying to train bravery at all; because no one panics anyway in an ordinary mission. There's too much moral bonus from killing enemies or from +bravery armour for moral to ever be a serious issue. On higher difficulties it seems that bravery is even less important, because there's just more stuff to kill - and hence boost moral!

10

XPiratez / Talking tactics

« on: July 04, 2016, 06:37:40 am »

One thing I like about this game is that there are a wide range of viable tactics - and different tactics are powerful in different situations. And today I thought I'd share a powerful strategy I've been using recently.




I set up a 'safe zone', where the enemies can't get line of sight to - either because of physical obstacles or smoke. I have my heavily armoured units peek out from the zone to spot enemies, and then snipe the enemies with long-bow archers from within the safe zone. If all goes to plan, the enemy gets wiped out and my units don't even get shot at, because enemies don't take reaction shots against units they can't see.



The archers wear amazon armour for the damage bonus and stamina regen. They also carry melee weapons and shurikens, just in case they need to go indoors.



A seductress or two helps deal with high-armour foes. (I think its a bit bizarre that a seductress can knock out a foe in power armour at long range, through smoke, such that they can't even see each other. That's some serious seduction. It's a pretty cheesy tactic.)




Clearly the archers are most effective in open areas and hilly maps. Maps with buildings or lots of trees make it a bit harder. Usually I bring reaper-rifle snipers and some high damage guns, but when I expect an easy mission I don't always bother.

[edit]
(1 sec. I'm shrinking the images.)

11

Programming / Minor bugfix for checking line-of-fire

« on: July 01, 2016, 03:13:07 am »

TileEngine::canTargetUnit is used to find a voxel within the target for which we have a clear line to, so that we can shoot at the target. It it finds a line-of-fire, *scanVoxel is set to be the target voxel and the function returns true. But when it cannot find a clear line-of-fire, the function returns false and *scanVoxel is just left on whichever value happened to be the last one checked.

That's all fine, but unfortunately the return value of TileEngine::canTargetUnit is actually ignored. Instead, the target voxel (whatever *scanVoxel was set to) is given to Projectile::calculateTrajectory, which then gets final say in whether or not we can take the shot. If it looks like we were trying to aim at a unit but the shot will actually hit a wall, then we'll abort the shot.

The problem is that Projectile::calculateTrajectory doesn't actually know what we were trying to aim at. Usually it is able to correctly guess that we were aiming at a unit based on the (bogus) voxel, but not always. What can happen is that TileEngine::canTargetUnitreturns false (meaning that we can't hit the target), but the final target voxel given to Projectile::calculateTrajectory makes it look like we didn't want to hit a unit anyway - and so our solider will happily shoot at empty space rather than telling us that there was no line-of-fire to the enemy.

--

The most obvious way to fix this would be to use the return value of TileEngine::canTargetUnit to decide whether we can take the shot. However, that could require some structural changes and some code duplication. So I've made a simpler 1-line fix, which just ensures that the target voxel given to Projectile::calculateTrajectory will always be in the unit when we were trying to aim at the unit.

Here:

Code: [Select]

diff --git a/src/Battlescape/TileEngine.cpp b/src/Battlescape/TileEngine.cpp
index 3510149..9265e20 100644
--- a/src/Battlescape/TileEngine.cpp
+++ b/src/Battlescape/TileEngine.cpp
@@ -820,6 +820,9 @@ bool TileEngine::canTargetUnit(Position *originVoxel, Tile *tile, Position *scan
  }
  }
  }
+ https:// Couldn't find a line of fire; so just set the scanVoxel to be at the centre of the target.
+ https:// (Not all callers pay attention to the return value of this function.)
+ *scanVoxel = Position((tile->getPosition().x * 16) + 7, (tile->getPosition().y * 16) + 8, targetCenterHeight);
  return false;
 }
 
--

PS. I'm not sure where the best place for these bug fixes is. I noticed and fixed this bug on xPiratez v0.99. I'm attaching a save game which demonstrates the problem. (Shoot at the enemy in the window; you will miss every single time. Debugging shows that there was no line of fire, but the game lets you shoot anyway.)

I guess I'll post something the bugtracker, at https://openxcom.org/bugs/openxcom/issues/new/issuetype/bugreport -- but I'll have to lie about which version of OpenXcom I was using; because as I said - I was playing a different version. The code does look the same though.

[edit]
Posted here. Please let me know if there is a better place or better way of reporting this kind of stuff.

12

Recycle Bin / Bug fix for parabolic projectile collisions

« on: June 30, 2016, 06:42:46 am »

Here's a bugfix that I recently posted on the xpiratez forum.

The effect of the bug is that many arcing projectiles (eg. arrows fired from a bow) will hit their target without any of the "hit" effects actually taking place. ie. an arrow will collide with an enemy and stop moving; but the enemy will not register as having been hit. They won't take damage etc.


The problem was a mismatch between the coordinates given to TileEngine::hit, and the coordinates where the actual collision occurred.

To do collection detection on arcs, the game calculates a list of points on the arc then draws straight lines between and tests if those straight lines make contact with anything. The game was correctly detecting the collisions with those straight lines, but then instead of storing the coordinates of the collisions, it just stored the coordinates of the end point of the straight line - which may or may not have been where the collision occurred. And so sometimes the end-point of those lines was inside the target, and sometimes it wasn't. The problem could be reduced by taking more points on the arc (so the lines are shorter); and doing that might still be a good idea to make the arcs more arc-like. But ultimately, we still need to store where the collision takes place - and that's what I've done.

Here's the fix.

Code: [Select]

diff --git a/src/Battlescape/TileEngine.cpp b/src/Battlescape/TileEngine.cpp
index 35214de..8d7fb9f 100644
--- a/src/Battlescape/TileEngine.cpp
+++ b/src/Battlescape/TileEngine.cpp
@@ -2755,29 +2754,31 @@ int TileEngine::calculateParabola(const Position& origin, const Position& target
  x = (int)((double)origin.x + (double)i * cos(te) * sin(fi));
  y = (int)((double)origin.y + (double)i * sin(te) * sin(fi));
  z = (int)((double)origin.z + (double)i * cos(fi) - zK * ((double)i - ro / 2.0) * ((double)i - ro / 2.0) + zA);
- if (storeTrajectory && trajectory)
- {
- trajectory->push_back(Position(x, y, z));
- }
  https://passes through this point?
  Position nextPosition = Position(x,y,z);
- int result = calculateLine(lastPosition, nextPosition, false, 0, excludeUnit);
+ std::vector<Position> contactPoint;
+ int result = calculateLine(lastPosition, nextPosition, false, &contactPoint, excludeUnit);
  if (result != V_EMPTY)
  {
  if (lastPosition.z < nextPosition.z)
  {
result = V_OUTOFBOUNDS;
  }
- if (!storeTrajectory && trajectory != 0)
+ if (trajectory != nullptr)
  { https:// store the position of impact
- trajectory->push_back(nextPosition);
+ assert(contactPoint.size() > 0);
+ trajectory->push_back(contactPoint[0]);
  }
  return result;
  }
+ if (storeTrajectory && trajectory != nullptr)
+ {
+ trajectory->push_back(nextPosition);
+ }
  lastPosition = Position(x,y,z);
  ++i;
  }
- if (!storeTrajectory && trajectory != 0)
+ if (!storeTrajectory && trajectory != nullptr)
  { https:// store the position of impact
  trajectory->push_back(Position(x, y, z));
  }


13

XPiratez / Balance of bows and bullets

« on: June 13, 2016, 05:33:38 am »

In my first playthrough, I didn't use bows much - because I kind of assumed that rifles would be more powerful.

However, this time around I'm feeling that bows are super-strong. Their accuracy is very high and their damage is respectable - but most importantly, they can hit targets from behind cover. I find it a bit absurd that my archers can fire arrows over the top of the airbus to hit targets that they can't even see, with close to 100% accuracy; while at the same time, my soldier with a blackmarch SMG can only get ~60% with a couching aimed shot.

Meanwhile, muskets and other low-tech firearms are completely overshadowed. Better guns are plentiful, especially if the player is using bows and melee to conserve ammunition.

I want to feel like my tech is progressing forward; but at the moment I'm thinking that I'm probably going to be using bows against anything that isn't heavily armoured for a long time. I'm thinking that maybe bows could afford to have their accuracy reduced a bit. I imagine that it's easier for people to dodge longbow arrows than dodge bullets!

What do others think about this?

14

XPiratez / Effective uses of Ghost armour?

« on: May 23, 2016, 02:13:57 pm »

I kind of like the idea of having stealth assassins sneaking around an slaying enemies while unseen; which is what ghost armour can do. But I haven't had much success so far.

The problem as I see it is roughly this: a soldier needs to be pretty well trained to use the armour effectively. (The need high psi skills, and high melee for the dagger.) So ghost soldiers are not simply throw-away cannon fodder. They need to be looked after. However, the protection of ghost armour is very low and the invisibility effect is unpredictable (as far as I know). So... maybe the ghost soldiers don't get shot at 7/8ths of the time, because of invisibility, but in that other 1/8th, they just die.

Ghost soldiers die easily to a stray grenade, or reaction fire. The invisibility effect is strong, but without some way of predicting whether or not the enemy will be able to see me, I can't see how to use the armour without very high risk of getting the soldier killed.


I'm interested to hear how people are using their ghost armour, and whether they think it's useful.

15

XPiratez / Confused by XG weapon requirements

« on: May 14, 2016, 10:34:21 am »

I've just researched XG assault, and XG rifle. I can now build the ammo, but I cannot build the weapons themselves. The game hasn't given my any hints as to why I can't build them.

I just checked the wiki to find out what's going on, and I discovered that I need Gauss Defences in order to build the XG weapons. That seems strange to me, because I can't yet build gauss defences; in fact, I can't even research them yet.

Why can I research XG weapons without this prereq. even being mentioned? Have I done something weird?

(By the way, I'm still on 0.98B. So if this has already been changed, then I'm sorry for bringing it up. I didn't see anything about it mentioned in the changelog; other than maybe "Research & manufacture updates & fixes".)