User:LaniGlobal

 = Lani Global''' =

'''LANI GLOBAL SYSTEMS Twitter feed
'''Lani Global Systems on Twitter http://twitter.com/LaniGlobal

Lani tweets about anything that amuses her.

'''Lani Global OSGrid Photo Gallery
'''Lani Global - OSGrid Photo Gallery http://gallery.osgrid.org/main.php?g2_itemId=6528

Photos, snapshots, imagery, and art in OSGrid, OpenSim.

= OpenSim Communications Projects =  

SubSpace Communications RP Chat System
''' Extended long distance Text Chat scripted wearable and rezzable system for: region-chat, region-to-region chat, grid-to-grid, standalone-to-standalone, etc.

Compatible with the OWI Open World Interface by Snoopy Pfeffer running on Dreamland Metaverse OpenSim servers ''' = OpenSim RolePlay Projects =  

Myriad Lite RolePlay Gaming and Combat System
 The Myriad Lite RolePlay Gaming and Combat System was founded by User:Allen_Kerensky, who is also the lead developer and primary code writer for it.'''

It is an Open Source scripted RolePlay Gaming and Combat System specifically designed to be compatible with OpenSim.

"Myriad Lite is a project to adapt a pen-and-paper role-playing game rulebook into OpenSimulator Xengine and SecondLife Mono scripts, and the related 3D objects, needed to implement a pen-and-paper role-playing game in 3D virtual worlds." -- Allen Kerensky

Lani Global contributions to the Myriad project include: Animations, Textures, HUD Design, Trap Scripts, Alpha and Beta Testing, Collaboration, Promotion and Community Distribution. '''

= OpenSim Community Projects =  

Sci Fi Hub of OSGrid
''' A community center for promotion of Science Fiction theme environments in OpenSim. Located in the Lani region in OSGrid. Includes the Sci Fi Teleport Poster Exchange project. ''' = OpenSim Vehicle Projects =  

Physical Vehicle Designed for OpenSim
''' In August 2012, Lani Global Systems embarked on a Physical Vehicle project designed specifically for OpenSim. See. Prior to this project, multi-passenger physical vehicles were practically non-existent and unknown to the public in core-dev-OpenSim. To fulfill the cutting edge goals of this project, a new vehicle script was specially written to take advantage of the then-current (OpenSim v0.7.5 dev) working vehicle functions, while simultaneously minimizing previously encountered bugs and failures. The project succeeded. Free distribution to the OpenSim Community was implemented through the release of several boxed-product objects in September 2012:

1. "Ornithopter 3-seater(c)2012 LANI GLOBAL SYSTEMS" Multi-Passenger Physical Flight Vehicle, complete with root prim engine script, multiple special effects scripts, animations, interlock system, lighting, seating, and moving canopy/physical-enclosure. copy/mod/trans.

2. "Physical Flight Vehicle Script Engine (c)2012 LANI GLOBAL SYSTEMS" root prim, open source script, pilot animation. copy/mod/trans. '''

= OpenSim Vehicle Bugs =  

Known Physical Vehicle Bugs Currently Existing in OpenSim
 OpenSim Mantis Report # 0006333: Local Chat Fail for Driver of Vehicle: Sitting Passengers & Vehicle Text Commands http://opensimulator.org/mantis/view.php?id=6333 '''

Pilot / Driver of physical vehicle can not communicate using local chat Say channels with sitting passenger(s) after the vehicle moves more than 20m from the point where the passenger(s) sits on the vehicle. This also affects chat say texting commands by Pilot / Driver to the vehicle. Say text commands from Pilot/Driver to vehicle fail more than 20m from the vehicle Pilot / Driver original point of sit.

The region doesn't seem to update the sitting avatar's location (or the vehicle's location) for chat texting purposes. Tests seem to indicate that the Passenger avatar's texting location remains at the location where the passenger sat on the vehicle. '''

Other Vehicle Bugs or Not-Yet-Implemented Parameters
''' Physical vehicle parameters for banking such as VEHICLE_BANKING_EFFICIENCY are not implemented (AFAIK) yet in OpenSim dev physics ODE. ''' = OpenSim Change-Advocacy Projects =  

Proposed Change Regions_ini Default PhysicalPrimMax 10m to 64m
 In the OpenSim simulator settings file: Regions.ini there is a line of the file:  ; PhysicalPrimMax = 10'''

This default should be changed to  ; PhysicalPrimMax = 64 to support the widespread use and distribution of physical vehicles content in the OpenSim Community. With more and more mesh being used, this has become an important issue.

'''The 10 meter prim size is an obsolete standard left over from the old days of SL.  The current standard is 64 meter prim size.'''



Comparison of a mesh physical vehicle normal size using PhysicalPrimMax=64m with a Physical Vehicle forced to be reduced in size due to PhysicalPrimMax = 10m.

PhysicalPrimMax 64m Discussed at OpenSimulator Meeting
09 October 2012: Discussion of PhysicalPrimMax 64m Default Change Proposed at OpenSimulator Meeting in Wright Plaza on 09 October 2012. The PhysicalPrimMax discussion starts at chat log time 11:49. It starts to get interesting at about 11:52.

16 October 2012: Discussion of PhysicalPrimMax 32m Default Change was discussed at OpenSimulator Meeting in Wright Plaza on 16 October 2012. The PhysicalPrimMax discussion starts at chat log time 11:18. It starts to get interesting at about 11:32.

18 February 2014: Since BulletSim Physics is now standard in OpenSim distrubutions and the use of mesh is widespread for vehicles, another suggestion was made to increase the default to 64m. This was discussed at the OpenSim Dev meeting. Discussion of PhysicalPrimMax 64m Default Change Proposed at OpenSimulator Meeting in Wright Plaza on 18 February 2014, The PhysicalPrimMax 64m discussion is at chat log time 11:23 and 11:53 and 12:04.

11 March 2014: PhysicalPrimMax 64m and the Mantis 0007028, with PATCH: PhysicalPrimMax to 64m for ini Default files to enable standard size prims and mesh to be used with vehicles was discussed at the OpenSimulator Meeting in Wright Plaza on 11 March 2014, the discussion starts at chat log time 11:07. Robert Adams, BulletSim Physics dev, is quoted as saying: "and it is time to either fix the old SL limitations or get off the bus".

The Patchwas applied to opensim around 2014-03-11.

PhysicalPrimMax Discussed at OSGrid Town Hall Meeting
 At the OSGrid Town Hall Meeting on 07 October 2012''', Lani Global presented a proposal to the citizens of OSGrid. The complete transcript of this meeting is available at: http://wiki.osgrid.org/index.php/TownHallMeetingLog20121007 

"As many of you know already, LANI GLOBAL SYSTEMS has introduced a new MULTI-PASSENGER PHYSICAL FLIGHT VEHICLE and an open source Physical Flight Script Engine developed for OpenSim / OSGrid. I'm not announcing this to advertise it or boast :) I am saying this because, honestly, most people previously thought that multi-passenger physical vehicles didn't exist in OSGrid. "

"Also, I would like to speak up about an important thing that is HOLDING BACK some talented OSGrid Content Creators in this field of Physical Vehicles (boats, aircraft, spacecraft, automobiles, and amphibious craft). The thing in OSGrid that is now holding back physical vehicle Content Creators is: currently there is a DEFAULT in the OpenSim OSGrid dev simulator (ini) setup file of "Maximum Physical Prim Size = 10metres". This Default prim size is a carryover from the old SL 10m prim size standard. It is now obsolete! Default "Maximum Physical Prim Size = 10metres" is WAY TOO SMALL for the design of multi-passenger Physical Vehicles... especially MESH and Sculpty vehicles, yachts, ships, airplanes, and spacecraft built to-scale."

"I realize that this is a new area of interest. During the past month of development of my open source Physical Flight Script Engine for OpenSim/OSGrid, I have been talking with other vehicle builders in OSGrid, working on converting some of the existing vehicles, and we all are stifled by this 10 metre physical prim default limitation. We now want to propose a NEW DEFAULT for "OSGrid's OpenSim dev version" be changed to "Maximum Physical Prim Size = 64 metres". This is equivalent to the current Maximum Prim Size 64 metres in current (SL) compatible viewers."

"We recognize that it is possible for each simulator owner/operator to set their own Maximum Physical Prim Size to 64 metres. We have changed this setting in some regions and are happy to report that everything works fine with larger physical prim vehicles. However, many people who rent regions in OSGrid or who run their own regions, do not have the skills to change this default. While lone builders and owners of regions can change their own regions' Maximum Physical Prim Size to 64m, it is a different story for Content Creators. Vehicle designers who create free products and put them in the stores for the larger market of the OSGrid Community (and OpenSim HyperGrid Community) must build to whatever is the Default limit! "

"Currently, the Content Creators can not deliver all their wonderful designs for vehicles, and users can't modify or convert their existing vehicles, if even one prim in the vehicle is larger than 10 metres. I argue that this is an obsolete prim size limit that has no place in our open spirit of freedom OSGrid is known for. I'm asking for the support of fellow OSGrid Citizens in respectfully proposing that the obsolete default of 10m physical prims be changed to 64m in future releases of OSGrid OpenSim dev versions. "

Open Letter to the OpenSim Developers
View original open letter proposal, posted on Opensim-dev email list

View this thread on Opensim-dev email list

Dear OpenSim Devs,

Date: 15 October 2012

PROPOSAL TO CHANGE PhysicalPrimMax=32m

This proposes a change to Regions.in file default parameter: PhysicalPrimMax=32m Old parameter was: PhysicalPrimMax=10m This parameter defines the maximum prim size limit (in any dimension x,y or z) at which the prim may be recognized by the region as a physical object. If any dimension of the prim is larger than this limit, the prim fails to become physical.

DISCUSSION AT OPENSIM MEETING

At the OpenSim Meeting last week in Wright Plaza OSGrid, I proposed changing the parameter default to PhysicalPrimMax=64m. However, after taking some data and doing some research testing various sizes and shapes of physical prims, I now propose PhysicalPrimMax=32m instead.

BACKGROUND:

The maximum prim build size using v1 viewers in SL was 10m, but this became obsolete recently with v2 and v3 viewers going to 64m. There has been *no limit* on the size of a physical prim in SL using their Havok physics engine. A mega-prim in SL can be physical (I have successfully tested 1024x1024x1024 physical prims in SL). However, in OpenSim there is good reason to limit physical prim size, mainly due to the simulator physics load causing simulator FPS to slow down.

WHY CHANGE?

Q: Why would we want to change this default value?

A: The primary motivation for changing this is the growing popularity of PHYSICAL VEHICLES in OpenSim. Content creators for the OpenSim community must design their products for the most common default value limits.

WHAT TYPES OF VEHICLES REQUIRE 32m PRIM SIZE?

Built to-scale vehicles require prim sizes larger than 10metres: boats, ships, trains, buses, airplanes, aircraft, spacecraft, automobiles, and amphibious craft. Especially multi-passenger vehicles and vehicles using tortured prims or mesh or sculpties. Tortured prims (path cut, dimpled, tapered) are often used to achieve the curve shapes of vehicles, and this leads to larger prim x,y, or z dimensions (even when the overall vehicle size is less than 10metres). Mesh vehicles tend to require larger prim size; an entire vehicle can be made with 1 mesh model.

BEST PARAMETER VALUE?

32 metres is the proposed best parameter value. It is a compromise based on performance vs the value of having creative content. Certainly 10m prims are safe performance, however, 10m severely limits the existence of vehicle content.

TEST RESULTS

In recent testing of free prims dropped to ground, it was found that there appears to be a "breaking point" in the physics FPS performance with physical prim size larger than 45 metres. When 64 metre torus shaped prims were tested, this brought the physics FPS down to a low level. But, when 32metre prim size torus prims were tested, acceptably good performance was achieved. Of course, physics performance varies considerably among simulators.

DATA:

Please see collected data on size vs. shape on Physics FPS: http://opensimulator.org/wiki/User:LaniGlobal#Proposed_Change_Regions_ini_Default_PhysicalPrimMax_10m_to_64m

CONCLUSION:

A proposal has been presented for a default change. The change would be from an obsolete, but "absolutely safe" default value, to a new value that is closer to the center of compromise in simulator performance, only when larger size physical prims are rezzed by users. The result of this change would yield a huge increase in physical vehicle content in the OpenSim Community.

Respectfully submitted,

Lani Global

Founder/Content Creator, LANI GLOBAL SYSTEMS (tm)

Owner of Lani region of OSGrid, an OpenSim/HG 3-D Virtual Sci Fi World

http://twitter.com/LaniGlobal

hg.osgrid.org:80:lani

= '''Lani Global Regions in Opensim OSGrid and HyperGrid =

'''Lani
Lani region of OSGrid is one of the most popular places in OpenSim. Creative Content for the OpenSim Community is developed and distributed. The Science Fiction environment features the Lani Global Systems Sci Fi Store, Lani Mall, the Sci Fi Hub of OSGrid, a RolePlay RP environment, RolePlay Gaming, Spacecraft Landing Docks, and the Alpha Station space station home pods for RP players. The Central Pyramid is a community center and gathering point for the Sci Fi Community of OpenSim. Lani region runs on a server by sim hosting company Dreamland Metaverse. It is HyperGrid enabled, in the Middle Realm at 8090,8090 grid coordinates. Some photo images and a real time graph of daily visitor count to Lani region can be found on the web at Most Popular Region of OSGrid

'''ixi
ixi region of OSGrid is a very popular Sci Fi sandbox area adjacent to Lani region. Creative Content for the OpenSim Community is designed, tested, and developed. ixi is well known for sandbox and RP Combat. ixi region is sponsored by Dreamland Metaverse, an OpenSim server sim hosting company. Changing rooms are provided for avatars. The Great Hall of Combat has seen hundreds of battles and duels fought. Research and development of vehicles. Myriad RP Gaming and Combat System is developed and tested. It is HyperGrid enabled, in the Middle Realm at 8089,8090 grid coordinates. Some photo images and a real time graph of daily visitor count to ixi region can be found on the web at ixi Region OSGrid visitor graph

= Lani Global Systems LSL Scripts =

Lani Physical Vehicle Flight Scripts for ODE


'''Reference Design. A physical flight hover vehicle engine and various accessory scripted parts for the vehicle child prims are presented here.''' The scripts were designed especially and intended for use in OpenSim. These scripts have been thoroughly tested and used in many vehicles in OpenSim, with the OpenDynamicsEngine (ODE) physics engine.

It is only functional for ODE PHYSICS in OpenSim.

These scripts were suitable for: Spacecraft, Hovercraft, Hoverpod, HoverJet, Helicopter, Ornithopter, Submarine, Flying Wing, Airplane, Aeroplane, Whirly Bird, Magic Carpet, Starships, Death Stars, Galactic Ships, Space Ships, Spaceship, UFO, Unidentified Flying Objects, Flying Saucers, and other types of vehicles.

A kit with a demonstration vehicle (Ornithopter) and all the parts (Engine, accessories, animations, sounds, etc) is available in the Lani Global Systems store, in Lani Mall. The mall is located in Lani region of OSGrid. HyperGrid hg.osgrid.org:80:lani

Lani Physical Vehicle Flight Engine v4 for ODE
Only for ODE PHYSICS in OpenSim

This is the engine script. This script goes in the contents of the root prim, the "seat cushion" that the pilot of the vehicle sits on. This script needs a sitting animation and 2 sounds to be functional. (Note: the engine in this script kit is designed for use with OpenDynamicsEngine (ODE) physics engine, not for BulletSim Physics Engine. For scripts designed for BulletSim Physics Engine, please see other sections of this page in the future.)

Lani Vehicle Head Lights v3
Reference Design. This is the vehicle lighting script. It goes in the contents of a child prim object that performs the vehicle headlights lighting.

Lani Vehicle Running Lights v3
This is the vehicle running lights script. It goes in the contents of a child prim object that performs the vehicle red running lights.

Lani Vehicle Lighting Touch Switch v3
Refrence Design. This is the vehicle lighting touch switch. It goes in the contents of a child prim object that can be touched to turn on/off the vehicle lighting. Normally this is a prim button on the dashboard or control console of the vehicle. This can also be edited to perform other linked message tasks. See script linked message channel notes.

Lani Vehicle Landing Gear v3
Reference Design. This is the vehicle landing gear script. It goes in the contents of a child prim object that is the landing gear that is "extended" or appears whenever the pilot is not seated. Normally this script is is a prim button on the dashboard or control console of the vehicle.

Lani Vehicle Propeller Thruster v3
Reference Design. This is the vehicle propeller thruster script. It goes in the contents of a child prim object that is the fan propeller gear that rotates when the vehicle is moved in certain directions. Normally this script is in a prim on the vehicle that has a circular texture that is animated by this script. It could be modified to provide rotation of the propeller via llTargetOmega or another method.

Lani Vehicle Brake v3
Reference Design. This is the vehicle brake script. Put this in a small child prim to be used as a button on the dashboard or control console of the vehicle. Touch it after the flight to stop the vehicle just before the pilot un-sits. This will stabilize the vehicle so it does not move after the pilot gets up.

Lani Vehicle Spherical Touch Canopy v3
Reference Design. This is the vehicle canopy that can be touched to open and close to provide entry and exit of avatars for the vehicle. Put this in a child prim and add a transparent texture. It is interlocked via link message so that it does not operate while the pilot is seated.

Lani Vehicle Passenger Seat v3
Reference Design. This is the vehicle passenger seat script. Vehicles can have multiple passenger seats. Put this in all the child prim seats where the passengers are to be seated. It requires an animation in the contents of the prim.

= Lani Global Stops Making Products for OpenSim =

'"The sands have shifted beneath my feet, revealing a cavernous pit of vipers below." --Lani Global'

I've stopped making new products for OpenSim as of April 2015.

The Lani Mall and Lani region will continue. There are now about 50 creators' shops in the Lani Mall, themed SciFi-Fantasy-Avatar-Steampunk.

It has been a wonderful 5 year run of creating products and content for OpenSim. Over the past several years, the prime focus of my work in OpenSim has been to promote and advance other creators' content and regions. When designing content, one must keep in mind the mainstream of users, as well as the limitations and quirks of the simulator platform. As the core OpenSim platform has evolved, this has often meant that products needed to be updated to work with changes in the sim software.

As for my personal decision to stop making new products for OpenSim... Here's a little background. I made products for years in Second Life, but stopped making new products when they unilaterally changed their TOS to "capture" each creator's copyright. I also took most of my older products off the market in Second Life, leaving only those products which I originally made in OpenSim but also exported to Second Life.

Recently, with the core OpenSim developer community agreeing on changes that nullify some existing OpenSim content, I decided that it was not prudent to continue to try to hit a moving target. One could be prolific and make lots of product creations, only to have the rug pulled out from under them by some new fix or "patch" in the OpenSimulator software. Since there is no respect for maintaining the usefulness of existing content, and no system of verification or checking to see if new versions break existing OpenSim content, it seems that even a very careful savvy product designer can't be assured of any longevity for the creations. In essence, the content creator is left with a choice of either to keep trying to make upgrades continuously and unexpectedly, or to stop creating for the OpenSim platform. It is the end of an early Golden Era of OpenSim, and the beginning of a new phase. There will be a new generation of creators in OpenSim. We see them now starting to appear. Currently, there is no automated scripting update method. Each script takes careful trial and error, or sometimes a re-write. Also, there is still the issue of LSL and OSSL scripting, both of which are available in OpenSim, but OSSL is not available for everyone. So, mainstream creators can not really design products using OSSL if they want the product to work for everyone.

Why Is My Stuff Broken?
'''For thousands of users, when their stuff doesn't work, they don't know why.. and they just think it is crap.''' The cause may be changes in the simulator server, or changes in the scripts, or the way prims or mesh perform. Backwards compatibility is often not paid attention to. When there is a proprietary interest, or moneyed interest in a business, such things would be carefully weighed. But, when volunteers write the code for free, the resources may not be available to keep track of everything, or test it.

What Can Be Done About It?
I won't be doing any crowdfund promotion or instigation. Most core OpenSim developers see it as an experimental project, not as a content platform... and therein lies a juxtaposition of user interest. So, no matter whether something is fixed in the near term... something else is only a patch away from being broken in next month's release. The OpenSim devs who are concerned about such things as continuity are only those who run their own for-profit grids, and they carefully manage their own proprietary versions of OpenSim simulator code that runs on their grid. I'm not disparaging OpenSim developers, far from it, I have the deepest respect and awe for what has been accomplished. It's just that there are many developers and each has a different level of expertise, direction of importance, and area of interest. After all, if I want something fixed in OpenSim, I can write my own patch for it. What a wonderful system!

Update September 2015
I've cautiously started making a few new products. But, I'm not working on any vehicles yet. I may wait another few months to see if the codebase has stabilised enough that it is worthwhile to put time and effort into a BulletSim vehicle Reference Design project, similar to the one I developed for ODE. The primary objective of such a project would be to make a drop-in retrofit engine script kit that would work for both ODE and Bullet. This would either be via automatic change-over, or by user dialog command.

= The End of ODE in OpenSim and The Rise of Bullet Sim Physics =



The Open Dynamics Engine (ODE) was the main physics system in core OpenSim since the beginning. Tens of thousands of person-hours were devoted to making thousands of products and a vast array of content based on ODE. ODE was an earlier design, and it had some shortcomings compared to more modern physics simulation, such as the new BulletSim Physics. Bullet Physics Laboratory, with the hard work of Robert Adams, brought improved Real-Time Physics Simulation to OpenSim recently, and it has become the default physics engine. For much of 2014 and early 2015, either ODE or Bullet could be selected by simulator owners for their regions.

Recently there has been a conscious decision among core OpenSim developers to abandon ODE entirely and rely totally upon Bullet. This kind of technical discussion of "Physics Engine" ordinarily would not be of any consequence to the average OpenSim resident or user... But, for one fact: Most products which move or have physics, that were designed over the past 7 years in OpenSim, were designed for ODE. The ODE products and content do not work well, or fail completely in Bullet. Up until core OpenSim simulator version 0.8.0, the usability of ODE was not affected. So a region owner could choose ODE or Bullet. On simulator software OpenSim version 0.8.1, OpenSim developers decided that it was OK to start introducing features to advance core feature performance to work in concert with Bullet physics. Some features that were introduced to advance Bullet were at the expense of rendering ODE products and content useless.

Deprecation of ODE and Evolution of Physical Vehicles
Oddly enough, a recent crowdfund to fix a core OpenSim feature related to physics caused some ODE products to fail :) One of the areas that I've worked to advance in OpenSim, is Physical Vehicles for ODE. The vehicle category was cited as "most popular" in numerous HyperGrid Business polls. HyperGrid Business polls of users over the last few years showed that Physical Vehicles were at the top of the desired list of features and functions for OpenSim. So, I worked within the coder & content creator community to develop a kit for vehicles. Prior to that work, the default for maximum physical prim size in OpenSim was 10 metres. This affectively made it impossible to make larger to-scale vehicle products. That default was changed to 64 metres size, which enabled multi-passenger physical vehicles to be marketed to mainstream. Oddly enough, there was a lot of resistance to that change by the OpenSim developer community. I lobbied and cajoled many core OpenSim developers for over a year, even published scientific tests and graphs, and then submitted the changes as a "patch" to the OpenSim code myself. It was finally accepted and became the default in OpenSim, ironically because it was compatible with new Bullet capabilities, which had progressed by then. Thus, we now have multi-passenger airplanes, ships, boats, helicopters, spacecraft, cars, etc. Reference: my campaign for multi-passenger physical vehicles in OpenSim http://opensimulator.org/wiki/User:LaniGlobal#OpenSim_Change-Advocacy_Projects

