Messages

166

XPiratez / Re: Bugs & Crash Reports

« on: July 06, 2016, 04:25:50 pm »

Clicking 'use left hand item' of the parrot causes the game to freeze. (The 'item' is just a blank space.)

167

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

168

XPiratez / Re: [MAIN] XPiratez - 0.99 - 7 Jun - First Impressions

« on: July 04, 2016, 01:49:59 am »

Speaking of difficulty, what exactly gets more difficult when I increase the difficulty level of the game? (ie. what changes if I choose Davy Jones instead of Blackbeard?)

I played my first game on v0.98b, Blackbeard; and now I'm playing my second game on v0.99, Davy Jones. It doesn't really seem significantly harder; but the base management side of things is much 'faster', for what of a better word.

In my first game, I had a shortage of money throughout pretty much the entire game; and also a shortage of armour parts, and a shortage of... well most stuff actually. When my money situation improved, I was using money to buy tac vests so that I wouldn't have to spent my precious armour parts. Also, there were a couple of points in the game where my research outpaced the available research topics (and so I was down to just research data disks, with nothing interested to go towards. I think the research bottleneck was mostly because it took ages for me to see any academy missions - so I guess that's a side issue.

Anyway, in my current game, I've got a huge stockpile of armour parts that I don't know what to do with; and I've got big heaps of gold bars and credit chips in my base that I haven't needed to sell. And the research tree has been wide-open for a long time. I think I've got all the resources that I need to get me well into the late-game tech.

It seems to me that the main difference is that the enemy's tech progresses a bit faster; and so I'm seeing more armoured enemies, and more enemies with good weapons. But I'm not sure if that makes it significantly harder. If I win a mission against well equipt enemies, then I get their equipment. Which means I get way more money, and more stuff to research, and more armour parts / power armour parts / grav units etc. So although it's a bit harder facing stronger foes early, the difficulty doesn't last long because it creates a turbo-boost for the player's economy. The stronger weapons from the enemies can be used to defeat their stronger armour; and everything has a high sell value. The only thing is, I'm not sure if I've got heaps of money because of the difficulty change, or because of the new early-game missions (which have provided me with many many apples). All I know is that I'm getting my 6th base far earlier than before; and the bottle neck for building study rooms is just the construction time - not the money or resources.

In any case, I'm curious as to what gets harder on harder difficulty levels; and I'm wondering if I could make some tweaks to the system so that it could be harder without the game being shorter. (eg. maybe less of an increase to enemy tech progression; and a percentage increase to all maintenance costs, or decrease to all selling values; or perhaps a small reduction to the rate of experience gain for the player's soldiers.) I'm just throwing ideas around. I have no strong opinions about this at the moment.

169

Programming / Re: Minor bugfix for checking line-of-fire

« on: July 04, 2016, 01:22:54 am »

Would it make sense/not be too much work to create a second set of checks for arcing shots?  I understand the idea that not shooting a bow at a target would make sense if the soldier can't see it, but this wouldn't this also have repercussions for other arcing weapons like mortars, grenade launchers, flamers, etc. where not having direct line-of-sight isn't as much as a problem?

Maybe this could be a thing exposed to rulesets - does this arcing shot weapon require line of sight?

Firstly, just to clarify - I didn't intend for the change to prevent arcing shots when line of sight is blocked; and even with the change they still will fire (and hit) if you hold ctrl when issuing the order. I do think it kind of makes sense for it to be like that, but that's not the kind of change that I'd advocate (except possibly as part of a ruleset, as you suggest).

I can think of a way to modify canTargetUnit so that it handles arcing shots. It wouldn't be a difficult change to make, but it would be a little bit computationally expensive. (My idea is just use "validateThrow" instead of "calculateLine" for every check inside canTargetUnit.) However, I not sure that's really necessary. My current thinking is that we can just ignore the result of canTargetUnit for arcing shots and throws as we did in the first place - but pay attention to it for direct shots. Like this:

Code: [Select]

diff --git a/src/Battlescape/ProjectileFlyBState.cpp b/src/Battlescape/ProjectileFlyBState.cpp
index 0d84d1e..ceb5edf 100644
--- a/src/Battlescape/ProjectileFlyBState.cpp
+++ b/src/Battlescape/ProjectileFlyBState.cpp
@@ -223,7 +223,17 @@ void ProjectileFlyBState::init()
  }
  else
  {
- _parent->getTileEngine()->canTargetUnit(&originVoxel, targetTile, &_targetVoxel, _unit);
+ if (_parent->getTileEngine()->canTargetUnit(&originVoxel, targetTile, &_targetVoxel, _unit) == false)
+ {
+ https:// if this action requires direct line-of-sight, we should abort.
+ if ((_action.type == BA_SNAPSHOT || _action.type == BA_AUTOSHOT || _action.type == BA_AIMEDSHOT) &&
+     !_action.weapon->getRules()->getArcingShot())
+ {
+ _action.result = "STR_NO_LINE_OF_FIRE";
+ _parent->popState();
+ return;
+ }
+ }
  }
  }
  else if (targetTile->getMapData(O_OBJECT) != 0)
