Particles - Changing image/colors via behaviors?

supafly129

I have one "main character" actor that has several particle rules depending on which character the player selects (the particle colors are different depending on the character). This can get pretty code intensive unfortunately.

I'm trying to make my code leaner but it doesnt seem like there's a way to link the RGB values or image to a table/attribute.

Wondering if spawning actors instead of particles is the only solution, but also concerned that will impact RAM/memory.

jamie_c

You're right, there is not way to link the image or color attributes of particles to tables or attributes.

I think it's pretty common to spawn actors if you need that kind of control. It might impact your performance but the only way to find out is to test it. If you are not spawning a ton of actors from a ton of actors it will likely be fine, but really have to test it to see.

Socks

@supafly129 said:
I'm trying to make my code leaner but it doesnt seem like there's a way to link the RGB values or image to a table/attribute.

Could you not do a simple 'otherwise' stacked sort of thing (that's a coding term).

If X is 1
--Particles Red
Otherwise
--If X is 2
----Particles Green
--Otherwise
----If X is 3
------Particles Blue
----Otherwise
------If X is 4
--------Particles Yellow

etc . . . ?

Wondering if spawning actors instead of particles is the only solution, but also concerned that will impact RAM/memory.

It certainly will, although you can get away with a lot of spawned actors (especially if they have no rules of their own - or a few simple rules) . . . but compared to particles we are looking at a couple of hundred actors vs thousands of particles, particles are vastly more efficient.

supafly129

Thanks guys. @Socks Currently I do have something similar like "When Char = 1, particles blue, When Char = 2, particles red etc). Is using "otherwise" more efficient than having a separate rule?

Socks

@supafly129 said:
Is using "otherwise" more efficient than having a separate rule?

It is, using the Otherwise section means GS will not need to evaluate rules below the one that is currently triggered.

So . . . if our rules are separate like this . . .

If X = 1 then do some stuff
If X = 2 then do some stuff
If X = 3 then do some stuff
If X = 4 then do some stuff
If X = 5 then do some stuff
If X = 6 then do some stuff

. . . and our value is (for example) 4, GS will need to evaluate all six rules, even though we already know X can have only one value at any one time - and it's already met the conditions to trigger rule 4.

If we use the Otherwise section like this . . .

If X = 1 then do some stuff
Otherwise If X = 2 then do some stuff
-- Otherwise If X = 3 then do some stuff
----Otherwise If X = 4 then do some stuff
------Otherwise If X = 5 then do some stuff
--------Otherwise If X = 6 then do some stuff

. . . then as soon as GS hits the condition that fits X (in this case '4') then it won't need to (and cannot) evaluate any more of the rule, because if X is 4 then the Otherwise section below that cannot trigger, as it can only trigger if X is not 4.

In this situation, every X value (except for 6) gives GS less rules to evaluate.

supafly129

@Socks interesting ill make a note of that, thanks again!