Messages

No. I was responding to this bit:

Hrmm... maybe I should've been clearer. By row 200, I meant the row at y = 200.

I'm saying that a 320x200 background has 200 possible values for the y-coordinate: 0, 1, 2, 3, .... 198, 199. y=200 is not a valid on-screen coordinate in this resolution; the highest possible y-coordinate, corresponding to the bottom row of the screen, is y=199. That's because you start counting at zero.

I realise that. y = 200 is out of bounds in a 320x200 background. I know how zero-based indices work. That's why I said "would be nice if there was a way to make row 200 walkable somehow" and suggested using a 320x201 background to allow me to place characters on the row at y = 200. Check your first comment though, it says "There is no row y=199 in a 320x200 background." ... that's what confused me. There is definitely a row where y = 199.

I don't know what you're trying to say, Snarky. Do you treat the axes as continuous?

Hrmm... maybe I should've been clearer. By row 200, I meant the row at y = 200. The row at y = 199 is walkable now. After setting player.z = -1, I found that I would have to redo all of my walkable areas as the characters no longer lined up with them (off by 1). Extending the room by one pixel, i.e. making it 201 pixels tall, is probably the neatest solution for me. But that requires reimporting all of the backgrounds and walkable areas, so it's still too much work. I think the whole thing is a mess and had I known about it from the beginning, I'd have made my rooms 320x201 and fixed the viewport so that only the top 320x200 was visible.

Hmmm... I guess I'll get over it then. My initial thought was that there was something wrong with my game, but when I found the same behaviour in the default game, I thought I'd ask questions. As it turns out though, it's too much fuss to shift everything by one pixels (walkable areas need to be adjusted), so I guess I'm just going to stick with it! Would be nice if there was a way to make row 200 walkable somehow. I guess I could if I extended my rooms. Thanks for the info though, Khris.

Hmm... the best site is probably this one. There's a scripting tutorial in the Help and Support section of the AGS page:

http://www.adventuregamestudio.co.uk/site/ags/tutorial/scripting/1/

If you need more groundwork before you dive in, the basic tutorial covers that:

http://www.adventuregamestudio.co.uk/site/ags/tutorial/ags/

There's also the wiki, which has a helpful tips for scripting novices:

http://www.adventuregamestudio.co.uk/wiki/Scripting,_Code_%26_Interaction

The main site also has a link to a YouTube video tutorial playlist:

https://www.youtube.com/view_play_list?p=21DB402CB4DAEAEF

I think the scripting stuff starts around part 4.

HTH

In the default game, if Roger is standing at the bottom of the screen, his feet don't touch the bottom. Here's the output of me walking to the bottom and hitting CTRL+D:

[imgzoom]http://i.imgur.com/Eq8cdOH.png[/imgzoom]

I checked a few of his sprites and there was no space at the bottom of them. Does anyone know why this happens? And is there a better solution than using player.z to adjust his position?

EDIT: It's possible, but it should be noted that it basically means redoing existing rooms. As far as I can tell, there are two equally impractical solutions:

- Change all of your rooms to be 320x201 and fix the viewport to the top of the screen. Not a big hassle, but you'll have to re-import the walkable area masks because the BG size changed.
- Shift the player using player.z = -1. A bit awkward because existing walkable areas won't line up with the player anymore.

I am able to run it full screen with the default settings under Windows 8.11, so I guess I'm not really much help. My desktop resolution is 1920x1200, so 16:10, but I don't know if that has anything to do with it. Lizzlebizzle, are you building it with 3.3.0 Update 1? The last build on the 1st of May fixed a lot of resolution switching issues. I'm not sure, but it might help others if you update to that version (if you're not already using it).

You removed the old search and the problem went away?  Do you mean you could still navigate to the point you were selecting?

More specifically, this is what I did:
https://github.com/gurok/ags/commit/d2635fa0116ea488dfa1c92171960b5911065e75

To clarify, I did not remove the old pathfinder completely. I just made it a second tier algorithm in the horz/vert case. With this in place, I could navigate the vertical paths outlined in my test case perfectly.

