Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drag path does not seem to be working correctly. #77

Closed
leowalter opened this issue Jun 22, 2018 · 10 comments

Comments

Projects
None yet
2 participants
@leowalter
Copy link

commented Jun 22, 2018

First image is from 1.4.4.2
https://i.imgur.com/29lsK1A.png

Send image is from 1.4.5.0
https://i.imgur.com/1Q1FAAC.png

With 1.4.5.0 I tried with AI on and off.

@JamzTheMan

This comment has been minimized.

Copy link
Owner

commented Jun 22, 2018

It's the same "cost" but ya. Technically, with AI on or off it uses the same algorithm to plot a path, it just ignores vbl/terrain when AI is off.

I plan to take a optimization pass in a future release to get it to do prettier diagonals...

It's "working as designed" but will hopefully "correct" it in the near future.

@leowalter

This comment has been minimized.

Copy link
Author

commented Jun 22, 2018

OK. Thanks. Will just continue using 1.4.4.2. Too many years our group has used the blue line to determine path and resolve AoO. Thanks for all the work you put into this!!!

@JamzTheMan

This comment has been minimized.

Copy link
Owner

commented Jun 22, 2018

The "blue line" path is still valid. And "technically" this would be more accurate once you put VBL in (and terrain modifiers). And if you want to walk in a more diagonal path vs up and over, you can move, right click, move, right click (to set way points).

But I get ya, it's not what you are use to. I do hope you try it on a few maps with VBL first though before giving up on it. 😄

@leowalter

This comment has been minimized.

Copy link
Author

commented Jun 22, 2018

The "blue line" is "different". Each path was drawn dragging straight from source square to destination square. One lets the elf safely pass, the other results in the elf going through the enemies square.
1.4.4.2 https://i.imgur.com/nzoxKDt.png
1.4.5.0 https://i.imgur.com/jGRvPwY.png

I understand the idea of what you are doing, but anytime you are in a large open space, where there is no VBL or terrain features, this is the result.

Keep up the good work! I am definitely not complaining. I understand you put a lot of personal time into this and I appreciate it. :)

@JamzTheMan

This comment has been minimized.

Copy link
Owner

commented Jun 22, 2018

Yep yep. but if there were npc's more in the middle, it would avoid those more in this example. Whether you go 2 block up and 6 over or 1 up 3 over 1 up 3 over the math is the same, it's just not as 'pretty'.

I did try to get that back but just sort of ran out of time. I will def note this and keep this open. You'll get a notification when this is "fixed" 😄

FYI: Free tidbit, if you Edit Token -> Config Tab -> Terrain Modifier and put a value like, say 999 in them, the PC tokens will actually avoid walking through those tokens. (All depends if your game lets that happen or not of course. I know this doesn't "fix" this issue, just throwing it out there.

@leowalter

This comment has been minimized.

Copy link
Author

commented Jun 22, 2018

Awesome! Thanks Jamz.

@JamzTheMan

This comment has been minimized.

Copy link
Owner

commented Jun 22, 2018

Notes to self...

Marking as enhancement (as working as designed).
Info on working on tie-breaking algorithm: http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html#heuristics-for-grid-maps

There are several trade offs when handling tie breaking, article goes into this pretty well.

JamzTheMan added a commit that referenced this issue Jun 23, 2018

#77: Drag path does not seem to be working correctly.
	* Tweaked the A* algorithm for more natural/straighter moves though
open spaces for both square and hex grids
	* Tweaked the A* algorithm to find shortest path more consistently

Task-Url: #77

Signed-off-by: Jamz <Jamz@Nerps.net>

@JamzTheMan JamzTheMan added the fixed label Jun 23, 2018

JamzTheMan added a commit that referenced this issue Jun 23, 2018

#77: Drag path does not seem to be working correctly.
 * Change log amended
 * Spotless applied

Task-Url: #77

Signed-off-by: Jamz <Jamz@Nerps.net>
@JamzTheMan

This comment has been minimized.

Copy link
Owner

commented Jun 23, 2018

It turned out not as hard as I thought, always good to take a step back and reexamine things. 😄

This is fixed in 1.4.5.2,

@JamzTheMan JamzTheMan closed this Jun 23, 2018

@leowalter

This comment has been minimized.

Copy link
Author

commented Jun 23, 2018

Not the same as 1.4.4.2, but much better than 1.4.5.0 and very usable. THANKS!!!!

@JamzTheMan JamzTheMan removed the in progress label Jun 23, 2018

@JamzTheMan

This comment has been minimized.

Copy link
Owner

commented Jun 23, 2018

Yea, I couldn't get it 100% the same because the math is different and more complicated now. Thanks for keeping me honest lol After taking a second look, it really did produce some "unnatural" results in open areas.

JamzTheMan added a commit that referenced this issue Jun 24, 2018

Release 1.4.5.2 (#79)
* #77: Drag path does not seem to be working correctly.

	* Tweaked the A* algorithm for more natural/straighter moves though
open spaces for both square and hex grids
	* Tweaked the A* algorithm to find shortest path more consistently

Task-Url: #77

Signed-off-by: Jamz <Jamz@Nerps.net>

* #77: Drag path does not seem to be working correctly.

 * Change log amended
 * Spotless applied

Task-Url: #77

Signed-off-by: Jamz <Jamz@Nerps.net>

JamzTheMan added a commit that referenced this issue Sep 2, 2018

Release 1.4.5.3 (#91)
* #77: Drag path does not seem to be working correctly.

	* Tweaked the A* algorithm for more natural/straighter moves though
open spaces for both square and hex grids
	* Tweaked the A* algorithm to find shortest path more consistently

Task-Url: #77

Signed-off-by: Jamz <Jamz@Nerps.net>

* #77: Drag path does not seem to be working correctly.

 * Change log amended
 * Spotless applied

Task-Url: #77

Signed-off-by: Jamz <Jamz@Nerps.net>

* Minor update to PDF Extract

 * Updated PDFBox lib to latest
 * Sync'd PDF extract code from TokenTool (similiar but not 100% same on
purpose)

Signed-off-by: Jamz <Jamz@Nerps.net>

* #80 Comparison method violates its general contract in...

 * Reverting VisibleAreaSegment to previous version...

Signed-off-by: Jamz <Jamz@Nerps.net>

* #81: Cell Highlight distance text not sizing for grid sizes

 * Cell Highlight distance text now properly scales with grid size
 * Adjusted logging slightly

Task-Url: #81

Signed-off-by: Jamz <Jamz@Nerps.net>

* CI Updates

* CI Updates

* CI Updates

* CI Updates

* Gradle Process Updated

 * Vendor property now comes from gradle.properties
 * Version now comes from Git, uses SNAPSHOT-{commit} for
development/non-tagged releases and uses Tag name if commit is tagged
 * Updated Apache logging versions
 * sentry.properties file now generated, DSN is now only configured for
tagged releases, eg Production. This prevents sentry logging during
development

Signed-off-by: Jamz <Jamz@Nerps.net>

* #41: Bug Fix to allow tokens without sight to move

 * Tokens without sight can move within current PC tokens field of view
when iFoW server options are checked
 * Tweaked sentry.properties to use dummy DSN when in development mode

Task-Url: #41

Signed-off-by: Jamz <Jamz@Nerps.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.