I’ve recently been batting around an idea for a community event. It would be similar to game jams or forty-eight hour film competitions, but with a distinct Opensim twist.
For forty-eight hours, a completely blank Hypergridded sandbox region is left open to the public. A theme is provided, as are any shared starting assets. Participants are encouraged to come by and build something in the theme that they want to share with the public. No outside assets are allowed, only what is provided and what is built. Dance parties are thrown at the zero, twenty-four, and forty-eight hour marks to give participants a chance to unwind.
At the end of the time limit, the region is archived as an OAR and made available to the community. The region may also be placed in a showcase mode, allowing users to come by and see the contributed works.
The OAR Party could be a fun, focused, community-driven way to generate new creative content for the Open Metaverse. What theme would you choose?
For the first time since I started tracking it, the simultaneous Hypergrid user count (as tracked by OpensimWorld) broke 100. Not only is this a sign of growth in terms of user population, but also in the terms of publicly listed regions. Sites like OpensimWorld are helping the Hypergrid immensely, but we shouldn’t underestimate the power of social proof. Humans are social creatures, and we do derive comfort from knowing that we’re part of a quantifiable, tangible group. 100 Users might not seem like an impressive milestone, but celebrating the small steps is crucial. Here’s to 200.
Update: Ange Menges, one of the co-creators of Kodipump, has responded. The models are being sourced from some free content sites, and they were unaware of the models’ origin.
This is going to get ugly, but I feel like we need to talk about this.
Yesterday I visited the Kodimpump2015 region on OSGrid. As someone with a passion for bringing game-play and interactivity to the Hypergrid, the concept of a themed hunt seemed to be something worth exploring and supporting. I was on the whole very pleased with my experience. My experience isn’t what I want to talk about, rather I’d like to talk about the gifts being given as rewards.
Pictured above is one of the mesh models I received as a reward. The character is Kai from the PlayStation game Heavenly Sword by Ninja Theory. To my knowledge, this is a piece of content that has never been released into the commons as a free asset. In fact, the only place I could find this model was here on the DeviantArt page of an individual who rips assets from commercial games. The other gifts I received are similarly questionable as to their origin, but none are a smoking gun like Kai here.
The Open Metaverse already has a bad rep for content theft. That reputation keeps experienced content creators away. Without compelling content, the draw to the Open Metaverse for newcomers is minimal. Distributing content like this only pours more fuel on that fire.
I get the allure of using content like this for your own personal use. If you upload it yourself, you are personally accepting the potential liability should the original content creator raise issue. Distributing it freely as gifts with no acknowledgement of its’ source to guests goes beyond that. You are exposing each recipient and the grids that host that recipients’ content to potential legal trouble.
Do I think the Kodipump creators have malicious intent? Of course not. Perhaps they have an open philosophy regarding intellectual property. Perhaps they got it from another party and were oblivious to its’ source. Regardless, it’s irresponsible to be distributing content of unknown origin. At the very least it tarnishes the reputation of the Open Metaverse and at worst exposes otherwise innocent individuals and organizations to legal action.
We can be better than this. In fact, in order to prosper, we have to be.
When we are confronted with the a large number of options, some people can feel paralyzed. This condition is known as “decision fatigue”, and if you’ve ever felt overwhelmed at the supermarket when trying to decide what kind of toothpaste to buy, then you’ve experienced it. The neurons in our brain can’t really tell the difference between a small decision and big one, and making any sort of decision requires our brain to expend energy.
As our brains get fatigued, we become more likely to taking shortcuts and more susceptible to suggestion. A 2015 study in Proceedings of the National Academy of Sciences, found this anxiety can heavily weigh on some people’s lives. The study found that judges granted parole to prisoners 65 percent of the time in the morning, but the rate decreased throughout the day to zero. When the judges were given a break, their grant rate jumped back to about 65 percent. Being tasked with making decisions fatigues the brain. Even when we feel confident with our decisions, the process causes anxiety.
There are a lot of places where this can be applied to Opensim. Viewer options, avatar customization (especially for new users), places/things for new users to go/do right off the bat, etc. As power users, we want these choices, but for new users too many options can be toxic.
Since the dawn of networked gaming, providers have looked for ways to keep the money spigot flowing. Games like World of Warcraft have subscription models, where users pay them every month for access to the online world. Other games like SecondLif…
While my experiments with Dogecoin have largely come to a halt, this article touches on some of my thoughts about the future of money on the hypergrid.
I've stopped waiting for the "right time" ,the "right conditions". I've stopped waiting for some group to sweep on and magically believe in Opensim. Nothing will be accomplished that way. Instead, I'm moving forward. I'm creating, experimenting, exploring what I can do Right Now with what I have for skills and resources. That OSSL heartbeat function I was pining after? A 10 line script using commands that already exists works just fine. New viewers to bring in new users? Let's see if I can create compelling content that would attract new and existing users regardless of viewers. I'm sick of being an armchair general. The war for an open metaverse is down in the trenches. It's every interaction a user has with the metaverse, every memorable experience. That's where I can be helpful and why I won't wait.
In this post, I'll describe a proposal for a new system for OSSL. It seeks to create a feasible workaround for the problems which plague the timer event in Opensim.
The OSSL Heartbeat System:
Problem: There is often the need for object scripts to act at regular time intervals in order to provide periodic action to provide stimulus for agents and other object scripts. However, the timer facility provided by LSL/OSSL has proven to be an inefficient solution to this problem. This has led to a scenario wherein creating content which requires timer-based periodic action is discouraged, thereby preventing the easy development of immersive interactive simulations.
Observations:
Simulations which exclusively react to explicit user interaction feel less immersive than ones in which actions occur proactively.
Many object scripts using the timer event don't need a precise timer, rather they need a simple and reliable system for repeated script triggering.
Many game systems implement repeated script action with a periodic world heartbeat event.
A heartbeat system can be derived from the simulation frame system, and provide a low-overhead solution to periodic script stimulus.
Solution: Economize the time-keeping functionality to provide a scalable system for proactive action. Rather than requiring scripts to request a repeating timer event, the simulator emits a periodic "heartbeat" event. If a script has subscribed to this heartbeat event, they will recieve the event via a dataserver event. The heartrate can be configured in two ways by the simulator. It can be derived via a set frame increment (once every x simulator frames). Alternatively, a target heart rate can be set, and the simulator will dynamically adjust the frame increment to attempt to match the target. The OSSL API provides facilities for determining the current and target heartrates.
Proposed API Definition:
key osHeartbeatListen()
Sets up a listener for the region's heartbeat. When the heartbeat is emmited, the script will recieve a dataserver event with a key matching the returned key. The returned message will be the current heartbeat count.
void osHeartbeatUnlisten()
Unsuscribes the script from the region's heartbeat.
float osGetHeartbeatInterval()
Returns a float of the average interval in seconds between heartbeats. This allows a script to dynamically adjust its behavior to match the simulator's heartbeart.
float osGetTargetInterval()
Returns the target heartbeat interval for the region (in seconds). If there is no target (i.e. there's a static frame increment), the returned value will be zero.
Additional Notes:
The proposed API has been kept intentionally short and as stateless as possible. There is a temptation to add more commands, but until these prove to be useful the API should remain small.
In order to facilitate the target heartrate and frame increment functions, there will need to be additions to the config files. Allowing these values to be settable via script seems inadvisable at this stage.
An added benefit of a heartbeat system is that it can facilitate synchronized object behavior without relying on time-sensitive message passing or knowledge of all participating objects. This is behavior which would be more difficult to implement using existing LSL/OSSL commands.
There is a weakness to this system if there is a significant script demand triggered by heartbeats. In extreme cases, this could lead to reduced simulator performance. The magnitude of this weakness remains to be seen pending implementation and testing.
There's been some talk recently about converting the RealXtend WebTundra client into a Opensim web viewer. This has many, very attractive attributes that are definitely worth pursuing. The question remains: What is the critical path to such a conversion?
Rather than pretend I have the answers, here's some thoughts/questions:
WebTundra completeness: Is WebTundra actually a fully functional piece of software, or is it just a collection of parts that need further assembly?
Simulator WebSocket work: While 0.7.6 brought WebSockets to Opensim, it's unclear how much more work is needed to have them fully replace the standard UDP client circuits.
Content Transfer: If simulators aren't hosting their own web viewers, how do we handle the problems of content transfer?
User login/session decisions: Is each region it's own web page? Is that page served by the simulator? Should anonymous users be allowed, and how would that work?
Prims: Do we ignore them outright and only display mesh? Do we attempt something akin to InWorldz's DreamShare and convert prims to mesh on the server? Do we go all-in and attempt to port the prim-meshing code into Javascript?
Avatars: Fully custom avatars are probably too much to ask for up front, so what is the alternative?
UI Design: With a focus less on avatar appearance, building, and inventory management, the UI will need a total rethink.
These are only the first few questions, some with no easy answers. Thankfully, we have the luxury of being able to start out basic and improve incrementally. My guess at a critical path MVV (Minimally Viable Viewer) would be:
I've made a super simple item vendor script that uses my Dogecoin checkout system. You can get it here: https://github.com/AlanTupper/SimpleBlockIOVendor/blob/master/vendor.lsl
In the process I made some improvements to the checkout system. It now gives you the ability to cancel a transaction you didn't intend, and will automatically return successfully if the transaction price is set at 0. You can get the upgraded script here: https://github.com/AlanTupper/BlockIO-LSL
Based on this, I'll be working on a multi-item vendor script and a vendor object to go with it.
This is pretty exciting, after all, you can literally now pay objects and get items! Commerce! Anywhere on the Hypergrid!
Such wow.
PS: These scripts will also totally work in SL if you like to live dangerously.
I have a terrible habit of not following through with projects. It's a frustrating, self-destructive habit and it's not something I want to keep as a personality trait. I suspect part of it has to do with a percieved lack of external input as to whether a project is worthwhile or needed, which leads to constant second-guessing and procrastination.
To the end of ridding myself of the habit, it probably can't hurt to list out all the different Metaverse projects and ideas I've been mulling over. For the sake of brevity, I'll exclude the ones I've already talked about in this blog. Ideally, it'll give me the ability to sort it all out, give you the ability to peek at what I'm up to, and give us the ability to suss out which projects and ideas are worth seeing through. Any and all feedback on the projects listed out here is more than welcome!
DI is a Hypergrided region I am creating to promote the use of Dogecoin on the Hypergrid. I firmly believe it is a good match for the decentralized, secure, microtransactional needs of the Hypergrid. Right now the island is roughed-in but there's a lot of content which needs to be added.
Dogecoin Transaction Scripts:
While implementing Dogecoin as an integrated currency module in Opensim could have some benefits, I'm currently of the opinion that it will only slow down adoption. I've created a basic transaction script that uses the Block.io transaction gateway to allow Opensim users to create, sense, and act upon Dogecoin transactions. This can be used for item vendors, tipjars, or any other system where payment is needed. While there's plenty I'd like to do to improve the script, you can find it here.
Nullspace Regions:
Nullspace Regions are a relatively minor tweak in Opensim/Whitecore behavior. Nullspaces have no land or sea, and can be as 1m x 1m. Their purpose is to create the ideal conditions for interior simulations, and other simulations where a square quarter-kilometer of land and sea are completely unneeded. It's still really an idea on paper.
GroupGrids:
GroupGrids is a reimagining of how Opensim could/should handle space continuity. It abandons the "see all the regions in the grid" style map, and instead allows groups to cultivate a collection of regions they find relevant. Your active group would determine what regions were listed for immediate access. The map would only show the regions physically connected to the user's current region, making the map actually useful again. Just an idea on paper at the moment.
Acetone Viewer:
Almost all current Metaverse viewers are far to complex, finicky beasts to be well suited for newcomers. Acetone is an attempt to create a viewer around one thing only: Social exploration of compelling Metaverse experiences. No build tools, no deep avatar customization, first person view, rethought UI, and an overall "it just works" mentality. Still on paper, still intimidated by thought of diving into the viewer code uninitiated.
Entity Event Scripting Language (EESL):
I have come around full circle on my internal debate of what to do with LSL, and am currently attempting to design EESL. EESL is a far more generic, expressive scripting language derived from LSL, but based on the needs of Opensimulator and other similar VW platforms. This is still in a pretty early phase, and to be honest, the idea of trying to write my own compiler or interpreter scares the crap out of me.
Open Hyperlinked Metaverse Protocol (OHM):
OHM is a very flexible protocol for defining complex multiuser virtual environments of practically any configuration. It assumes pretty much nothing about what the environments are or what their use is. OHM uses XMPP/Jabber as it's baseline. I've roughed out all of the core logic and flows of OHM, but haven't sat down to flesh out a concrete protocol vocabulary.
Parametric Universal Multicast Protocol (PUMP):
PUMP is meant to be used in conjunction with OHM. PUMP fills the role of efficiently streaming live updates between users, something OHM isn't designed to handle. The combination of OHM and PUMP is intended to make a very expressive, scalable Metaverse architecture that can be both flexible, big, and fast. Like OHM, I have the rough contours of it sketched in, but have been reluctant to solidify any details.
Persistent Region of Multi-agent Physics Templates (PROMPT):
PROMPT is a deconstruction of an Opensimulator region, ripping away everything but the physics simulation. By focusing only on the physics, the hope is to make improvements to scalability, performance, and flexibility. Theoretically, a PROMPT could be conversant with both PUMP and OHM. Still just an idea on paper.
A Reasonably Small Object Notation (ARSON):
ARSON is an attempt to take what was started with BSON and hit it with a shrink ray. Its primary motivation is to make a very efficient format for pushing lots of small data objects back and forth very quickly. I got as far as creating some basic schemas, but got bogged down on some special features that are probably completely unneeded.
Looking over this list I'm seeing a pattern of failing to commit to the details, or avoiding implementing ideas. If anyone has some insight on how I can get over this, that would be excellent.
I've just created a subreddit community for the Hypergrid. I hope you join me in sharing and discussing amazing people, places, and things from around the Hypergrid!
So if you haven't heard yet, Linden Labs is developing a new virtual world platform. It sounds like it will be a clean break from Second Life, more in line with the current trends in computer usage (tablets, maybe VR headsets).
Good on them. As a company, it's the right thing to do.
There's an uproar happening right now as the rumor mill kicks into high gear, with words like "Abandoning" and "R.I.P" being tossed around. Some are saying this is bad for Opensim as well.
Let's have a deep breath and have a reality check. We have (for years) been developing Opensim as a liferaft for Second Life users. With the recent 0.8 release, the software is readier than ever to start accommodating those who feel Second Life is now a sinking ship.
The Metaverse is not dead, nor critically wounded by this announcement. I say it is strengthened.
Knowing that SecondLife will not be immortal is an important realization in order to solidify action toward an Open Metaverse. Without it we will forever hang on the Linden's word, deferring to Second Life as the reference implementation.
This is not the end, this a milestone.
As for ongoing development, the eventual mothballing of SecondLife will pose something of an organizational challenge for viewer developers. They have long deferred to Linden Labs when it comes to new features. We will need to come together to find a new method of organizing development, most likely in the vein of how the Web handles new feature innovation. This may be a rocky transition, but it's not the end. The amount of outcry says as much.
Parental Issues: The Case for Object Attachment Points
This is the third and final article about a set of new object types I would love to see implemented in Opensim. The world is very flat for objects in Opensim. Not flat in a traditional up-down sense, but rather in terms of hierarchy. An object can either fly solo, or be part of a single link set object. But what if we wanted two or more linked objects to act like one unified structure? Barring some fancy (and laggy) script work, it's hard to make one linked object act as the child to another. What we need is a system where a linked object can have attachment points, not unlike the ones avatars currently have. Objects can be assigned to these attachment points, and will follow the movements and behavior of their parent object. By making these attachment points objects themselves, we can stay consistent with the manner in which objects are currently handled in Opensim, imparting transformation, communication, and scripting abilities to attachment points. Combined with the Client-side Sprites mentioned in the previous article, they might even replace pose balls some day. Giving objects the ability to connect flexibly with each other is important. Without it, the world will always be a bit too stiff for its own good.
This is the second of three articles about new object types I'd love to see implemented in Opensim. Today, when you log into Opensim you view two different worlds. One is the 3d world of the region, where avatars and objects exist. The other is the flat world of the UI attachments, welded solidly onto the viewer, viewable only to their wearer. The two worlds remain visually quite separate from each other, despite the fact they are both hosted on the same simulator and rendered on the same viewer. There is a middle ground between these two worlds which is largely unaddressed by Opensim. This middle ground is objects which appear to exist in the 3d world, but are only visible to a certain user. These kinds of objects are crucial for many applications, from games to engineering, because they provide something very useful: personalized information in the 3d context. Client-side Sprite objects could fill this role. They would appear as a floating icon image/graphic that exists in the 3d space, yet would only be visible to certain users as determined by object scripts or region modules. They would be reactive to events such as touch and proximity, allowing their behavior to be dynamic and intelligent. These Sprites would basically be Augmented Reality for the Metaverse. Imagine games where characters had health-bars, or navigation systems where destinations are marked for only the people who need it. Those are only a few possibilities. The potential is there, waiting to be unlocked.
turnnoffyourmind
kianamaiart
theartofmadeline
areudirty
izzy806
