revochen Mayne

Hello Wanda! I was testing it by setting my viewer language to german and i still got the object description field text in english. So it seems to be a server side action and english only, no matter what viewer language is set.

Hi Blue! As LSL is a procedural language, it's a good entry point to start. Think of programming languages like RL languages. Some of them are easier to learn, others rather hard. They all explain objects or behaviour in some way, more or less efficient. They might have advantages over or disadvantages to others. Some languages might have their root in another older one. A language might change by time, grows or deprecates stuff or even stops existing. I agree with Innula and the reason of scripting languages being similar to more advanced programming languages like C# or C++ is, because these programming languages are used to make the SL viewer and scripting work server side. They are called object oriented and much more advanced than scripting is. A lot of programmers started by scripting including me. It might takes some time and hair pulling nights to get any specific concept of a language and make things work with. But it's worth it for sure and there are very helpful resources like Innula already posted. Don't hesitate to ask for help if you're stucked either through group chat or forum. We all had to start once and know how hard it might be to try finding bugs and fix them.

DarkDemonia wrote: Denke auch mal nicht das da jemand antwortet zumindest nicht in den naechsten 4Wochen.(Weil nur Basic Account) Ich musste auch vor etwa zwei Wochen den Support kontaktieren und habe innerhalb von einem Tag eine Antwort bekommen. Es ging zwar um etwas Banales (Items von mir auf dem Marketplace) aber ich bin auch nur Basic. Ich kann verstehen, dass dich das ârgert, aber warte doch noch 1 oder 2 Tage. Ich bin mir sicher, dass sich jemand um dein Problem kûmmern wird.

Sorry, wasn't intended as offence. I even love those type of code allthough i rarely understand it yet. My test result is: 57 % Nerd, 52% Geek, 39% Dork :matte-motes-nerdy:

To be honest, i was reading the code now a duzend times. Really trying to understand it but i still failing yet. It is definitely my candidate for the geek script of the year! :matte-motes-nerdy:

Nice idea to use an event parameter (integer b) for other purposes instead of creating a custom local variable. But naming variables or the jump scope only like a, b, c or d is also quite inconvenient and not clever on a public domain script.

Yes but i believe its much more convenient to read as a while loop or flow control structure if possible and even might be less code. Chapeau! if the code runs proper. I rarely see such code. Reminds me on BASIC :matte-motes-nerdy:

Greetings! The LSL wiki says about using@ and jump "It is generally considered inadvisable to use jumps (commonly know as gotos) where other flow control structures could be used." and i'm also not a fan of such structure.

Hello Yurtiel! You are using llDetected* functions within a state_entry event at 2 of your scripts in various states. The llDetected* functions only work in touch, collision and sensor event types but not in state_entry.

Hello! You may use llGetObjectDetails straight within your HUD script and get the rotation of the in-world object by its key. This will at least reduce the impact of script communication.

Are you aware of the NPC functions openSim provides? I was playing with them some time ago on my own server and they seem to work well. They are atually avatars and you can move, animate, dress and let them talk by script. I was using pathway prims with certain commands within the description field and make the NPC/bot find them through a sensor. However this needs a custom configuration at the openSim.ini file. This article provides detailed informations: http://opensimulator.org/wiki/OSSLNPC

Greetings! Sounds like an interesting project. What is it for and is it public and/or public domain? It gets a bit tricky when linking and moving prims because a script needs granted permissions by its owner in order to link additional prims to an object by script. So what your script needs to do is: 1) Activate a chat listener by using llListen: http://wiki.secondlife.com/wiki/LlListen 2) Request and grant PERMISSION_CHANGE_LINKS by using llRequestPermissions: http://wiki.secondlife.com/wiki/LlRequestPermissions 3) Link your arm prim(s) to your robot prim(s) by using llCreateLink: http://wiki.secondlife.com/wiki/LlCreateLink when your gesture triggers the listen event in your scrip (Wonder why the mod got the thread moved to the Wanted forum.)

You may use a touch_start event and reload the float text when the owner touching the object. Code will look like this: // Code snippet - Reload object name and description as float texttouch_start(integer num){ if(llDetectedKey(0)==llGetOwner()) { llSetText((string)llGetObjectName() + "\n" + (string)llGetObjectDesc(), <1,1,1>,1); }}

You also might want to know that the 'vec' touch position vector is normalized, means its scaled to a range between 0.0 to 1.0. This means vec.x will always be less or equal 1.0 but never any more. So you may remove the "vec.x <= 1.0" and a "&&" in the if condition statement.

Dora Gustafson wrote: Are you sure the recieving child prim is number 2? Are you sure the scripts are in the same linkset? :smileysurprised::smileyvery-happy: And most important: Is the script set to running? :matte-motes-nerdy:

