[Plugin] jcw_trace (raycast)

> Follder22

>

> It seems that there are several big plugins in this project

> 1. Q3D plugin(s)

> 2. photon plugin

> 3. jcw_trace plugin

>

> Thus it is not suitable to wrapping all things into a "single plugin", a well document template (capx) is a better solution. imo.

>

But im not using q3d

So, you're a genius? ??

Follder22 is the source available to look at?

Follder22 is the source available to look at?

Not now, i still need to fix some stuff

> Follder22 is the source available to look at?

>

Not now, i still need to fix some stuff

How many lines of events approx does it take to run all of this?

I managed to convert your plugin to C3 using a converter:

Download

Tested using the sample capx and it works

This is awesome, it works like a charm, just what Construct 2 needed.

I was using https://www.scirra.com/tutorials/902/lightning-fast-raycasting which is really optimized, but this plugin just decreased the CPU usage by a 85% aprox. with raycasted lasers and it works much better and highly accurate

thanks a lot, I hope this plugin don't cause any problem in the future

Thx for the plugin !

Can we use it to manage collisions of a moving object to calculate bounce off ? thx

Hello ,in case anyone wanted to have fewer instances of this plugin on their layout i crudely modified it to use 'tagged' rays and from now on the expression to access hit data requires tag ,as an example : Trace.HitX("tag")

It may be possible to attain such behaviour with original plugin but i couldn't grasp it.

I don't have that much experience with coding and solution i came up with is really wonky and has a major flaw because i took this tag implementation from official "Timer" behaviour ,which accomplishes it by storing 'timers' in dicitonary and freeing them as soon as they expire but i wasn't able to decide on how to free stored ray cast data and in order to do it i made another action just to free unwanted tagged ray cast data.

It would be really cool if someone could provide a better solution.

Here is the link to modified plugin :

dropbox.com/s/f61fzomgmfiv3dr/trace.rar

Hello ,in case anyone wanted to have fewer instances of this plugin on their layout i crudely modified it to use 'tagged' rays and from now on the expression to access hit data requires tag ,as an example : Trace.HitX("tag")

It may be possible to attain such behaviour with original plugin but i couldn't grasp it.

I don't have that much experience with coding and solution i came up with is really wonky and has a major flaw because i took this tag implementation from official "Timer" behaviour ,which accomplishes it by storing 'timers' in dicitonary and freeing them as soon as they expire but i wasn't able to decide on how to free stored ray cast data and in order to do it i made another action just to free unwanted tagged ray cast data.

It would be really cool if someone could provide a better solution.

Here is the link to modified plugin :

https://www.dropbox.com/s/f61fzomgmfiv3dr/trace.rar?dl=0

It is a good idea, you just need to fix that problem.

Hello ,in case anyone wanted to have fewer instances of this plugin on their layout i crudely modified it to use 'tagged' rays and from now on the expression to access hit data requires tag ,as an example : Trace.HitX("tag")

It may be possible to attain such behaviour with original plugin but i couldn't grasp it.

I'm not sure why people keep insisting that you need more instances of the plugin than you actually do. You only need 1 instance per collision configuration, and that's if you want to avoid re-configuring a single instance constantly (you should want to avoid that, don't waste CPU cycles just because you can).

All you need to do is fire off a trace and then use the data from it in the events immediately following the one that fired it, and not fire another trace until after you are done with the data from the previous trace. If you need to keep the data around while performing another trace, store it in some variables.

You can easily service 1,000 different uses of the trace plugin in a single tick and with only 1 instance. If you think you need more for any reason other than multiple collision configurations, please explain the exact scenario you believe requires it.

Hey, i'm sorry for sounding arrogant in my previous post i can't exactly recall my mindset at the time perhaps it was due to my misunderstanding of this plugin when i opted for 'fixing' nonexistent issue of having multiple instances of it. But i still like the idea of tagged raycasts as i find it a bit easier to store hit data like that without resorting to variables in c2 itself