Now we are moving into a brand new phase of content made for OpenSim that is designed only for Bullet Physics, since ODE has been "defacto deprecated", which is developer-speak for "abandoned". So, core OpenSim content that was made prior to 2015 that uses physics must be either thrown away or modified to be compatible. In some cases, the ODE-based content may be broken, even if the simulator owner has selected the ODE engine for their region. Some OpenSim grids still run entirely on ODE, and have made proprietary improvements to it that rival the performance of Bullet. Indeed, there may be some advantages to ODE, such as reduced server memory requirements. Even though, many believe Bullet performance is superior, and it probably is in many ways. In my case, I don't take sides on which is superior. My philosophy has always been, to design creative content for the mainstream user.

Dealing With Physical Vehicle Compatibility Issues for Reference Designs
I developed Reference Design scripts and a companion free product, a sort of "Lego kit" of parts, so that anyone could build their own vehicle. Or, they could just drop that "script engine" into their favourite mesh model and have a working vehicle. Reference: my script for multi-passenger Physical Vehicle Kit for ODE http://opensimulator.org/wiki/User:LaniGlobal#Lani_Physical_Vehicle_Flight_Scripts_for_ODE

Because of the version incompatibilities for virtual physical product design, I was recently faced with the need for at least 3 different versions of each product.

(1) ODE products prior to OpenSim 0.8.1 and

(2) ODE products after OpenSim 0.8.1 and

(3) Bullet products after 0.8.0.

I worked on a script system that could detect and auto-switch the product from ODE to Bullet, but found it infeasible. In the HyperGrid Business article "Dahlia Trimble’s fix earns bounty" an OpenSim developer was crowdfunded to fix a function. Dahlia's fix of the llLookAt function was hailed as a great achievement. And yes, it was, for Bullet-based sims. But it broke ODE content. http://www.hypergridbusiness.com/2015/02/dahlia-trimbles-code-fix-earns-2000-bounty/

Of course, where there's a will, there's a way. But at the recent OpenSim developer meeting I attended, it seems there's no desire to maintain "legacy content", which is developer-speak for "existing stuff you already have".

It is difficult enough to write code for OpenSim, even for a single physics engine. To keep track of all the differences, isn't feasible. So, the move to abandon ODE is completely understandable and probably a wise one. Wise for the coders and developers of OpenSim.

A for-hire OpenSim dev I know, developed magnificent ODE physics engine code for vehicles that rivals Bullet. But that code was locked away. And they did that in 2012. It was only used in a walled garden for-profit closed grid. That is the problem with software platform "Forks". When there's a fork in the code, it is up to the fork-maker to be on their own from then on. That makes it a lot less likely to be merged back into the core platform software, for various reasons.