BTW I just figured there is also a short version for this code: integer previousStatus=-1;default{ state_entry() { llSetTimerEvent(1); // timer fires every second } timer() { integer agentInfo = llGetAgentInfo( llGetOwner() ); integer isFlying = (agentInfo&AGENT_FLYING); if(isFlying!=previousStatus) { //llOwnerSay(llList2String(["not flying","flying"],isFlying)); previousStatus = isFlying; llSetLinkAlpha(LINK_THIS, isFlying, ALL_SIDES); llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_POINT_LIGHT ,isFlying, <1.0, 1.0, 1.0>, 1.0, 20.0, 1.0]); } }}

Although the script is working as expected, it has one downside. It will continue to set the light and alpha even if they are already set. To avoid this, there are just a few additional lines of code needed. Following script will check if the 'status' parameter is different to its previous state and only changes the prim light and alpha if so. integer previousStatus=-1; default{ state_entry() { llSetTimerEvent(1); // timer fires every second } timer() { integer status = llGetAgentInfo( llGetOwner() ); if( (status & AGENT_FLYING) && previousStatus!=AGENT_FLYING) // if you are flying (and not flying already) { // llOwnerSay("flying"); previousStatus = AGENT_FLYING; llSetLinkAlpha(LINK_THIS, 1.0, ALL_SIDES); // set alpha to 1.0 ( visible) llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_POINT_LIGHT ,TRUE, <1.0, 1.0, 1.0>, 1.0, 20.0, 1.0]); // TRUE = light ON } else if((status & AGENT_FLYING)==FALSE && previousStatus == AGENT_FLYING) // if you are NOT flying (and had AGENT_FLYING as previous status) { // llOwnerSay("not flying"); previousStatus = 0; llSetLinkAlpha(LINK_THIS, 0.0, ALL_SIDES); // set alpha to invis 0.0 llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_POINT_LIGHT ,FALSE, <1.0, 1.0, 1.0>, 1.0, 20.0, 1.0]); // FALSE = light OFF } }}

Well its late here (2am) but i came up with 2 more possible solution. 1) By having invisible and phantom path prims along the track. The locomotive may set its rotation based on those prims on collision and just has to move forward based on its local forward orientation. 2) With a second script containing in the track object which forwards the positions and rotations of each track section to the locomotive. Especiall number one sounds promising as it might results in a much more dynamic track path. (Yes, i better get some rest now befor i come up with more nutty ideas) :matte-motes-nerdy: :smileyvery-happy:

Hello Emma! Actually there is only one potential solution i can think of for this script. In theory it will be like this: The script may detect a specific prim of the track based on the offset positions computed in the uuMakeCurve method. Then it may gets the x and y rotation of that track prim by using llGetObjectDetails and OBJECT_ROT as parameter and applies it to the computed rotation for each step. But that for there are a few requirements. The locomotive and track prims will need a proper/matching center of rotation and each track section will need something like a ground prim to asure the script is detecting anything when raycasting. It also might need some testing and tweeking as i'm currently not sure if a raycast may detect a child prim of an object or the just the object. Anyway as i'm also struggling with object rotations and its quite late here, i rather tend to wait if anyone else may come up with a better solution.

Another way to achieve an alpha fade in or out is by using a texture grid and the llSetTextureAnim function. This might be the less lag way, especially as llSetTextureAnim is client side.

I only know such a prim behaviour if the prim/object has physics enabled and has nothing to do with scripting.

The easiest way i can think of is by changing the touch_start event into: touch_start(integer num) { if(llDetectedName(0) == "Ed Min") // when bonus-admin touching the dice { llSay(0, "Player "+llKey2Name(llGetOwner())+" got +5 bonus!"); } else { ObjectName=llGetObjectName(); llSetObjectName(""); string player = llGetDisplayName(llDetectedKey(0)); integer roll = (integer)(llFrand(100.0)+1); llSay(0, "/me " + player + " rolled " + (string)roll); } }

wasn't me! :smileylol:

You are trying to pass ListKey inside a list as a parameter for the llDialog function: llDialog(llGetOwner()," ", [ListKey] , -99); But ListKey is a list already so it needs to be: llDialog(llGetOwner()," ", ListKey , -99);

Hallo Dugengo! Auf dieser Seite erklaert Maddy Gynoid das sehr ausfuehrlich und gibts allerhand hilfreiche Tips. Allerdings musst du dazu wissen, dass das Ruckeln 2 unterschiedliche Ursachen haben kann. Es koennte als Erstes natuerlich an deiner Hardware (bzw die deines PCs) liegen, dass zB Grafiken nicht schnell genug gerendert werden koennen (sogenannter Client-Side Lag). Darauf hast du Einfluss, indem du die Grafik- und Interneteinstellungen anpasst oder bessere Hardware einbaust. Es gibt zudem keine allgemein verbindlichen Einstellungswerte, weil jeder PC unterschiedliche Leistung haben kann, die von seiner Hardware und der vorhandenen Internetanbindung abhaengt. Du wirst also selber etwas rumprobieren muessen, um die optimalen Einstellungswerte fuer deinen PC zu finden. Als Zweites koennte die Ursache fuer das Ruckeln allerdings auch bei den SecondLife Servern liegen (sogenannter Server-Side Lag), wenn diese zB ueberlastet sind. Das kann verschiedene Gruende haben, auf die wir als Benutzer leider keinen großen Einfluss haben. Eine sehr ausfuehrliche Erklaerung ueber Client-Side und Server-Side Lag findest du auf http://lslwiki.net/lslwiki/wakka.php?wakka=lag (Vorsicht, Englisch!) :matte-motes-nerdy: