OpenXcom Forum
Modding => Released Mods => XPiratez => Topic started by: karadoc 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?
-
Bows are not overpowered!! I am saying no to another nerf of bows in advance!!
-
Let me just clarify that I'm not trying to advocate for a nerf. I'm just saying that my current style of play makes me wonder if a nerf might be warranted, because my bow soldiers are outclassing my other soldiers. (ie. I've been using bows with far greater success than I expected, and I'm wondering if bows are too good, or if its just that I'm using bow-friendly tactics.)
I'd be ok with a nerf, but what I'm really looking for is a discussion.
-
Bows do very much favor a certain play style. One that just happens to be one the more abuse-ably effective ways to play given the limitations of the ai. Bows are actually reasonably well balanced on an even field vs other weapons. The problem is that the game itself is not an even field given how it works. The best way to avoid expensive casualties with the gals is to NEVER be seen at all. 1 day per lost hp is punishing. Armor will never completely and reliably protect a gal from harm because of the 0-200% dmg function. So how do we not get shot at? Abuse squadsight and vision because the ai is a retard when it comes to getting vision.
-
Fact 1:
With enough experience, you can always find a weak spot in the AI.
Fact 2:
If there was no weak spot, you would always lose... which would probably happen in real life... but is not desired in a computer game.
My logical conclusion:
If you find a weak spot... enjoy it for a short time... and then stop abusing it if you wish to still enjoy the game.
-
I feel that bows are strong in that they combine the best characteristics of both sniper-style weapons and arcing-shot weapons, and are thus excellent at filling the roll of single-target long-range fire support. I also think they are balanced by the fact they require four stats to be high to use well - TUs, stamina, throwing accuracy, and strength, and the fact that without AoE, arc-firing can be dodgy at certain angles. Against armor though, there are much better tools - grenades, mortars, sniper gauss with high firing accuracy.
Remember your gals are uber-mutants, and anything that scales off of stats properly will be strong - just imagine the type of bow they would be drawing with all their strength, and it's no wonder weapons made for pureblood humans pale in comparison.
-
Remember your gals are uber-mutants, and anything that scales off of stats properly will be strong - just imagine the type of bow they would be drawing with all their strength, and it's no wonder weapons made for pureblood humans pale in comparison.
And that's the crux of it! The bows designed by the brainers are monstrous things that take advantage of Uber physiology. They are not the bow that a typical human would use (although they also don't have pulleys, so maybe modern bows could be similar). The bows in XPiratez would be harder to draw than anything a normal human could sustain doing, but the gals are stronger and recover faster, so they can do it.
By opposition, the guns you have at the beginning are weak human guns. They have to be light, because most humans don't have the strength of an Uber. Once the brainers design their own gun, you usually see a significant increase in firepower, and weight (again, taking advantage of the gals' strength).
So in a sense, you start the game and use primitive weapons (throwing weapons, bows, spears), because you are taking advantage of the gals' physique. They are stronger and faster than humans, so they use weapons that would be useless to humans, but are useful to them. Then eventually you start using your brains too, and develop weapons that are even better suited.
The only "problem" is accuracy: A long distance bow shot at a single moving target should be really hard to achieve. You have to consider the arcing trajectory which is more difficult than a straight line. The arrow doesn't travel as fast as a bullet, so the target has the possibility to move more. The increased travel time and volume of the arrow also make it more vulnerable to winds affecting the trajectory. And then, for long distance shots, no matter how fast the arrow leaves the bow, on the descent from the peak of the trajectory, the arrow can only go at terminal velocity. You can't pull harder to make it "fall faster", although you could make denser arrows requiring more pull so they reach a higher terminal velocity.
That's why I was advocating for a ranged based power reduction instead of accuracy reduction (arcing non-AoE weapons have game engine hit computation problems, which is overcompensated by having very high accuracy). Make bows a great medium range weapon (20-25 tiles), but not great sniper weapons (25+ tiles, which used to be out of direct sight)
-
The only time arced shots are used with bows is when you are providing bombardment fire against an enemy army.
Otherwise bows are operated in a similar horizontal fashion as guns, though with more heavy adjustments for gravity.
-
It's a good point about ubers being suited to different weapons than humans. (Although the bows are relative strong even when the girls are still weak.) I generally agree with Arthanor's thoughts on this.
I'm unaware of the arcing accuracy problem in the game. Is it something to do with hit-detection not working correctly? Whatever it is, I presume it is fixable...
-
I'm unaware of the arcing accuracy problem in the game. Is it something to do with hit-detection not working correctly? Whatever it is, I presume it is fixable...
After shooting from a bow, look at the hit log (Ctrl+H)... from many angles, all shots will just always miss.
-
After shooting from a bow, look at the hit log (Ctrl+H)... from many angles, all shots will just always miss.
Ok. I've been doing this a little bit recently; and I have noticed that sometimes shots that appear to hit have actually missed. (I've also noticed that some shots say "0", which I presume means a zero damage hit. I sure could have used that info in my first playthrough when I was trying to work out whether particular enemies have high resistance or just heaps of health!)
I presume this is a bug... and I expect that it's possible to fix. Is this something people want fixed, or is it so entrenched that people are use to it and the game is balanced around it and so it should just be left alone.
I'll probably have a few spare hours up my sleeve next week, and I could have a go at fixing it if there is interest. (I haven't looked at the code for this game, but I know a bit about programming, and about projectile motion. So I might be able to fix it.)
Incidentally, I suppose that this problem also affects acid flasks... which might explain why their effect often seems lacklustre. (In my first playthrough, I once threw a heap of acid flasks at an armoured car so that I'd have a better chance of killing it with auto-fire boarding gun & other weapons. The strategy was surprisingly ineffective.) I reckon acid could afford to be more accurate or more powerful, and bows could afford to be slightly less accurate (but probably not less powerful).
-
It would be great if this was fixed, Karadoc. X-Com tactical engine is ingenious, but it has a few bugs like this.
-
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
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:
#(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.
-
Thanks for the effort and best luck!
It's a long shot, but maybe the issue is not with the projectile but the target? Something with being hit from above? No vanilla weapon does that.
-
An issue with the target object would certainly make sense to me. Given the peculiarities of invisibility(ie hacking the models) increasing in complexity at differing elevations.
-
ok. I've found the bug.
Here is a patch.
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.
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.)
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.)
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.
-
I think proper way of doing bug fix is upload it to github (as your fork) and after that create pull request to supsuper master branch: https://github.com/SupSuper/OpenXcom/
-
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.
-
Perhaps something along the lines of the scaling for snipers? Such a manner would reflect that a poorly skilled archer can't hit squat but a master will manage quite impressive feats. Perhaps with not so extreme a curve given how early bows are presently placed in tech progression.
-
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.)
-
The high accuracy of bows reflects the reality in which starting troops have Throwing in the 40-50 range. Even x150% (hunting bow) this only gives acceptable 75% acc. This, in turn, is to make grenades less-than-100%-sure (their accuracy is multiplied by the fact they target a tile, not an unit). Only with Gym spamming you will easily get Throwing scores in 75-85 range.
'Sniper' scaling is used for throwing knives and ninja stars, so they become deadly only with Throwing exceeding 80-ish. In part this coincides with the plans to add some throwing-dedicated armors.
However, if this bow patch is pulled into the main build, accuracy drop of all bows by circa 1/5th is a good idea.
-
However, if this bow patch is pulled into the main build, accuracy drop of all bows by circa 1/5th is a good idea.
I will most probably take this into my fork.
Currently I am in process of merging it with oxce3.0... which will take "forever" since I got a conflict basically on every single file :(
After it's done, I fully agree with accuracy drop, makes sense.
-
I will most probably take this into my fork.
Currently I am in process of merging it with oxce3.0... which will take "forever" since I got a conflict basically on every single file :(
After it's done, I fully agree with accuracy drop, makes sense.
I have one suggestion that save me couple of days of work:
https://stackoverflow.com/questions/9776527/merging-without-whitespace-conflicts
https://stackoverflow.com/questions/18131515/how-can-i-see-a-three-way-diff-for-a-git-merge-conflict
Without this two I would probably do rage quite and refuse to merge master branch.
-
Undefined 'floor' in CraftWeapon.cpp.
It compiles just fine both in vs2015 (windows) and in mingw/mxe (linux) for me.
But I've added that include if it helps.
-
It compiles just fine both in vs2015 (windows) and in mingw/mxe (linux) for me.
But I've added that include if it helps.
It does help. Thanks.
I'm surprised that it compiles fine for you without including <cmath>. The functions you are using are definitely in the cmath library, so my best guess is that something else you are including just happens to include cmath in those other systems, but not on my system. I'm compiling it on Windows with mingw (the nuwen distro (https://nuwen.net/mingw.html)).
In your recent updates, there have been a couple of other similar cases. For example, in the most recent build I'm getting compiler error:
\OpenXcom\src\Savegame\Soldier.cpp:608:15: error: 'ceil' is not a member of 'std'
which again is fixed by including <cmath>. (It also happened with the previous version, but I can't remember which source file has the problem.)
In any case, thanks for including the parabolic collision fix in your version. It's good to see my work actually get used. I was happy to contribute, but it's a bit disheartening for me when I put a bit of work into something, only to have it ignored. There seems to be no interest in the arcing shot fix (https://openxcom.org/forum/index.php/topic,4726.0.html), or my line-of-fire fix (https://openxcom.org/forum/index.php/topic,4729.0.html) on the development forum, and so I'm not inclined to try to fix anything else in the base game.
I'm pleased that the arcing collision fix is now in xpiratez; and I guess I'll just continue to recompile my own .exe with my line-of-fire fix for each version. (At least that change doesn't affect the balance of the game!)
-
Don't feel too discouraged. Your fixes are great. Most people just don't have the engine mechanics knowledge to notice the problems even exist. I mean I don't think even Meridian fully realized the issue till he made the hit log feature.
-
Don't feel too discouraged. Your fixes are great. Most people just don't have the engine mechanics knowledge to notice the problems even exist. I mean I don't think even Meridian fully realized the issue till he made the hit log feature.
Hit log was created, because I noticed the issue, not the other way around :)
In your recent updates, there have been a couple of other similar cases. For example, in the most recent build I'm getting compiler error:
\OpenXcom\src\Savegame\Soldier.cpp:608:15: error: 'ceil' is not a member of 'std'
which again is fixed by including <cmath>. (It also happened with the previous version, but I can't remember which source file has the problem.)
OK, just post them here, I'll fix it.
In any case, thanks for including the parabolic collision fix in your version. It's good to see my work actually get used. I was happy to contribute, but it's a bit disheartening for me when I put a bit of work into something, only to have it ignored. There seems to be no interest in the arcing shot fix (https://openxcom.org/forum/index.php/topic,4726.0.html), or my line-of-fire fix (https://openxcom.org/forum/index.php/topic,4729.0.html) on the development forum, and so I'm not inclined to try to fix anything else in the base game.
I'm pleased that the arcing collision fix is now in xpiratez; and I guess I'll just continue to recompile my own .exe with my line-of-fire fix for each version. (At least that change doesn't affect the balance of the game!)
Last time I checked, the line-of-fire patch was not finished... is it finished and tested now? And if yes, where can I find the latest version? Also, could you add a few words what has been changed and why?
It's good to see my work actually get used.
I know exactly what you mean.
-
or my line-of-fire fix (https://openxcom.org/forum/index.php/topic,4729.0.html) on the development forum, and so I'm not inclined to try to fix anything else in the base game.
You've made that work? Man, why did you keep quiet about this! It's a sorely needed feature!
Also, your contribution was likely doomed as soon as you mentioned X-Piratez :) Jk; the devs have their own visions about OXC and it's normal that they ignore contributions they don't feel would fit. That they don't communicate their decisions? Well, they don't want to burn the bridges, I guess? Surely your fixes remove some of 'vanilla experience'. My point is, the devs never said they will accept all, or any, contributions. I think this, by itself, is understandable.
-
The bow fix was awesome and I am very much looking forward to a LoF fix too. Nothing as frustrating as seeing a soldier land 20/20 shots in a doorframe when told the shot has 50% chance to hit and being allowed to shoot which implied that there is a line of fire.
Fixing that would definitely improve thinges. I don't care for "vanilla experience" when it is frustratingly buggy. Don't give up man! We need you people who can make the engine better!
-
My line-of-fire fix doesn't "fix" the percentages. You can still miss "100%" shots; and in fact, there are still some 100% shots which miss most of the time. (This happens when there is only a very very narrow line of fire. 100% shots still have a small amount of random drift. So if there is only a few voxels of target visible to hit, then you're still likely to miss.) What it does fix is that shots with no line of fire at all will always be reported as having no line of fire.
Here's the fix I'm currently using. It perfect in the way it handles arcing shots, but to be honest, the way arcing shots work is still a bit haphazard, and so this is about as good as we're going to get without doing a heap of other changes. (And there are no impossible shot problems with arcing shots anyway. It's just that the precise voxel aiming is a bit weird sometimes.)
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..c62687f 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;
}
@@ -2632,7 +2635,7 @@ int TileEngine::calculateLine(const Position& origin, const Position& target, bo
result = voxelCheck(Position(cx, cy, cz), excludeUnit, false, onlyVisible, excludeAllBut);
if (result != V_EMPTY)
{
- if (trajectory)
+ if (trajectory != nullptr)
{ https:// store the position of impact
trajectory->push_back(Position(cx, cy, cz));
}
@@ -2682,7 +2685,7 @@ int TileEngine::calculateLine(const Position& origin, const Position& target, bo
result = voxelCheck(Position(cx, cy, cz), excludeUnit, false, onlyVisible, excludeAllBut);
if (result != V_EMPTY)
{
- if (trajectory != 0)
+ if (trajectory != nullptr)
{ https:// store the position of impact
trajectory->push_back(Position(cx, cy, cz));
}
Here's the message I typed into my own commit
commit a0d17322e4a4344eca0cefc7c5eb811d86038e06
Author: karadoc <karadoc@gmail.com>
Date: Mon Aug 1 19:40:19 2016 +1000
Fixed line-of-fire problems
TileEngine::canTargetUnit correctly determines whether or not a
character has line-of-fire to a target, but this information was not
being correctly used. The result was that the game often behaved as
though a character has line-of-fire when they actually didn't.
This is now fixed so that the return value of TileEngine::canTargetUnit
is the primary way of preventing shots with no line-of-fire.
I think I explained the problem in a bit more detail in the other forum (https://openxcom.org/forum/index.php/topic,4729.0.html); but the gist of it is that canTargetUnit was only being used to determine precisely where a soldier should aim. If there was no line of fire, then usually the shot where they were aiming would make it obvious that they weren't going to hit what they were aiming for. But problem was that at the point in the code where the game decided whether or not to take the shot, there was no way of knowing what the player was actually trying to hit; and so sometimes the game would allow the player to shoot under the assumption that they had deliberately targeted a wall or an empty tile.
My change makes the game check for line-of-fire when it _does_ know what the player was trying to aim at; and so it can correctly abort impossible shots.
One side point is that the same line-of-fire stuff is used to determine where arcing shots are to be aimed at. Arcing shots don't need a direct line-of-fire, but the line-of-fire is still used to determine which voxel they should target. So the change I made at the end of canTargetUnit is just to make sure that arcing shots will target the centre of a unit if there is no direct line of fire whereas previously they would target somewhere on the unit's soldier or something like that - which is an illogical thing to do; and probably results in unnecessary misses.
To be honest, it might be better if arcing shots just always aimed at the centre. I don't think it is helpful or necessary for them to aim at a voxel with direct line-of-fire. The only reason I didn't change that is that I generally like to fix problems with as few side-effects as possible.
The 'nullptr' changes at the end don't actually have any effect whatsoever. I just like to fix that stuff when I see it, for good code hygiene. There was a time when `if (pointer != 0)` was standard practice; but that time is behind us (since nullptr was introduced in the 2011 version of C++).
OK, just post them here, I'll fix it.
There's the one you fixed already in CraftWeapon.cpp (I also changed `floor` to `std::floor`, but it works either way. I suppose there must be a `using std` somewhere else in the code.). The following two files also need the same treatment. (i.e. #include <cmath>)
src/Mod/RuleDamageType.cpp
src/Savegame/Soldier.cpp
-
Thanks for the reply, I'll have a look, see what I can use.
As for pointer != 0, I am still using it because I want to backpatch some of my changes to vanilla and they are still in the pre-2011 era.
And the cmath will be fixed too.
-
The 'nullptr' changes at the end don't actually have any effect whatsoever. I just like to fix that stuff when I see it, for good code hygiene. There was a time when `if (pointer != 0)` was standard practice; but that time is behind us (since nullptr was introduced in the 2011 version of C++).
I prefer too C++11 stuff (other wise I would not switch to it) but there third option: `if (pointer)`.
There's the one you fixed already in CraftWeapon.cpp (I also changed `floor` to `std::floor`, but it works either way. I suppose there must be a `using std` somewhere else in the code.). The following two files also need the same treatment. (i.e. #include <cmath>)
`floor` is C function and `std::floor` C++ function.
-
`floor` is C function and `std::floor` C++ function.
I did think of that, but I thought that the C function would only be defined in <math.h> (or stdlib.h, or something like that). But I think you're probably right that it was the C version rather than an using std thing.