Particle effects problem

I've created a script that makes a list from a notecard. Part of the information obtained are specs for a particle effect. However, the particle effect does not seem to be working. Here is part of the code and maybe somebody will be able to see why it doesn't work.

This reads the notecard.

state getSpecs
{
	state_entry()
	{
		gQueryID = llGetNotecardLine(spell, gLine);			// request first line
	}
	dataserver(key query_id, string data)
	{
		if(query_id == gQueryID)
		{
			if(data != EOF)						// not at the end of the notecard
			{
				spellSpecs(gLine) += data;			// output the line
				gLine++;					// increase line count
				gQueryID = llGetNotecardLine(spell, gLine);	// request next line
			}
			else
			{
				if((integer)spellSpecs(0) == TRUE)
				{
					state menu;
				{
				else
				{
					state castSpell;
				}
			}
		}
	}
}

And here is the particle effect part of the script.

		llParticleSystem([
			PSYS_PART_START_SCALE,		llList2Vector(spellSpecs, 2),	// Start Size, (minimum .04, max 10.0?)
			PSYS_PART_END_SCALE,		llList2Vector(spellSpecs, 3),	// End Size,  requires *_INTERP_SCALE_MASK
			PSYS_PART_START_COLOR,		llList2Vector(spellSpecs, 4),	// Start Color, (RGB, 0 to 1)
			PSYS_PART_END_COLOR,		llLIst2Vector(spellSpecs, 5),	// End Color, requires *_INTERP_COLOR_MASK
			PSYS_PART_START_ALPHA,		llList2Float(spellSpecs, 6),	// startAlpha (0 to 1),
			PSYS_PART_END_ALPHA,		llList2Float(spellSpecs, 7),	// endAlpha (0 to 1]);
			PSYS_SRC_BURST_PART_COUNT,	llList2Integer(spellSpecs, 8),	// # of particles per burst
			PSYS_PART_MAX_AGE,		llList2Float(spellSpecs, 9),	// how long particles live
			PSYS_SRC_TARGET_KEY,		target,				// key of a target, requires *_TARGET_POS_MASK
			PSYS_SRC_PATTERN,		llList2Integer(spellSpecs, 10),	// 1=DROP, 2=EXPLODE, 4=ANGLE, 8=ANGLE_CONE
			PSYS_SRC_INNERANGLE,		llList2Float(spellSpecs, 11),	// aka 'spread' (0 to 2*PI)
			PSYS_SRC_ACCEL,			llList2Vector(spellSpecs, 12),	// aka gravity or push, ie <0,0,-1.0> = down
			PSYS_SRC_OMEGA,			llList2Vector(spellSpecs, 13),	// Spin
			PSYS_SRC_BURST_SPEED_MIN,	llList2Float(spellSpecs, 14),	// Minimum velocity for new particles
			PSYS_SRC_BURST_SPEED_MAX,	llList2Float(spellSpecs, 15),	// Maximum velocity for new particles
			PSYS_PART_FLAGS,						// Flags
			// Choose from the following options what you want enabled:
				PSYS_PART_EMISSIVE_MASK |				// particles glow
				PSYS_PART_FOLLOW_VELOCITY_MASK |			// particles rotate towards where they're going
				PSYS_PART_FOLLOW_SRC_MASK |				// particles move as the emitter moves
				PSYS_PART_INTERP_COLOR_MASK |				// particles change color depending on *_END_COLOR
				PSYS_PART_INTERP_SCALE_MASK |				// particles change size using *_END_SCALE
				PSYS_PART_TARGET_POS_MASK				// particles home on *_TARGET key
		]);

it may also be the way I'm putting in the information in the notecard, but the only thing I could think of is that maybe I shouldn't be putting "<" and ">" in the vectors. Other than that I'm lost at what it could be.

LSL does not have Arrays so

spellSpecs(gLine) += data;

isnt legal syntax.

spellSpecs += data;

Likewise

if((integer)spellSpecs(0) == TRUE)

should be

if(TRUE == llList2Integer(spellSpecs, 0) )

And yes Vectors require < > 's

|Rather than storing into a list you may be better off storing directly into the correct variables. Slightly more over head in the data server event but less memory useage.

actually those were mistakes in the copy on my comp, I guess I missed them. I have fixed those already in the version actually on sl, but the grid is down and can't get to it. so thats my bad. Is there anything else that could be causing it because what you showed me is already fixed and it still wasn't working.

Without seeing your notecard its kind of hard to know for sure.

I'd drop: llOwnerSay(llList2CSV(spellSpecs)); into the particle script to check you're really getting what you think... I notice, for example, your lowest list element is 2 (for PSYS_PART_START_SCALE). What happened to 1?

the grid is back online so I will post the notecard. as far as what happened to 1, well lists start at 0. this is a spell hud I have been working on. 0 says whether the spell is cast on another person, or if it is cast on the user. 1 gives the animation name of the animation to be played. but I will put in an llOwnerSay to check it out.

1
Cast Foreward
<0.1, 0.1, 0.1>
<1.0, 1.0, 1.0>
<1.0, 0.8, 0.0>
<1.0, 0.0, 0,0>
0.8
0.0
20
1.0
2
0.25
<0.0, 0,0, 0,0>
<0.0, 0.0, 5.0>
5.0
1000.0
15
1
fire
1

I checked what the list is putting out and apparently all of the vectors are being set to zeros for some reason, I'm not sure why. And it seems to be just the vectors being affected. Any suggestions.

Couple of things, in your posted note card you have several stray commas (e.g. <1.0, 0.0, 0,0>

...and, can you try this: spellSpecs(gLine) += [data];

With the square brackets. That's the way I tend to append lists.

Oh, and you can also put the llOwnerSay stuff in the dataserver Event if you want to 'watch' the data values and spellSpecs list being bult.

I think we all use lots of llOwnerSay's to debug our scripts. Heh, or llSay(DEBUG_CHANNEL, "text"; if you want to see it in-line with any other debug messages the script is reporting.

I hadn't noticed the stray commas b4, thanks. as far as using the square brackets, I checked and thats what I did. so no problem there. the information seems to be entering into the list just fine, but the vectors are still registering as zeros when it gets down to where the particle effect is. This I do not understand, since the only times before then the list is only called to bring information out of it, it doesn't change any of it. Yet it keeps changing to zeros.

Perhaps a bug in the llList2Vector command?

Not a bug a 'feature'.

See: http://cheesefactory.us/lslwm/llList2Vector.htm

then what good is llList2Vector?

Each element of a list has a value and a type. I'm guessing that a line from a note card is always a string... so, you might do something like this:

spellSpecs += [(vector)data];

...but that would make them all vectors, so... the note card line could carry both the value and the type:

V<1.0, 1.0, 1.0>

if llGetSubString(data, 0, 0) == "V" spellSpecs += [(vector)llGetSubString(data, 1, -1)];
else etc.

It all depends on what you're trying to do, and the coding 'cost' of casting latter rather than sooner. You can have hours of fun with note card input... especially if the 'user' gets to update it.

Thanks, I just used (vector)llList2String. It works now but now I'm not sure if I want to use the script. The delay caused by getting the information the note is too much, or at least much more than I'd like. Is there a way to do something similar that has less of a delay?

You could preread the notecard, that way the delay is only at start up.

Or you could create hardcoded spell scripts that are called via linked messages.

Another idea would be to examine the spells for patterns and try to compress the data in some manner.

There is also the Notecard name trick, create a blank notecard and store the data in its name, there is a VERY limited amount of memory to play with (128 bytes?) but with thought and possibly combining the compression idea its possible.

need any more?

Yes, reading note cards is slow.

You only really have the option of reading them once and allowing all the information to persistent as variables if you want to avoid incurring the read-time over and over. But, of course, that all depends on your application and how much memory those variables will consume.

In your case I don't know how many spells you have but you could load many spells... all into a single list. Then, say each spell consumes 20 entries in that list, you can extract spell n by looping through the list from (n - 1) * 20 for 20 elements, or by using llList2List to extract a portion of the large list into a working list.

Also, bear in mind, that if the values are never going to change, you can just hard-code the lists although this obviously makes the script inflexible - again it depends on the application.

Sooner or latter it often comes down to juggling lists so either way it would be good practice.

If memory becomes a constraint things can get even more convoluted and you may need to employ helper scripts. Sometimes things split into more than one script in a neat and elegant way, other times it just gets hacky.

In any event, llMessageLinked and its associated Event: link_message are the way to have scripts communicate with each other under-the-covers. For example, the main script could request the data for spell n from a secondary script which then sends that information to the main script. The secondary script would initially read the note card and do nothing but store information. Confidence with transforming data between strings and lists then becomes important because that's essentially what the llMessageLinked function in one script communicates to the link_message Event in another script.

Or, you could have a script for each spell.

And so on.


<waves at Newgate> I've typed it now so I'm gonna post it.

*waves back* accidentally turning Pale into a small purple bucket with his new spell wand.

*waves back* accidentally turning pale intoa samll purple newt with his new magic wand

Turns out the delay really isn't that much except in high lag. Unfortunately the place I'm designing it for is just that. So I might keep this code and sell it as version one till I get one for high lag areas finished. Or just sell that one because the point of using notecards was to let users make their own spells for the system more easily. Will probably just hard code it. And thanks a lot for your help.

If thats the case then your best bet may be a hybrid solution.
Use notecards but have each one processed by a seperate script at start up or on change.