Notice to Vehicle creators.

[Qie Niangao]

45 minutes ago, Theresa Tennyson said:

 Upon moving from one region to another, you're actually entering a completely different simulation, and your avatar and all its goods and chattels needs to be removed from one simulation and added to another.

Well... except the sim has no use for your Inventory information. That's all between your viewer and your Inventory server, isn't it? and once in a very great while, when you attach or rez something, between that Inventory server and the sim. I can't come up with any reason the sim should care about your big ol' Inventory during handoff.*

Attachments are a whole different matter. And worst of all, attached scripts.

Groups... maybe, although just crossing a parcel boundary involves some group-specific processing. And Friends, you know, this wouldn't be the first time I've heard that the number of Friends has a weird effect on something totally unexpected.

__________
* which, admittedly, is not quite the same as saying the sim doesn't care. I doubt it does, but this is SL where everything mysteriously interdepends on everything else. I mean, I could imagine some vestigial plumbing where the sim mediates all data transfer between viewer and inventory, but even for SL that seems daft.

Edited April 11, 2019 by Qie Niangao

[Fionalein]

Inventory size affects log on speed, I bet some people just jumped to conclusions from this (wether they be true or not)

Edited April 11, 2019 by Fionalein

[Alyona Su]

1 hour ago, Fionalein said:

Inventory size affects log on speed, I bet some people just jumped to conclusions from this (wether they be true or not)

Is this still the case? For me (on Catznip, at least) - I log-in pretty fast. Then (before I cleaned it up) I could see the Inventory count actively counting up and I could just start doing my SL while it did that, meaning I am fully logged-in way before Inventory was loaded. I do know that Viewer Cache size *definitely* affects Viewer startup time (if not login time). Go ahead and set viewer cache to the utter maximum on Firestorm. Let it get filled up. Then watch the clock as you start-up the viewer for the first time after a system start. You won't even need a stopwatch, the second hand on any clock will do because it takes *that* long. LOL

One thing, though: I was likely misremembering the "inventory" category, and that it's not necessarily your account inventory that causes border-cross slow-downs, but rather *object* inventory - so if your vehicle has 500 BDSM animation that you likely never use and 50 scripts to manage it all: THAT has to go from one region to the next. So my boo-boo when I said "inventory" can slow down border crossing - in hindsight I meant object, not account inventory.

Edited April 11, 2019 by Alyona Su

[KT Kingsley]

The inventory thing is related to the size of the first level of inventory: the folders directly under the inventory folder that you see when you open the inventory floater, and their contents. Sub-folders of those seem to load quietly in the background or when they're opened.

[Whirly Fizzle]

Part of the viewer login process is "creating inventory views" from your accounts inventory cache stored on your computer.
Creating inventory views from cache can take a log time if the accounts inventory is very large & flat (flat being more important then large).
System/drive speed also plays a part for how long inventory views take to create.
So if you have a large & very flat inventory structure together with a slower system, this may make the login process take so long that it times out or if you do make it inworld, you''l get disconnected after a couple of minutes because you didn't actually fully make it in, even though it may look like you did.

For people affected by this, LL support can automatically deflatten your inventory with a special tool.
You can also deflatten it yourself manually by keeping as little as possible directly in the root inventory folder & not having more then 1000 items in any one folder. Subfolders within subfolders is good - the deeper your inventory folders are nested the better.

I don't believe inventory size or flatness plays any part in region crossings, though I may be wrong about that.

You can actually see how long inventory views take to create by looking in the viewer session log.
Just search for "Creating inventory views" from a session where you logged in with fully cached inventory.
Look at the time it takes to move onto the next step - "Startup state changing from STATE_INVENTORY_SEND to STATE_MISC"

If your inventory cache is empty, creating inventory views is instant.  This is why those waiting to get their inventory deflattened have to purge inventory cache each session in order to get logged in.

 

[Anna Nova]

24 minutes ago, Whirly Fizzle said:

Part of the viewer login process is "creating inventory views" from your accounts inventory cache stored on your computer.
Creating inventory views from cache can take a log time if the accounts inventory is very large & flat (flat being more important then large).
System/drive speed also plays a part for how long inventory views take to create.
So if you have a large & very flat inventory structure together with a slower system, this may make the login process take so long that it times out or if you do make it inworld, you''l get disconnected after a couple of minutes because you didn't actually fully make it in, even though it may look like you did.

For people affected by this, LL support can automatically deflatten your inventory with a special tool.
You can also deflatten it yourself manually by keeping as little as possible directly in the root inventory folder & not having more then 1000 items in any one folder. Subfolders within subfolders is good - the deeper your inventory folders are nested the better.

I don't believe inventory size or flatness plays any part in region crossings, though I may be wrong about that.

You can actually see how long inventory views take to create by looking in the viewer session log.
Just search for "Creating inventory views" from a session where you logged in with fully cached inventory.
Look at the time it takes to move onto the next step - "Startup state changing from STATE_INVENTORY_SEND to STATE_MISC"

