[Behavior] Grid based sight

bowiz2

100 - round(min((distance(Sun.X, Sun.Y, Sun.Sight.CurPixelX, Sun.Sight.CurPixelY))/(Sun.Sight.Radius * Sun.Sight.Tilesize),1) * 100)

This above should work set the LightCell effect to "Destination out."

Finally, the drop off effect as I've mentioned (the core bit you talk about) is some elaborate maths which at the moment I can't think of, try Google! <img src="smileys/smiley17.gif" border="0" align="middle" />

Hi Rez - I really like what you have done so far and I question whether this can be done even more efficiently without the use of sprites - I wonder if drawing vectors with canvas to create the effect would be better in the end.

something I looked up

I don't know if you'll continue to work on this plugin or not - I just wanted to share that link to see if the second example was possible

Hi Rez - I really like what you have done so far and I question whether this can be done even more efficiently without the use of sprites - I wonder if drawing vectors with canvas to create the effect would be better in the end.

something I looked up

I don't know if you'll continue to work on this plugin or not - I just wanted to share that link to see if the second example was possible

I understand there are vector functions for plugins however I noticed Ashley mention about slow down using to many of these. I wanted to leave the rendering to the designer rather than my plugin as this can be used for many different things.

If I come across a good method I would add it to the plugin believe you me!

I'll have a look at your reference. Thanks Vile! <img src="smileys/smiley20.gif" border="0" align="middle">

Hi,

I just tried to download your behavior, but it appears that the link is no more available? Is there a place where can we find it?

Thank you for sharing your work!

Beurt

Sorry for the delay Beurt.

Seems I may have deleted the original files will sort this out tonight for you.

I'm currently working on a much, hopefully, simpler cleaned up version which also includes path finding. The behaviors new name will be "Rogue" as it incorporates two functions relating to roguelikes; path finding and grid based sight! One thing I don't like with my current release is it's usability and accessibility which will hopefully be much better in this next release.

Speed wise not much difference although rendering is better in the new releases of Construct 2 anyways.

Watch this space, once I've ironed out the bugs a new version will be uploaded! <img src="smileys/smiley9.gif" border="0" align="middle" />

P.S. Two things eluding me at the moment, a way to have smooth timed movement and shadow rendering from the runtime... <img src="smileys/smiley11.gif" border="0" align="middle" />

Beurt

Sorry for the delay Beurt.

Seems I may have deleted the original files will sort this out tonight for you.

I'm currently working on a much, hopefully, simpler cleaned up version which also includes path finding. The behaviors new name will be "Rogue" as it incorporates two functions relating to roguelikes; path finding and grid based sight! One thing I don't like with my current release is it's usability and accessibility which will hopefully be much better in this next release.

Speed wise not much difference although rendering is better in the new releases of Construct 2 anyways.

Watch this space, once I've ironed out the bugs a new version will be uploaded! <img src="smileys/smiley9.gif" border="0" align="middle" />

P.S. Two things eluding me at the moment, a way to have smooth timed movement and shadow rendering from the runtime... <img src="smileys/smiley11.gif" border="0" align="middle" />

The link *should* work now.

NEW plugin: I look forward to it.

In the meantime, though, could you upload an example project using this plugin? The download doesn't come with one, and I can't figure out how light cells work. :c

00Rez

The link is working perfectly now: thanks !

I'm eager to test your new plugin :-)

seven

Beurt

New version uploaded still alpha let me know what you think and if any problems occur...

Rez

seven

Beurt

New version uploaded still alpha let me know what you think and if any problems occur...

Rez

Updated today see first post.

Update!

Upcoming changes (r2.2):

• Radius is now set within actions.

• The action to draw sight cells now has the options to draw "seen", "not seen", etc.

To do:

• Need to remove various crap from the scripts.

• Better opacity rules when drawing cells.

• Choice of using custom opacity rules.

• Make smooth grid movement work. <img src="smileys/smiley19.gif" border="0" align="middle" />

I'm impressed at the performance of this, compared to event-based field of view. However, there are a number of bugs with pathfinding. I've modified your demo to demonstrate: here.

You can cause a crash a number of different ways:

-Place a second instance of the Enemy object.

-Require the Enemy to find a new path as often as it moves.

-Right-clicking excessively will eventually cause a crash. This usually happens when the Enemy is adjacent to a Blocker object (orthogonally or diagonally) even when the object is not in the way of the path. Oddly enough, this never becomes an issue if you control the player with the arrow keys.

There are also some unexpected behaviors which, although not exactly bugs, would still be considered unexpected:

-The behavior assumes all objects are equal to the grid size. This becomes an issue e.g. if using a tiled background for the walls.

-In some cases, the behavior thinks the object for which fov is being calculated is inside a wall. I haven't yet been able to reproduce this outside of one project, but one solution is to ignore the tile the object is currently occupying.

I'm impressed at the performance of this, compared to event-based field of view. However, there are a number of bugs with pathfinding. I've modified your demo to demonstrate: here.

You can cause a crash a number of different ways:

-Place a second instance of the Enemy object.

-Require the Enemy to find a new path as often as it moves.

-Right-clicking excessively will eventually cause a crash. This usually happens when the Enemy is adjacent to a Blocker object (orthogonally or diagonally) even when the object is not in the way of the path. Oddly enough, this never becomes an issue if you control the player with the arrow keys.

There are also some unexpected behaviors which, although not exactly bugs, would still be considered unexpected:

-The behavior assumes all objects are equal to the grid size. This becomes an issue e.g. if using a tiled background for the walls.

-In some cases, the behavior thinks the object for which fov is being calculated is inside a wall. I haven't yet been able to reproduce this outside of one project, but one solution is to ignore the tile the object is currently occupying.

Thanks for this seven.

I'll have a look. With regards to tile size are you saying to calculate the cells that are blocked based on the dimension of the object rather than position and tile size?

The wall thing occurs when you place the "player" on top of a cell that is blocked didn't think it blocked itself?

Working on the pathfinding <img src="smileys/smiley5.gif" border="0" align="middle">

— cells based on the dimension of the object: yes. I think it's still safe to assume that all objects for which sight is calculated will be a multiple of the tile size; but if the object is 2x2 (in grid cells) or is a Tiled Background that is extended outward, more than just the origin of the object should be recognized.

—: sorry for not being clear. the player can be to the left of a sight-blocking object (presumably to the left because that is the origin of the object) and have all sight cells disappear, as if the player actually went inside the wall. I haven't been able to isolate the problem, but it's enough to ignore the tile the player is currently occupying when calculating fov.

Bug:

Using your example, if I scroll the layout at all based on the player position it completely screws up the pathfinding.