|
Threads
View context
Be careful what you wish for... This has been a long trek through the "rabbit hole". I want to say I am at 75% on the progress scale and I will be ready for BETA testers prior to opening... I have accepted your Friend request and I will send out messages to those who wish to participate. It could still be a month or two, assuming I do not run into any major obstacles. My primary concerns are:
1. Getting the rest of the rides properly keyframed and fully operational, I am at 70%.
2. I still need to simulate attractions doing the unexpected like breaking down. 0% on that.
3. The skill games are at 5% right now. They will control the NPCs which populate the sim and
4. I need to tweak bulletsim for better collision performance with hidden traps.
like(0)
1. Getting the rest of the rides properly keyframed and fully operational, I am at 70%.
2. I still need to simulate attractions doing the unexpected like breaking down. 0% on that.
3. The skill games are at 5% right now. They will control the NPCs which populate the sim and
4. I need to tweak bulletsim for better collision performance with hidden traps.
View context
OOPS, I accidentally left it open to the public... I had some HG visitors the other day and I needed to open it up for them to test some code I was working on. Glad to know you liked what you saw but be aware there could be a bunch of changes the next time you see it... Visually, most of the park should stay the same but much of the work will be in scripting or keyframing the attractions.
I will send out notices to those who want in on the beta test along with the requirements... I still have a way to go before it is ready for beta testing.
like(2)
I will send out notices to those who want in on the beta test along with the requirements... I still have a way to go before it is ready for beta testing.
View context
YOU ARE SHARING... and they can enjoy your creations when they visit your sim. When you visit an ART gallery or a MUSEUM you do not get to take a copy of the ORIGINAL ART or the dinosaur bones home with you. So many people in Opensim and OTHER GRIDS have this attitude that anything they see they should be able to take. As a content developer, you have a right to exclusivity. I label my most popular attractions "not for sale" in the description. If there is something I made that someone wants bad enough, I will be happy to share my tips on making one for themselves which will be an ORIGINAL work. I would think that should have more value than something copied. Don't be put off by these selfish naysayers, continue doing your own thing, it is your time and resources. You will get so much more out of those who really appreciate your talent. Cheers!
like(6)
View context
Many of us who run simulators have been doing so for several years. When I started hosting my simulators Bento had not come out yet. You had a choice of ode or bulletsim and Xengine was the only script engine that I am aware of... 0.7x was being phased out in favor of 08x ... I refused to upgrade to 09x until it matured... Remember the memory leaks, @Opensimworld? You will have people who are hesitant to upgrade and there are plenty of valid reasons for it.
like(1)
The first Opensim grid I joined in 2018 was run by retired IT professional Bill Blight, and he was already using 0.9.0 at that time. Every time Ubit had something new, he and Bill would get together and load it into the grid, then ask me to tell them if my store broke or not. It was wild but fun. For a while, Bill even had his own version of the Firestorm viewer that I loved called Openstorm, but then he had a heart attack and decided to retire from grid hosting altogether. The current NGC development group has his mindset, and I love their willingness to be the first to step into the unknown. I'm on three of their grids now.
like(0)
View context
I had way too many console errors as a result of switching to Y (temporarily) last night. Some would mention the script name, others would use some string of characters I do not understand and I would have no clue on locating the problematic item.
like(0)
One thing that I believe can cause issues is not clearing out the ScriptEngines folder before restarting. i.e. you should shut down the sim, make the INI file changes to switch X off and Y on, then delete everything in ScriptEngines folder, then start up.
like(0)
I renamed the ScriptEngines folder and it generated a new one... this way I have a backup of my X script states. I should have mentioned this in my prior post...
liked(1)
View context
I sat up half the night running Y through the hoops.... I found a bunch of irritating little things which could be fixable but I am not willing to do so... For Now, X is perfect for my needs. Y is fast but not worth the headaches. A lot of my gadgets use your code or derivatives thereof and I cannot live without them! Thanks for chiming in!
like(0)
View context
I remember that It took Kitely a while to move onto Opensim 0.9.x. Kitely's adaptation of Opensim is rock solid, they have patched the software to do some remarkable things no other grid has been capable of. Adoption may be slow while they are tweaking their improvements to match current code. In the meantime, the older, reliable option is available to those who choose to wait. Cheers.
like(0)
There are already a significant group of grids who have been developing and using ngc 0.9.2 for some time now very successfully - a fork well ahead of anything else going on. I have regions on 3 of those grids
like(0)
Truth be told, I have a few issues with forks, particularly when they aren't maintained by and for a big and popular grid.
One issue is that the maintainer of a fork has to take over changes at the original in order to stay compatible. Especially if we're talking about a one-person project, the maintainer may be rather picky in what's taken over. For example, several forks that were created from OpenSim 0.8.0.* or 0.7.* did not implement the changes in vanilla 0.8.2.1 that led to basic Bakes-on-Mesh compatibility. This gives you an OpenSim NextGen that reports back the version number 0.9.1.0, but that doesn't support BoM at all, even less than vanilla 0.8.2.1.
Another one is that the development of forks may end quickly. NextGen is dead and gone. The once-popular German fork ArribaSim is dead, too. Just to name two. Both were discontinued before even implementing BoM.
If your fork dies, you can be lucky if there's a way to migrate your grid to vanilla. If there's none, you can choose between going on running an increasingly outdated grid with gaping security holes and no support for any new mesh body version that came out in the last two and a half years and re-installing your entire grid. And the feasability of the latter depends on whether IARs and OARs created with the fork are still compatible with vanilla. If too much has changed, have fun starting over from scratch.
I do hope that the NGC developers won't quit anytime soon, also because that'd mean that the Fire and Ice Grid would be one of the next to sit on a dead fork.
liked(1)
One issue is that the maintainer of a fork has to take over changes at the original in order to stay compatible. Especially if we're talking about a one-person project, the maintainer may be rather picky in what's taken over. For example, several forks that were created from OpenSim 0.8.0.* or 0.7.* did not implement the changes in vanilla 0.8.2.1 that led to basic Bakes-on-Mesh compatibility. This gives you an OpenSim NextGen that reports back the version number 0.9.1.0, but that doesn't support BoM at all, even less than vanilla 0.8.2.1.
Another one is that the development of forks may end quickly. NextGen is dead and gone. The once-popular German fork ArribaSim is dead, too. Just to name two. Both were discontinued before even implementing BoM.
If your fork dies, you can be lucky if there's a way to migrate your grid to vanilla. If there's none, you can choose between going on running an increasingly outdated grid with gaping security holes and no support for any new mesh body version that came out in the last two and a half years and re-installing your entire grid. And the feasability of the latter depends on whether IARs and OARs created with the fork are still compatible with vanilla. If too much has changed, have fun starting over from scratch.
I do hope that the NGC developers won't quit anytime soon, also because that'd mean that the Fire and Ice Grid would be one of the next to sit on a dead fork.
Yes, I loved NextGen. Sadly that is no longer being updated and nobody has taken over the project. This is a cold reality. Some forks in the OpenSource world are alive and well... Ubuntu is a fork of Debian. Manjaro is a fork of Arch. Opensim never gained the same traction as other projects and that is unfortunate.
like(0)
My guess is that NextGen arrived at a dead end. Vanilla OpenSim had basic BoM support from 0.8.2.1 to 0.9.1.0 and full BoM support starting with 0.9.1.1. NextGen, which had 0.9.1.0 as its highest version number AFAIK, never had any BoM support.
Now, OpenSim 0.9.1.1 had full BoM support as one of its key killer features. In order to achieve that, a whole lot of work would have been necessary on NextGen, if the modification on NextGen in comparison with vanilla had made the implementation of BoM possible at all.
like(0)
Now, OpenSim 0.9.1.1 had full BoM support as one of its key killer features. In order to achieve that, a whole lot of work would have been necessary on NextGen, if the modification on NextGen in comparison with vanilla had made the implementation of BoM possible at all.
I am pretty sure the latest NextGen has BOM. I understand Hyacinth worked with LaNani on the project to add new features but I have not seen anything as to whether or not she will pick up the project in LaNani's absence. There are plenty of other forks that people can check out though. 'Isthmus' is the most promising derivative and I know the person who maintains it has been around a long time and is dedicated to her work.
like(0)
Well, Otterland runs on OpenSim 0.9.1.0 NextGen, and I know from personal experience that the grid doesn't have any properly-working BoM support. You're likely to return with an avatar that needs repair.
like(0)
View context
I appreciate all of the feedback. If you guys have any additional security tips to share, feel free to add them here. =D
like(0)
View context
I run Xengine on my regions and I love it. IT WORKS and it is STABLE. If it ain't broke, why should I need to fix it?
I LIKE TO READ AND I DO MY RESEARCH: According to the opensimulator website, on their yengine page, it states in highlighted warning boxes under "new language extensions" that there is more than one version of yengine that your scripts may fail to work on. This clearly tells me that Yengine is TOO new and it needs more time to mature.
Why should I have to upgrade to an engine which will cause half of my scripts to stop working, making me have to re-write code when the current engine is doing the job to my satisfaction? AND what happens when a new update to Yengine borks the lsl that you spent several hours programming? Many of us Linux geeks who truly embrace open sourced software want STABILITY in our programs and are cautious to allow NEW software to mature before opting to use it.
The Xengine page states: This is a fully functional, full featured script engine which supports persistent script states and script state serialization. OH yea? If Yengine is so GOOD, why is there no mention of this on the Yengine description page? I love the idea of being able to start up my simulator without needing to recompile the scripts every time the simulator is launched. Having script states stored on the server is an excellent time saver.
NOW... it is not my goal to start a HOLY WAR here. Use whatever makes you HAPPY just make people aware of the system requirements of your products. If you are making a WAR hud that requires YENGINE, then put that information ON THE BOX or on a notecard inside the box so people do not complain about your stuff not working.
Just because you want to hop on the BLEEDING EDGE bandwagon does not mean everyone else has to. I will eventually get around to testing Yengine again but until it exceeds my expectations, I will stay on the older yet STABLE Xengine.
like(4)
I LIKE TO READ AND I DO MY RESEARCH: According to the opensimulator website, on their yengine page, it states in highlighted warning boxes under "new language extensions" that there is more than one version of yengine that your scripts may fail to work on. This clearly tells me that Yengine is TOO new and it needs more time to mature.
Why should I have to upgrade to an engine which will cause half of my scripts to stop working, making me have to re-write code when the current engine is doing the job to my satisfaction? AND what happens when a new update to Yengine borks the lsl that you spent several hours programming? Many of us Linux geeks who truly embrace open sourced software want STABILITY in our programs and are cautious to allow NEW software to mature before opting to use it.
The Xengine page states: This is a fully functional, full featured script engine which supports persistent script states and script state serialization. OH yea? If Yengine is so GOOD, why is there no mention of this on the Yengine description page? I love the idea of being able to start up my simulator without needing to recompile the scripts every time the simulator is launched. Having script states stored on the server is an excellent time saver.
NOW... it is not my goal to start a HOLY WAR here. Use whatever makes you HAPPY just make people aware of the system requirements of your products. If you are making a WAR hud that requires YENGINE, then put that information ON THE BOX or on a notecard inside the box so people do not complain about your stuff not working.
Just because you want to hop on the BLEEDING EDGE bandwagon does not mean everyone else has to. I will eventually get around to testing Yengine again but until it exceeds my expectations, I will stay on the older yet STABLE Xengine.
For a lack of anything better to do tonight I enabled Yengine and disabled X.... upon first launch of the simulator it crashed... I have a shell script which relaunches opensim.exe when this happens. I was able to get the regions started and the console reported a crap ton of errors; mostly from my NPC rez scripts but they appeared to be working. In some instances it would rez 2 of them... This means I must restart the siim from the region console to fix the problem because my favorite regions have 30-40 npcs with the ability to have 75 per region. After a few days of running my simulator I am using 3.5 gigs of ram... I will see how "Y" does in that same timeframe and report back. I do not like having to go back and fix things when a sim starts so that is one strike on "Y". I do not like all of the console errors "Error: must explicitly cast from string to vector" or " Error: looking for var name, type, state or default, script-defined type declaration" and if I must fix all of those scripts... I will go back to X because that is TOO MUCH WORK.
like(0)
View context
This is why it was suggested that people consider having a lightweight hypergrid avatar. It is up to guests to determine what types of content they will use when visiting foreign grids. The HOST is under no obligation to accommodate them. If you know beforehand that you are visiting a sim where scripts are not allowed you can choose to go someplace else or you can choose to adapt. If I were to use a mesh avatar on hypergrid I would opt for a body where I have the textures and alphas already baked into the mesh without needing any code to maintain appearance... With all of those mesh bodies being given out full perm, it is VERY EASY to fix them so scripts are not needed. I may consider doing a video tutorial demonstrating this in the future. Cheers!
like(1)
My hypergrid avatar consists of the basic skin, hair, shape and eyes. The clothing texture is baked into the skin. Lightweight does not mean 'clothing optional' ...Sorry... I could not resist, I had to chime in on that one =D
like(0)
Well, if I know beforehand that the place I'm travelling to doesn't allow scripts and may cause trouble with Bakes-on-Mesh, I can turn BoM entirely off by selecting a skin referenced by the Roth2 v2 HUD. I've modified the HUD so that I can select my own skin textures, and I have variants of them with alpha cut-outs already included. However, this limits me to wearing only a small selection of clothes because I can't include all alpha cutouts I have into that HUD.
Still, I don't have to sacrifice the flexibility that comes with BoM by throwing every last script out of my body and firmly baking one static skin onto it like onto a newly-rezzed prim cube. If I take all combinations of alpha masks which I need day-by-day into consideration, I'd need several dozen separate mesh bodies just for the alpha cutouts. Add several variants of each one of them on top for baked-on socks.
This flexibility is even more important for my in-world sister Juno and all the other Ruth2 v4-based avatars: They absolutely require BoM to be able to wear underwear, swimwear, hosiery, make-up etc. and alpha masks on top. Without BoM and without scripts, Juno would literally need SEVERAL THOUSAND variants (!!!) of her body to have the same flexibility she has now with BoM. And each one of these variants would require up to three textures being edited in GIMP, exported and manually baked onto the body.
Most of the time, however, I don't know beforehand whether or not my destination has blocked scripts. I don't always have the time to visit it before an event. And some places treat avatars differently, depending on whether said avatar is alone or has arrived when there are already 20 other avatars present. So I have to be able to react when I'm there.
like(0)
Still, I don't have to sacrifice the flexibility that comes with BoM by throwing every last script out of my body and firmly baking one static skin onto it like onto a newly-rezzed prim cube. If I take all combinations of alpha masks which I need day-by-day into consideration, I'd need several dozen separate mesh bodies just for the alpha cutouts. Add several variants of each one of them on top for baked-on socks.
This flexibility is even more important for my in-world sister Juno and all the other Ruth2 v4-based avatars: They absolutely require BoM to be able to wear underwear, swimwear, hosiery, make-up etc. and alpha masks on top. Without BoM and without scripts, Juno would literally need SEVERAL THOUSAND variants (!!!) of her body to have the same flexibility she has now with BoM. And each one of these variants would require up to three textures being edited in GIMP, exported and manually baked onto the body.
Most of the time, however, I don't know beforehand whether or not my destination has blocked scripts. I don't always have the time to visit it before an event. And some places treat avatars differently, depending on whether said avatar is alone or has arrived when there are already 20 other avatars present. So I have to be able to react when I'm there.
View context
Correct: I have scripts which will activate upon permission change and will destroy the object and it's contents. This does not stop someone from using a "no scrip zone" to godmode the item and look at the scripts inside.
like(2)
View context
Good question. The reason I turn off the FLY option is because some of my regions are heavily themed. Having avatars fly around breaks immersion or established lore in your sim. Disabling flight is OPTIONAL and does not provide any security, moreover some legal viewers can override this setting. I have seen sim owners in SL and OS banish users for flying where it is not permitted.
like(1)
View context
From the OPENSIM wiki: Actively Malicious Hosts
The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.
Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:
The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.
Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.
like(0)
The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.
Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:
The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.
Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.
View context
I encountered the same bug... some of my replies are not posting either... I have reported the problem.
like(2)
View context
The suitcase is a temporary storage folder where content is stored when traveling on foreign grids. Once you return home, you can move the content to your regular inventory folder. You only want items in your suitcase that you plan on using when traveling outside of your grid. The less items in there, the quicker those items will load when you attempt to use them.
like(3)
Just finished weeding out the suitcases in my AMV and Kitely accounts. Took the better part of an hour. 2 main avis, and three alts! Thankfully not as bad (or as massive) as managing my SL inventories, that's taking forever and a day...
liked(1)
It took me about a year to get my SL inventory under control. I still have too much stuff I should get rid of. Cheers!
liked(1)
View context
Lets try this again, my response apparently vanished. I will report the error... I used to host regions on Zetaworlds and I was under the impression that they were still an open grid, I can confirm that is still possible. https://zetaworlds.com/host-your-own
like(2)
View context
I have not deleted any comments and WILL NOT delete comments. I DO NOT believe in censoring opposing views.
I am well versed in the creation of NPCs. I can tell you that the appearance notecards are INSECURE. If you are wearing your inventory in a prim when you are cloned, the owner of the generated appearance card has access to anything you are wearing and the CONTENTS within it.
like(2)
I am well versed in the creation of NPCs. I can tell you that the appearance notecards are INSECURE. If you are wearing your inventory in a prim when you are cloned, the owner of the generated appearance card has access to anything you are wearing and the CONTENTS within it.