Teravus Ousley, among many other things, is the Open Dynamics Engine physics engine guru for the OpenSim project. Teravus, who is a proficient and prolific c# programmer, committed work on the evening of Dec 6 (or thereabouts) that fixed physical linkset and linkset collision issues.
This is a matter of some significance, and the importance of this work from a simulation science standpoint cannot be overstated.
Thanks Teravus, and Kudos!
W00Tz!!!
Monday, December 8, 2008
Thursday, December 4, 2008
Building Rexx Viewer on Linux
First off, the source is BIG. Weighing in at 20MB, it's a hefty download.
Having just unzipped it, I am surprised to see no README or INSTALL in the archive root. This is not especially encouraging. What is there are four directories: avatargenerator, maxscriptexport, rexmeshtool, and rexviewer.
With the complete dearth of any sort of build instructions, I am left with no choices but educated guesses - I rather suspect that avatargenerator and maxscriptexporter are utilities, and so I will begin with what might be the one included dependency, rexmeshtool. Here goes Norton!
Ok, so the rexmeshtool directory would appear to contain some sort of microsoft project. My guess is, there is no nant build configuration in the .sln file. Let's go see :D
Well, that didnt go far LOL
No nant .build file - this is essentially a microsoft-only project, and without a bit more work from the it's devs, it simply isnt going anywhere on linux.
I'd love to yell long and loud about the many things I had to do to get this to build - but unfortunately, that isnt going to happen.
So what I will yell long and loud about is this: This project is in NO WAY ready for building on linux. It may be a few short steps from it - it may be light years from it.
But without at least a prebuild file to gen a nant config to bootstrap the build process, it just isnt going to happen.
I will be keeping my eye on this, and on the Rexx guys - but they have a bit more work to do if they truly want to see this run on a linux desktop. Keep an eye on this blog for news relating to progress along these lines.
Cheers for now :)
Hiro P
OSGrid
Having just unzipped it, I am surprised to see no README or INSTALL in the archive root. This is not especially encouraging. What is there are four directories: avatargenerator, maxscriptexport, rexmeshtool, and rexviewer.
With the complete dearth of any sort of build instructions, I am left with no choices but educated guesses - I rather suspect that avatargenerator and maxscriptexporter are utilities, and so I will begin with what might be the one included dependency, rexmeshtool. Here goes Norton!
Ok, so the rexmeshtool directory would appear to contain some sort of microsoft project. My guess is, there is no nant build configuration in the .sln file. Let's go see :D
Well, that didnt go far LOL
No nant .build file - this is essentially a microsoft-only project, and without a bit more work from the it's devs, it simply isnt going anywhere on linux.
I'd love to yell long and loud about the many things I had to do to get this to build - but unfortunately, that isnt going to happen.
So what I will yell long and loud about is this: This project is in NO WAY ready for building on linux. It may be a few short steps from it - it may be light years from it.
But without at least a prebuild file to gen a nant config to bootstrap the build process, it just isnt going to happen.
I will be keeping my eye on this, and on the Rexx guys - but they have a bit more work to do if they truly want to see this run on a linux desktop. Keep an eye on this blog for news relating to progress along these lines.
Cheers for now :)
Hiro P
OSGrid
Physical Vehicles Update
**** Physical Vehicles Update ****
The short story is, we have a few now :D
Thanks to one Owen Oyen of SecondLife and OSGrid :)
One day last month, Owen showed up at my deltazone region to discuss physical vehicles. Owen makes some rather specialized content in SL - he is the one who brought us the pitching of boats under sail, tidal currents based on an analysis of sailing grounds, and a host of other good things related to virtual sailing in SL.
Owen's concern that day we met was why exactly there were no physical vehicle functions implemented yet in opensim. After a brief bit of discussion, we came to the conclusion that the llVehicle class of functions in LSL are really a dramatically simplified approximation of a linear motor with some twists thrown in - literally - for rotating a vehicle about it's axis of travel.
As proof of our sound thinking, Owen produced in collaboration with myself, a very satisfying and functional virtual sailboat :) recently, Owen and Bri Hasp have extended this further, producing an iceboat as well :D
Both are available at or near the south edge of Bri's 'Baya' sim on OSGrid. Unfortunately, Owen has chosen not to make the scripts open - leaving it to me to apply what I learned with him in the production of such scripts.
While I have not yet produced these scritps (I got a job shortly after Owen released his freebie-but-no-copy boat), I will do so in the future - and, I will happily share with you the basics of the implementation.
First, llSetForce and llApplyImpulse are used as motors, depending on the need and circumstance. Owen, I think, finally settled on the use of llSetForce exclusively, but for reasons that were a bit obscure to me. Second, to prevent the vehicle from accumulating energy on an exponential curve, llGetMass is used to calculate a bit of friction, which takes the form of a force applied in a direction opposite to the direction of motion, in the same timer-driven calculation that applies the force which keeps the boat moving.
Finally, a wind source and sail position/forces are calculated and applied. Coupled with some stabilization and correction of movement through the periodic re-inititalization of axes outside that along which movement occurs with constants (usually zero), we have a boat that is readily pushed about the sim on Owen's 'wizard wind', which he has scripted into the boat as well.
Maybe that reads like greek to you - if so, go pick up one of Owen's freebies at Baya and just go have fun with it. Be sure to read the included notecards, because this vehicle has peculiarities and quirks uniquely associated with opensim. If not, I heartily ecourage you to take up this ground-breaking work and see what sorts of vehicles you can produce.
Off to attempt to build Rexx viewer source on linux :D
Cheers for now :D
WISH MEH LUCK!
and see the following post, wherein I describe my rexx-viewer-on-linux-viewer-building experiences.
Hiro
OSGrid
The short story is, we have a few now :D
Thanks to one Owen Oyen of SecondLife and OSGrid :)
One day last month, Owen showed up at my deltazone region to discuss physical vehicles. Owen makes some rather specialized content in SL - he is the one who brought us the pitching of boats under sail, tidal currents based on an analysis of sailing grounds, and a host of other good things related to virtual sailing in SL.
Owen's concern that day we met was why exactly there were no physical vehicle functions implemented yet in opensim. After a brief bit of discussion, we came to the conclusion that the llVehicle class of functions in LSL are really a dramatically simplified approximation of a linear motor with some twists thrown in - literally - for rotating a vehicle about it's axis of travel.
As proof of our sound thinking, Owen produced in collaboration with myself, a very satisfying and functional virtual sailboat :) recently, Owen and Bri Hasp have extended this further, producing an iceboat as well :D
Both are available at or near the south edge of Bri's 'Baya' sim on OSGrid. Unfortunately, Owen has chosen not to make the scripts open - leaving it to me to apply what I learned with him in the production of such scripts.
While I have not yet produced these scritps (I got a job shortly after Owen released his freebie-but-no-copy boat), I will do so in the future - and, I will happily share with you the basics of the implementation.
First, llSetForce and llApplyImpulse are used as motors, depending on the need and circumstance. Owen, I think, finally settled on the use of llSetForce exclusively, but for reasons that were a bit obscure to me. Second, to prevent the vehicle from accumulating energy on an exponential curve, llGetMass is used to calculate a bit of friction, which takes the form of a force applied in a direction opposite to the direction of motion, in the same timer-driven calculation that applies the force which keeps the boat moving.
Finally, a wind source and sail position/forces are calculated and applied. Coupled with some stabilization and correction of movement through the periodic re-inititalization of axes outside that along which movement occurs with constants (usually zero), we have a boat that is readily pushed about the sim on Owen's 'wizard wind', which he has scripted into the boat as well.
Maybe that reads like greek to you - if so, go pick up one of Owen's freebies at Baya and just go have fun with it. Be sure to read the included notecards, because this vehicle has peculiarities and quirks uniquely associated with opensim. If not, I heartily ecourage you to take up this ground-breaking work and see what sorts of vehicles you can produce.
Off to attempt to build Rexx viewer source on linux :D
Cheers for now :D
WISH MEH LUCK!
and see the following post, wherein I describe my rexx-viewer-on-linux-viewer-building experiences.
Hiro
OSGrid
Friday, November 7, 2008
Scripted Physical Vehicles in OpenSim
First, to establish a bit of context on this report, I am referring to any vehicle that moves under the influence of the physics simulation. This specifically excludes llSetPos and like techniques.
While my experiments did not involve e.g., llSetVehicleType, they are still physical vehicles too - and dont worry, we'll examine the status of llSetVehicleType and friends while we're at it.
The first trouble I encountered in attempting to make a physical vehicle in OpenSim, is that there are no llVehicle* style functions implemented in the script engine. Or are there? a casual glance at the source code (if there is such a thing) would lead one to believe so. A closer investigation, though, will show that while the 'Not Implemented' stubs have been replaced with meaningful code that passes values up to the wooly innards of OpenSim, the afore-mentioned innards don't actually pass it on to the physics engine. But just about everything is in place to do so.
Why hasn't this last step been done? The answer to that is a bit complicated.
The short story is, the wooly innards are about to get rearranged, hopefully into a somewhat less wooly form. And as this is where all that physical script plumbing empties out, it's arrangement has considerable bearing on how llSetVehicle and friends are implemented.
Hold that thought while we take a stress breaker :)
What I *have* had at least some moderate success with is making a flying prim that is a physical vehicle. I know, but it's a start. How can this be done? Why, with llApplyImpulse and llTargetOmega.
Ok, it's an utter kludge LOL but it works.
Why llTargetOmega? it's the only LSL function currently implemented that can physically rotate a prim. llApplyImpulse provides both the lift and the forward thrust. I use the standard vehicle 'control' event to obtain the users inputs via 'llTakeControls', and I use llTargetOmega to stop and start a rotation of the prim when the appropriate keys are pressed to turn left and right.
Why dont I post that script here and now? It's just too ugly. When I spend a bit more time with it, I *might* actually have a reasonably manueverable flying prim - but as it is now, it's just barely proof-of-concept.
Now, stressbreaker is over!
Basically, the work on the OpenSim 'wooly innards' I referred to above is highly complex, represents a huge change to the core codebase, and must be worked over and discussed by at minimum 10 different software engineers. It's going to take a bit of time, I'm afraid. Be patient, it'll be worth the wait.
In the interim, I hope to properly implement llSetRotaionalImpulse and llSetRotationalVelocity, both of which bear enough resemblance to llTargetOmega that I should be able use it as a reference in the source code; if I am successfull, this should give us sufficient tools to implement some very useable vehicles based on llSetForce and llApplyImpulse.
Crude, I know. But better than a foot-race :)
Cheers for now!
While my experiments did not involve e.g., llSetVehicleType, they are still physical vehicles too - and dont worry, we'll examine the status of llSetVehicleType and friends while we're at it.
The first trouble I encountered in attempting to make a physical vehicle in OpenSim, is that there are no llVehicle* style functions implemented in the script engine. Or are there? a casual glance at the source code (if there is such a thing) would lead one to believe so. A closer investigation, though, will show that while the 'Not Implemented' stubs have been replaced with meaningful code that passes values up to the wooly innards of OpenSim, the afore-mentioned innards don't actually pass it on to the physics engine. But just about everything is in place to do so.
Why hasn't this last step been done? The answer to that is a bit complicated.
The short story is, the wooly innards are about to get rearranged, hopefully into a somewhat less wooly form. And as this is where all that physical script plumbing empties out, it's arrangement has considerable bearing on how llSetVehicle and friends are implemented.
Hold that thought while we take a stress breaker :)
What I *have* had at least some moderate success with is making a flying prim that is a physical vehicle. I know, but it's a start. How can this be done? Why, with llApplyImpulse and llTargetOmega.
Ok, it's an utter kludge LOL but it works.
Why llTargetOmega? it's the only LSL function currently implemented that can physically rotate a prim. llApplyImpulse provides both the lift and the forward thrust. I use the standard vehicle 'control' event to obtain the users inputs via 'llTakeControls', and I use llTargetOmega to stop and start a rotation of the prim when the appropriate keys are pressed to turn left and right.
Why dont I post that script here and now? It's just too ugly. When I spend a bit more time with it, I *might* actually have a reasonably manueverable flying prim - but as it is now, it's just barely proof-of-concept.
Now, stressbreaker is over!
Basically, the work on the OpenSim 'wooly innards' I referred to above is highly complex, represents a huge change to the core codebase, and must be worked over and discussed by at minimum 10 different software engineers. It's going to take a bit of time, I'm afraid. Be patient, it'll be worth the wait.
In the interim, I hope to properly implement llSetRotaionalImpulse and llSetRotationalVelocity, both of which bear enough resemblance to llTargetOmega that I should be able use it as a reference in the source code; if I am successfull, this should give us sufficient tools to implement some very useable vehicles based on llSetForce and llApplyImpulse.
Crude, I know. But better than a foot-race :)
Cheers for now!
Monday, September 8, 2008
KUDOS!!
Kudos to JHurliman of the libomv project and Teravus Ousley of the OpenSim project for their highly successful efforts this weekend!
JHurliman and friends have recently finished up some fairly major work on libomv, and Teravus worked closely with him on the one hand, and with the opensim/osgrid user community on the other, to bring this fresh new libomv into our OpenSim project.
The technical hurdles were numerous and sometimes quite high, but these fellows were definitely up to the task and it looks as if all the real show-stoppers and toe-stubbers have been addressed; things are cooking along quite nicely. :D
Cheers Guys! Great Job!
JHurliman and friends have recently finished up some fairly major work on libomv, and Teravus worked closely with him on the one hand, and with the opensim/osgrid user community on the other, to bring this fresh new libomv into our OpenSim project.
The technical hurdles were numerous and sometimes quite high, but these fellows were definitely up to the task and it looks as if all the real show-stoppers and toe-stubbers have been addressed; things are cooking along quite nicely. :D
Cheers Guys! Great Job!
Friday, August 22, 2008
Concerning the future of the 'Grid' as a paradigm for VR
The Death of the Grid is Nigh!
Two of the most interesting OpenSim-related blog posts I have seen in recent weeks were penned by none other than Adam Frisby (his post is at http://www.adamfrisby.com/blog/2008/08/the-world-wide-3d-web/), and Justin Clarke-Casey (who's post is at http://justincc.wordpress.com/2008/08/15/could-there-be-a-future-without-big-grids/), pose the question, "does the grid continue to have relevance in the future of OpenSim, long-term?"
Whoa! Heresy! Blasephemy! Chaos! teh barbarians are at the gates!
Or are they?
The History and Nature of The Grid
First, lets reflect a bit by what we mean when we say ''Grid'' in the context of VR. VR has it's technical beginnings in the code of MMORPGs. If you don't know what an MMORPG is, you may wish to crawl back under your rock ;) SRSLY though, OpenSim inherits many of it's metaphors through a direct line of inheritance going all the way back to the text-only muds of yesteryear, and even more remotely to games like Infocom's ''Zork''.
For our purposes, a ''Grid'' is a means for grafting little slices of geographical metaphor together to present them as a contiguous aggregation of ''Land'', or ''RealEstate'', with all of the connotations and overtones that come along with that as baggage (or value, depending on one's perspective). That perspective largely stems from one's interests in implementing a virtual space.
This is a fairly traditional paradigm, and is largely taken for granted even in the literature which initially inspired the developement of current VR models; to such a degree that a potential debate begins to take form centered on the notion that grid vs. not-grid is an assertion in need of evaluation.
For myself and others, this is a question which is largely evocative of swift reaction, we having invested a great deal of time and energy in developing, supporting, and using grid applications of OpenSim and supporting software and practices. Upon reflection, however, I have arrived at the position that the question is largely moot. And I'll gladly tell you why in subsequent paragraphs, as we leave off the discussion of canonical grid architecture and examine that of OpenSim.
OpenSim Architecture
OpenSim is designed to address not just one but a potentially infinite set of use cases. Great care has been taken both in the forward-looking design and the backward-glancing refactorings to implement feature sets as modules. To say that OpenSim is very configurable is a gross understatement. OpenSim is literally three different complete software systems; the simplest of which is the 'Standalone' codebase - it is really the other two combined, but 'lite'. The remaining two software systems are the 'Grid Services', and the 'Region Server'.
As an aside, our first clue to trouble appears here, that is, even if there is no duplication in code, there is certainly duplication of purpose - the two variations (grid and standalone) are distinct in the interest of addressing concerns of scale. While scale is definitely a matter of concern if one wishes to embrace a large body of users, it's pretty well acepted that two distinct but similar applications is not the ideal way to address this concern.
The reason grid mode scales better than standalone is that the grid provides a centralized backstore for assets, user authentication, and user-ownership of assets. Or so the story goes. The truth is, these services do not, of a necesity, need to be delivered from a single source; in fact, there is every reason to believe that spreading them around a bit will - you guessed it - scale better.
To elaborate a little further on standalone (hopefully without putting too fine a point on it), the standalone codebase implements a specific use-case: the 'Walled Garden'. This walled garden, as the name suggests, is a slice of geographical metaphor that is unaffiliated in any other explicitly virtual way with any other seperate but similar slice of geographical metaphor.
A Potential Pheonix in the Making
Note that the primary reason for the existence of these two distinct but similar applications is more profoundly technical than social. Some might beg to differ, but the ability to limit incidental visits by anonymous or other uninvited users is more by consequence than by design. This is evidenced in the relative ease with which standalone has been patched in early OGP/InterOp testing.
What may rise from the ashes, or, where I'm actually headed with all this
Essentially, what needs to happen (and therefore, what will most likely happen) is that the current state of affairs will slowly be displaced by one in which a much more thoroughly distributed model will be preferred. Think standalone mode on steroids: configurable to use local or remote backstores; to participate (or not) in some third party authentication and/or asset providers; to appear (or not to appear) on agglomerative geographical representations, with concommitant metaphorical participation in-situ (see into/from 'adjacent' regions, participate in object/script crossings, physics/water table/terrain cooperations, etc.)
This architecture pushes relevant responsibilities for authentication, hosting, and permissions/ownership back onto the region operator, where they really should be. Does this really eliminate the 'grid'? potentially, perhaps, in any oraganizational sense. Grid operators will likely become the first operators of the afore-mentioned service level organizations. Indeed, they already are ;)
The Nature of the (new) Beast
- This 'idealized' OpenSim will be simpler to support. There will only be one of them, as we will no longer make a distinction between gridmode and standalone.
- It will be more homogenous, as all instances will be potentially reachable from all others, even where no metaphorical geographical relationship exists
- It will be more socially satisfying as all spatial agglomeration will be voluntary, deliberate, and by design.
Long Live the Grid, all hail the Grid
To bring this all to a comfortable close, I think the death of the grid is a bit overstated. Sure, it'll pass (especially in it's current incarnation), but it will represent the progress of many sure steps forward, and produce a far more usefull operational paradigm; one in which politics will become less important in the developement of the software, promoting easier support, smoother developement and testing, and a better, more satisfying VR experience for Operator and User alike.
So for my part, I say bring it on!
Cheers,
James G. Stallings II
aka daTwitch/Hiro Protagonist/Lazarus Longstaff
Two of the most interesting OpenSim-related blog posts I have seen in recent weeks were penned by none other than Adam Frisby (his post is at http://www.adamfrisby.com/blog/2008/08/the-world-wide-3d-web/), and Justin Clarke-Casey (who's post is at http://justincc.wordpress.com/2008/08/15/could-there-be-a-future-without-big-grids/), pose the question, "does the grid continue to have relevance in the future of OpenSim, long-term?"
Whoa! Heresy! Blasephemy! Chaos! teh barbarians are at the gates!
Or are they?
The History and Nature of The Grid
First, lets reflect a bit by what we mean when we say ''Grid'' in the context of VR. VR has it's technical beginnings in the code of MMORPGs. If you don't know what an MMORPG is, you may wish to crawl back under your rock ;) SRSLY though, OpenSim inherits many of it's metaphors through a direct line of inheritance going all the way back to the text-only muds of yesteryear, and even more remotely to games like Infocom's ''Zork''.
For our purposes, a ''Grid'' is a means for grafting little slices of geographical metaphor together to present them as a contiguous aggregation of ''Land'', or ''RealEstate'', with all of the connotations and overtones that come along with that as baggage (or value, depending on one's perspective). That perspective largely stems from one's interests in implementing a virtual space.
This is a fairly traditional paradigm, and is largely taken for granted even in the literature which initially inspired the developement of current VR models; to such a degree that a potential debate begins to take form centered on the notion that grid vs. not-grid is an assertion in need of evaluation.
For myself and others, this is a question which is largely evocative of swift reaction, we having invested a great deal of time and energy in developing, supporting, and using grid applications of OpenSim and supporting software and practices. Upon reflection, however, I have arrived at the position that the question is largely moot. And I'll gladly tell you why in subsequent paragraphs, as we leave off the discussion of canonical grid architecture and examine that of OpenSim.
OpenSim Architecture
OpenSim is designed to address not just one but a potentially infinite set of use cases. Great care has been taken both in the forward-looking design and the backward-glancing refactorings to implement feature sets as modules. To say that OpenSim is very configurable is a gross understatement. OpenSim is literally three different complete software systems; the simplest of which is the 'Standalone' codebase - it is really the other two combined, but 'lite'. The remaining two software systems are the 'Grid Services', and the 'Region Server'.
As an aside, our first clue to trouble appears here, that is, even if there is no duplication in code, there is certainly duplication of purpose - the two variations (grid and standalone) are distinct in the interest of addressing concerns of scale. While scale is definitely a matter of concern if one wishes to embrace a large body of users, it's pretty well acepted that two distinct but similar applications is not the ideal way to address this concern.
The reason grid mode scales better than standalone is that the grid provides a centralized backstore for assets, user authentication, and user-ownership of assets. Or so the story goes. The truth is, these services do not, of a necesity, need to be delivered from a single source; in fact, there is every reason to believe that spreading them around a bit will - you guessed it - scale better.
To elaborate a little further on standalone (hopefully without putting too fine a point on it), the standalone codebase implements a specific use-case: the 'Walled Garden'. This walled garden, as the name suggests, is a slice of geographical metaphor that is unaffiliated in any other explicitly virtual way with any other seperate but similar slice of geographical metaphor.
A Potential Pheonix in the Making
Note that the primary reason for the existence of these two distinct but similar applications is more profoundly technical than social. Some might beg to differ, but the ability to limit incidental visits by anonymous or other uninvited users is more by consequence than by design. This is evidenced in the relative ease with which standalone has been patched in early OGP/InterOp testing.
What may rise from the ashes, or, where I'm actually headed with all this
Essentially, what needs to happen (and therefore, what will most likely happen) is that the current state of affairs will slowly be displaced by one in which a much more thoroughly distributed model will be preferred. Think standalone mode on steroids: configurable to use local or remote backstores; to participate (or not) in some third party authentication and/or asset providers; to appear (or not to appear) on agglomerative geographical representations, with concommitant metaphorical participation in-situ (see into/from 'adjacent' regions, participate in object/script crossings, physics/water table/terrain cooperations, etc.)
This architecture pushes relevant responsibilities for authentication, hosting, and permissions/ownership back onto the region operator, where they really should be. Does this really eliminate the 'grid'? potentially, perhaps, in any oraganizational sense. Grid operators will likely become the first operators of the afore-mentioned service level organizations. Indeed, they already are ;)
The Nature of the (new) Beast
- This 'idealized' OpenSim will be simpler to support. There will only be one of them, as we will no longer make a distinction between gridmode and standalone.
- It will be more homogenous, as all instances will be potentially reachable from all others, even where no metaphorical geographical relationship exists
- It will be more socially satisfying as all spatial agglomeration will be voluntary, deliberate, and by design.
Long Live the Grid, all hail the Grid
To bring this all to a comfortable close, I think the death of the grid is a bit overstated. Sure, it'll pass (especially in it's current incarnation), but it will represent the progress of many sure steps forward, and produce a far more usefull operational paradigm; one in which politics will become less important in the developement of the software, promoting easier support, smoother developement and testing, and a better, more satisfying VR experience for Operator and User alike.
So for my part, I say bring it on!
Cheers,
James G. Stallings II
aka daTwitch/Hiro Protagonist/Lazarus Longstaff
Friday, August 15, 2008
But SRSLY
I haz created a more or less traditional book in OpenSim using LSL scripting.
It runs in a single cube prim. For your own copy of my first effort, paste this into a script and drop it in a cube prim:
vector opensize=<0.064,0.5,0.35>;
vector closedsize=<0.04,0.265,0.35>;
string book="closed"; // b6258725-335d-4e47-9676-39361010f5cc 34270b40-68a2-4341-aeb3-10e3b2f45214
list pageUUIDs=["ce3f600b-0028-40f0-a77b-10426b8ff975","07a9e95b-ef73-47ef-80f1-b6c168529142","e39d7c07-aa29-4776-8083-b6a055427995","589e5863-b3a5-4441-a2c8-fd960cf1997e","32ae5dd8-582c-410a-afc9-fef75fc4a6b4","4152fba5-02ef-4f1a-a7d2-9d4ebc4a8be1","f4427be8-651d-47d5-ab06-5597443b92d2","aeb9162e-a2e3-4942-ba58-1ed0cbb250ab","98888e86-b1d4-412f-b275-a98d04038dad","1840ea8f-ba8e-47b0-8182-cf3abc56bb8d","a00dd649-f617-4f39-a4e0-6b110199d439","a063425d-b31a-4309-8d4d-1886f1cd8530","afb3f53e-9ca6-425e-874a-f9bba796d7cf","09c65ace-d015-4a6c-9467-421f9f728f42","bb976ea4-f423-4706-b7f8-33fd4d856029","8b7f7d9e-57f2-4c17-a010-30972be1982c","707e44d8-e432-47f7-9535-b42e032f485f","f860fb9b-d1fb-486c-948f-7131bade9662","b065b77a-6e6c-4cfd-9079-50df43455595","006e3243-9817-49e2-b975-1c1c8e5b5222","2e86574c-21a1-46ef-a6cb-e076c6e94d27","f4df80e8-2e47-4287-abc8-9422d299995c","5470da29-83f5-4cab-8ee1-c0cd80102450","19ef268b-03e5-4678-aff8-d7db5d3b1ccf","fef6f8ed-554f-44e5-88ec-93338196981b","b61d1655-044f-4332-aa1b-558b042f2ea1","dbdeb221-5eb7-461e-acd1-a57b0e733c4f", "bf5b0c57-2d57-4bb4-82f3-a22ce8e9a1ac", "ccee6b1d-7201-43c1-bf31-e664a6f4c808",
"b6258725-335d-4e47-9676-39361010f5cc", // right here gets a repeat
"34270b40-68a2-4341-aeb3-10e3b2f45214","209f134d-32ef-49cf-8760-478f2e356534","d0353b58-7513-4180-90f2-5b0cba0fda5d","3f61aaa4-3168-4605-bcd3-41a12f0cae69","1d4072de-b47d-43f9-acf6-2bd33a081313","a6bcd0c1-af54-4639-8e44-804038b30c73","96989e63-3697-4952-9921-7f950122c962","13ac21e6-54a9-41be-9bb3-42dee4cbad8d","9378acb0-187a-48c9-94b3-dc3fad2e02d1","6992ee7b-b1c9-4685-9437-742ad33b066b","51061eb8-a8e3-48c1-b969-83cda8496250","e7a86214-23f5-4840-8eb2-fae38dcd0ddf","9a993a2c-c6f2-430c-95de-10367879cf1e",
"b3bd7ec4-ad57-427f-9d9f-dc1457a30d1b","d5d5d201-dbad-4540-9559-a75c768b0e75","ec60869c-df31-43fe-a80f-400f49b3f3d8","2f180734-558a-4e8d-9131-317f93f9019c","fab8d130-6d23-4c25-bd7e-abf0c2c9674f","e91a5db7-ad57-4766-9bcd-1b54f39bfb78","c5a0438c-e86c-4e8c-a461-a14570e36242","4092de87-0b38-4fe1-be51-ab258bfe01cd","1251b2ca-0602-4a57-a5d2-5e19898bdbc7","c0f03827-7112-4124-af64-37f5dc624c4b","d01de6ae-f48c-4781-884e-d8ffd7c9ff15","044038a3-e2ce-42f7-bead-2ac491e1e7fd","9d355fe2-4e47-473c-b197-c14096d04fb1","047295f3-2fbe-4bc0-a20a-0c4ee45e9c0c","f31329b3-5a86-4bbd-a354-946047293896","b3b8e143-596c-4dcc-b343-a1d6e2259ace","f89e5cfc-34f8-496a-8502-797878860b73","5512e24a-7ba1-4c60-8b0e-82be455d0314","2881aad1-f9ae-4145-9eb7-9cfaab604f26","b8892fb5-df34-448c-9528-f807b6d0c6cd","876a6985-c37a-4510-b940-cd185621f4ff","611fdde9-6abd-4d48-b4e8-aeda55414258","a46dade4-5efd-4f5a-afb0-e44324606405","bb89eebb-9e8b-4718-8fee-d0676a77839d","87955458-f05b-445d-8721-b359fcb1a279","ece2b053-0245-4b08-bc6f-22755823f968","7101e397-4f8b-43ff-80fb-2ea6eb792373","55fd7df3-06c7-4c92-9701-a511f3838317","80b13e0f-8f66-495c-9af1-086606e052fb","3435ed56-7e8a-4b8b-abf2-58011ff91b15"];
integer pagesets=72;
integer pageset=0;
settexture()
{
string ID=llList2String(pageUUIDs,pageset);
key textureID=(key) ID;
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",0);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",1);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",3);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",4);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",2);
llSetPrimitiveParams([PRIM_TEXTURE, 5, textureID, <0.5,1,0>, <0.25,0,0>, 0.0]);
llSetPrimitiveParams([PRIM_TEXTURE, 6, textureID, <0.5,1,0>, <-0.25,0,0>, 0.0]);
// llSetTexture(textureID,5);
// llSetTexture(textureID,6);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",7);
}
closebook()
{
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_BOX, 0, <0,1,0>, 0.0, <0,0,0>, <1,1,1>, <0,0,0>]);
llSetPrimitiveParams([PRIM_SIZE, closedsize]);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",5);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",0);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",1);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",3);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",2);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",4);
}
default
{
state_entry()
{
closebook();
book="closed";
pageset=0;
}
touch_start(integer num_times)
{
if(book=="closed")
{
book="open";
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_BOX, 0, <0,0.725,0>, 0.0, <0,0,0>, <1,1,1>, <0,0,0>]);
llSetPrimitiveParams([PRIM_SIZE, opensize]);
settexture();
} else if(book=="open")
{
pageset=pageset + 1;
if(pageset>(pagesets-1))
{
closebook();
book="closed";
pageset=0;
} else {
settexture();
}
}
}
}
See if you can figure out why it repeats the 31st pageset, I cant - it may be a bug in OpenSim.
Oh, and a bit of an easter egg for those of you running linux that read this far:
get a debian pkg of qavimator binaries here:
http://www.byteme.org.uk/qavimator.html
Cheers!
It runs in a single cube prim. For your own copy of my first effort, paste this into a script and drop it in a cube prim:
vector opensize=<0.064,0.5,0.35>;
vector closedsize=<0.04,0.265,0.35>;
string book="closed"; // b6258725-335d-4e47-9676-39361010f5cc 34270b40-68a2-4341-aeb3-10e3b2f45214
list pageUUIDs=["ce3f600b-0028-40f0-a77b-10426b8ff975","07a9e95b-ef73-47ef-80f1-b6c168529142","e39d7c07-aa29-4776-8083-b6a055427995","589e5863-b3a5-4441-a2c8-fd960cf1997e","32ae5dd8-582c-410a-afc9-fef75fc4a6b4","4152fba5-02ef-4f1a-a7d2-9d4ebc4a8be1","f4427be8-651d-47d5-ab06-5597443b92d2","aeb9162e-a2e3-4942-ba58-1ed0cbb250ab","98888e86-b1d4-412f-b275-a98d04038dad","1840ea8f-ba8e-47b0-8182-cf3abc56bb8d","a00dd649-f617-4f39-a4e0-6b110199d439","a063425d-b31a-4309-8d4d-1886f1cd8530","afb3f53e-9ca6-425e-874a-f9bba796d7cf","09c65ace-d015-4a6c-9467-421f9f728f42","bb976ea4-f423-4706-b7f8-33fd4d856029","8b7f7d9e-57f2-4c17-a010-30972be1982c","707e44d8-e432-47f7-9535-b42e032f485f","f860fb9b-d1fb-486c-948f-7131bade9662","b065b77a-6e6c-4cfd-9079-50df43455595","006e3243-9817-49e2-b975-1c1c8e5b5222","2e86574c-21a1-46ef-a6cb-e076c6e94d27","f4df80e8-2e47-4287-abc8-9422d299995c","5470da29-83f5-4cab-8ee1-c0cd80102450","19ef268b-03e5-4678-aff8-d7db5d3b1ccf","fef6f8ed-554f-44e5-88ec-93338196981b","b61d1655-044f-4332-aa1b-558b042f2ea1","dbdeb221-5eb7-461e-acd1-a57b0e733c4f", "bf5b0c57-2d57-4bb4-82f3-a22ce8e9a1ac", "ccee6b1d-7201-43c1-bf31-e664a6f4c808",
"b6258725-335d-4e47-9676-39361010f5cc", // right here gets a repeat
"34270b40-68a2-4341-aeb3-10e3b2f45214","209f134d-32ef-49cf-8760-478f2e356534","d0353b58-7513-4180-90f2-5b0cba0fda5d","3f61aaa4-3168-4605-bcd3-41a12f0cae69","1d4072de-b47d-43f9-acf6-2bd33a081313","a6bcd0c1-af54-4639-8e44-804038b30c73","96989e63-3697-4952-9921-7f950122c962","13ac21e6-54a9-41be-9bb3-42dee4cbad8d","9378acb0-187a-48c9-94b3-dc3fad2e02d1","6992ee7b-b1c9-4685-9437-742ad33b066b","51061eb8-a8e3-48c1-b969-83cda8496250","e7a86214-23f5-4840-8eb2-fae38dcd0ddf","9a993a2c-c6f2-430c-95de-10367879cf1e",
"b3bd7ec4-ad57-427f-9d9f-dc1457a30d1b","d5d5d201-dbad-4540-9559-a75c768b0e75","ec60869c-df31-43fe-a80f-400f49b3f3d8","2f180734-558a-4e8d-9131-317f93f9019c","fab8d130-6d23-4c25-bd7e-abf0c2c9674f","e91a5db7-ad57-4766-9bcd-1b54f39bfb78","c5a0438c-e86c-4e8c-a461-a14570e36242","4092de87-0b38-4fe1-be51-ab258bfe01cd","1251b2ca-0602-4a57-a5d2-5e19898bdbc7","c0f03827-7112-4124-af64-37f5dc624c4b","d01de6ae-f48c-4781-884e-d8ffd7c9ff15","044038a3-e2ce-42f7-bead-2ac491e1e7fd","9d355fe2-4e47-473c-b197-c14096d04fb1","047295f3-2fbe-4bc0-a20a-0c4ee45e9c0c","f31329b3-5a86-4bbd-a354-946047293896","b3b8e143-596c-4dcc-b343-a1d6e2259ace","f89e5cfc-34f8-496a-8502-797878860b73","5512e24a-7ba1-4c60-8b0e-82be455d0314","2881aad1-f9ae-4145-9eb7-9cfaab604f26","b8892fb5-df34-448c-9528-f807b6d0c6cd","876a6985-c37a-4510-b940-cd185621f4ff","611fdde9-6abd-4d48-b4e8-aeda55414258","a46dade4-5efd-4f5a-afb0-e44324606405","bb89eebb-9e8b-4718-8fee-d0676a77839d","87955458-f05b-445d-8721-b359fcb1a279","ece2b053-0245-4b08-bc6f-22755823f968","7101e397-4f8b-43ff-80fb-2ea6eb792373","55fd7df3-06c7-4c92-9701-a511f3838317","80b13e0f-8f66-495c-9af1-086606e052fb","3435ed56-7e8a-4b8b-abf2-58011ff91b15"];
integer pagesets=72;
integer pageset=0;
settexture()
{
string ID=llList2String(pageUUIDs,pageset);
key textureID=(key) ID;
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",0);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",1);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",3);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",4);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",2);
llSetPrimitiveParams([PRIM_TEXTURE, 5, textureID, <0.5,1,0>, <0.25,0,0>, 0.0]);
llSetPrimitiveParams([PRIM_TEXTURE, 6, textureID, <0.5,1,0>, <-0.25,0,0>, 0.0]);
// llSetTexture(textureID,5);
// llSetTexture(textureID,6);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",7);
}
closebook()
{
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_BOX, 0, <0,1,0>, 0.0, <0,0,0>, <1,1,1>, <0,0,0>]);
llSetPrimitiveParams([PRIM_SIZE, closedsize]);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",5);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",0);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",1);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",3);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",2);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",4);
}
default
{
state_entry()
{
closebook();
book="closed";
pageset=0;
}
touch_start(integer num_times)
{
if(book=="closed")
{
book="open";
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_BOX, 0, <0,0.725,0>, 0.0, <0,0,0>, <1,1,1>, <0,0,0>]);
llSetPrimitiveParams([PRIM_SIZE, opensize]);
settexture();
} else if(book=="open")
{
pageset=pageset + 1;
if(pageset>(pagesets-1))
{
closebook();
book="closed";
pageset=0;
} else {
settexture();
}
}
}
}
See if you can figure out why it repeats the 31st pageset, I cant - it may be a bug in OpenSim.
Oh, and a bit of an easter egg for those of you running linux that read this far:
get a debian pkg of qavimator binaries here:
http://www.byteme.org.uk/qavimator.html
Cheers!
Subscribe to:
Posts (Atom)
