OpenXcom Forum
Contributions => Programming => Topic started by: redv on September 07, 2013, 08:04:52 pm
-
On the screenshots - result of cooperative work three options:
battleRangeBasedAccuration, battleShowChanceToHit and battleShowThrowTrajectory
screen064. Was chosen snap shot. Near crosshair you can see probability of hitting.
screen065. Next rookie in the skyranger ready to throw smoke grenade. The game is shows the blast radius and the throw trajectory.
screen066. Chance to hit for first soldier significantly decreased because of dense smoke.
I wrote this code just for fun) , but
I would be interested to know ideas about this and suggestions about optimization.
Code:
chance to hitting: https://github.com/redv/OpenXcom/compare/rigth_shot_chance_view
throw trjectory: https://github.com/redv/OpenXcom/compare/throw_view
-
The area of effect ring looks a tad out of place, but all the same I'd love to have this.
-
Part of me thinks this is cheating but the other part of me thinks this is a really useful idea ( especially for newbie's).... I am so confused right now, Good Job :P
-
The area of effect ring looks a tad out of place, but all the same I'd love to have this.
Yeah it seems useful but the graphics look kinda jarring.
-
perhaps make that ring a little thinner? or even several thinner rings with a bit of spacing between them (2-px-width rings with 2-px-width free space between them?) might look cool...
-
This is a great ides redv!! Give the ring a little bit of transparency. I think that's all it needs. If it still looks ugly, thin it up.
redv, can you post more pictures on the trajectory? I can barely see it on the second screen. I'd like to see different angles and stuff.
-
The area of effect ring looks a tad out of place, but all the same I'd love to have this.
The circle is drawn around last point of trajectory. After call convertVoxelToScreen(), last point always in the top corner of tile. Now i found the cause of the error. I just need add correction to my calculations. Just 8 pixels down.
Yeah it seems useful but the graphics look kinda jarring.
Yes, i know it. Therefore i asked to the forum about this)
I want get ideas about improvements.
Give the ring a little bit of transparency. I think that's all it needs. If it still looks ugly, thin it up.
redv, can you post more pictures on the trajectory? I can barely see it on the second screen. I'd like to see different angles and stuff.
I thought add texture to the circle and change its in cycles. Like rotation or pulsation of the circle. But, in my opinion, even this effect will looks very well, this will looks like as taken from other game.
Static shadow or transparency also not good. I tryed it. Because if it looks good at day, but bad at night.
Now i think about adding pulsation of the shadow of tiles under the ellipse. And try a different thinness of line.
screen035. Throw at night. Trajectory shows good.
screen036. Throw at day. Trajectory shows good too. Because uses two colors for drawing the trajectory.
-
The circle is drawn around last point of trajectory. After call convertVoxelToScreen(), last point always in the top corner of tile. Now i found the cause of the error. I just need add correction to my calculations. Just 8 pixels down.
No no- I meant, out of place as in it doesn't look like it would fit the graphics/art style that XCOM uses.
Try some other colours for the ring, maybe the same shade of yellow as the accuracy number, or the red of the targetting reticle... that sort of thing.
-
Try some other colours for the ring, maybe the same shade of yellow as the accuracy number, or the red of the targetting reticle... that sort of thing.
Damn! Why? Why i didn't think about that?(
Yes, this is much better.
Thank you)
If anyone (any visible unit) standing inside blast radius, then color will change to yellow and blink like yellow crosshair.
-
Ooh, nice! So it actually behaves exactly like the red box/crosshair... that's perfect!
Merge! Merge! Merge!
:)
-
Merge! Merge! Merge!
Tora! Tora! Tora!
-
Oh my god this looks GOOD!!! Excellent job.
-
Nice job, Merge it :P
-
is that "ring" a flat object (on the ground) or a 3D-like object? it looks like it could be a torus with a square cross-section, but perhaps it's just two concentric rings of different color...
(I'm asking because I'm not sure how to interpret the way it intersects with the haystack on the left.)
-
is that "ring" a flat object (on the ground) or a 3D-like object? it looks like it could be a torus with a square cross-section, but perhaps it's just two concentric rings of different color...
This ring is flat object on the ground.
1. I draw whole ellipse on special surface.
2. Cut a rectangles 32x40 from the ellipses surface.
3. Superimpose these rectangles to the map surface.
One problem - 3D map blocks is not rectangle) https://www.ufopaedia.org/index.php?title=Module#Terrain
As result, in some cases, apear artifacts like 3D intersections.
Now i finished optimizations. Later will try to solve these problem.
-
The problem with 3D interceptions resolved.
PR sent)
-
May have ideas about improve drawing trajectory of throw?
-
hmmm... yeah, the circle now looks better, but I guess we'll run into visibility problems if the ground has a lot of objects on it (underbrush in jungle terrain, wheat field in farm terrain, "roof" tiles in the urban tileset etc.) because it might obscure the circle completely...
the shading routine used for path preview only re-colors the ground, doesn't it? is there a shading routine that also affects objects in the tile? if yes, perhaps make everything inside the circle flash red? including units and other objects, of course. that way, you can immediately see who and what will be affected.
-
Nice job redv. Hope to see that in the options of the nightly builds soon :D
-
it would look better if it was semi "transparent". What function you used to blit it?
-
it would look better if it was semi "transparent". What function you used to blit it?
I use blitNShade https://github.com/redv/OpenXcom/compare/throw_view#L2R415
Do you mean semi-transparency for blast circle or for trajectory?
I think need to remove rendering trajectory from this commit. Leave only blast area. I have tried several options to render trajectory, but stay dissatisfied.
-
tomorrow I will made special function that will made blast circle more transparent.
-
tomorrow I will made special function that will made blast circle more transparent.
Keep me posted on when and How it works , i am thinking i may need other things partially transparent later on :P
-
the shading routine used for path preview only re-colors the ground, doesn't it? is there a shading routine that also affects objects in the tile? if yes, perhaps make everything inside the circle flash red? including units and other objects, of course. that way, you can immediately see who and what will be affected.
It is possible. But will be need check each tile, repaint them or not. Even if this option will be disabled. I'll think about it.
tomorrow I will made special function that will made blast circle more transparent.
It would be nice)
-
first try.
BTW redv you didnt include correct headers to `Map.cpp` file. When I try first compile I get couple errors.
-
Looks nice!
Could you post a screenshot with the circle in a wheat field?
-
The transparency effect looks good. But what about color shifts? Color does vanilla-like behavior of crosshair.
I think, for each pixel, something like:
If (srcPx)
dstPx = srcPx + ((dstPx & 0xF) >> 1);
or
If (srcPx)
dstPx = srcPx + std::max( (dstPx & 0xF) - tileShade - 2, 0 );
BTW redv you didnt include correct headers to `Map.cpp` file. When I try first compile I get couple errors.
I know, sometimes i skip headers. But i don't know which particular) Because VC2010 compiles this without errors)
Which headers i miss? Perhaps SDL_video.h
-
Looks really cool and red/yellow much better then blue as a colour but how would it look if it just did outline on affected tiles? It would be a lot different to your implementation because I believe yours is based on the location of the cursor and not from the tile so you could have a grid outline and put it around affected tiles, if you can tell what the active tile is then could do the radius from a snap to centre of the tile instead of location of cursor so it should be accurate and you don't need to actually locate the tiles you are going to draw it around, just the one tile at the centre.
Although thinking about it even though it would be more accurate it might look even more jarring, tile outline only difference is accuracy of blast radius on edge of the radius so only affects those fringe tiles where the blast power is heavily reduced anyway so it doesn't really even matter if friendly or hostile is on edge.
So in conclusion ignore the above but good job :D
-
Looks really cool and red/yellow much better then blue as a colour but how would it look if it just did outline on affected tiles? It would be a lot different to your implementation because I believe yours is based on the location of the cursor and not from the tile so you could have a grid outline and put it around affected tiles, if you can tell what the active tile is then could do the radius from a snap to centre of the tile instead of location of cursor so it should be accurate and you don't need to actually locate the tiles you are going to draw it around, just the one tile at the centre.
I exactly know, where the center of the explosion in the tile space.
https://github.com/redv/OpenXcom/compare/throw_view#L2R348
And I can calculate locations of affected tiles.
https://github.com/redv/OpenXcom/compare/throw_view#L2R1273
-
I know, sometimes i skip headers. But i don't know which particular) Because VC2010 compiles this without errors)
Which headers i miss? Perhaps SDL_video.h
You need to disable the precompiled headers (Properties > C++ > Precompiled Headers) to see header errors, an annoying side-effect of using them.
-
The transparency effect looks good. But what about color shifts? Color does vanilla-like behavior of crosshair.
I think, for each pixel, something like:
If (srcPx)
dstPx = srcPx + ((dstPx & 0xF) >> 1);
or
If (srcPx)
dstPx = srcPx + std::max( (dstPx & 0xF) - tileShade - 2, 0 );I know, sometimes i skip headers. But i don't know which particular) Because VC2010 compiles this without errors)
Which headers i miss? Perhaps SDL_video.h
you miss in "Map.cpp":
#include "../Engine/Screen.h"
#include "../Savegame/BattleItem.h"
in "Map.h":
class BattleAction;
This is my version:
https://github.com/Yankes/OpenXcom/tree/throw_view
As you can see it isnt many changes, most important part is `Transparent::func`, its core of this effect.
You can easy change implementation of this function to achieve different effect.
This is screenshot of `if(src) dest = src + ((dest&0xF)>>1);` function:
-
Transparency without recoloring looks not good in some cases (screen046, screen047).
Transparency with recoloring reduces contrast and, as result, transparency is almost invisibly:(
So, i think, best solution is use red/yellow crosshair without transparency.
Transparency can be useful for rendering trajectory of throw.
-
Transparent circle maybe still useful, right now when circle is behind wall it disperser completely. I think it can be transparent then.
-
This new transparent version is even better.
-
Transparent circle maybe still useful, right now when circle is behind wall it disperser completely. I think it can be transparent then.
I did some tests. What is your opinion?
-
I think you should change a bit transparent part. Right now it is too bright if background was dark.
Maybe try function like that:
dest = (dest & 0xF0) | ((dest & 0x0F)*3 + (src & 0x0F)*1)/4dest shade will be 3 times more dominant than src.
-
This tests with ((src&15) + (dest&15)*3)/4;
-
I think those last ones are heading into the right direction. where the circle is directly visible it looks right, and where it is partially obscured you can still see it, but it doesn't cut through the objects like it did before.
this looks great :)
-
Personally I preferred the approaches used earlier (screen046-047 etc). Circle with different color patches looks kinda weird, especially in the edge cases where only a few pixels are obscured.
-
I see strange patterns on transparent part, do you draw circle multiple times on one position?
If its true, you need add "mask" that will prevent multiple draws on same pixels.
you need change 2 things:
a) `Transparent::func` change first `int` arg to `const Uint8& mask` and in body add new test:
if(src && mask) {/* old draw code */}b) every `ShaderDraw<Transparent>` you need add new argument with last drew object, e.g.
ShaderSurface(tmpSurface, screenPosition.x, screenPosition.y)
If this dont fix it, send me last version and I will try fix myself.
-
Personally I preferred the approaches used earlier (screen046-047 etc). Circle with different color patches looks kinda weird, especially in the edge cases where only a few pixels are obscured.
But only for the directly visible part, right? I mean, those versions wozld be completely invisible in any terrain with objects (even grass)!
-
add:
i also like the earlier forms where it disappears behind/beneath walls & objects
(otherwise my eyes are on a roller coaster going up onto walls etc)
and goes translucent on floors that the thrower can't see, perhaps, or that the explosion won't reach. i guess
/yap!
-
I see strange patterns on transparent part, do you draw circle multiple times on one position?
If its true, you need add "mask" that will prevent multiple draws on same pixels.
I post updated branch: https://github.com/redv/OpenXcom/compare/throw_view#L2R224
You can check it.
In my opinion, best variant is red/yellow with blink effect. Like on picture, but without throw trajectory.
If parts of circle will be obscured, it is not problem, because this mod not affect on gameplay. It just for fun.
Latest versions is not very good.
-
RED color looks better, because of the "explosive warning" feel.
The yellow looks like "agricultural spraying of pesticides" or "build a house there".
-
by "blink effect" you mean that the circle is red, but turns yellow-flashing if a target is within the blast radius? (maybe you should post a video :) )
-
RED color looks better, because of the "explosive warning" feel.
The yellow looks like "agricultural spraying of pesticides" or "build a house there".
by "blink effect" you mean that the circle is red, but turns yellow-flashing if a target is within the blast radius? (maybe you should post a video :) )
hmm.. agrocultural? O_o
This is default behavior for Xcom crosshair when you aim.
-
hmm.. agrocultural? O_o
This is default behavior for Xcom crosshair when you aim.
yes. precisely. so your circle mimics the behavior of the original crosshairs, right?
would it be easy to change the code so that the circle's line is a little bit thinner?
or on another note, perhaps you could provide three versions, so everyone can find what they like best, to be toggled in the advanced menu:
0) no grenade circle
1) thin red/yellow circle
2) thick red/yellow circle
3) transparent circle
arc trajectory would be toggled seperately...
-
Yeah, just include red in circle's coloring. That will show "Danger!" to the user so we will take extra care not to blast our soldiers.
-
perhaps you could make some kind of ray tracing to determine the precise area of the granade blast ? with the area described by the shape (not necessarily a circle then) the precise area including stuff stopped by the walls etc ?
-
perhaps you could make some kind of ray tracing to determine the precise area of the granade blast ? with the area described by the shape (not necessarily a circle then) the precise area including stuff stopped by the walls etc ?
No. This feature was conceived as not affecting to gameplay. Just entertainment.
Next thing - performance impact. Is it really need do ray tracing each frame?
-
A tile overlay (like in path preview) might be more accurate, but probably wouldn't look as good.
-
by "precise" I've meant including covers like walls etc. but recently I've noticed that they are not taken into account, and a blaster bomb exploding on the right of my avenger has killed folks inside of my craft :p
-
by "precise" I've meant including covers like walls etc. but recently I've noticed that they are not taken into account, and a blaster bomb exploding on the right of my avenger has killed folks inside of my craft :p
I think they are taken into account, it's just walls don't fully stop a blast, they just mitigate it a bit, specially against a blaster bomb. :P
-
yeah, but if the wall stands it takes all impact, and you're not simulating shards of walls flying inside, are you ? :P
-
yeah, but if the wall stands it takes all impact, and you're not simulating shards of walls flying inside, are you ? :P
not in vanilla X-Com, it doesn't. walls reduce splash damage, they don't block it entirely.
-
I was speaking of logic behaviour moriarity. when a projectile hits a tank, it isn't the explosion on the outer side of the armor that kills everyone inside, but a piece of metal torn away in the point of impact and all kind of rivets flying inside.
I don't quite remember vanilla work that way, but I trust in your knowledge on that topic.
-
Hey!
I'm new here, I've been reading the forums for quite a while, but this is my first post!
This improvement to show both chance to hit and throw trajectory seems very useful. However, I was wondering how can I actually enable/use it in Openxcom? Do I have to download files from somewhere? I apologize for my computer-illiteracy and would greatly appreciate any help, as this is a very useful feature IMO :)
And many thanks for keeping this project running!!! I'm sure there are a bunch of people like me who are not necessarily visible on the forums but love your work. Keep it up!
Yours,
Badger
-
A tile overlay (like in path preview) might be more accurate(...).
I agree. It can even be somewhat misleading since the outer tiles would only be partly covered by the circle, leaving it unclear whether a given fringe tile is affected.
And regardless of colour, the circle looks jarring and out of place because the battlescape deals in squares.
-
This improvement to show both chance to hit and throw trajectory seems very useful. However, I was wondering how can I actually enable/use it in Openxcom? Do I have to download files from somewhere? I apologize for my computer-illiteracy and would greatly appreciate any help, as this is a very useful feature IMO :)
Hello, Badger!
Feature "show a chance to hit" was added to the pull request: https://github.com/SupSuper/OpenXcom/pull/586
Maybe will be merged to upstream. Maybe after 1.0. Maybe never.
Feature "show throw trajectory" will never be merged to upstream for some reasons)
But, if you really want add this feature to your game, you can get the code here: https://github.com/redv/OpenXcom/tree/throw_view
-
Shouldn't the blast radius be more like a circle with square edges?
-
Forgive me for resurrecting this old topic, (and my ignorance), but what's the status of this feature? Merged, still under development, dead?
-
The feature works well for me but wasn't proposed for master build.
This is fresh screenshot:
(https://cloud.githubusercontent.com/assets/3616568/2731180/14c540da-c628-11e3-865f-3b5781114be7.png)
I made exactly what i wanted, but i saw a required a little more. Transparency for example.
I tryed several different algorithms for transparency, but result was not good for me. Therefore sometimes the feature looks like this:
(https://cloud.githubusercontent.com/assets/3616568/2731507/0526b87e-c62e-11e3-9d0e-7c53c3c33dbf.png)
Therefore, i belive, this feature not ready for PR.
Anyway, if you want to do as best as possible you can get a start point here: https://github.com/redv/OpenXcom/tree/throw_view
-
Indicator of danger zone better to be tile-based, since it doesn't affect on part of tile. Also it could consider tile occlusion (i.e. use actual algorithm), and simpy coloring them into red, like it was for first version of path preview.
That's how I see it.
-
I like the circle + highlight of all the targets that will be affected by the explosion. That's the best option IMHO.
As for the circle's appearance, I'd go with this approach:
(https://openxcom.org/forum/index.php?action=dlattach;topic=1532.0;attach=6063;image)
I know that the circle looks "floaty", but that's a small price to pay.
-
Basic idea was to do something like this:
(https://cloud.githubusercontent.com/assets/3616568/2743548/ffb129fe-c715-11e3-813c-8435fae471c8.jpg)
but this thing must look like a part of vanilla Xcom.
If we use transparency in OpenXcom, then this circle will looks like was obtained from another game.
-
I also vote for a simple orange ring and all viable targets (units, not tiles) flashing the same colour.
I understand the circle can be obscured at times (wheat field being the most extreme case), but the flashing effect should be enough help. And you can simply move the circle to some other terrain to assess its size.
-
I truly disregard this project (xcom2012) and his gamedesigner and am totally sure it's a disgrace for xcom1-3 lovers. Why he spoiled whole internet by adding enormous amounts of ambiguity? When you're trying to search for "ufo enemy unknown" you're getting messy results diluted with lots of crap. Why didn't they take totally different title like XCOM:Reborn or something? Right, to become a leech at the fame of Gollop's title. That's how marketing works.
And I highly discommend using something of their questionable features and doubtful inventions. It's ordinary console game for alternatively gifted, not even close to vanilla game of 1994.
Question: How can you see if that particular tile is under attack or not if that orange circle line touches tile slightly, or slightly more than that?
Answer: There's no way! The only way is to highlight particular tiles.
In sake of saving time I recommend not to waste time on "nice","fancy","xcom2012-ish" but totally impractical things.
-
I also vote for a simple orange ring and all viable targets (units, not tiles) flashing the same colour.
I understand the circle can be obscured at times (wheat field being the most extreme case), but the flashing effect should be enough help. And you can simply move the circle to some other terrain to assess its size.
I understand your point. Perhaps, you right. Yankes have a code for recoloring of unit in real time.
https://openxcom.org/forum/index.php?topic=523.msg17008#msg17008 (https://openxcom.org/forum/index.php?topic=523.msg17008#msg17008)
The code can be used and for blink units. I'll think about that.
And I highly discommend using something of their questionable features and doubtful inventions. It's ordinary console game for alternatively gifted, not even close to vanilla game of 1994.
Question: How can you see if that particular tile is under attack or not if that orange circle line touches tile slightly, or slightly more than that?
Answer: There's no way! The only way is to highlight particular tiles.
This feature isn't intended as precise instrument. This is just for fun. The feature has no effect on the gameplay.
Xcom 2012 is perfect game, IMO. I had much fun when I played this game. Especially first encounter with chryssalids in terror mission. When they wiped out my squad :( Do you think I am alternatively gifted? ;)
-
This feature isn't intended as precise instrument. This is just for fun. The feature has no effect on the gameplay.
It's not just "non precise", it's simply misleading and confusing. And that's not even fun. It should take actual explosion data, perhaps even considering obstacles/walls.
Xcom 2012 is perfect game, IMO. I had much fun when I played this game. Especially first encounter with chryssalids in terror mission. When they wiped out my squad :(
No, I just think you're in the wrong community. You won't get support for xcom2012 (and don't post herithic screenshots here). xcom2012 is not even close to vanilla xcom game.
Do you think I am alternatively gifted? ;)
Sometimes I found myself drawing circles on the paper without any reason when relaxing my brain.
Anyways, playing xcom2012 too much can injure one's cognitive functions. I wouldn't recommend that.
Seriously, it's a bad example of "sequel" or "remake". I simply disdain looking at it. It's gross. It's like Windows8 Metro UI for programming.
-
<off-topic> I don't think this entire community is devoted to bashing xcom2012. Yes, it's different, but it does have a lot of interesting ideas. On the other hand, I can see a relevant percentage of this community agreeing that it's nice to use moderate language and abstain from trying to bully people into accepting your beliefs.</off-topic>
the circle graphic, while simple and nice-looking, might lead people to believe that something will be affected which in truth isn't, as well as vice versa. A highly-precise tile-by-tile recoloring, while correct, will probably be ugly. I really don't know what would be better. Perhaps you could provide both? Like the path preview option, which can be toggled between "off", "arrows" and "arrows w/TU", this could be toggled between "off", "circle" and "tile-by-tile". People could then decide which it is they like best.
The idea of units inside the blast radius flashing as a visual cue is certainly a nice extra, if it's possible.
-
if affected units are to flash, take care that only /seen/ units flash. this shouldn't make visible otherwise hidden aliens.
-
Well, I thought the circle did correspond to the grenade's area of effect... Well, as much as a circle can correspond with square tiles.
I agree it shouldn't be misleading, but on the other hand I don't want to see AoE composed of big squares. No clear idea on solution for now.
-
as much as a circle can correspond with square tiles.
This, precisely :) there will always be tiles touched by the circle that actually aren't affected, or tiles that are affected but not touched.
For that matter, maybe an "expanding circle" effect would be nice? Kind of like the concentric waves from a stone thrown into water? They could trail off at the approximate blast radius. Grenades are already too precise for my taste, anyway ;) - give the user the clear idea that the graphic shows an approximation, not a precise information.
-
Come on Volutar, we're discussing improvements here, not perfection.
Granted, there may be a better way of doing this stuff (that's why we're discussing), but there is also a limit from where the gain is not worth the effort.
Please don't just tell why a feature is wrong, but also tell how would you correct it.
Considering that in the original there was absolutely no way tot tell which tiles were affected (except by visually counting them), I think that this feature is a goos step forward. It won't give you the exact tiles which will be affected by the explosion, but it will give you something better than the noting we have now.
I understand the circle can be obscured at times (wheat field being the most extreme case), but the flashing effect should be enough help. And you can simply move the circle to some other terrain to assess its size.
If this gets implemented, you will see which enemy units will be affected. And this will give you all the info you need, regardless of the circle visibility, or if it only touches the corner of a tile.
@redv: Can you give as an advanced option for the circle like 0 = disabled, 1= obscured by terrain and 2 = drawn over everything else (the flashing is always enabled for #1 and #2 values), like the current "Explosion height" advanced option?
-
Come on Volutar, we're discussing improvements here, not perfection.
Sorry, but I don't see how fancy misleading ring is improvement. Improvement means it provides reliable information.
Granted, there may be a better way of doing this stuff (that's why we're discussing), but there is also a limit from where the gain is not worth the effort
Please don't just tell why a feature is wrong, but also tell how would you correct it.
I already told what would be better. By having affected tiles recolored, probably even with colors, meaning damage amount (there's already explosion map calculated during explosion itself, and it could be use to visualize).
But that kind of precision (showing which tile will be safe due to blockage) could push it beyond the line called "cheat", or "easy life".
See, xcom is about hard life, making it easy by "automating" everything will make it cheap softcore (opposite to hardcore), and not really tough, which is important for xcom lovers. Thus I'm not sure if that is really needed.
-
The preview also makes the assumption that the explosive will hit the target tile, but misses happen. IMO the game already gives enough information with the smoke and tile damage : After a few explosions, you get the right feeling for the "danger zone". I don't think I've ever counted tiles.
-
It should be a mod instead of being implemented in 1.0.
-
I already told what would be better. By having affected tiles recolored, probably even with colors, meaning damage amount (there's already explosion map calculated during explosion itself, and it could be use to visualize).
That's the only constructive thing you've put in that post. Could have done without the rest.
-
I think that we need a simple thin red ellipse that draws over all tiles and shows you an approximate blast radius (not tile by tile accurate) for every weapon. It's anyway better than feelings of danger zone.
-
I think that we need a simple thin red ellipse that draws over all tiles and shows you an approximate blast radius (not tile by tile accurate) for every weapon. It's anyway better than feelings of danger zone.
@Xtendo: I like your design for this feature. Looks good and fits in with the "feel" of the game. This is a pretty old thread so I assume it's not getting in the Nightlies at this point, but I would support it.
I'm pretty strict about not re-loading when bad things happen to my troops, but I will sometimes reload to "test" a blast radius before I commit to using it. I'm not always good at visualizing the "danger zone" in my mind so it's easier to shoot and re-load if I it turns out I was in the blast radius and I kill myself (then I just move slightly out of it and re-shoot). This feature would allow me to know without doing that.
Maybe when I'm a "vet" I'll be stricter, but right now this is one of the ways I "cheat". I don't consider it that cheaty though because hypothetically I could look up each weapon's radius and count tiles anyway, but that's very tedious so I just test and re-load.
-
This is a pretty old thread
Yes, but feature is already implemented, works without a lot of rewriting and looks interesting for me. I simplified a code without checking would you hit an enemy by explosion, draws circle over all objects ("smart" circle draw below objects will require a lot of reworking of drawing objects) and changed a code to show blast radius for every weapon, not only for things that you can prime.
I'm pretty strict about not re-loading when bad things happen to my troops,
I also like playing in roguelike style with permanent fails if bad thing happens.
I could look up each weapon's radius and count tiles anyway, but that's very tedious so I just test and re-load.
Later I found that we need count also a damage. You can define a crazy radius in ruleset but with low damage it's not possible to damage everything in blast radius. So low damage reduces a blast radius and huge red circle will confuse you at that case. I added another yellow circle. In a screenshot I'm trying to throw a grenade. Red circle shows max blast radius without counting damage. Yellow circle shows efficient blast radius taking into a consideration a damage. Everything in red circle are less likely that somebody will receive damage.