I guess this deserves a bump.

Rereading this thread a few times I think I understood what this is all about. Is it me or is there practically no way to write the data back to an external csv file without using php? I was also checking this thread and got the idea that using the csv plugin for acquiring data only to resort to php to export data back to server is actually less convenient than going all for php as one would be doing as much work if not more when trying to utilize this plugin alongside php. Am I right? Can someone please guide me to a more feasible method that doesn't involve using php?

Kyatric

Sorry about the delayed response. I must thank you again. :) Your suggestion helped and I now have a simple turn based grid prototype running, can even call it a basic game. Only difference being that I had to subtract 1 from pathlist length instead of 2 when the length is over 2 but it's sorted (unless I discover a horribly glaring flaw far too late :D )

Kyatric

I hate to distract you but I have to tell this: I don't think the pathlist generated by the latest version is 0-based.

When you set one neighboring cell as the source and the other as target, pathlistlength returns 2 instead of 1. This makes calculating movement costs impractical if not impossible.

Sorry for the interruption.

Example

I'm hope you're not thinking I'm ungrateful. Quite the opposite, I'm posting this stuff for documenting what might be ironed out. :)

Meant to add this as an edit actually but it's also a seperate question. Can cells with other than square aspect be possible? Like 84x48? Until now I thought we could specify cell width and height seperately but it appears that's not the case.

I played with this a bit more and I'm sorry to say that either construct or the pathfinder behavior is looking for an excuse to crash. I found acceptable workarounds for most issues but here is the one bugging me at the moment:

I used the information on this thread for for previewing my path target by picking instances. Used Yann's and Kyatric's methods there and am having issues. I also had to lay invisible sprites around like a noob because that's all I could think of.

v1.capx

Yann's version. Instances aren't deselected properly and they often remain picked over the mouse's trail. Probably c2 issue. Workaround is to reduce the hotspot by at least 3 pixels on all sides. Quite unacceptable. Why can't there be "on mouse enter" "on mouse leave" conditions?

v2.capx

Kyatric's method. Reason why I'm using this thread right now. Successfully picks only one instance at any given moment but line 6 is problematic. Moving the mouse pointer outside the canvas or switching tabs around by mouse shortcuts locks the application up. Can't know if it's a c2 or pathfinder issue. Maybe this is simply the result of an overall unstable "on every tick" condition or maybe it only manifests itself when the pathfinder behavior is around. Either way, this is burning me out. :/

Additional request:

Pathfinder wants to register tiles with their middle pixel thus doesn't play well with the built in pixel grid. :/

In other words, I'm doing it wrong. :) It's always better not to rush it, take your time. ;)

Today I also noticed that moving the pointer outside the canvas is a sure way to crash it. Increasing the path generation frequency from every tick to a second allows it to survive longer but it eventually fails.

Also edited the capx a bit more.

Nice, thanks :)

Meanwhile I've got another report that might help you debug it more.

In a real turn based environment, movement costs and unit movement ranges come into play and one has to calculate paths before the movement is triggered then allow it accordingly. I can easily throw in a variable and compare it to the pathlist to decide whether or not the movement is allowed however I do need to calculate paths dynamically therefore I'm running the pathcheck on every tick, with issues:

With this capx, one of these things happens:

1- Works as intended for a while eventually locks up the canvas. May occur in the path generation phase before the movement is triggered with the mouse. Just hover the mouse around any element for a while and it'll lock up.

2- Canvas is frozen upon load, elements can be seen but are locked up.

3- Canvas is filled with a solid grey color.

This behavior has great potential and I'm getting the hang of it now. It'd be a shame if it wasn't actively developed so thanks for all the effort you've been putting into it.

(edited for clarification)

Also, this is how it happens vertically, from A to B and vice versa. This only happens when the sprite is on the right or below of the obstacle, never when it's to the left or above it:

<img src="http://dl.dropbox.com/u/3138530/weirdpath2.jpg" border="0" />

Excuse my constant whining but I made this badly drawn graphic to point out an unintentional behaviour. Sprite doesn't move on a straight line from A to B but rather prefers the long route I've drawn, avoiding the green obstacle by leaving a margin of 1 cell. I'm not sure if this may have anything to do with the way motion is implemented in the example or the heuristic formulas but the online demo is working as intended. Something to do with the newly modified obstacle code perhaps?

<img src="http://dl.dropbox.com/u/3138530/weirdpath.jpg" border="0">

By the way, this latest version only worked for me when I removed line 6 (version) from edittime.js <img src="smileys/smiley2.gif" border="0" align="middle" />

edit: maybe it was just the missing ,