> Updated the plugin using the 0.4.1 version of EasyStarJS. Since I practically did this on my lunch break at work, absolutely NO testing whatsoever was done so please try it and report your success here. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

>

> https://magistross.github.io/files/easy ... p_1_02.zip

>

Sweet!

Thanks for putting this together so quickly. I will test it out as soon as I can next week. I have to get through another project tomorrow.

Based on a minor tweak to the example .capx (I had to put the "destroy" under the "On path 'test' found", rather than every tick) and 10 minutes of testing, it appears to work great!

Attempt at optimization for garbage collection:

Although the example was only using about 125 objects and 6% CPU time on my Surface Pro 4, I thought I would try to optimize garbage collection by not destroying and creating new nodes every time a path was found. Instead, I created a grid of nodes on start of layout and set them all as invisible. When a path is found, I set only the path nodes to visible.

Result:

With this "optimization", CPU usage was insignificant, but frame rate dropped to an unplayable 25 fps, with a noticeable pause in pathfinding. I assume this frame rate drop is happening because of a GPU bottleneck, but I had no idea that it would be so dramatic.

Conclusion:

-Having a node object for every grid tile is more computationally expensive than just creating and destroying nodes as needed for a 28 x 16 grid.

-Better yet, don't put any node objects on screen at all. Instead of actual objects, compute direction based on the nearest tilemap square.

Further work:

I need to play around with things now to figure out how to get AIs to follow the path. I will be working in 3D with physics, so path following will be a bit more complicated, but EasyStar.js seems to be rock solid. Thank you! Thank you for putting this together -- you saved me a ton of time!

Updated the plugin using the 0.4.1 version of EasyStarJS. Since I practically did this on my lunch break at work, absolutely NO testing whatsoever was done so please try it and report your success here. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

https://magistross.github.io/files/easy ... p_1_02.zip

Sweet!

Thanks for putting this together so quickly. I will test it out as soon as I can next week. I have to get through another project tomorrow.

Anyway, just to conclude on the rotation bits. I found that multiplying pi with any positive number will rotate the Q3DModel without any problems. It's an acceptable starting point for spinning hazardous objects that are statically placed in the world.

So weird. Thank you for figuring this out.

I feel like someone should be making a list of Q3D quirks and gotchas.

> ...I ended up using torques instead of setting angles for all physics objects.

> I have no idea what is going on with the uneven angles though. It was just plain bizarre.

>

My last resort is to use torque (maybe), which, is rather overkill for a statically placed wind-turbine providing one among many other hazardous obstacles for the player vehicle (for a game I'm working on).

And the effin' angles... yes. I'm still trying to figure that out. Even if i made a 3D floor tile in Blender3D, duplicated a few, rotated them and wrote down each tile's X, Y, Z rotation on a piece of paper, then input them into as values in Q3DModel, they don't visually appear the same either.

I agree. I have found the Oimo physics is actually faster than most of the techniques I tried - to the point where I was satisfied with the performance.

> ...I ended up just ignoring it and working around it.

>

It's "workaround-able" for some games but can introduce far-reaching inefficiencies for others. I think the real question is, is rotating by a local axis -- which should have been a problem-free instruction -- even "advised" or not.

By "advised" i really mean robust, or should I just treat it simply as a non-existent function and move on?. There are a few things I'm seeing but don't have an IQ of a thousand or more.

So, if anyone can correlate why the rotations are only okay at angles 3, 6, 9, 12 etc., as can be seen here, then you're a genius (maybe). Basically values in multiples of 3 (integer) or pi.

Another really weird thing I found is that it was computationally three times as expensive to set rotation than to apply a torque to achieve the same effect. I ended up using torques instead of setting angles for all physics objects.

I have no idea what is going on with the uneven angles though. It is just plain bizarre.

It's unfortunately out of my control. The pathfinding algorithm comes from an external library. This plugin simply expose its API so you can use it in Construct. However, the version of the library that the plugin uses is quite outdated. Maybe this particular problem was fixed in a more recent version, but I can't be sure unless I try a newer version.

Wow! I'm really impressed by the speed of the algorithm!

I would love to use this in my game, rather than writing my own. Any chance that it would be an easy update to get the newer version running in the plugin?

Eh... I'm trying to rotate a collider mesh (no model) but am getting strange results. It's just me?

Does this (video below) happen to anyone else? Really small .capx test file included below.

Would appreciate any explanations as to why this happens.

I saw this problem as well when trying to apply a manual rotation to a physics object. I ended up just ignoring it and working around it.

Thanks for the information.

So you do recommend registering at least an LLC just to avoid taking a big hit if someone sues? Even if I make a game that doesn't copy anything, it's probably better safe than sorry.

If you have an income and are willing to pay the yearly filing fees, then yes. Here in Illinois, it costs me about $1000/year between LLC, attorney, accountant, Apple Developer fee, and C3 license. This does not include web hosting, artwork, equipment, advertising, software, hardware, or any other expenses. I would not be able to cover my costs on app sales alone, but with contract work I am able to pay the bills.

If I did not do contract work, there would be a 100% chance of me losing thousands of dollars because I formed a company, versus a negligible chance that someone would come after me for copyright infringement. The bottom line is that someone would have to actually care enough to sue, and there are millions of people developing things and making almost no money on sales, just like me. If you are planning to do development to support yourself full time, then yes, form a company to protect yourself. Otherwise, you run the risk of incurring lots of yearly expenses that you won't be able to recover in sales.

> Hi

>

Hi, thanks for the great plugin first of all!

Is there anyway to get a fake "3D-look" of walls?

Very cool plugin!

You could use the Q3D plugins with it to make actual 3D walls. I was toying with the idea of procedurally-generated levels, and this might be just the ticket!

What country are you from? XPF is set to default currency for:

Wallis and Futuna

New Caledonia

French Polynesia

Is that wrong?

I am in the US, but my payment defaulted to "XPF" as well. I have never heard of the islands, but they led to a fun little geography lesson.

Solved it! The problem with parenting and setting transform = Yes is that I had initially scaled the laser body model in x,y, and z. This meant that the motors were also scaled in x,y,z and came out elliptical instead of round. All I had to do was to scale each motor/wheel by the same amount whenever I created them. The correct order of operations is:

1. Create a "laserwheel".

2. Set it to the correct position on the laserbody.

3. Change the laserwheel's parent to "laserbody", with Transform:Yes.

4. Set the laserwheel's local object scale to the same ratio of Sx, Sy, and Sz as the laserbody. In this case, (self.Sx*1, self.Sy*0.6, self.Sz*0.7).

Now that everything is parented correctly, it takes a single event running each tick to correctly rotate each wheel and motor about its local y axis. This cut the CPU usage for these events by 80%.

Love the promo image! Nice work!