OpenXcom Forum
Contributions => Programming => Topic started by: 7Saturn on November 25, 2015, 07:51:21 pm
-
Well, I know, last time I opened up a debate about this aspect, it turned warboy a little bit angry. However, I think it still needs some addressing.
It's about hitting apparently impossible targets, while the engine doesn't seem to recognize them as impossible to hit. I created such a situation, shown in the attached image. You can reproduce them like that, but there are many other situations, that act like this one.
If you want to take out the snakeman in the right upper corner of the room with the soldier kneeling in front of the door, you won't hit it from that position, regardless of kneeling or standing and regardless of your accuracy or used non explosive weapon. Even with Accuracy 180+ you won't succeed in hitting the snakeman from the door, unless you use a weapon with splashdamage. There's simply no way in hell, to hit a unit in the right upper corner from the position at the door, inside the room. However, the engine doesn't seem to recognize that and let's you empty every clip you have, unless you realize, that you simply won't hit the target this way.
Last time I had this discussion, I wasn't sure if I just wasn't able to express my thoughts properly or not. But the situation in the picture seems to be quite reliably acting in the way I described above and is easily created. And the result is rather self explanatory. Can someone confirm the disability to hit a unit in this specific constellation? (I'd give you the savedgame, however it's heavily modded, so most players couldn't do a lot with it anyways...)
-
Well i do have a similar situation like this, recorded on video here(dropboxlink) (https://www.dropbox.com/s/wwu1jo15r1jgucw/aimerror.mp4?dl=0)
Savegame attached.
-
A "voxel screenshot" (F10 key, needs debug mode active) would be helpful to show what your unit actually sees (and how the chair is in the way)
It's what I did in this older post, to illustrate the common case of two units in diagonal positions, with a single wall covering "half" of the line of sight
https://openxcom.org/forum/index.php/topic,3672.msg46492.html#msg46492
-
Maybe it's because of the original sin - "see by eyes, shoot from shoulders". But indeed, such situations happen with irritating - even predictable - regularity, like firing upon someone on the mountain-top - his head is visible, but your gun will never hit it even if you shot a 100 times with 200% accuracy. Or shooting across some bushes on the jungle map, and on and on.
-
Volutar described those situations and how the algorithm used for aiming (pick visible point that is closest to middle of body) fails in this case, and how he could make it aim at the middle of the visible target instead to help. But there was a huge argument stemming from misunderstandings and I don't think anything was ever considered.
But in this case, you aim at the point closest to the center, you fire from your center, and with the minimal deviation of shots with high precisions, you can't hit. If you have lower accuracy, the added deviation could actually make you hit some times (weird!) and, if we had volutar's algorithm, you would likely hit.
There's also this cool thing where OpenXCom units used to shoot from the hand that carried the weapon (so you could put a weapon in the right hand, hug a wall to your left, and an alien would likely hit the UFO wall on his right with his right handed weapon whereas you could return fire properly with your left hand), but it was deemed bad for the complicated TftD maps and OpenXCom returned to the original "fire from the middle" mechanic regardless of hands.
-
Voxelscreenshot attached.
Represents the voxelview of the soldier shooting the muton in the Video i linked from my dropbox.
First screenshot is kneeled down (problem shown in the video occurs).
Second screenshot is standing (no problem).
-
Maybe it's because of the original sin - "see by eyes, shoot from shoulders". But indeed, such situations happen with irritating - even predictable - regularity, like firing upon someone on the mountain-top - his head is visible, but your gun will never hit it even if you shot a 100 times with 200% accuracy. Or shooting across some bushes on the jungle map, and on and on.
Yeah those can occur quite on a regular scale. Especially if you are fighting in a lot of mountain terrain, were those situations happen more often.
-
Here's mine. And yes, of course there's a chair in the way, it was quite obvious, that this seems to be the problem. :P Don't get me wrong, I know, where the problem is coming from. And it's OK, that there's this obstacle. But the engine doesn't seem to agree on that, as there is that exceptionally small possibility to hit the target. So in order to avoid wasting rounds (and turns), you will really really have to know, whether the engine will kick your but like this, or not, in advance. Imagine a new player, not aware of this phenomenon. OK, forget the new player, think about how annoying it is to veterans... It's simply an unnecessary problem for players. It's like: When new UFOs appear in this special order (or over this special pixel on the geoscape), you will not be able to down them, even if you have 100 Avengers firing their plasma guns empty. First, you will have to know that, and second, it'd still drive you nuts.
-
Volutar described those situations and how the algorithm used for aiming (pick visible point that is closest to middle of body) fails in this case, and how he could make it aim at the middle of the visible target instead to help. But there was a huge argument stemming from misunderstandings and I don't think anything was ever considered.
It's a shame that it never was even considered. Since aiming on the visible part is usually the natural thing you would assume from a shooter with a dircet to hit fire weapon (like a Rifle e.g.).
I consider this a bug for myself, which i want to have fixed in the future.
But in this case, you aim at the point closest to the center, you fire from your center, and with the minimal deviation of shots with high precisions, you can't hit. If you have lower accuracy, the added deviation could actually make you hit some times (weird!) and, if we had volutar's algorithm, you would likely hit.
Thats excactly the point.
Maybe it's because of the original sin - "see by eyes, shoot from shoulders". But indeed, such situations happen with irritating - even predictable - regularity, like firing upon someone on the mountain-top - his head is visible, but your gun will never hit it even if you shot a 100 times with 200% accuracy. Or shooting across some bushes on the jungle map, and on and on.
Indeed lets change it.
-
It's a shame that it never was even considered. Since aiming on the visible part is usually the natural thing you would assume from a shooter with a dircet to hit fire weapon (like a Rifle e.g.).
I consider this a bug for myself, which i want to have fixed in the future.
Exactly that. I mean, it's not counter-strike, where it's helpful to try to shoot through walls... Either aim at visible parts or make it a no-LOF-case, where the engine simply refuses to fire at that position. Otherwise it's just messing around with the player. Or at least, give the player something like in ufo2000, where you can make the game make you show the trajectory a straight aim would take.
-
Why not make it as simple as "if you can see it, then you can hit it"? I.e. just roll a dice for any transparent obstacles, when dice fails, hit the obstacle instead of target.
-
Why not make it as simple as "if you can see it, then you can hit it"? I.e. just roll a dice for any transparent obstacles, when dice fails, hit the obstacle instead of target.
This is interesting low-cpu use solution, but not neccesary IMO - all it would take would be to place "seeing pixel" and "firing pixel" in the same exact position in space. Well it wouldn't heal all the problems, but at least some of them. It'd be awesome if it was possible to shift the firing/looking point to the side, for example, by entering a command, or automatically - this would erase another stupid situation, where when you stand next to a corner, you cannot shoot but can be shot at. In normal world, the soldier hugging the corner has an advantage, not the other way around.
-
can see == can shoot is too simplistic because there are many times when you can't see a unit, but you are allowed to shoot : darkness, smoke cover, 20-tile daytime range...
However, I don't understand why the game uses two different systems for determining :
1) is shooting allowed (yes/no)
2) actual trajectory if you fire or force-fire
The infuriating cases are when 1 says "no problem" while 2 aims at an obstacle
-
It's a detail: It is in principle possible to hit the target. That's important to understand, why the engine isn't refusing fire. However, as it's blocked to a great extend/in an unfavorable way, it's practically impossible to hit, anyways. That's the core of the problem. These nearly-impossible targets however, are greatly annoying, as the player is simply used to accept the binary decision of the engine: If the engine allows to fire at the target, it's as likely to it it as the accuracy permits. In fact the accuracy is down to almost zero, in these situations, which you can't foresee without a big deal of experience with it. That's the problem. It behaves in a completely atypical manner. But there are solutions, which should make this problem much more rare (limited to situations, where the target actually is almost 100% covered by obstacles). E. g., aim for the center of the biggest visible part of the target.
-
What if there was a multiplier added to the accuracy % based on how much alien is visible. Sectoids would be "harder" to hit than sectopods when both are in plain sight, and a muton facing to your left or right would be "harder" to hit than a muton facing you. If there are obstacles blocking the way more, you reduce the multiplier accordingly.
I have no idea how something like this would be calculated.
-
I have no idea how something like this would be calculated.
And the important part: How would you show that to the player? Right now, accuracy is just shown, when you click on the weapon and choose the type of attack/usage. At this point, the engine simply doesn't know, where you will end up pointing it to. So you'd have to choose the target first, then the engine assesses the accuracy at this target, and then you'd have to have a chance to reconsider your choice. I don't think, that this would improve gameplay for all those situations, where obstacles aren't a big problem. And if the engine could assess the very high likelihood of failure on that specific target (let's say, .1% chance), it could as well simply refuse to point there, as it does with targets, that have in fact 0% chance of hitting.
-
There's no need to calculate it, it's already done for you through the fact that the larger the target is, the easier it is to hit them due to taking up more space for projectiles to hit.
-
And the important part: How would you show that to the player? Right now, accuracy is just shown, when you click on the weapon and choose the type of attack/usage. At this point, the engine simply doesn't know, where you will end up pointing it to. So you'd have to choose the target first, then the engine assesses the accuracy at this target, and then you'd have to have a chance to reconsider your choice. I don't think, that this would improve gameplay for all those situations, where obstacles aren't a big problem. And if the engine could assess the very high likelihood of failure on that specific target (let's say, .1% chance), it could as well simply refuse to point there, as it does with targets, that have in fact 0% chance of hitting.
Ineresting question. What if you were trying to hit a tree? The engine would have to somehow know what you are aiming for and use it's projected surface area in the multiplier calculation. It doesn't fix the problem, only "fixes" the alien part of the problem.
-
"The algorithms were, of course, very fun to construct and interesting to discuss outside of the game. The players, however, felt left behind -- the computer was having all the fun -- so we cut the feature. Further, games require not just meaningful choices but also meaningful communication to feel right. Giving players decisions that have consequence but which they cannot understand is no fun. Choice is only interesting when it is both impactful and informed." --Sid Meiers, on Civilization game design
-
"The algorithms were, of course, very fun to construct and interesting to discuss outside of the game. The players, however, felt left behind -- the computer was having all the fun -- so we cut the feature. Further, games require not just meaningful choices but also meaningful communication to feel right. Giving players decisions that have consequence but which they cannot understand is no fun. Choice is only interesting when it is both impactful and informed." --Sid Meiers, on Civilization game design
Pity the Master of Orion ]|[ lead designer didn't think like this. And Distant Worlds people too. :)
-
It's a decent point. In vanilla UFO / X-COM, alien events seemed totally unpredictable to me. It's only since following OpenXcom that I learnt there was a system of monthly, race-specific "missions", and that killing scout crafts would cancel the rest of it.
-
That would mean that a soldier with 100% firing accuracy will have a 100% chance of hitting an exposed alien (100% of it is visible) and 25% chance of hitting an alien that is 75% hidden by cover, which is pretty natural IMHO.
However this creates the issue that OXC might show 100% or more accuracy for a soldier, but since the actual chance of hitting the alien might be 10% or less, the game will let you fire and you will have no idea why nine out of ten shots go wide...
This must go hand-in-hand with an accuracy display on cursor.
-
However this creates the issue that OXC might show 100% or more accuracy for a soldier, but since the actual chance of hitting the alien might be 10% or less, the game will let you fire and you will have no idea why nine out of ten shots go wide...
Which get's even worse, when the actual probability to hit the target is far less than 10%, more like 0.1% to 0.01% or something like that. That's what's annoying people right now but it's not that sharp defined. So it also applies to your scenario.
-
This must go hand-in-hand with an accuracy display on cursor.
No it doesn't. The game shouldn't just let you fire impossible shots. It should be up to player to decide if he should try firing anyway, regardless of cover. Unless we throw the whole bullet tracing out of the window.
Basically the best idea IMO was hammered out on Volutar's thread: he wanted to write a tracing with 100% perfect accuracy (if the game says you have 100%, you will hit 100%, even if you see just a single enemy pixel); if a random spread was added to that (say, in normal conditions, it'd be like 8x8 pixels representing a normal-sized target), the result would be "100% means 100% chance to hit a standard-sized, unobstructed target" which would be both realistic and basically non-computable for the purpose of cursor-display (basically it'd have either to account for every tile along the way, or show a false number). That spread could be lowered for >100% accuracies, say by 1 pixel per every 10% above 100, or ruleset tweaks. Naturally if only a few pixels were visible, for example just enemy's head, the standard spread could well mean shooting above enemy's head or hitting cover. The player wouldn't be surprised as he would clearly see that those 9 missing shots were very close to the target, and each went by a slightly different trajectory (in current system, all 100% acc missed shots always follow the same, erroneous path which is simply frustrating and shows that you miss due to a glitch). To make this even more sensible the engine would try to aim at a pixel which is both visible and closest to enemy's centre of mass. One of the biggest advantages of such a system would be realistically working cover - instead of exploiting aiming glitches, players would choose cover naturally, and kneeling behind a boulder would actually increase your chances of survival by a non-negligible degree.
However, with Volutar gone, chances of such an engine emerging are slim... Also the spread would have to be optional since there was no spread in vanilla - one-pixel shots routinely connected if accuracy was 100% or more.
Getting back to my initial denial, I'll explain it more now: as a player, I'd rather have the cursor displaying an 'ideal' number and leave guessing my real chances to my experience (as long as the engine is flawless), than have it displaying some machine-calculated probability that is rather confusing than helpful. Manual control. I don't need the cursor to tell me that there is cover in the way, as I can see it for myself. Also, when I force-fire through full cover, the cursor showing '0%' would be plainly and completely misleading.
-
I would prefer system when you could miss "aiming". Something like separation of weapon accuracy and human accuracy.
a) try find perfect trajectory, you have couple trials based on only on solder accuracy to find random trajectory that can hit enemy.
b) do normal shoot using found trajectory.
This will prevent wasting all your ammo on small obstacle that was on the way but will prevent you hitting enemy in foot form end of map.
-
For accuracy: I suggest adding as option a mode, which makes game show maximum deviation in degrees instead of vague "accuracy". Because not only is it maybe more convenient in certain situations, but also because new players are prone to think of "accuracy" as change of hitting. Heck, even I was like that some time until I got myself to UFOPaedia.
-
I don't know, the max deviation is fun info for science but I don't particularly care by how much will I miss if I don't hit (there's a simple function for that - or actually 3 linear functions chosen by a conditional statement, as far as I can tell, it goes to about 0 for about 160% acc, and you will still miss if the trajectory is affected by the glitch the OP brought up). I'm more interested in practical issues, ie. how likely I am to hit. The accuracy, understood as 'accuracy under lab conditions', is far more informative IMO.
But maybe it's just me - to me personally is rather obvious to not fully trust any kind of simplistic evaluations to complex problems, especially if the evaluation is done by a machine. Useful, sure, but still just a guideline.
And the 'lab accuracy' is very useful - if 'true acc calc' would be somehow implemented, it would deny me the knowledge of how likely I'll be to hit if the current obstructions were gone... It will, like a genius moron, tell me that I have 0% chance of hitting an enemy who's behind a wall...
-
Is this the same bug as the one in which sometimes you hit an alien way too many times and it won't die? I suspect this one is a bit different. It seems that you're apparently not actually hitting them, but the graphic appears to have shown you hitting them. It happens with aliens in certain spaces, like the passable alien craft rear wall segments, which weren't passable in the original game.
-
Is this the same bug as the one in which sometimes you hit an alien way too many times and it won't die? I suspect this one is a bit different. It seems that you're apparently not actually hitting them, but the graphic appears to have shown you hitting them. It happens with aliens in certain spaces, like the passable alien craft rear wall segments, which weren't passable in the original game.
I don't think I've heard about this, but indeed it cound be true. The problem is, without proper debugging tools it's impossible to determine if the fact that Sectoid didn't die after being hit three times from a laser rifle is a bug or he was simply very lucky - after all it could be three bad rolls on your part. But yes, it's possible it's some sort of a bug, and it could be related to the obstacle bug.
-
Causing no damage is not a bug, it's a probability. 4 hits in a row which don't cause visible damage is not a proof of anything. If you have doubts, put some logging code, which prints out the damage rolls (min, max, randomly picked). When If you experience a suspicious series of events, look at the logs.
-
The best solution would of course be implementing pain sounds ~ ala Doom ~ so that hits can be identified.
-
The best solution would of course be implementing pain sounds ~ ala Doom ~ so that hits can be identified.
There are several orthogonal solutions:
1. hit points flying out of the damaged unit, like in final fantasy games.
2. info window, exposing all the dice rolls the game engine makes.
3. hit animation. I.e. displace damaged unit for a second.
4. sound. (having just them will offend the deaf users)
5. blood and gibs.
-
Causing no damage is not a bug, it's a probability. 4 hits in a row which don't cause visible damage is not a proof of anything. If you have doubts, put some logging code, which prints out the damage rolls (min, max, randomly picked). When If you experience a suspicious series of events, look at the logs.
I might look that up next time I see it happen. Now I often see a unit survive hits that seem odd but I understand that's chance, for instance a sectoid once survived two hits from a laser rifle. But I have seen units sometimes survive ridiculous amounts of assault, and always while next to a solid object that could be providing some sort of occlusion bug. The most grievous instance happened when a silacoid survived four heavy laser snapshots (from my improved heavy lasers), 4 hits from a heavy auto-laser, 7 hits from a laser rifle, 18 hits from a laser auto-pistol, and 3 hits from a cannon tank. The silacoid decided to pop in to say hi and the aliens' turn ended with it surrounded by my soldiers. Now all my weapon power values were edited, but I know that all of these weapons were capable of penetrating silacoid armor because I killed all of the other silacoids in the site, including that one--after it moved.
-
3,4,5 in some combo. 1 & 2 not really - too much info, info a player should not have.
-
3,4,5 in some combo. 1 & 2 not really - too much info, info a player should not have.
The weapon efficiency should be exposed somehow. I.e. what firepower would be enough to take down UFO walls or some heavy armored alien?
-
The weapon's damage value is exposed in the ufopedia. The resistance-value of ufo-walls and such things would be nice there, too, yes.