OpenXcom Forum
OpenXcom => Suggestions => Topic started by: Volutar on September 28, 2011, 01:53:41 pm
-
Generaly, they say it doesn't matter how path is built, unless it's not optimal in TUs cost.
But this is wrong.
There are situations, when you need unit to keep straight line. So obviously if there are alternatives, unit must keep most straightest path possible.
Let me illustrate.
-
Some dude already have been working on this "problem".
https://www.irontowerstudio.com/forum/index.php/topic,1720.0.html
And actually, XCOM game series have exactly this, "straight" version of pathfinding, which is the only acceptable pathfinding for this kind of games.
-
Okay.
I've been using dijkstra algorithm for marking all possible shortest paths.
Each grid cell may have number of "vectors" which shows direction to the next cell of shortest path, though at the end all of these alternatives eventually will get to "start" point.
First case is most difficult. There are 2 alternative ways, which are absolutely equal in TUs cost. Final point (at the bottom of 1st grid) have 4 (FOUR) alternative ways out, so making optimized paths would be quite difficult.
Second case also have two alternatives, which seems to be quite okay, but actually it's not that easy. Final point at the right of the grid. So there are 2 ways - above horizontal bar, or below it. Which of it will be most straight? I think below one, because initial walk vector will be closest to vector to the target point.
Optimizing those "equal areas" to straight line is not hard. You just need to look through all cells (from the closest) which have only ONE direction, until bresenham line (LOF) is possible.
-
If you want to play with application i've made for testing these "equal paths":
https://volutar.eu5.org/pathfinder.zip
Actually finding most "straight" path is quite hard as I see, though it's clearly possible.
-
Another thought. Pathfinder shouldn't even try to go into/through black unknown areas... Say, how can they know the path in the unknown? Clicking into the darkness and going though the maze with one click is a kind of a cheat...
-
If we use bresenham to figure out furthest straight trajectory possible, then we'll get weak path with low tension. Which is bad.
On the picture below you may see green line going way too far, so next segment become silly.
Note: Path traversed backwards from the final point (which is at the right), so green line will be too long. And even if we try to travese it in forward direction - it won't help a bit.
So we need some kind of algorithm, finding better "corners" for bresenham.
-
Sort of success, though there are bugs possible - should test alittle.
Test program also updated.
-
Hello again.
Another update. Now it recognizes objects and walls.
-
Application updated. Now you can set source point with RMB and destination with LMB.
URL is the same: https://volutar.eu5.org/pathfinder.zip
-
Do you plan to add in xcom specific things? Like ufo walls (that are objects acting as walls) and the stairs functionality? Also, it seems like an interesting project, but since it's a standalone application, I don't see the immediate benefit to the openxcom project - unless at some point you release the code and it's portable to the openxcom engine somehow.
-
Daiky, ufo walls? what's the difference between them and ordinary walls?
-
ufo walls - actually the diagonal ufo walls - are objects, but they don't behave like objects where you have to walk around, depending on the direction you walk along them.
Ok, never mind this, I have this totally wrong , you can actually walk diagonally passed every object, so ufo walls don't make a difference... arggh, well even I can make mistakes :)
-
Yeah, these diagonal ufo walls made with kind of trick: they used wall_diagonal + wall_corner interleaved, so they cannot be passed to move inside or out, though these wall_corners are almost invisible and can be passed like right green arrow on second screenshot without problem.
-
I've begun to implement ufo map (saved games) processing (with all MCD data) with my pathfinder.
And discovered that we might be done something wrong.
First thing - they're using "is_wall" flag of MCD of some of objects (diagonal walls). This flag mean unit cannot walk by this tile diagonally (i've marked these objects with yellow dots). This explains why we can walk through north-east wall of Avanger, and cannot walk through north-west - they just haven't set this "is_wall" flag for north-east wall.
Second thing - UFO_140. WE can see they're extensively using diagonal walls flags even if it unnecessary (western and northern outside walls also work as "diagonal"), and if you can stand besides south wall of UFO, you cannot stand near northern!!! You can check it. I don't see any reason to do that.
Third thing - you cannot walk along diagonal walls in UFO (at least of this UFO).
-
I think there should be TWO kinds of "is_wall" flags of MCD. Or probably this field should be a BYTE, not a BOOL field, and have 3 states: 0=not a wall, 1=SWNE(/) wall, 2=NWSE(\) wall, so we could make diagonal walk along these walls possible. Plus we can change these "walls" which have an 3 (object) type, and setup at 3rd byte (where object should be). I really don't know why they made this illogical decisions. There is an easy way to to fix this up and make it better.
-
maybe read LoFtemplates to determine how you can move?
-
LOFT? Really silly idea.
-
Well, i've altered AVENGER.MCD and U_EXT02.MCD. Now it have "wall" flag set to 2 or 3 for either one diagonal or another.
But there are some ugly tiles outthere.
As you know UFO uses concept of NORTH/WEST walls only. If you need to get SOUTH wall - you just put NORTH wall to south tile, that's all. But it doesn't work for outer UFO walls. They were made as actual SOUTH and EAST walls of tile, so they were decided to be used as objects with "wall" property to avoid diagonal crossing. As side-effect of this - unit cannot stand beside this wall. The reason of this decision, as I think, is "convex" profile of wall, so it's the only way to make them "protrudable" outside.
Daiky, what is rendered first - unit or object?
We could make another "wall flags" of objects - south and east walls, to be rendered after unit, and allowing standing on them, but not walking through (acting as north/west walls of adjacent tiles).
On attached pictures you can see nice diagonal walls allowing walk along them, but not through them. And unit can get behind double chairs at north side of UFO (in UFOEU unit can't get there). Avenger hole also was "fixed" (but i'm not sure about this, it could bad choice to do so). There are "cross" objects, which aren't diagonals, so they act as usual "wall" object of UFOEU. On UFO these cross "objects" are those south and east walls.
-
Okay. So "is_wall" boolean field of object tile basically was improved.
Was:
0=not wall
1=wall object (cannot pass by diagonally, cannot stand)
Become:
0=not wall (can be passed by in any direction)
1=wall object (cannot pass by diagonally, cannot stand)
2=/ wall (can be passed by from south-west to north-east)
3=\ wall (can be passed by from north-west to south-east)
4=east wall (translated into west wall of eastern tile, can stand)
5=south wall (translated into north wall of southern tile, can stand)
6=east+south walls (translated into north wall of southern tile and into west wall of eastern tile, can stand)
This format of MCD is compatible with classic UFO MCD (they don't care which value exactly, if not 0). But new pathfinder will work with it much better than classic. The only thing is left - is draw order of such pseudo-objects.
========
What about LOS? I think this flag also used for LOS calculation... LOS probably also slighly glitch for these walls (look along north or west side of UFO and see if these walls block the sight). So these improved flags could be used for LOS too.
========
On second screenshot - Floater soldier cannot go where cursor pointing to. In Classic XCOM1. Isn't that a gameplay bug?
-
All these improvements was made only with some of MCDs modifications, and improoved pathfinder. Maps kept untouched.
Objects meant to be under units, so draworder will draw objects first and units after, but objects-walls actually are in front of units, so draworder should also be fixed to handle these kinds of objects-walls.
-
Daiky, what is rendered first - unit or object?
Object. Take the skyranger ramp as example, the unit need to be rendered on top of that object.
-
Thus rendering draworder tweak will be required in order to handle such wall objects.
-
There's another "outer wall" object which have "wall" flag... It used in "Terror Ship" (I guess it's the only place).
(https://www.ufopaedia.org/images/b/b7/UFO_150MAP-L1.JPG)
So I decided to add value=6 of this "wall" field. It's like value 4 + value 5 (both south and east walls).
I think that's too much but I dont see any alternative how to make this "object wall" path/view blocking shit fixed.
On bottom image there was an explosions happened, so why not all inner walls out there :)
I've made new application for this purpose. Now it loads UFO savegame ("game" folder) and can use it for "pathfinding". Although you may see every level, pathfinding works only on current level (still 2D). And it doesn't know anything about elevation and different TUs cost for moving (4/6TUs only).
https://volutar.eu5.org/ufomap.zip
-
Another finding.
Some of ground tiles have 0TUs cost, instead of 4.
The thing, is you can walk through them for free, but you cannot stop at them(!).
These tiles marked as crossed.
Actual testing: In source point unit has 47 TUs. It's behind the powersource. Destination point is 4 steps away from it. One of step is diagonal. So this path should consume 6+4+4+4=18TUs. But instead we have only 8TUs consumed. How's that? Two of those steps was made through "free" tiles, so only 4+4=8TUs been consumed.
In summary, I can say, there are ground MCDs which have abnormal behaviour:
1) They are free to move through.
2) You cannot go directly there, only walking through is possible.
Isn't that a bug? Doesn't it require a fix implying MCD modifying?
What should we do with it?
-
A good topic to think about - how to implement MCD (and eventually MAP) files mods in openxcom.
Currently they are treated as "resources", while they actually ARE NOT, they are rulesets/datasets. And all other rulesets/datasets are now part of openxcom package instead of extracted from the game, like all the weapon info etc.
-
There is no particular reason some things are called "resources" and others aren't, aside from keeping all the file loading in one separate place. I didn't really put much thought into it, the only reason stuff like weapon info wasn't loaded from original files was because IT'S A HUGE PAIN IN THE ASS (and kinda limiting). :P
Optimally you'd want all the game logic stuff in the Rulesets, while the ResourcePack (terrible name) should be for cosmetic stuff which can be swapped around without impacting the game (graphics/sounds/etc). I'm not sure where MCD/MAP/etc fall in this.
-
Another glitch which easily can be fixed. Roof of Aventer. Have you ever walked on the roof? Are you happy with how units walk down roof? 1. Units actually falling into roof, instead of being elevated; 2. When trying to go away, he just flies up and then down, spending alot of TUs.
So obviously MCDs have alot of bugs inside which should be fixed.
-
My opinion - we should use our OWN map format and OWN mcd format (which would handle more accurate LOFT objects). Don't know about images, probably we should use PNG images instead of pck's.
You may ask - and what's the point of using original UFO resources? There's no point! I think every game resource of original XCOM1 have bugs to be fixed. Original resources - just a temporary solution.
Though, YAML is not very good choice, specially for non-structured raw data like map (even for savegames). Or there should be some sort of RAW (base64) fields
-
Once the method of pathfinding is determined, it would make for good information to display in the map editor. What did you write the pathfind.exe in?
-
It's written in Delphi. And it's not finished yet.
I think MAP editor don't need to know anything about pathfinding. It would be helpful if it shows how much TUs will cost for moving from one cell to another (neighbour one). Or at least TUs values for each selected tile element (and elevation which also used to block movement). Anyways it will require setting up movement type (walk/slide/fly).
By the way, there's another interesting thing about movement cost. For 2x2 units TUs cost counted for 4th sub-tile (south-east part of unit), although main part of 2x2 unit is 1st one (north-west).
-
From a map debugging standpoint, I think it would be useful if it showed the path and the total TU cost between two points. So that when your guy makes a move you dont think is reasonable, you can see why it goes around certain tiles instead of passing through them.
Thers a couple ways I can think of to interface with your executable to generate paths between two points of a map - a C-interface or parsing stdout from your exe.
-
Hey, are you crazy? "parsing stdout" :) After finishing pathfinder algorithm I will gladly give you my code... Anyways, don't bother about that.
I think you're right at least about one thing - pathfinding definately will be helpful in mapeditor for better ROUTE visualization (trajectories between different route nodes).
-
Yeah that was my thinking as well - adding it to the route viewer
-
Another proggy update.
Now it work in 3d (I hope).
On attached image there's BARN. Starting point is marked blue on level2, destination point is purple on level2.
Unit goes up, then over the roof, down to barn entrance, then to the stairs, and towards destination point.
It don't know anything about lifts yet, and Stairs don't work as they should (they don't make any inter-level switch), and max elevation is not implemented. But I think it's not that hard to do.
==Addition:==
Application is uploaded. You can use any of your xcom1 maps (from battlescape savegames, just replace contents of /game with appropriate /GAME_XX).
-
Here is (https://volutar.eu5.org/ufomap.zip) updated version. Now it can:
- Use lifts
- Go stairs
- Fall (if can't fly - fly mode is triggerable)
- Falling into objects (diagonal walls) replicated bug
- Going upstairs into objects - replicated bug (in Avanger - going from ramp up into diagonal wall)
Still can't:
- Go downstairs level down without falling (this could also be in original)
- Getting upstairs to next level if pointing on the same level "behind" the steps - it just goes around to pointed location whilst in original it goes up level
- Nicely smooth path if it's broken into different Z levels (though it should go by bresenham when going up to the hills).
Known bug:
- Path trace slightly broken when source point is in the air, while unit can't fly, and pointed somewhere on the ground level (not all falled levels traced)
-
Wow! This is really impressive.
The "known bug" shouldn't really matter, does it? Since falling things should fall down all the way first...
-
Nah.. I've fixed it (app updated). It just required for extra value for equal distances (when unit falls TUs aren't consumed).
-
Interesting thing... Going straight by ramp is more costy than immediate jumping off.
Folowing path takes 30 TUs, while straight path (which is chosen by UFO pathfinder) will take 32 TUs.
Strangely, in original UFO, it can be either 30 or 32 TUs when going down ramp. It can be either 4 or 6TUs when going through Avenger door on ramp. It consumes 6TUs when stopping right on upper ramp segment, and 4TUs when going through it without stop. This is really strange and subject to figure out the reason.
===Added===
Found another thing. When you're pointing at ground level for going outside - the cost is 30TUs. When pointing on same tile but level2 - the cost is 26TUs... how's that?
I've modified TUs cost for ramp tiles from 2 to 6...and going by pointing to ground level become 42TUs, while when pointing to up level stayed 26TUs... Trajectory is absolutely the same.
-
Another test in UFO: Enemy Unknown. Ramp extra TUs was given 0. I.e. ramp walk cost is 4TUs. And modified ground TUs from 4 to 8!.. So going to ramp and 4 tiles beyond should cost... 4+4+4 + 8+8+8+8 = 48 but actually it was 50TUs (extra 2 TUs may be because of "door"). But when I pointed 2nd level from the ground, it was 30TUs only! It was like 4+4+4+ 4+4+4+4 = 28 (+2TUs for "door").
So obviously, if unit will be going lower level than pointed, he will go with TUs cost like he would be flying... He gets TUs cost of tiles of level of the target, but actually will walk on the ground.
This is real bug, which can save alot of TUs if used properly. I don't know if anyone have discovered this earlier... Anyways this could be used and people might be expecting same pathing behaviour (even it's not fair).
Did you know you can walk on water? In polar terrain.. If you point directly from craft (2nd level) over water tiles (also 2nd level).
https://www.ufopaedia.org/index.php?title=Exploiting_Collision_Detection
I guess this is of the same thing... They are calculating route through the level you're on, and TUs of your level, even if it changed during walk.
-
This is field rendering. 60TUs are marked with light green and 60TUs with light pink (80 overall + 20 reserved).
As you can see - it's not a round field, but rather "octogonic". Blue cells have TUs=0 to passthrough, red circles are objects which cant be walk thorough, but can be walked by diagonally. Light purple cells are hills (or ladders, and more intense color - more elevation it has).
-
Application updated. Some bugs was fixed, and added functionality of "GAME*" folders scanning, to switch map from different saved games (by combobox). Also several examples have been put.
I foresee another bug. When you getting through hinged door, it switched to other position, and there could be situation when your unit goes through one door two times. This issue haven't been taken into acount yet.
-
I wonder how currently A* pathfinder handle hinged door double open?
Daiky, do you handle this?
-
Volutor, I think I know what you mean with hinged door double open, but I'm not sure.
Is it where you first have to close the hinged door because it's in your way, and then open the door again to walk inside the room/building? If it's that case, the pathfinder will only take into account 1 time the door crossing TUs. Because the pathfinder itself will not change the state of the door, the state of the door only changes when you are actually walking through it.
Is it a big problem? I don't think so, as most people will see this as expected behaviour. In real life you are not going to fully close the door to open it again. So I think the bug is "fair".
-
Yeah, you got me right. And still, this is a bug, and pathfinder which meant to be picking most optimal route, will pick route with double-opened doors... i.e. not optimal.
I think it should consider concequences of going through the door... otherwise it will choose not the best path.
Indeed pathfinder doesn't change state of the door, I've faced same situation. But it doesn't have to. I believe there is a way of considering this.
-
Unless you would change the TU cost of walking through a door so it is the same as walking around the door.
Hmm, this reminds me... I don't think in openxcom there is any TU cost of opening a door with rightclick :D
-
Unless you would change the TU cost of walking through a door so it is the same as walking around the door.
Hmm, this reminds me... I don't think in openxcom there is any TU cost of opening a door with rightclick :D
There isn't any in TFTD either.
-
Opening doors for free (without passing) depreciate this door tile passing TUs cost...
There are some options:
1. Door passing cost should be 0
2. Door opening (without passing) should cost same TUs_cost as passing it.
3. If door was opened (for free), passing through empty doorway will cost same value as for straight passing, if done in the same move. But there are dealbreaker thing outthere - when you will open the door (for free), and then see alien there - you may decide to go back (through same door which is in another position). Second "switching" (closing) will also cost 0, but going through door's old location will cost you TUs.
I wonder how it done in original xcom?
If you're going through closed hinged door which have alien standing behind it, the door is opening and your move is aborted. So actually you do not cross the line, but door tile is changed to alternative (opened). Will it decrease your TUs for this "unperformed" move through the doorway, or it will be TUs-free?
-
Anyone?
As far as I remember, door open TUs (with right click) cost 4TUs, which is equal to door passing TUs. Though there are doors with 8TUs passing cost. I don't know if rightclick-opening cost 8 or 4 for those, but I think logically it should be 8, like if you're passing it. Otherwise manual opening will save some TUs which would be a gameplay bug.
-
I'd like to stick with the TFTD approach, of no TUs cost when manually opening the door.
I agree that in RL it's faster to open the door (open, not crash through it) while walking through it in one continuous action than stopping in front of it, opening it wide and only then passing through 8)
But then, XCom soldiers are in full battle gear and when encountering a door they open it instead of just kicking it wide open (the door is not damaged, it just opens) so I suppose It's a little bit faster to open then pass instead on opening and passing it in one move :D (they might hit the door with the weapon or backpack, or worse: https://www.youtube.com/watch?v=NvAvuJxk3w0 (https://www.youtube.com/watch?v=NvAvuJxk3w0))
My two cents ;)
-
You can click at tile before door, open it manually and go further. If so, we can disable TUs for going through doors at all... But this is a obvious, while comfortable BUG. I don't think we should replicate this bug... it's like... we'll keep bugs if we like them, and fix those which are uncomfortable... Firstly, it's a double standard (which is bad). Secondly, such approach (automatic - more TUs, manual - no TUs) is illogical, and have no excuse.
In order to keep gameplay coherent, we either make manual door opening costy (equal for passing through it), or make door open free, both for manual and for walking through.
-
True, this might be a "convenient" bug. I always considered to be a little bit weird to be able to open the door at no cost, but pay a "open door TUs cost" when passing through, but since I always stop in front of a door to avoid some of the reaction fire, it was, as I said, convenient.
Well, then set the cost of door opening at 4 TUs, as for simplicity's sake we should consider opening the door has the same cost regardless of the intention: open only or pass through
-
In TFTD right click door opening done with calling "walk" function to next tile with "no_move" flag set, so unit stays where it is (and keeping kneel state), just door open is happening. They just disabled TUs_Consume call, if it's a manual opening. If they reenable it - unit would stay, but TUs would be consumed as if it walks to this tile (which is wrong). I think they could be thinking of adding "half_walk" functionality(count only wall crossing TUs), but forgot to get it done (stayed at temporary "no cost"). Implementing such "door crossing" TUs consume would require alternative "walk_to_neighbor" or even "walk_to" functions. Well, they've made alot of weird stuff which hardly could be explained logically.
So such illogical things are not the best reference.
-
"Half walk"? Meaning that opening the door without passing was supposed to cost 2 TUs?
How about sticking with the intended (but not implemented) functionality for opening without passing?
But then, how should "open and pass" be considered? "Half walk" (4+2 TUs)? Or "full walk" (4+4TUs)?
-
For door passing there are 4..8TUs... For ground passing is 4TUs (almost all the time). When your unit makes a step inside, it opens the door and step to next ground tile. So its cost will be 4..8+4=8..12TUs.. By "half-walk" I meant wall passing (door opening) without getting to the next tile. So it obviously would be 4..8TUs (depending on door type).
By the way I asked a question and nobody answered: how many TUs will be consumed when you open a door without entering it in original XCOM1??? Your unit is standing next to the door, and alien is standing on the other side of it. You're left-clicking to tile behind the door. Door become opened, but your unit will stand still (because tile is occupied).
For example, getting inside UFO with one walk click will cost: 8(door)+4(ufo ground tile) = 12;
Manual (controlled) walk will be: 8(door manual opening)... looking inside, + 4 (ufo ground tile) = same 12;
So there will be no difference between manual opening and going inside and going inside with automatic door opening.
Though the only case when manual door opening will have obvious benefits, is when your unit opens it while standing diagonally.
Actually I think this right click door open (apart from cheat of free TUs), was implemented with a thought of DIAGONAL door open... In all other cases it doesn't matter - manual or not.
-
Next version of openxcom beta will have the option to first preview the path. It's just a basic coloring of the tiles on the path in green or red (if it's out of your TU range).
The first click will let you preview the path calculated by the pathfinder, a second click on the same tile confirms the path and makes the unit move.
It does not fix the problem you found with equally weight paths not choosing the best path, but allows for more control and information to the user what route the unit will take.
-
Nice. But I think coloring here is too "rough". Is it possible to make it more pale?
-
This is very, very, awesome! It takes a lot of the guesswork out of moving your units and actually fits in with the rest of the user interface! ;D
-
Volutar, yeah, the colors can be tweaked (although remind there is only about 16 colors ;)
And I probably make an option for a JA2 style preview, where the preview automatically is shown when you hover the mouse x milliseconds over a tile, so you can still walk with 1 click instead of 2.
Concerning your improved pathfinder, while theoretically it's nice, when I go back to your original "problem", I think with a simple "patch" to the current openxcom A* pathfinder I can cover 90% of all situations where you will have an actual problem in the game.
The original problem was: when you have multiple solutions with the same TU cost, you want a straight line solution for the sake of keeping out of enemy line of sight or line of fire.
To me this implies that this is a situation where you ask for a simple path from A to B in a plain field with all equal cost tiles and where there are no obstacles to avoid. In such a case you want a bresenham calculated line (= as straight possible line on a grid).
Knowing this, I imagined a patch to the current A* pathfinder where I first of all do the normal pathfinding (to know the total TU cost of the optimal path). And after that I do a bresenham path check from start to end, and if this bresenham path check did not get blocked I check the total TUs of that bresenham path is equal to the TUs of the optimal path.
When this is true, I take the bresenham path as my optimal route.
If you watch a lot of xcom LP movies you'll see how people, when there is possible danger of aliens shooting at you, will generally move forward in smaller, very simple paths. They will actually take control over the path themselves, instead of asking the AI to do a complex path and trusting it will do a good job.
Because when there is a blocking object in your path, for example a tree in the middle of a straight path, you need a very advanced AI to know which way around this object is the best, if both ways around it are the same cost.
Also, this patch will take me less than an hour I think to program. While rewriting the pathfinding from scratch, will take me more time, including possibly new bugs. Precious time I better spend on implementing large units pathfinding and a lot of other issues that are asking attention (like the ufo walls you said) :)
-
Daiky, by your words, you are actually going to replicate what i've suggested, but in more complicated manner.
If I got you right - you're going to "post-process" your A* path. Take A as start point and B - point next to it, and if bresenham check succeed (and TUs cost the same), you'll "fix" your path. Then you'll get advance for B point, and try next bresenham, and so on until it fail. Then are you going to try next A as A+1? Or take it from B? Because in second case you'll get what I've called "not tensed path" (though it will work faster). And will walk by green-purple lines instead of blue.
(https://openxcom.org/forum/index.php?action=dlattach;topic=295.0;attach=568;image)
So in order to keep path "straight" you have to get advanced your A point step by step, not by leaps of already scanned.
And you probably will get same results as mine. :)
P.S.: I've though of your method and found it will get not very nice "alterations" when there are small obstacles on the way. I believe you have to scan every B possible (not until bresenham failed) for every A. Because there are situations when you can get multiple bresenham failures, but after a while you can get bresenham success (when you get around some obstacle). I think I may try to do my own "alterator" for path.
P.P.S.: So you basically need "check_bresenham" function from A to B which will return TUs count for this "bresenham" path or -1 if there are obstacles, "replace_path_with_bresenham(A,B)", and simple double loop of A from 0 to path_size and B from A+1 to path_size (probably there could be some condition to break this loop early, for optimization sake). For maximum pissible xcom1 path with 25 steps, it will require 325 bresenham checks. For path with 50 steps it will require 1275 bresenham checks. For 100 steps - 5050 checks. One level maze of xcom map (50x50 tiles) will require 3126250 checks.
P.P.P.S.: Saying about smaller control. Okay, some people indeed prefer to move by 1 step in such situations. But not every one. Moreover, AI will suffer more, because it will get unwanted attention more often because of this.
-
The first click will let you preview the path calculated by the pathfinder, a second click on the same tile confirms the path and makes the unit move.
Suggestion.
How about having it so that holding down SHIFT makes the pathfinder appear after you have selected a unit?
This lets you preview the path without clicking; an important consideration if OpenX-COM is going to be played on laptops with badly laid-out mousepads.
-
Suggestion.
How about having it so that holding down SHIFT makes the pathfinder appear after you have selected a unit?
This lets you preview the path without clicking; an important consideration if OpenX-COM is going to be played on laptops with badly laid-out mousepads.
What if you're playing it on a device without a SHIFT? :P
-
What if you're playing it on a device without a SHIFT? :P
There could be one user defined setting that will activate the path preview - this should work on all platforms
-
Hi, for the people that don't like two clicks for every move, Volutar thought about adding a option of the path preview appearing after staying with your cursor on the same place more than 0,5sec. So this can be an alternative to the shift-click.
PS. This is the method use for JA2 as well.
The extra safety for the two-click movement is that if you clicked the wrong place by accident, you can correct. Which is what happens to me a lot, and a wrong click can mean sometimes the loss of a soldier or a whole mission. I got used to the two clicks very fast.
-
I think the two click proposal is more feasible for device without mouse e.g android, tablet, iPhone.
-
So what? Just because someone wants to port OX to android, we've got rid of nice features, like hover path hightlighting? Everything should be optional. And no feature should be denied because of platform limitation.
-
so what????????
I only provide suggestion and hope you take this into consideration.
to be optional is good ;D
I am not sure whether it is nice feature or not but I prefer Daiky's suggestion.
PS. I like to play this game on PC instead of android, iPhone, tablet, etc
-
BTW path highlighting is almost invisible on the grass, because of green palette. I think it will eb better to have kind of "foot" overlay sprites for path.
-
Chill out guys, I was just making a joke. :P An option isn't as needlessly complex as you make it out to be.
-
What about flying units? How it will work?
-
Michal, currently it doesn't :) If there is no floor tile, it can not be colored.
But the feature served it's purpose for me, to debug that straight path issue.
The large unit pathfinding is starting to work, just some glitches on the stairs still left to do...
-
I find interesting article about path finding:
https://aigamedev.com/open/tutorial/symmetry-in-pathfinding/
-
About door opening. If manual opening with right click cost 0TUs, so automatic opening when going through it also should cost 0TUs. And let them open/close doors infinitely if they wish.
-
Pathfinder exploit.
Pathfinder is perfect! My respect to developers.
But, pathfinder can be even better.
The problem.
1. If alien stand behind door, pathfinder can't get direction for my unit. And I know, alien behind closed door.
2. If my unit stand at the door, alien unit never try to open the door.
The suggestion.
When pathfinder calculate the path, it should not be taken into account undetected enemy units.
For example, if pathfinder calculate the path for alien unit, it not be taken into account undetected my units and civilian units.
On the other side, if pathfinder calculate the path for my unit, it not be taken into account undetected aliens and civilians.
This will give the dramatic into gameplay. Casual meeting will be possible at the doorway, on the stairs, around the corner.
In original Xcom rencounter were possible.
-
could you please shrink screenshots to 640x400 before posting? thank you.
-
I love screenshots with speech bubbles :)
About the exploit:
it was first brought up here: https://openxcom.org/forum/index.php/topic,586.msg5524.html#msg5524
and I fixed it.
but after this bug: https://openxcom.org/forum/index.php/topic,678.0.html
I removed the fix again, as it was causing this bug
I was reminded again here: https://openxcom.org/forum/index.php/topic,820.0.html
and here :)
If I get reminded enough times, I might even get out of my lazy chair and get in my working chair and try fix it :p someday
-
Let me guess, the working chair is the one without built-in speakers and joystick ;p
@redv: Love the dialogue.
-
I love the speech bubble also, you should make a Little Xcom comic script, create a Team and create a story following there missions.
-
How it could look like.
Notice: shadow under arrow is "transparent" as under units. It is possible within current 8bit mode, using Yankes' shader blit.
-
Me likes!
-
funny how a debugging feature for developers only, now has become almost a main feature of openxcom :) I want my simple colored floortiles back :p
-
funny how a debugging feature for developers only, now has become almost a main feature of openxcom :) I want my simple colored floortiles back :p
That seems to be the norm around these parts.