OpenSimWorld is the directory of 3D Virtual Worlds based on OpenSimulator and connected through the HyperGrid. Learn More
New Members
Topnhacaiasia, LianaBloobury, Lexxilicious74, Fleur, Prestige Outdoor Living, Moonstone, Jun881dev, Muneebjutt, KaoruSlade, Thalya, SpookyKid, Ezarhon, V9bettel, Windows VPS Cheap, EllenOptinett, RavenIce, ToquiNovic, Dionnem, SkyeArabella, AladdinLikes
The difference between Xengine and Yengine...
Yengine has premptive multitasking, xengine does not.
This solves the lsl function problem of llSleep(n); Which could not run on Xengine the same way. On Xengine using llSleep would use one of the cpu's threads and place it in sleep mode. Yengine, simply places a sleep command into a wait queue and keeps the cpu thread available for more processing of other scrips. Xengine is also slower because it translate script to c# language, then uses .net compiler to generate it. Once a script is loaded into Xengine the memory from it cannot be recovered even if the script ends. Yengine scripts recover the ram memory when a script ends, so it can be used by other things for example more visitors to your sim.
Xengine does not follow a true AOS (algebraic operating system) and will evaulate sequences to the wrong boolean expression, Yengine follows AOS to the letter, and will always evaluate expressions mathematically correctly.
Yengine is a modified derivative of XMREngine created by dreamnation and avination. It is faster, uses memory and cpu threads much better than xengine, and thanks to ubit umarov, it is now more stable than Xengine, and all the bugs have been eradicated, that were found.
So you can keep using the outdated broke Xengine, thinking you have gold. But as a professional programmer I realize the average person doesn't understand the importance of memory management, memory leaks, and thread lockup. So it's rather ludicrous for me to waste my time trying to explain why something is better to people who have no concept of professional programming fundamentals. I suppose I should put on my armor for when the attacks from idiots start rolling in...
Yengine has premptive multitasking, xengine does not.
This solves the lsl function problem of llSleep(n); Which could not run on Xengine the same way. On Xengine using llSleep would use one of the cpu's threads and place it in sleep mode. Yengine, simply places a sleep command into a wait queue and keeps the cpu thread available for more processing of other scrips. Xengine is also slower because it translate script to c# language, then uses .net compiler to generate it. Once a script is loaded into Xengine the memory from it cannot be recovered even if the script ends. Yengine scripts recover the ram memory when a script ends, so it can be used by other things for example more visitors to your sim.
Xengine does not follow a true AOS (algebraic operating system) and will evaulate sequences to the wrong boolean expression, Yengine follows AOS to the letter, and will always evaluate expressions mathematically correctly.
Yengine is a modified derivative of XMREngine created by dreamnation and avination. It is faster, uses memory and cpu threads much better than xengine, and thanks to ubit umarov, it is now more stable than Xengine, and all the bugs have been eradicated, that were found.
So you can keep using the outdated broke Xengine, thinking you have gold. But as a professional programmer I realize the average person doesn't understand the importance of memory management, memory leaks, and thread lockup. So it's rather ludicrous for me to waste my time trying to explain why something is better to people who have no concept of professional programming fundamentals. I suppose I should put on my armor for when the attacks from idiots start rolling in...
Liked by: 
Comments
Xengine is still the most widely used along with Bulletsim. YEngine had a serious arithmetic bug that broke the Satyrfarm. That said, the farm, SFsail and the Sfposer all work well with Y now. I m not sure about the speed improvements since both of them rely on the C# compiler which optimizes everything.
When it comes to physics, ubode is more smooth for vehicles, however it doesn't work with most existing meshes. Bullet has improved a lot and even though it is not as smooth, it is good enough for most stuff. Currently my scripts are primarily made for X+BS
like(3)
When it comes to physics, ubode is more smooth for vehicles, however it doesn't work with most existing meshes. Bullet has improved a lot and even though it is not as smooth, it is good enough for most stuff. Currently my scripts are primarily made for X+BS
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)
I found that going from X to Y is more than just simply changing the settings in the ini file! Bugs/Quirks that work in X don't always work in Y (and vice versa) so watching the console/scanning the log files when you switch is essential to see all the things that fail! I'd say it's worth doing, but depending on how many regions and scripts you have, you may need to decide just how much downtime you are going to get as you fix all the compatibility issues.
like(1)
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...
like(1)
Y Engine was developed for the Physics Engine UBODE. X Engine is for Bullet. As far as llsleep best remove it from script if you have issues.
like(1)
AFAIK they are separate subsystems. There is no reason why Y or X runs better / worse with ubODE
like(0)
The Y engine was designed and implemented by Ubit who is the designer of UBODE to improve the Physics Engine. Bullet is a Robert Adams invention that uses X engine :) UBODE Physics is best or close resembles SL scripts. I use both in my grid being some things run better on Bullet while others prefer UBODE. Best to use whats best for your application that uses Physics.
like(1)
It's a little odd for me that this conversation is happening now. When I finally settled in Opensim 5 years ago, the grid I was on was already using ubode and within a year switched to Yengine. There were some really old Xengine scripts that broke on some users regions that took a little work to sort through, but the few scripts I used the grid owner rewrote for me. All of the grids I'm on now, with the exception of Kitely, have used that combination for a long time. Additionally, all my spacecraft dating back 3+ years use ubode and Yengine and have had no issues in that time. Been very happy with the combination.
like(0)
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)
Is Yengine the one that's better for cars? I want to have cars that drive well and handle predictably. I don't run my own grid, but maybe someday.
like(0)
I have always opted for stability over novelty. This one, though, I'm following closely. It's interesting to try out everything that comes out. Maybe in this follow-up we will find the evolution and we will leave aside the "patching" (let's see if it means the same thing in English, if not, sorry).
like(0)
Interesting thread. I would love to know the differences between the various physics engines too.
If you have a long standing sim that has been on Xengine for donkeys years then I can see the argument for not switching over, but if you are just starting out then I don't see any reason not to use Yengine.
I have just got back into opensim in the last few months after a 9 year break. It has improved a lot since then. It is most likely the default option for the script and physics engines that made the difference.
like(0)
If you have a long standing sim that has been on Xengine for donkeys years then I can see the argument for not switching over, but if you are just starting out then I don't see any reason not to use Yengine.
I have just got back into opensim in the last few months after a 9 year break. It has improved a lot since then. It is most likely the default option for the script and physics engines that made the difference.
The grid I call home uses the XEngine. I want YEngine stuff. I used to use a few of your HUDS. I wish you could make one for the XEngine as I miss using them. I suppose that is impossible though. Thank you for explaining the difference between the two. I have a much better understanding now. :)
like(0)
All the grids I've been on the last four years or more, with the exception of Kitely, have all used YEngine with no issues
like(1)
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.
like(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)
I also run XEngine on 3 core 3 threads virtual machine.....
1. If this about sleep and thread is true you all may be happy - Bordello is freeze....NOT TRUE!
2. Memory leak is result not from XEngine bug!!! This is other bug in OpenSIM where he misunderstand UDP on ports 123 and 1900. After block this port my grid use 1,22Mb YES 1 MegaByte and 200 Kilobyte memory and i restart only if make som changes.
3.About compatibility..... Only 2-3 sripts not work here and after speak with authors they find errors in scripts and repair. My own scripts work in all grids where i visit without any errors.
4. Multitasking....... I USE 3 CORE 3 THREADS and with this start BestFakeSIM and activate 80 Active NPC to make dance party for 3-4 days with 30-40% CPU load. XEngine is slow and...........
like(0)
1. If this about sleep and thread is true you all may be happy - Bordello is freeze....NOT TRUE!
2. Memory leak is result not from XEngine bug!!! This is other bug in OpenSIM where he misunderstand UDP on ports 123 and 1900. After block this port my grid use 1,22Mb YES 1 MegaByte and 200 Kilobyte memory and i restart only if make som changes.
3.About compatibility..... Only 2-3 sripts not work here and after speak with authors they find errors in scripts and repair. My own scripts work in all grids where i visit without any errors.
4. Multitasking....... I USE 3 CORE 3 THREADS and with this start BestFakeSIM and activate 80 Active NPC to make dance party for 3-4 days with 30-40% CPU load. XEngine is slow and...........
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)