If your inventory cache is empty, creating inventory views is instant.  This is why those waiting to get their inventory deflattened have to purge inventory cache each session in order to get logged in.

 

This is VERY helpful.  I have a very deep directory structure.  (Sorry I can't get the Windows naming habit, directory = folder)  My attachments stuff is mostly in #RLV so that I can use CTS Wardrobe for almost everything.  I also make extensive use of links, but I have no idea if they are better or worse (or irrelevant) than copies for SL sim crossing/TP.

I do use a maximum cache on an SSD, the notes in Firestorm suggest this is best.  But maybe that needs a more comprehensive understanding.

Session log says: 

2019-04-11T15:21:34Z for Creating inventory views

2019-04-11T15:21:35Z for Startup state changing from STATE_INVENTORY_SEND to STATE_MISC

So I guess that means it's quite quick.

Fascinating.

Edited April 11, 2019 by anna2358
realised I used a log-in to Osgrid for the stats....

[Fenix Eldritch]

Related question: do similar thoughts apply to object inventory? Will an object with a large inventory affect sim performance when said object moves between sims?

I vaguely understood inventory in general to be a list of wrappers that eventually will resolve to the asset when appropriately referenced (rezzed, applied as a texture, sound, animation, etc). My assumption was that the inventory list was just that: a lightweight list.

Edited April 11, 2019 by Fenix Eldritch
clarification

[Selene Gregoire]

3 hours ago, Fionalein said:

Inventory size affects log on speed, I bet some people just jumped to conclusions from this (wether they be true or not)

If that were true then how come it takes longer for me to log in now at under 30k inventory than it did when my inventory was almost 100k?

[Fionalein]

10 minutes ago, Selene Gregoire said:

If that were true then how come it takes longer for me to log in now at under 30k inventory than it did when my inventory was almost 100k?

The Lab saved money on the new authentification servers? I dunno,...

Edited April 11, 2019 by Fionalein

[Selene Gregoire]

10 minutes ago, Fionalein said:

The Lab saved money on the new authentification servers? I dunno,...

Whirlz knowz. 

[greek Wingtips]

I have a property on the mainland its been over 8 years and they still cannot fix this sim crossing problem, I have given up riding my bike on the mainland.

[HeathcliffMontague]

SIM crossings are worse than just weeks or months ago, for sure. While they have never been great, I lost a bike for the first time in about two years recently, a Moto Bazzi one that has always behaved well on SIM crossings.

I have the "Superbike" by JC Hill. An old bike which is worn. I've hardly ever noticed SIM crossings on that one before, now it won't even cross SIM lines. Not even the bridge from the premium Orville airport, probably one of the least laggy places in SL. Stops dead cold, it used to cross SIMs like no other bike on the mainland, as script and LI heavy as it is.

PS: I haven't seen this many vehicles stranded/crashed on the mainland with the engine still running in a while.

Edited April 11, 2019 by HeathcliffMontague

[Fionalein]

It is all Region transfers, wether vehicle, teleport or on foot, yesterday was the first time I crashed while sim crossing on foot in Linden Realms...

 

Edited April 12, 2019 by Fionalein

[animats]

1 hour ago, HeathcliffMontague said:

I have the "Superbike" by JC Hill. An old bike which is worn. I've hardly ever noticed SIM crossings on that one before, now it won't even cross SIM lines. Not even the bridge from the premium Orville airport, probably one of the least laggy places in SL. Stops dead cold, it used to cross SIMs like no other bike on the mainland, as script and LI heavy as it is.

Strange. I go there because the sim across that bridge, Arowana, has zero scripts running and zero script events per second. If I want to see if something is using script time, I take it there. 20 minute autoreturn and a rez area, so you can test objects there.

Crossed the bridge OK. The bike is stopped, engine off. Statistics bar shows "Script events: 0 eps." This is a totally quiet sim.

Went back and forth across the sim crossing without problems.

A worn bike isn't even a vehicle, just an attachment. I tried an old freebie wearable motorcycle and went back and forth across that crossing several times without problems.

Is it still happening for you?

[HeathcliffMontague]

17 hours ago, animats said:

Is it still happening for you?

Yes, still happening. I have other bikes which do OK there, though.

For all I know the JC Hill bike may have outlived it's usefulness (well, it did some time ago, but still...). Just a bit strange that it went from smooth to totally useless on SIM crossings. The problem could be on my end, of course, but nothing's changed on my part. Ping times, FPS etc. are the same as usual.

[Anna Nova]

I would like to say that I personally am very grateful to the Linden Labs folk who have been working on the recent sim crossing/TP issue.  And they appear to have not just fixed it, but also to have significantly improved sim crossing even over what we had last year.

😄❤🍺👏😄❤🍺👏😄❤🍺👏😄❤🍺👏😄❤🍺👏😄❤🍺👏😄❤🍺👏😄❤🍺👏😄❤🍺👏

Edited April 20, 2019 by anna2358