diff --git a/src/Battlescape/TileEngine.cpp b/src/Battlescape/TileEngine.cpp
index 3510149..f7038a2 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;
 }

Notice that I've still kept the original change that I made to the bottom of canTargetUnit, where it sets the final value to be at the centre of the unit. Even if we ignore the return value of canTargetUnit, it is still being used to choose the specific target voxel for arcing shots; and so I still think this is a helpful to set that target to be the middle of the unit if we can't see a better spot.

Arcing shots have different checks later in the code for determining whether an arc is possible. So this change is looking pretty good to me. I can't guarantee that there isn't something else I haven't thought of though. D

170

Programming / Re: Minor bugfix for checking line-of-fire

« on: July 03, 2016, 03:21:26 pm »

Ok. I've just discovered an unwanted side effect of my second "fix". ProjectileFlyBState::init uses the same checks for arcing shots as it does for direct shots. So if it is changed to abort when canTargetUnit returns false, then it will abort any arcing shot that doesn't have direct line-of-sight, even if the shot could hit.

In some sense, this make sense - because the soldier can't see their target anyway. They aren't sure that they can hit it. And if the player wants, they can take the risk by using ctrl to force the shot. Nevertheless, it's probably an unwanted effect.

My suggestion is to keep my original fix; the one in the first post. It doesn't correct the 'behind-the-wall' case; but it does fix many cases and it doesn't have a problem with arcing shots. In fact, it's probably even better for arcing shots because it will have the soldier aim at the middle of the unit rather than aiming a corner of the unit (which is what it would have done in the past, because that's the last place checked for direct line-of-fire).

Ideally, "canTargetUnit" would take into account whether or not the shot is arcing, and return the correct result accordingly. But I'm getting impression that most people don't care about this stuff anyway... so I think my original fix is good enough for the time being.

I'd be interested to know if anyone has any thoughts about what I'm talking about. Have people noticed the bug? Does the fix make sense? Does anyone care about this kind of stuff?

171

XPiratez / Re: Balance of bows and bullets

« on: July 02, 2016, 10:24:22 am »

That could work. But I think I'd lean towards just having normal accuracy scaling, but with ~100% instead of 130%. (That's a very big drop in accuracy; but its still higher than most guns, and combined with the bug fix we'll probably still get more hits than we're currently getting anyway.)

172

XPiratez / Re: Balance of bows and bullets

« on: July 02, 2016, 01:57:59 am »

That's probably the best way; and I do have some pretty nice commit comments to go with my patch... but I kind of feel a bit silly having a whole fork on github just to post a couple of bugfixes. Maybe I'll set up a fork if I decide to work on it some more, but for the time being I think I'll just follow 'option 2' on [urlhttps://openxcom.org/forum/index.php/topic,181.0.html]this page[/url], in which SupSuper suggests posting a patch on the development forum.

--

Incidentally, having played a bit with the parabolic collision fixed - I think I can now return to my original suggestion: I reckon we can afford to reduce the accuracy of bows a bit. Maybe they don't _need_ a nerf for balance; but I just think it's weird that it's far easier to hit things with a bow than with pretty much anything else.

173

Programming / Re: Minor bugfix for checking line-of-fire

« on: July 01, 2016, 08:54:53 am »

On closer inspection; more works is needed. My fix only fixes the problem in some cases. The problem still exists in other cases. I'm attaching another save file which demonstrates the problem. (Again, this save is from xPiratez.) From the save, command Athletic Walker to shoot at the alien above her. She'll shoot, and always miss. Debugging shows that the game never expected her to hit; and in fact even with perfect accuracy she'd be shooting into a wall. There is no line of fire; and so the game should tell us this rather than letting her take the shot. The reason the game allows it in this case is that targeting the square directly behind a wall is how the player is meant to shoot at a wall - and so the game thinks that the player actually wants to shoot at this wall.

I'll post again if I discover more.

[edit]
Ok. I was mistaken about it being difficult to just abort based on the result of canTargetUnit. This fix should work fine, as far as I can tell. (The other change is no longer needed, but I'd probably choose to keep it anyway.)

Code: [Select]

--- a/src/Battlescape/ProjectileFlyBState.cpp
+++ b/src/Battlescape/ProjectileFlyBState.cpp
@@ -223,7 +223,12 @@ void ProjectileFlyBState::init()
  }
  else
  {
- _parent->getTileEngine()->canTargetUnit(&originVoxel, targetTile, &_targetVoxel, _unit);
+ if (_parent->getTileEngine()->canTargetUnit(&originVoxel, targetTile, &_targetVoxel, _unit) == false)
+ {
+ _action.result = "STR_NO_LINE_OF_FIRE";
+ _parent->popState();
+ return;
+ }
  }
  }
  else if (targetTile->getMapData(O_OBJECT) != 0)


174

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.

175

Programming / Re: How to be a horrible programmer: OpenXcom coding guidelines

« on: July 01, 2016, 02:43:48 am »

I've noticed that most functions declare all their variables at the start of the function, and initialise them later.

I'm a firm believer that variables should be initialised at the same time that they are declared (and that they should only be declared when it possible to initialise them).

I'm not suggesting that we go through all the code and change all that stuff, but I am wondering if the start-of-function declarations are a deliberate style decision, or just a historical artefact. ie. would anyone be upset if some declarations moved to the middle of functions when the code was updated?

176

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


177

XPiratez / Re: Balance of bows and bullets

« on: June 30, 2016, 06:18:01 am »

ok. I've found the bug.
Here is a patch.

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;
+ result = V_OUTOFBOUNDS; https:// why??
  }
- 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));
  }

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.


Aside from that fix, here are a couple of other unimportant changes that I've made. Take them or leave them as you see fit.


---
Undefined 'floor' in CraftWeapon.cpp.

Code: [Select]

diff --git a/src/Savegame/CraftWeapon.cpp b/src/Savegame/CraftWeapon.cpp
index 2b952c4..b2e51c0 100644
--- a/src/Savegame/CraftWeapon.cpp
+++ b/src/Savegame/CraftWeapon.cpp
@@ -17,6 +17,7 @@
  * along with OpenXcom.  If not, see <https://www.gnu.org/licenses/>.
  */
 #include <algorithm>
+#include <cmath>
 #include "CraftWeapon.h"
 #include "../Mod/RuleCraftWeapon.h"
 #include "../Mod/Mod.h"
@@ -168,12 +169,12 @@ CraftWeaponProjectile* CraftWeapon::fire() const
  */
 int CraftWeapon::getClipsLoaded(Mod *mod)
 {
- int retVal = (int)floor((double)_ammo / _rules->getRearmRate());
+ int retVal = (int)std::floor((double)_ammo / _rules->getRearmRate());
  RuleItem *clip = mod->getItem(_rules->getClipItem());
 
  if (clip && clip->getClipSize() > 0)
  {
- retVal = (int)floor((double)_ammo / clip->getClipSize());
+ retVal = (int)std::floor((double)_ammo / clip->getClipSize());
  }
 
  return retVal;

---
Marginally reduced code duplication and straightened lines for collision detection. (Unimportant house-keeping changes.)

Code: [Select]

https:// Never mind. I've discovered a minor mistake in this change, and rather than taking the time to fix it and repost it I think it's better to just keep the current code.

----
Named defined value instead of 'magic number'. (This change doesn't do anything at all; but I highly recommend it. There are stacks of 'magic numbers' like this in the code, and they really should be phased out whenever possible to improve clarity and reduce the likelihood that future changes will break something.)

Code: [Select]

diff --git a/src/Battlescape/ProjectileFlyBState.cpp b/src/Battlescape/ProjectileFlyBState.cpp
index 7101e35..0d84d1e 100644
--- a/src/Battlescape/ProjectileFlyBState.cpp
+++ b/src/Battlescape/ProjectileFlyBState.cpp
@@ -564,7 +564,7 @@ void ProjectileFlyBState::think()
  }
  }
 
