ellestones

a place to start would be to change say_message(...) to display the message as text on the HUD rather than send the message to the owner's chat this is what you currently have: say_message(string message) { llOwnerSay(message); llSetColor(<0, 1, 0>, ALL_SIDES); llSleep(0.5); llSetColor(<1, 1, 1>, ALL_SIDES); } to get you started change to: say_message(string message) { // llOwnerSay(message); llSetText(message, <1.0, 1.0, 1.0>, 1.0>; llSetColor(<0, 1, 0>, ALL_SIDES); llSleep(0.5); llSetColor(<1, 1, 1>, ALL_SIDES); }

Rate and NewRate are comparative, as the same calculation is used for both. this calculation is of the multiplicative problem class. Where the left operand is a variable and the right operand is a constant. the OP design as posted is to use llVecMag(llGetVel()) as the left operand. whether this choice is ideal for a universal wheel is a design consideration and not a coding issue per se. However if we are going to use this choice in our design then it remains, how might we alternatively write code that more efficiently conforms to the design parameters as given. design - as animats has explored, design parameters for a universal wheel that can also be considered are things like: wheel diameter and direction amongst others. We could also raise things like gearboxes also in such a design discussion. And as you raise, is llVecMag(llGetVel()) an ideal design choice as input to an operand ? if we decide that it isn't, changing the input to the left operand doesn't change the problem class or how the class can be coded given that the right operand is a constant. Example: timer() { float m = llFrand(30.0); if (m < 0.3) m = 0.0; else if (m >= 24.0) m = 27.0; else m = (float)((integer)m / 6 * 6 + 3); // logic method // m = (m * (float)(m <= 24.0)) + (24.0 * (float)(m > 24.0)); // m = (float)((integer)(m >= 0.3) * ((integer)m / 6 * 6 + 3)); NewRate = m; }

ah! ok as the topic has opened up a bit then another way to calculate the rate is with a little bit of arithmetic. Example using the posted script parameters timer() { float m = llVecMag(llGetVel()); if (m < 0.3) m = 0.0; else if (m >= 24.0) m = 27.0; else m = (float)((integer)m / 6 * 6 + 3); // logic method // m = (m * (float)(m <= 24.0)) + (24.0 * (float)(m > 24.0)); // m = (float)((integer)(m >= 0.3) * ((integer)m / 6 * 6 + 3)); NewRate = m; }

as written there is no reason why Rate is not being surfaced in the angle procedures. Put a debug Say(Rate) in each procedure to assure yourself of this when you are assured, then suggest you remove the first call to llTargetOmega as there is not a lot to be gained by stopping the omega and then restarting it in a 2nd call suggest also that you slow down the timer. 0.1 seconds is faster than the LSL timer event can execute safely under all server load conditions. Try 0.2 or slower.

if "bandage me" is typical of the type and length of message being communicated then the simplist way would be to wear attached to HUD and use llSetText to display the message on the receivers' screen. You will able to set the text color and script a fade out effect. You won't be able to change the font or fontsize.

the script I posted above was just to show the concept of a arena bounding box and how to process typed inputs. As game design is actual terrible as wrote. It takes as inputs absolute coordinates when relative inputs should be the design examples of relative inputs are something like: /17 10 10 5 /17 -20 50 30 /17 40 0 100 /17 5 -12 /17 0 etc i post another example code which shows a way relative can be done. I would suggest you go with some kinda relative coord method rather than absolute in your game design // arena bounding box list arena = [ <128.0,128.0,20.0>, // arena origin. z = bottom of arena < 50.0, // x width from origin center 50.0, // y width from origin center 100.0 // z height from origin bottom > // 50,50,100 = 100x100x100 arena box ]; default { state_entry() { llListen(17, "", llGetOwner(), ""); } listen (integer channel, string name, key id, string text) { list coord = llParseString2List(text, [" "], []); vector v = llList2Vector(arena, 0); vector w = llList2Vector(arena, 1); // when input coordinate is out of bounds default to origin coordinate if (llAbs(llList2Integer(coord, 0)) <= w.x) v.x += llList2Float(coord, 0); if (llAbs(llList2Integer(coord, 1)) <= w.y) v.y += llList2Float(coord, 1); float f = llList2Float(coord, 2); if (f >= 0.0 && f <= w.z) v.z += f; llSetRegionPos(v); } }

come on this forum and ask Rolig how to fix it

the hard part is evaluating that the typed input is valid and to make the typed entry as simple as possible for the player. Is faster for example to type #2 #1: /17 <128.0,128.0,20.0> #2: /17 128 128 20 whether using #1 or #2 we have to check that the input coordinate is in bounds a way to do this using example #2 ... // arena bounding box list arena = [ <128.0,128.0,20.0>, // arena origin. z = bottom of arena < 50.0, // x width from origin center 50.0, // y width from origin center 100.0 // z height from origin bottom > // 50,50,100 = 100x100x100 arena box ]; default { state_entry() { llListen(17, "", llGetOwner(), ""); } listen (integer channel, string name, key id, string text) { list coord = llParseString2List(text, [" "], []); vector v = llList2Vector(arena, 0); vector w = llList2Vector(arena, 1); // when input coordinate is out of bounds default to origin coordinate float f = llList2Float(coord, 0); if (f >= (v.x - w.x) && f <= (v.x + w.x)) v.x = f; f = llList2Float(coord, 1); if (f >= (v.y - w.y) && f <= (v.y + w.y)) v.y = f; f = llList2Float(coord, 2); if (f >= (v.z) && f <= (v.z + w.z)) v.z = f; llSetRegionPos(v); } }

sometimes we want a random integer not the same as the last one integer rnd(integer mag) { return (integer)llFrand((float)mag); } integer rndNotSameAsLast(integer num, integer mag) { return (num + 1 + rnd(mag - 1)) % mag; } default { state_entry() { integer m = 4; integer i = 0; llOwnerSay("..."); // get the first one integer this = rnd(m); llOwnerSay((string)i + " : " + (string)this); // get some more for (i = 1; i < 20; i++) { this = rndNotSameAsLast(this, m); llOwnerSay((string)i + " : " + (string)this); } } }

to maintain integrity my approach would be similar to Innula by only have one dice generator for the game. create a independent dice cup object (game controller) containing script which rolls the numbers and regulates the players' turn. the dice cup sends a message to each players HUD in their turn that its their roll. the player clicks the roll button on their HUD. A message is sent to the dice cup which does the roll. The dice cup says in public what they rolled. some other advantages of game controller - multiple and out of turn clicks can be safely ignored by the game controller. - if the player doesn't roll in X time, their turn can be forfeit or dice auto-rolled depending on game rules. In either case the game can proceed and not be held up by slow play - the issue of ppl using fake HUDs has no effect on the integrity of the game. All gameplay is performed by the game controller. The HUD is only an interface to receive inputs (roll dice now) and display outputs (your score is) etc

That's seriously cool Even more cool when/if there will be a interface to visual components where class object public properties can be set at design time by the object owner. I can see an explosion of user -created components taking Sansar by storm should this be the case

thanks arton

agree

Patch First Elle Fourteenth q: (:

i never survived the last forum so I will try again (:

is there any way to preview a post before submitting it yet ? or is that coming ?

across the street I came across a discussion about skew, normal and uniform distributions for use in LSL game code as this is a new forum interface and as I have started over again recently then for my first post under my new tag I will repost on here what I posted over there + a 2-die multi-face method that skews from a normal distribution at one end to a uniform distribution at the other end integer twoDx(integer a, integer b, integer m) { integer n = ((integer)llFrand(a) + (integer)llFrand(b)) % m; if (a > b) // skew low return m - 1 - n; return n; } default { state_entry() { list counts; integer i; integer rounds = 500; integer die1 = 5; integer die2 = 6; integer magnitude = 10; for (i = 0; i < magnitude; i++) counts += [0]; for (i = 0; i < rounds; i++) { integer value = twoDx(die1, die2, magnitude); counts = llListReplaceList(counts,[llList2Integer(counts, value) + 1], value, value); } for (i = 0; i < magnitude; i++) llSay(0, (string)i + ": " + llList2String(counts, i)); } } distributions for magnitude = 10 and one die having 5 faces twoDx(5,6,10) :: normal values: 0 1 2 3 4 5 6 7 8 9 counts: 1 2 3 4 5 5 4 3 2 1 twoDx(5,7,10) :: skew hi values: 0 1 2 3 4 5 6 7 8 9 counts: 2 2 3 4 5 5 5 4 3 2 twoDx(8,5,10) :: skew lo values: 0 1 2 3 4 5 6 7 8 9 counts: 3 4 5 5 5 5 4 3 3 3 twoDx(5,9,10) :: skew hi values: 0 1 2 3 4 5 6 7 8 9 counts: 4 4 4 4 5 5 5 5 5 4 twoDx(5,10,10) :: uniform values: 0 1 2 3 4 5 6 7 8 9 counts: 5 5 5 5 5 5 5 5 5 5