Thanks! Yes, it's embarrasing The distance thing is very helpful as well!

The Physics behavior has these expressions: "VelocityX" and "VelocityY", and it has a condition for "Compare (total) velocity". However, I can't see a way to get the value for "total velocity" itself .

I've looked up the formula online but can't wrap my head around it. They seem to be teaching how to get Vx and Vy, given the total/resultant velocity and angle while in C2, it's the other way around, i.e. the Vx and Vy are known and the total/resultant velocity (while seemingly known since there's a condition for it) is not accessible to the user.

I need to know how to get total/resultant velocity given Vx and Vy. Thanks in advance!

I will test later when I can but when I enable collision again, wouldn't it detect the collision again and set the laser length accordingly? What happens when the enemy laser is hitting the shield at the moment I disable collision? Then the laser would get through when it shouldn't.

That looks like another handy plugin, thanks!

rexrainbow

I don't think it'll work. I need the unit's shields to allow it's own laser through, but block enemy lasers so I can't disable collision. If it could ignore checks for certain instances only, instead of all objects of the same type, that would do it, I think. It's what my laser is doing now but testing shows your plugin is significantly faster (not to mention a whole lot easier to do).

After spending about 2 days figuring out how to make lasers and bullet-tracers, I find this excellent plugin that does it better (significantly faster according to the debug mode) and far simpler.

However, I wonder if I might request a feature. Is it possible to exclude certain instances from the collision triggers? The player unit and his allies as well as enemies all have Shields. I was hoping the light behavior could ignore collision with all instances of the Shield object belonging to the attacker and his allies.

The way I did it before was to save the attacker's UID and faction name in the laser/tracer's instance variables then make the laser/tracer ignore shields and allies of the same uid/faction. Basically, the laser/tracer would ignore collisions with objects from the same source.

If you ever solve this issue, could you post it here or, if you would, even the "How Do I...?" pinned thread. This would be very useful, I'd think.

Hey Rex, any word on the persist behavior I mentioned above? I'm now fast approaching the point where I have to choose between not using Grid Move (which I really don't want to do) or sticking with Grid Move and not using other layouts, relying instead on toggling visibility for layers.

Hey rex,

This is a(nother) great plugin as usual. I use several of your plugins and they greatly reduce the headaches that I would've gotten without them.

Anyway, is there a way to make the Board object have the persistent behavior?

In my board game, I make the main layout using your Board plugin and movement with GridMove. However, when I go to another layout and go back to the main one, I lose the functionality of Grid Move. Everything else looks the same since they all have the Persistent behavior but I can no longer move my player piece.

EDIT: I stop the creation of the entire Board (with tiles and chess) when I revert to the main layout because the tiles and chess can change according to the player's actions.

Hi LittleStain,

Thanks for weighing in! That's certainly the easiest and simplest way but, as I said in the OP, with lots of planned enemies or objects, the list can get quite long. This way, I can store all possible objects to spawn in an array and call them from there.

c4sp3r89 (little harder to type your name :)

I've fiddle with the Nickname plugin a bit and while I can't find a way to simplify it the way I think should be possible yet, it's certainly doing the job better than the way I have it right now. Thanks again!

Thanks for the reply! I will take a look at that plugin :)

EDIT: This looks like it has excellent potential! Now if I can just get around to actually understanding it lol. Thanks again for pointing me in the right direction. That Rex is amazing!

I am trying to do something along those lines OP. see: scirra.com/forum/topic75112.html where I try to get help. So far, I'm just using what seems to be an inefficient workaround.

If you wanted a simple implementation, the way I would do it is like this:

Trigger: On Death

-> select DeadEnemy| Action: set lootVar to round(random(1,3)

        -> if lootVar = 1|Action: DeadEnemy: create Loot1

        -> if lootVar = 2|Action: DeadEnemy: create Loot2

        -> if lootVar = 3|Action: DeadEnemy: create Loot3

As in my own problem however, the more Enemy types you have and the more Loot types you have, you'll have to find another way of doing it or you'll end up with a whole lot of events. Anything beyond the simplest Function is beyond me right now, so can't help there. Also when you want different chances for different loot (common, rare, etc), as I did, things become even more complicated.

8 day bump! :D

My workaround/hack is just letting C2 keep on creating random objects from the Family, checking if it's the right one (through it's instance variable) and destroying it if not.

However, it seems very inefficient. For example, even with just 4 objects in the Family (1,2,3,4) it can create 1,1,1,1,2,3,2,3,1 when you're trying to get it to create 4. This means potentially a lot of useless actions before I get the one I actually aim for. Problem just gets worse with more objects in the family.