- if (_projectileImpact == 4)
+ if (_projectileImpact == V_UNIT)
  {
  BattleUnit *victim = _parent->getSave()->getTile(_parent->getMap()->getProjectile()->getPosition(offset) / Position(16,16,24))->getUnit();
  if (victim && !victim->isOut() && victim->getFaction() == FACTION_HOSTILE)


---

[edit]
You probably don't need the "why?" comment in the bugfix...   But I'd consider removing that `if` block. In fact, I'm going to delete it now, and then just keep playing my game. I don't expect any negative side effects; but I do expect it might be marginally easier to fire arrows from the ground into enemies in high-up windows.

178

XPiratez / Re: Why tho

« on: June 30, 2016, 01:22:06 am »

Its intentional in the sense that your starting bus is pretty low tech, and there are a lot of things it can't do. I doesn't have global reach; it doesn't have any weapons; its very slow; it has low carrying capacity...

Not being able to reach the progrom is a side effect of this. It isn't "intentional" in the sense that the game isn't deliberately putting in progroms which you can't reach; but it is a known and normal part of the game now. (And as ThatDude points out, you will not be penalised for missing the progrom in the early parts of the game. So you've got plenty of time to get a longer range ship before it really matters.)

179

XPiratez / Re: Balance of bows and bullets

« on: June 29, 2016, 06:35:26 am »

It would be great if this was fixed, Karadoc. X-Com tactical engine is ingenious, but it has a few bugs like this.

Ok. I've started looking into it now. I haven't spotted anything that's obviously wrong. The algorithms make sense, it looks like it should probably work. But there are a couple of things that I think are a bit strange. For example, it seems to forbid projectiles from hitting their target on the way up. They can only hit on the way down. I don't know why they'd make a rule like that - but I don't think its the source of our problem.

Anyway, I've got a couple of ideas and checks that that I'd like to do, but unfortunately I'm having trouble getting the thing to build.

I've used cmake to create mingw makefiles, but it's telling me

*** No rule to make target 'C:/tools/MinGW/lib/libSDL_mixer.dll.a -lwinmm'

It seems to think that libSDL_mixer.dll.a -lwinmm is a single thing, whereas to me that's meant to be two separate libraries. (And the SDL stuff does exist in that path.) I then manually edited the makefiles to fix it so that SDL_mixer and winmm were treated separately. That got it a bit further along, but then there were a bunch of undefined symbols in the final linking. So that's where I'm currently at. I'll try wrestling with it again another time.

I am interested in game mechanics, logic, and coding; but trying to fix build problems related to dependences and linking is frustrating for me. I suppose it is for everyone. I'd rather not have to completely delete all my compilers and libraries and everything just so that I can follow someone else's build instructions line-for-line; but that's what it might come to.

[edit]

I've successfully worked through the quagmire of linking problems. Just in case someone else has similar issues, I'll briefly describe what I did.

Firstly, my original problem was caused by what looks like a mistake in CMakeLists.txt.

Line 442 of CMakeLists.txt says

Code: [Select]

    set ( SDLMIXER_LIBRARY "${SDLMIXER_LIBRARY} -lwinmm" )
Presumably that's wrong. I don't see how that could ever work correctly. That's what makes "make" think there is a dependency with a weird two-part name which it doesn't know how to build. So I got rid of that line.

Secondly, there were a stack of missing functions in linking phase. I don't really know what belongs to what, so I added stuff based on guesswork and internet searches until everything worked. I ended up with this:

Code: [Select]

