Strange behaviour in A* pathfinding - path-finding

Please watch this GIF for better understanding
.
I am encountering this strange behaviour in A* pathfinding. One thing I've got to say is that my G-cost formula is just
distance(this, startNode)
I have a problem in understanding proper G-cost formula. Please correct me, because im probably wrong. So the G-cost of the current node should be
this.gCost = parent.gCost + distance(this, parent);
Where distance(this, parent) returns either 10 or 14. In this way gCost will be calculated by following the path made by parents and not the shortest path? Am I right?
Also - once parent is set, I do not update it - I think this is the main problem. Could you explain me in pseudo-code when to change node's parent?

Yes, that's the correct way to calculate g-cost. As for updating the parent, you do it when the g-cost you've calculated is lower than the previous g-cost for that node.
If it helps, think of nodes as starting out with a g-cost of infinity, and you set the parent of a node whenever you can lower the node's g-cost.

Related

How can I get a Clip object for a ClipLauncherSlot?

I have a ClipLauncherSlot in Bitwig API, and I'd like to get ahold of the Clip within it so I can transpose it on user input.
The docs aren't online that I know of, so I can't link to them. But extensive searching has yielding absolutely no way of getting ahold of Clip objects in general.
I think you're supposed to work with a CursorClip.
Instead of directly accessing the clip, you access it through a CursorClip. The CursorClip will follow your selection and always represent the currently selected clip.
Something like this:
CursorClip cursorClip = host.createLauncherCursorClip()
clipLauncherSlot.select()
// Now your cursorClips represents the desired clip.
cursorClip.transpose()
Not entirely sure about the exact implementation, maybe you have to do some additonal steps for the cursor to correctly follow, but something like this should work.
See also here: https://www.kvraudio.com/forum/viewtopic.php?t=550738 for a similar problem. They had some problems with execution time, keep that in mind if you run into unexpected behaviour.

JavaFX Game Issues with wall boundaries

I am having trouble getting my simple JavaFX Maze Game to work. I just wanted to do this to test how much I knew, and I have gotten almost to the end.
All I want to do now is see if there is a way for me to combine all of the Rectangle2D Boundaries into a single bounding shape for me to do collision detection with.
Right now, I have maze walls set up like
this, and I have to check for collision against every single one of the wall objects, which I have contained in a list.
What I want to know is there anyway of turning that into a single shape that I can check collision against. That would make my job so much easier when it comes to finishing my game.
EDIT 1: The red boxes in the image are just there to represent the Rectangle2D bounding boxes. They will not actually be there in the final product.
EDIT 2: All of these have been created using a simple black square sprite, and all of the bounding Rectangle2D boxes are using the javafx.geometry package, not the javafx.scene.shape package.
Any help would be appreciated. Thanks in advance!
Do you mean union many shapes into one?
Thanks to the help of the comment thread on Powercoder's answer, I was able to get it figured out. Instead of using javafx.geometry classes, I was able to switch to javafx.scene.shape classes, which allowed me to finish everything I was trying to do.
Here is my old code: https://pastebin.com/1DBXuq79
and here is my new code: https://pastebin.com/uXTrcsZ2
For anybody who wants to compare and figure out how I changed it.

cytoscape: Dagre-layout prevent nodes from laying on edges

I am using cytoscapejs with dagre layout (https://github.com/cytoscape/cytoscape.js-dagre). I am very happy with this extension, however, there is one problem I am struggling with. In particular, I would like to prevent that nodes are allowed to lay over edges. Because of that, there are some examples where one cannot distinguish between an edge from a node to a successor and an edge from the successor of the particular node to the succeeding node. There is also an open issue regarding this misbehavior (https://github.com/cytoscape/cytoscape.js/issues/1078)
I allready tried out other curve-style layouts such as 'segments' and 'haystack' but unfortunately without success.
Does anyone of you have an idea how to do that?
Thanks in advance
Andy
You'd have to convert the points that Dagre gives you into segment values. You could put those values in .scratch() to be used in a mapper.
See https://github.com/cytoscape/cytoscape.js-dagre/issues/5
There are a lot of things in the queue for Cytoscape and the extensions, but unfortunately time and resources are constrained and this feature request is relatively low priority. You're welcome to make a pull request on the extension if you'd like to use the feature.
Thanks

Deleting a property from a node in Alfresco

I want to remove a property from a node.
Using "removeProperty(NodeRef nodeRef, QName qname)" i can remove it, but i don't know will it cause any problem(like data correption, indexing issue or something ).
Can anyone please help me
The short answer is, no - it won't cause any data corruption or indexing issues. One caveat to this, the data model will not allow you to remove mandatory properties (you'll get an error if you attempt to do this). It will not cause any issues with indexing.

How to make correct PathFinding for large size entity in cryengine?

I have been confused by the pathfinding problem for a few days, it seems that the space between generated path and forbidden area are constant. I am really dry, and did not find anything relating to my question on official documentation.
I have tried to modify "pathfindProperties.xml", there is no difference when switching different "Type"
Scale up the radius of collider
is there anybody can give me a help? I really appreciate it!
{A screenshot of my question: http://www.crydev.net/download/file.php?id=86461}
After investigating the problem, I found a solution:
To use the Multi-layer navigation mesh, rather than the default navigation system. And define a proper volume for actor via "NavigationType" property.

Resources