The old logic was:
if the line is not straight then
  try dijkstra and return on success
end if
try old pathfinder

The new logic is:
try dijkstra and return on success
try old pathfinder

I am really tempted to roll back my engine code and check that out.  If you're getting to the second search and the image is a 3x3 grid, then the first search must be hitting its limit.  Increasing the limits them can make pathfinding more successful, but it runs to the risk of introducing a more significant lag on slower machines.  I removed them on my machine.

The old search is just plain broken.

I think I may have poorly communicated what I actually did. See my outline of the logic changes above.

Agreed though! The old search is broken.

There are cases where it should work, but it fails by doubling back on itself.   Based on the text dumps that you uploaded, it looks like that's what happened.  My assumption was that the some of the quirky behavior of this old search became expected.  Otherwise, why keep it at all?  Why not use Dijkstra twice?   In fact, I tried that, and it works like a champ.  It's not an optimal solution though.

This is what I couldn't fathom. The reasoning for the use of the old search "don't use new algo on key presses" doesn't make any sense. That theory about the old search behaviour becoming expected sounds like a possibility. It would certainly explain why Dijjkstra was ruled out entirely for those cases. Perhaps this means I should hide the changes in the commit above behind a game version check, i.e. If game version is >= 3.3.1, ignore is_straight.

My main focus in getting into the pathfinding was to produce non-technical documentation in order to help users working with the current engine.

After doing that, I replaced the entire thing with an A* based strategy.  It's about 3/4 finished.  I had wanted to make an interface to allow the designers (AGS users) to control the resolution of the search.  However, after CW announced his departure and the forum started talking about refactoring, I stopped working on that code altogether and went back to my other commitments.

This is a better long term strategy, but I'd still like to patch the engine for now to at least *try* Dijkstra in these purely horz/vert cases. It does fix the problem for me. The 3x3 gridding you did to my walkable mask did not. I think the pathfinder is doubling back, like you suggested.

Regarding a future A* implementation, I think the interface could be as simple as a few values in a new Pathfinding section under General Settings, e.g.:
Pathfinder Grid Size (default = 3)
Pathfinder Timeout (default = 100ms?)
Use New Pathfinder (default = true)

Unless your project has the luxury of using its own version of the engine, if you need to get this room working, I would suggest shrinking the mask 33%, and then enlarging it to 320x200 using nearest neighbor.   If that still doesn't work, I'm at a loss... I'd have to throw it into the debugger.  I must have missed something about this system. 

Yeah, I do build my own version of the engine. I thought I would make a pull request because it's listed in the bugtracker. I think your analysis is right. You might have missed a corner case or two that causes the old pathfinder to double back, as your 3x3 suggestion didn't seem to do anything. But nobody could really know what's expected with that old pathfinder!

Try this one.

The same bug is present with that walkable area mask, TheBitPriest. After reading through that Pathfinding Granularity thread, I now suspect there's some part of my walkable area mask causing the old pathfinder to double back and/or halt due to depth. Even if clamping the path to a 3x3 grid did work for this case, I think it would be a really clunky approach.

I applied a patch to my local copy of AGS that does not use the old pathfinder over Dijkstra's algorithm when navigating straight lines and the problem went away. Similar to what I outlined a few posts above. I'm going to recommend this as a patch when CrimsonWizard gets back. The whole straight line assumption seems bogus to me.

Some more thoughts...

One possible reason for the "don't use new algo on arrow key presses" comment might be that the old pathfinding algorithm was determined to be faster for horizontal and vertical lines. Even if this is the case, that's no reason to discard the Dijkstra pathfinding entirely in these cases. We could use is_straight to determine which of the two algorithms is tested first.

I think it's more likely that this is old code though. As I said previously, WalkStraight makes reference to can_see_from, but not find_route. The keyboard modules I've seen use WalkStraight, so this find_route code isn't even called "on arrow key presses". And it's a bad assumption anyway because it doesn't cover diagonal arrow keys.