Physical Vehicle Reference Designs for ODE and Bullet
Generally speaking, Bullet physical vehicles and ODE physical vehicle scripts are not compatible. ODE required special script design. Bullet physical vehicles scripts are more like Second Life vehicle scripts, but there are still a lot of changes and tweaks by trial-and-error. There are not really any How-To-Guides for Bullet scripting that I know of. Experimenters and creators are needed to make what we call "Reference Designs". Reference Designs are like engineering plans that are usually open and suggested as a starting point by manufacturers. Designers use the Reference Design as a foundation, and then embellish it or mould it into what they need for their product. In my case, I made a Reference Design, a physical vehicle for ODE. It became widely used by many OpenSim creators. I did it because I was interested in promoting OpenSim and there were no viable Reference Designs out there at the time. Nebadon did the same for an ODE land vehicle, the "Neb's Racer" car. While I did it for flying or water vehicles. There are a number of Bullet vehicle scripts floating around, made by various creators. Some are adapted/modified SL vehicle scripts. But, so far, a published open Reference Design script for Bulletsim physical vehicles has yet to reach the mainstream. I developed my own Bullet physical vehicle script for flying vehicles. I was working toward an ambidextrous vehicle script Reference Design that could auto-switch ODE/Bullet. I was in the process of working out the bugs of it, and have collaborated with 2 other vehicle scripters on it.

But the February 2015 changes in OpenSim's "ODE abandonment" made me re-think that. I would have needed a switch for 3 different 'modes', and who knows if something else might change again that would render it fruitless. So, as one might say, "The sands have shifted beneath my feet, revealing a cavernous pit of vipers below."

= OSGrid Is Two Grids In One =



OSGrid has been somewhat of a conundrum in itself. Founded as a "Test-Grid/Residental-Grid" for core OpenSim, it became a huge residential grid. But sometimes the Test Grid aspect of it made it not such a wonderful Residential Grid. Yet, the residents were needed to test, so it exists as a vicious circle of wonderfully chaotic symbiosis that somehow works out well.

= Determining Physics Engine by Script Functions =

NOTE July 2017

A solution to this problem has been implemented in OpenSim. see string osGetPhysicsEngineName []

The OpenSim Mantis report can be viewed here: []

Since multiple Physics Engines are available on a modular basis in OpenSim, there is a need for scripted objects to self-discover which Physics Engine is active in a region. The OSSL function OsGetPhysicsEngineType is available in regions which have OSSL allowed and authorized for access of the function by the user. However, OSSL is not universally authorized to all users who have script allowed. This is needed for viable content creation and product manufacture of physical scripted objects, such as vehicles which run solely LSL script. Therefore, I propose that an LSL function be modified and extended with some additional flag or value so that it can be utilized.

One possibility for an OpenSimulator extension of an LSL script function to determine Physics Engine, is the llGetEnv function.

An OpenSimulator Mantis Bug Report has been generated for this issue. OpenSim Mantis #0007528: Discover Region Physics Engine Type by LSL Script Function

llGetEnv Test Unit
Function: string llGetEnv( string name );

Returns a string with the requested data about the region.

• string name – The name of the data to request.

Note: the value returned is a string, you may need to cast it to an integer for use in calculations.

More information on the llGetEnv function

Region Flags Test Unit
Another possible method is, for example, to use one of the ancient deprecated flags in the LSL function llGetRegionFlags, it could be newly implemented and extended in OpenSim simulator code. To explore this further, I made a Region Flags Test Unit. A script for testing region flags, using the function llGetRegionFlags is offered below. Drop the script into a prim and touch it. It will say the total value of region flag and the hex value of every possible region flag hex bit.