Jump to content

Advice on multiple particle effects


You are about to reply to a thread that has been inactive for 2318 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I'm making a script/scripts for an object that based on the users choice of the options will produce a different particle effect. I will have each set of parameters in separate user-defined functions. My question is, should/could I have several (up to 100) of those UDFs in one script, or should I make multiple scripts for the different effects, and communicate the intended particle effect via link message? Of course if I go the separate scripts route, I would break the effects into groups of say 10 per script instead of a separate script for each effect.

Link to comment
Share on other sites

my preference is to go with the least number of scripts. So if can achieve the goal with 1 then go with 1

if have 10s/100s of different effects then could think about putting all the effects parameters and texture uuids in a struct contained in notecard(s) in the object contents. Then only need 1 script to read and execute them all. When create a new effect then is just a matter of adding (or amending) a notecard   

 

 

Link to comment
Share on other sites


wherorangi wrote:

my preference is to go with the least number of scripts. So if can achieve the goal with 1 then go with 1

if have 10s/100s of different effects then could think about putting all the effects parameters and texture uuids in a struct contained in notecard(s) in the object contents. Then only need 1 script to read and execute them all. When create a new effect then is just a matter of adding (or amending) a notecard   

 

 

But then it would need to read the notecare each time, or possibly overload the script to read and store the parameters, which runs into the original problem of "How many can I contain in one script?" It's an object I plan to sell, so putting texture uuids in a notecard is a no-go. I thought about lists, but that would get complicated too, as not all the effects would have the same colors, sizes, push, wind, etc besides the textures

Link to comment
Share on other sites

particles are a property of the prim, not the script(s). A script is used to apply the particle property parameters to the prim. Once the properties are applied then the script is no longer needed. So if use multiple scripts then is kinda overkill, when the parameters can be stored in another form

i take your point about notecards in a sale object tho. In this case then I probably go with a struct in a list

eta: by struct I mean a strided list (is how LSL refers to this)

http://wiki.secondlife.com/wiki/LlList2ListStrided

has good examples of how strided lists are constructed and used

Link to comment
Share on other sites


wherorangi wrote:

particles are a property of the prim, not the script(s). A script is used to apply the particle property parameters to the prim. Once the properties are applied then the script is no longer needed. So if use multiple scripts then is kinda overkill, when the parameters can be stored in another form

i take your point about notecards in a sale object tho. In this case then I probably go with a struct in a list

I know that particles are a prim property. I will have a hud/dialog menu for the user to choose from options, and each option chosen will produce a different effect. It's not a one-off thing where they choose an option once and that's the particles that the object will have forever. Some of the choices will target objects or avatars with particles, some of them will rez objects as well.

I suppose I could write it something like:

list effect1 = [particle params];

list effect2 = [particle params];

etc., but that won't take the rezzing into account which is why I would need to do it like:

option1(key target, string object){llParticleSystem([blah blah,PSYS_TARGET, target]);llRezObject(blah blah);llSetTimerEvent(xtime);//to stop the particles after certain amount of time}option2(key target){llParticleSystem([blah blah,PSYS_TARGET, target]);llSetTimerEvent(xtime);//to stop the particles after certain amount of time}bits of events:::timer(){llSay(some channel, "Die");llParticleSystem([]);}

 

Link to comment
Share on other sites

yes. you pretty much onto it

i just add that using separate variables for each particle param list means that we can't reference them from a single piece of code without creating a whole bunch of IF statements

a struct list is the way to go to avoid this. Some p-code example:

 

list table = [   params for effect 1,   params for effect 2,   ...   params for effect N];// when the length of the stride (record) is equal for all then 
// is the same as a table of fixed length records.
// Each record can be read by multiplying the ordinal
// index (recnum) by the length of the record. Example:integer reclen = 10; // or whichever integer recnum = 0; // or whicheverinteger recpos = recnum * reclen;// 0 * 10 = 0; 0 + (reclen-1) = 9;// 1 * 10 = 10; 10 + (reclen-1) = 19; etc // when the length of the 'record' is unequal
// (some 'records' have more elements/fields than others
// then need a second list to index the 'table'list recpositions = [0, 8, 15, 23, ..., N]; // where N is the last element
// and contains the length of the table list recnum = 1; // or whichever
recpos = llList2Integer(recpositions, recnum);reclen = llList2Integer(recpositions, recnum + 1) - recpos;
// example read

list record = llList2List(table, recpos, recpos + reclen);

llParticleSystem(record);

 

  eta p-code typo

Link to comment
Share on other sites

hmm, so I went to test how that handled things separated by pipes (the particle masks), it basically ignores them. also the only way I could get it to compile was to put the list inside a custom function. it doesn't like lists with pipes as a global. i suppose I could construct the list the same way by making a separate list of masks and using the unequal method you  mentioned, but I'm not sure how to construct the list using llList2List using pipes instead of commas

Link to comment
Share on other sites


Ruthven Willenov wrote:

hmm, so I went to test how that handled things separated by pipes (the particle masks), it basically ignores them. also the only way I could get it to compile was to put the list inside a custom function. it doesn't like lists with pipes as a global. i suppose I could construct the list the same way by making a separate list of masks and using the unequal method you  mentioned, but I'm not sure how to construct the list using llList2List using pipes instead of commas

Those "pipes" aren't separators, they're bitwise logical operators. They're just mashing together bits to make a single integer bitvector value for the PSYS_PART_FLAGS parameter.

Assuming these flags are user-set (as I understand your application), then you'll need to handle them regardless of whether you're using one script or one-per-effect.

Link to comment
Share on other sites

sorry, I missed this

the | is a operator which we can't use in a global assignment. We have to convert what it operates on to the result (hex is easiest). Example pcodes

 

list table = [ // record 0: effect A    PSYS_PART_FLAGS, 0x108,  // PSYS_PART_WIND_MASK | PSYS_PART_EMISSIVE_MASK. 0x008 + 0x100     PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_EXPLODE,     PSYS_PART_START_COLOR, <1.0, 0.0, 0.0>, // record 1: effect B   PSYS_PART_FLAGS, 0x10C,  // PSYS_PART_WIND_MASK | PSYS_PART_BOUNCE_MASK | PSYS_PART_EMISSIVE_MASK. 0x008 + 0x004 + 0x100   PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE_CONE,    PSYS_PART_START_COLOR, <0.0, 0.0, 1.0>, // record 2: effect C   PSYS_PART_FLAGS, PSYS_PART_WIND_MASK,   PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_DROP,    PSYS_PART_START_COLOR, <0.0, 1.0, 0.0>]integer reclen = 6;integer recnum = 0;integer recpos = recnum * reclen;list record = llList2List(table, recpos, recpos + reclen - 1);

  eta: i cant count (:

 

Link to comment
Share on other sites

I read some of the hexidecimal page on the lsl wiki, and kind of understand it, but not sure if I have it correct in how to add them together, like your second example resulting in 0x10C. I did try:

default{    state_entry()    {        llOwnerSay((string)[PSYS_PART_WIND_MASK | PSYS_PART_EMISSIVE_MASK]);            }}

which spits out an integer, so could I potentially drop the flags for each particle effect into this script and copy the integer it spits out to the list in the mass script?

Link to comment
Share on other sites

one other thing, I can't seem to find the other place that I read, but this page says:

LSL list has a limitation in length, in the sense that a programer cannot start with a list with more than 72 items.

In order for programer to have a list of more than 72 items, she must create 2 or more lists and join them.

I realize that's an old article, but was wondering if that still applies. I also read on the page that I can't find again, that the compiler can only have the 72 limit, but the script operations can grow the list larger with enough free memory, so basically in order to compile a larger list, it would need to be split into multiple lists when typed into the compiler, then added together in say, state_entry by doing:

 

list ListAll;list List1 = [things, more things, etc];list List2 = [things, more things, etc];default{state_entry(){ListAll = List1 + List2;}}

 

Link to comment
Share on other sites

i am not sure. That might be the case for compiling to LSL bytecode given the date of the article. It may be more when compiling to Mono. Dunno exactly

the way to know for sure is to type in a list, and see how many elements can be stuffed in

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2318 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...