Thank you Billbis. That was very informative. I did a quick text-based dump to see what was happening with the old pathfinding:





Now, I can only speculate right now as to why it stops at those points. Perhaps it runs out of directions to try, gets confused? I don't know. But this assumption in the code:

Code: ags

; // don't use new algo on arrow key presses

Is actually incorrect anyway.

1) Diagonal key presses won't give you a vertical or horizontal line to follow
2) Keyboard movement modules use WalkStraight anyway (which uses can_see_from, but not find_route)

I could be wrong, but it feels like this chunk of code should try find_route_dijkstra and then *only* if that fails revert to the old pathfinding routine.


EDIT: I tend to think it should be this:

Code: ags

  // Try the new pathfinder
  if (find_route_dijkstra(srcx, srcy, tox[0], toy[0])) {
    return 1;
  }

  // if the new pathfinder failed, try the old one
  pathbackstage = 0;
  memset(&beenhere[0][0], 0, wallscreen->GetWidth() * wallscreen->GetHeight() * BEENHERE_SIZE);
  if (try_this_square(srcx, srcy, tox[0], toy[0]) == 0)
    return 0;

Or at the very least, use is_straight to determine the order of old/new, not skip new entirely.

Thanks Khris! Just knowing that someone else can replicate it is a big help. Your notes are pretty thorough. I've got the same results from my testing. Also, it's not tied to column 158 specifically. It just needs to be the same column that Roger walked to in the first place.

I'm still investigating. Appreciate any ideas.

I think I'm slowly going mad. I think I've found a bug, but I'm not sure if I'm missing something or maybe it's a known issue or something. Here are the steps:

1. Create a new Default Game
2. In the first room, use this as the background and the walkable areas mask:

3. Place a new label on the status line. Call it "lblStatus" and put this code in the global repeatedly_execute_always:

Code: ags

lblStatus.Text = String.Format("Player: (%d, %d)   Mouse: (%d, %d)", player.x, player.y, mouse.x, mouse.y);

4. Start the game
5. Move the mouse to (158, 69) and click. Roger walks there (expected). Let him finish walking.
6. Move the mouse to (158, 183) and click. Nothing happens. In fact this seems to be true for (158, n) as far as I've tested.

Can anyone else replicate this and does anyone know what's going on here? I'm presuming it's a pathfinding bug, but I'm open to suggestions. I thought my paths were pretty safe (no areas < 3 pixels wide).

People don't use toilets. Toilets do.

I'm sorry, am I in the wrong thread?

As this is about replacing XP, I thought this might be appropriate:

http://forums.mydigitallife.info/threads/40191-Windows-Embedded-POSReady-2009

Yes, you can replace XP with XP (for 5 more years). Just do not run MS Office. Or do, the licensing restriction doesn't seem to matter much.

Me, I run Windows 8.11 for Workgroups. I know why you love XP -- MS screwed up Explorer and progressively broke OS features in later releases. But if you want to build Windows applications, use > 4GB RAM* and test web applications in IE, you've got to stay up to date. Give in to the bloat!!



*You could run Win2000 DataCenter Edition for this.

Awww, nobody got it. It was But I'm a Cheerleader! I'm going to hand the conch shell over to Tramponline, as he was close to guessing even though he cheated ;-).

What do you call a camel with no humps?

I know the joke, but http://en.wikipedia.org/wiki/Guanaco or even llamas are in the same family.

Is the actress on the right in that last pic Clea DuVall?

Correct! The actress in the first pic should be fairly recognisable too.

Damn. Good shots! I know that movie, but I can't wrap my head around it.

Is it any way related to witches / witchcraft somehow? (frogs?)
For some reason I seem to have that association in my head.
No clue why though.

Hrmmm... no witches or witchcraft, though I did find this broom/rake handle:





And here's another shot:

No, but it is a comedy.

Are you calling Legally Blonde a comedy?

Hey, I didn't believe it either, but that's what IMDB says .

Anyway, here's another similarity/hint. Both movies have cheerleaders.

No, but it is a comedy.

So much pink and blue.