#(original) target_link_libraries ( openxcom ${system_libs} ${SDLIMAGE_LIBRARY} ${SDLMIXER_LIBRARY} ${SDLGFX_LIBRARY} ${SDL_LIBRARY} ${OPENGL_gl_LIBRARY} debug ${YAMLCPP_LIBRARY_DEBUG} optimized ${YAMLCPP_LIBRARY} )
target_link_libraries ( openxcom ${system_libs} ${SDLIMAGE_LIBRARY} ${SDLMIXER_LIBRARY} -lwinmm ${SDLGFX_LIBRARY} ${SDL_LIBRARY} ${OPENGL_gl_LIBRARY} debug ${YAMLCPP_LIBRARY_DEBUG} optimized ${YAMLCPP_LIBRARY} -lz -lpng -lvorbisfile -lvorbis -logg -limagehlp -lDbghelp )
Thirdly, after all that, it finally compiled - but I discovered that I was actually using the wrong branch. I was on the master branch whereas I should have been on `oxce2.9-plus-proto`. I tried stashing my changes to apply them to the correct branch, but the branches were too different for the merge to work. So I had to do them again manually.
(Also, in latest version of oxce2.9-plus-proto, savegame/CraftWeapon.cpp is missing `#include <cmath>`, which it needs for std::floor.)

And finally, with the correct branch, successfully compiled and linked, I found that the game ran really slowly. I guess it's because it compiles a debug version by default. So I told cmake to make a 'Release' version. That fixed the speed issue. I'm just mentioning that because it occurs to me that some of the stuff I added to the linker was probably only needed for the debug version; such as -Dbghelp.

In any case, I've finally got the thing built and ready to play. My intention is to just tweak things that I think look suspicious, and play through my usual game without any particular focus on testing.

As I said before, I haven't spotted any obvious mistakes, but there are a lot of things I would have done differently if I was writing it myself. So I'll start by just changing minor things and see if it makes any difference. I'll let you (someone) know if I learn anything important.

180

XPiratez / Re: [MAIN] XPiratez - 0.99 - 7 Jun - First Impressions

« on: June 27, 2016, 02:38:40 am »

The air combat is anything but balanced, but at least it offers several alternatives, several challenges and some payoff (I hope). Fighters armed with dual Lancers used to dominate the game, as it's the longest-range weapon. Then the idea of 'tank' appeared, which is quite natural concept for jrpg-like model of air combat (a skewed one, I'd say, since 1 ship can protect 3 others).
However, if you comment on the air combat, always clarify what diff level are you using. At highest diff enemy ships, especially the military ones, can dish out at least thrice as much punishment as on the easiest diff (re-fire rate for Battleship and many of its ilk is 23-46 sec on easiest diff, and - if my calcs are correct - 7-14 sec on the highest diff, if OXC is faithful to the original in that matter).

(I'm playing on the second hardest difficulty.)

I'm currently thinking that the need / payoff of air combat might be too small in the early to mid game. A large research and money investment is required just to get off the ground, and missiles and heavy weapon ammo is expensive to supply. If you do shoot down some ships, and successfully complete the ground assaults, the resources do pay for themselves - but that's only if you have the ability to do the missions and claim the rewards.

I'm finding that I've got plenty of missions without needing to shoot down anything. There are lots of landed ships, enemy bases, progroms, and mini-missions. My ground forces are stretched (I've got about 30 injured soldiers, and 10 more ready to fight); and my vaults are already full of loot. I don't need the additional resources from the crashes, and I don't want to build more barracks to hire more hands to do the missions anyway.

In the previous versions, early-game air combat was almost a necessity. It was possible to shoot down ships right from day 1; and since there were no mini-missions, the crashes were a major source of income. It isn't like that now. Air combat is an expensive and risky optional extra whose payoff is dwarfed by what we're getting for free. Shooting down peacekeeping missions is kind of attractive, but those missions are usually run by fairly strong enemy ships - and so it isn't a strong option until we get better air-combat tech anyway.

I've got one suggestion which may help adjust that balance. The suggestion is to give successful ground assault missions on landed ships a chance of generating crackdowns. (ie. if you defeat all enemies on a landed ship, the ship's faction may choose to do a crackdown mission.) I see three main reasons for making this change:

• It makes sense from a role-play point of view. Destroying the craft and crew of a landed ship is just as damaging as shooting it out of the sky; so a crackdown is equally warranted.
• It incentivises shooting down civilian ships in the early game rather than risking crackdown from landed factional ships.
• It creates a need to shoot down crackdown Sentry ships when they do come looking for you.

On the other hand, it would make the early game a bit harder. If early-game crackdowns are going to be a problem for balance, then perhaps the crackdown chance could apply only to medium or larger ships; or perhaps they should only attempt a crackdown if the player's reputation is above a certain threshold.