Mine's got to do with books and algorithms. There's a series of fantasy books where the crime boss of one of the major cities as called things like "The Upright Man" and the like (Raymond E. Feist's Riftwar Saga and the others in that LONG series.) And then I enjoy writing pathfinding algorithms and the like. So I crammed 'em together to become UprightPath (Linkin' my love for fantasy and for pathing.)

Some information about the actual code in question (Whether it's completely written out by you, whether you're using some sort of library, etc.) would be useful. Asking people to watch an entire video to try to spot the error's a bit difficult, especially for those answering on a mobile device. Further, due to the speed of the video it's a bit hard to see anything beyond your 'Writing it out on the grid pad' part.

I... Broke my water heater. I'd had my bag for coke cans hanging off the exposed, insulated power cord. It wasn't a problem until I started crushing cans again instead of just tossing them in uncrumpled. The weight was finally enough to cause the power to disconnect some how (When I moved the cans and shifted the cord it powered back up. Which makes me think it was badly wired. >.>). It was brilliant. I spent the day without hot water because of it. xD

Also, reinstalled ADK and other stuff on my desktop in preparation of using it as a development computer again (After my laptop keeps continuously crashing badly on me.)

Downloaded ArtFlow to my tablet and learnt to use it. It's a great little tool, it may be all I need for 2D art, I'm using it to make some new art for my Verbal word game.

I've got several issues with it (Haven't used it in about two months though. >.>):1) Even with the settings at max opacity the pen tools tend to need layering to put down a clear specific color.2) No real selection tools.3) Paint tool glitches out at times on larger image sizes and doesn't completely cover the screen (Like, it selects a diagonal line across the image and paints everything to one side of it.) It seems like it's an issue with how the layers are stored in memory.

So, my thought is to use a combination of a flood-fill and a grid style 2d iterator~

Takes care of the currently listed cases, I believe, and does it without the whole recursive thing. The only issue is that it does 'create' a bunch of Coordinate objects (Local only), but if you're creating a map then the bit of overhead there shouldn't be too bad.

Print out your actual path, in order, and see if it's making any sense at all. I think that it's currently just all of the items that have been 'active', not the ones that act actually part of the path.

Then do a 'backtrack' through your node.parent fields and see if that path makes any more sense.

You're getting a bit closer! And don't worry, it's a common mistake and all part of learning how to do these things. :3

Basically, now, you need to change your list such that it's a sorted list (Have your Tile extend Comparable<Tile> and have your comparable return the difference between the computed Fs of the tiles) and then at the start of each iteration set active = open.get(0) (That'll ensure that you're computing the best past).

The issue with the path that you have right now is that you're adding each explored tile to the path (Your Path will look VERY similar to your closed list at current). You should be creating the path by backtracking down tile.parent once you've found your goal.

As a separate, but related note, you might also being having issues with your computation of F. Currently, the weight of the tile is being applied to the entire path when F is computed, rather than to the single node (That is to say that after it will consider a path that's taken '100' steps to get to better if the next step has a weight of 10, than a path that's taken 50 step to get to but has a weight of 25.

Also, what you're currently doing is not an A* Search algorithm. It's a heuristic Depth First Search. The difference being you're only checking the children of your current not to see which should be next to be visited. In an A* (Or other list-based algorithms) you make use of the 'open list' (A list sorted based off of the node's F value) to find your next candidate for expansion.

Further, your path's going to be very wonky because it's not actually keeping track of the best path. It's just keeping track of expansion order.

As for the current issue? Print out the expansion order and check of tx and ty are ever reached. It might be that this call: check(min, tile) && available(tile) is either failing or being overwritten by a subsequent call (IE- the tile that would get you to [tx, ty] is NOT the last expansion node (bottomRight) but the bottomRight evaluates that call to true.)

Which IDE are you using? (And what IDE? Because that makes a difference for the loading in Desktop but not Android.) It's likely an issue of you only editing the file-system and the IDE not knowing that there was a change (Eclipse is terrible at this.)

As for the other errors? It's because you've download the HTML version of the documents which the .json parser and the .pack parser can't read. It's basically getting an HTML document and going "What is this!?" Anyway, you can solve THAT problem by cloning the repo and copy/pasting directly from it, or viewing the files in their raw form and making sure that they're saving as the right type of document.

By 'Need only recognize one direction at a time' do you mean that it literally needs just one, so there are no diagonals? If so, then you can use the code that follows (Or something like it). Basically, you have to keep track of both axis that you're worried about and then make decisions off of both of them. In this case, the code ensures a 0 value when it's less than the deadzone to make computations easier. Also, when the joystick's at a perfect 45 it'll always favor the X axis.

1) Your name is suddenly in use in a way you weren't expecting it. What follows is you running and attempting to figure out what the person who now legally uses your name is doing. Sort of like an odd, confused identity thing going on.

2) Perhaps something like attempting to track down the person-- after some years-- in an attempt to get your name back? I mean, it depends on what the setting would be, I s'pose.

Also, if you just need to know which of the tiles, and perhaps which of the objects, has been touched you can do something like give each tile a bounding box and check which the screen ray passes through first. You can also give your entities their own bounding boxes for this. There are many optimizations, such as if you know which tiles are being shown (Such as if you track which of your tiles are being culled during projection).

What you get? If you rotate your screen you use the same method of checking. If you make it a 2.5d game where there is a Z component for objects (Such as hills) you will get the 'higher' tiles if you click on them rather than the tiles behind them.

Okay, let's say you define the world to have two axises. You have the Y axis which is basically the length of the Klein bottle; The part that goes from the inner surface to the outer surface. This axis is basically infinite in that it has no edges. However, it has some length Y0 such that if you travel along for Y0 distance you arrive back at the same spot you started.

Knowing this, then for some object traveling this axis there is some point on the horizon, both in front and behind, where an object on the same axis will appear to be on the surface below the object.

Now, we look at the X axis which is basically the circumference of a cylinder. When two objects are at similar Ys they will have similar Xs (Two objects at the same Y will be able to move on the same X). Objects that are 1/2 Y0 away from each other will be on opposite sides of the surface and inhabit the same X, save being on opposite sides of the Surface.

Aren't old-school game maps (Of the wrapping over head sort) basically these? I'm just saying that you can probably model it by doing positions based off of one of these maps but with some sort of mapping that states that if you're more than 1/4th a map length away on the height/length of the bottle (arbitrary Y axis) then you're on opposite 'sides' of the surface?

Further, the circumfrence surface (Arbitrary X axis) could be controlled by some sort of mapping that adjusts the relative radius of the infinite cylinder.

Of course, this doesn't help if you want to include the wonkiness of the handle if you honestly want the world to be shaped like a klein bottle.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org