search

HalcyonGrid / halcyon

Halcyon 3d virtual reality world simulator
BSD 3-Clause "New" or "Revised" License
20 stars 20 forks source link

Prim Contents not loading beyond 26 items under current Firestorm #71

Open zauberparacelsus opened 5 years ago

zauberparacelsus commented 5 years ago

Under Firestorm 6.0.x (and maybe some earlier versions), they pulled in some upstream changes from Linden Lab, which include a protocol change to how prim contents are downloaded by the viewer. As a result, when using current Firestorm versions under Halcyon, you cannot view anything beyond the first 26 items in a prim's contents. And as well, if you try to open a box, you only receive the first 26 items it contains.

When the issue occurs, the following output appears in the viewer log:

2019-02-20T21:34:16Z INFO #Xfer#  llmessage/llxfer.cpp(311) LLXfer::processEOF : xfer from 192.227.85.92:9505 complete: C:\Users\Robert\AppData\Local\FirestormOS_x64\inventory_5a1c6fdc-7c99-432f-82db-0c1d194bf0cb.tmp
2019-02-20T21:34:16Z WARNING #  newview/llviewerobject.cpp(3412) LLViewerObject::loadTaskInvFile : ONCE (50th time seen): Unknown token while reading from inventory file. Token: '}'
2019-02-20T21:34:16Z WARNING #  newview/llviewerobject.cpp(3404) LLViewerObject::loadTaskInvFile : Encountered too many unknowns while reading from file: 'inventory_5a1c6fdc-7c99-432f-82db-0c1d194bf0cb.tmp'

The important log error appears to be this:

Unknown token while reading from inventory file. Token: '}'
kf6kjg commented 5 years ago

Confirmed.

Yichard commented 3 years ago

Auburne LittleBoots proposes a script as a workaround hop://grid.enchantedgrid.com:8002/Kitteh%20Korner/133/139/1002 Drop it in the task (prim) and it tells the content.

Yichard commented 3 years ago

In the Firestrom Jira https://jira.firestormviewer.org/browse/FIRE-30832 Beq Janus is asking where we are with this one, Unfortunately I am still unable to connect, password lost and no recovery email. Can somebody reply for me?

emperorstarfinder commented 3 years ago

In checking this to confirm the actual Object Inventory Limits (Object's Contents Tab) the following appears to be the limits. Multiple viewers and platforms were tested.

Ideally, you do not want the object's inventory loaded too much because it puts more strain on the resources in the server being used to load the contents of the inventory. However, during testing, I did find that closing the object edit window and reopening the edit window will update the actual number of contents in the object's inventory when it loads at least until it hits that maximum.

This likely is just a symptom of the code logic in Halcyon not having been updated due to no development until recently. It might take time for this to get rectified.

Yichard commented 3 years ago

Ok I could not connect with the Firestorm JIRA, but I had a conversation with Beq Janus in SL. She wanted to close that JIRA, which makes sense since the problem is in Halcyon.

She also thinks that the problem comes from missing packets (only the first received, the others missed). I cannot say if this is ok, but this may be a track. She explains the protocol here:

[05:07] Beq Janus: https://jira.firestormviewer.org/browse/FIRE-19738
[05:08] Beq Janus: that's the most recent fix in FS

More complete explanations: [05:10] Beq Janus: http://opensimulator.org/mantis/view.php?id=8391 (Added: mostly only beq's comments are of interest for the packets theory)

After all, if it was a protocol change from SL, Open Sims was confronted to the same problem, and apparently they solved it.

emperorstarfinder commented 3 years ago

There was a protocol change by LL but I had initially been under the impression that they decreased the maximum number in the Object_inventory when it appears they increased it. But considering there hasn't been active development (until recently) in Halcyon it is possible there are some adjustments needed in the packet information too. Probably even in the OpenMetaverse libraries as well.

I will have to look into this further though to figure out where the issue is.

Yichard commented 3 years ago

When resetting scripts I noted that attempts to reset all scripts fail if a script is not showing, beyond the 26. This means the same bug shows in two places: -when displaying the content -when some functionality need to access elements beyond the 26.

emperorstarfinder commented 3 years ago

Because the object_inventory limit is currently 26 in Halcyon, this will also have an effect on how many scripts in the object's inventory can actually be reset. This is partly due to the fact that you can only select the visible items that are in the object's inventory. So this is kinda one of those issues where, the way Halcyon is currently hardwired, it is working the way it should be. However, because the limits the viewers can handle have been changed and increased over time, this method needs to be refactored and upgraded to work in line with current viewer and platform protocols.

mdickson commented 3 years ago

Doing the script reset from another script should actually work. The server has no such limitation inside the script engine. It's the prim inventory contents transfer (task inventory) where the problem exists. If do a reset all or recompile all from the viewer you'll see the issue because the viewer's definition of "all" is the limited list of 26 items. Also note I dont believe this is related to # of items since Halcyon supported large task inventories before this bug. it's an additional flag if I recall in the streamed data. Something is missing in the packet formats in LibOMV.

emperorstarfinder commented 3 years ago

Actually, to clarify, I didn't say it was the scripting engine itself. the max object inventory items cutoff is actually done in the ObjectInventory logic itself. There are packets in the Halcyon version of LibreMetaverse that do need to be updated. I believe Halcyon is actually using the Halcyon_Compatibility branch of LibreMetaverse.

You can actually reset scripts in each script itself using llResetScript which you can get info for at: http://wiki.secondlife.com/wiki/LlResetScript

You also can do llResetOtherScript (assuming Phlox has support for llResetOtherScript? I don't recall if it does) which you can see more info at: http://wiki.secondlife.com/wiki/LlResetOtherScript

I generally use these scripting functions in my scripts just to save myself time when it comes to resetting scripts. It at least can give you a potential workaround until it can be fixed in the hardwired code.

Yichard commented 3 years ago

Added: setting all perms grobally for the whole inventory also raises the same issue than in my post above.

On the bright side, the Enchanted devs seem to have fixed all three issues (my test hop://grid.enchantedgrid.com:8002/Sandbox%202/127/128/22 ) while they were aware only of the first. So the three processes use the same routine, and probably all other potential processes using the inventory list.

mdickson commented 3 years ago

I would imagine "they" (whomever they is) updated LibreMetaverse which should have the protocol changes. Would be nice if it actually is fixed if the changes would find their way back here.

mdickson commented 3 years ago

Just did a quick test and this still appears to be an issue on EG. So if something was fixed I'm not sure what it is that was changed. The 26 item issue with a current viewer still appears to be an issue on EG however

Yichard commented 3 years ago

It is fixed in Sandbox 2. They are awaiting for feedback for a full rollout. I have set a tester (big blue cone) in that place

mdickson commented 3 years ago

Confirmed with a test object I did. So I'll repeat my comment, ideally the code should make its way back here

Yichard commented 3 years ago

It also fixed the issue in another unexpected case: to set perms globally (for the whole inventory). Happily the three cases use the same routine

Yichard commented 1 year ago

AS I commented above, I saw this fixed in "sandbox 2", but not remembering if it was in Enchanted or in one of Vinhold's worlds (not Mundos Market). If it was in Enchanted, then probably the fix is lost. In more they had a version numbering mistake, so that it is better not to rely on any of their documents. If it was in 3D world or something from Vin, then Vin you may check the version. I lost the login URI for that world, to a firestorm update probably. And no it is not on the site, even if I log in :-)

The current versions of Mundos Market and Sovaria is 0.9.45.7836 and the fix is not there.

mdickson commented 1 year ago

The 26 item fix along with some of the behaviors for group notices and profiles can all be chalked up to viewer protocol changes. SL has been moving to http/REST based services for most of their support infrastructure and the messaging between client and server has been adjusted accordingly. Beq has backported some of the old-style protocols into current viewers but they're still at least one generation ahead of what's in Halcyon.

The fix for this (in my opinion) is to update LibreMetaverse to a current version but the current one in use is fairly old and as far as I could find the sources are lost. So, there is no easy way to just catch differences between versions. This issue is symptomatic of a number of problems I encountered when setting up and Skye Grid for about a year. The huge volume of changes required to bring the Halcyon sources up to current practice was such a burden that we chose instead to migrate users to my OpenSim NGC based (aptly named Tranquillity, with permission from David) grid, Utopia Skye. Its current with regards to protocols and is slowly getting some of the enhancements we developed for InWorldz. Based on the huge workload to bring Halcyon up to standards and the state of the codebase I won't be updating it and will instead be focusing on OpenSim NGC.

life777eternal commented 1 year ago

@mdickson Apparently you were right, The Firestorm Jira issue that @Yichard opened was closed, "because they adapted to a change in LL protocol." and "It is up to Halcyon to adapt in our turn" as Yichard stated in the new "Halcyon-Development" text channel in the Sovaria Estates Discord group/server.

Ana-Green commented 1 year ago

Subject: Bug Reports in Halcyon - Gray Texture Bug and 26 Items in Prim Bug

Dear Halcyon Developers,

I am writing to inform you about a set of persistently vexing bugs that have been reported by Halcyon users, including my Dad (Frank Orbis) on the Dream Castle Grid. These issues require attention and resolution to enhance the overall user experience and system functionality.

Gray Texture Bug:

One of the most prominent issues is the "Gray Texture Bug." Users have consistently reported encountering this problem after a certain duration of online activity. Specifically, textures, such as those on trees or buildings, fail to update with newly uploaded textures. As time progresses, this issue escalates, resulting in a growing number of grayed-out objects. Upon teleporting to another region and returning, approximately half of the objects suffer from this texture loss. The current workaround involves logging out and then back in, a solution that is understandably frustrating for users.

We have discovered that, in many cases, forcing a client rebake using the Ctrl+Alt+R key combination can help mitigate the issue. It's worth noting that, occasionally, the viewer may successfully bake the textures, but a failure occurs during the texture upload to the simulator or redistribution to other viewers. In such cases, a viewer rebake might prove effective. Additionally, users are encouraged to clear their viewer cache and log back in. Experimenting with different viewers, such as Imprudence, Kokua, or Firestorm, may also yield varying results, as viewers can employ different methods for texture baking and may have bug-related differences.

Furthermore, it is crucial to ensure that users are utilizing the latest graphics drivers available from their respective graphics card or integrated motherboard graphics manufacturers (e.g., ATI/AMD, Nvidia, Intel). Halcyon viewers are known to be graphically intensive, and issues arising from outdated graphics drivers are not uncommon. For a comprehensive troubleshooting approach, users are advised to explore different simulators, even if they are running the same version of Halcyon. Variations in the software stack (e.g., Mono versus Windows .NET) or hardware can lead to differing behaviors.

Lastly, the environment in which a user resides may affect the occurrence of these issues. Regions with high avatar and object traffic might be more susceptible to appearance-related problems. To test this hypothesis, users can visit quieter regions or, ideally, experiment with a local installation of Halcyon.

Additionally, if users employ the same viewer with the same name on multiple grids, switching to a different viewer installation might resolve potential inventory confusion issues. Some viewers can inadvertently mix inventories across grids when avatars share the same name.

It's important to note that this represents only a partial selection of the issues at hand. As we encounter more challenges and discover workarounds or solutions, we will continue to update this report.

26 Items in a Prim Bug:

Another critical issue is the "26 Items in a Prim Bug." This bug restricts users to viewing only 26 items within a prim, even when additional items are correctly stored within it. This limitation proves especially problematic for furniture items containing numerous animations. When notecards become invisible due to this bug, the issue is further compounded.

In contrast to the "Gray Texture Bug," it's worth emphasizing that this issue is unique to Halcyon and does not manifest in OpenSim.

We kindly request your attention to these matters, as they significantly impact the functionality and usability of our Halcyon environment. Resolution of these issues would be greatly appreciated.

Should you require further information or wish to discuss these concerns in more detail, please do not hesitate to reach out. Your assistance in addressing these bugs is paramount in enhancing the overall user experience.

Sincerely,

Ana Green

life777eternal commented 1 year ago

Greetings @Ana-Green, thank you for your letter(long comment). Although it seems that you may be conflating different issues in your comment/letter on this issue post for the 26 viewable items in a prim limitation. The part on the "Gray Texture" bug is related to #103 Although I have not seen this "Gray Texture" bug on Sovaria nor on my own Halcyon World, though apparently others have.

Although I have seen a few textures on in-world objects disappearing or turning transparent after being in a region for a while(several hours). Just last weekend at your Dad's event I thought I saw some textures that had gone transparent. You mentioned rebake in there too, and that's related to the textures on the avatars outfit, not on prims or in-world objects. Though teleporting or relogging seems to temporarily reset this issue, for a while and yet it still happens later.

You mentioned keeping our Graphics card divers updated to the latest version available, and that is definitely important. Also if people use the same viewer on different grids, they'll just need to clear the cache once in a while. Open Preferences [Ctrl] + [P], click "Network & Files" on the left side, then click the Directories tab. Underneath "Cache Location" click on "Clear Cache" to the right. Then relog.

For anyone who has an NVidia Graphics card, they can use GeForce Experience to keep their drivers updated. Although there might be something similar for ATI/AMD & Intel graphics cards. A person just has to create an account, though that's easy with Password Safe.

For a comprehensive troubleshooting approach, users are advised to explore different simulators, even if they are running the same version of Halcyon. Variations in the software stack (e.g., Mono versus Windows .NET) or hardware can lead to differing behaviors.

Please be careful with your word choice, with your use of the word "simulators" I believe you meant different Viewers, or 3D Viewing applications. Is that correct? Each Halcyon region is s "Simulator" in and of itself, or each Console window on the server with the numbers(9500-9509). So you could confuse people with that. Also there's not very many different Viewers available, the one that has the most updates is FirestormOS, where as there is also Singularity and it has the ability to import XML files, though it's not updated very much at all, and is likely outdated now. So it would only be useful for importing XML objects (if a person cares to do that). Also we can use two different versions of FirestormOS, and older version and the newest version, we just have to install the second to a different folder name, and they both will still use the same app data folder. There's a few other viewers that you mentioned though are any of them not forked from Firestorm?

By the way, there's not very many instances of Halcyon setup on Linux with Mono. There's no physics available yet with Halcyon on Linux.

Thank you, Shabbat Shalom.

life777eternal commented 1 year ago

Greetings Lady @Ana-Green Do you realize that you just duplicated pretty much all of your comments in your long letter? Creating duplication and conflating issues doesn't really help. Please share what's relevant for #71 here, and what's relevant for #103 on that one, and what's relevant on other issues under them. Thank you, Shabbat Shalom.

Ana-Green commented 1 year ago

No I did not if so my excuses though :)

mdickson commented 1 year ago

There is a mess of stuff in one place here so it's hard to tease apart things. There are 2 issues mentioned I'll comment on.

Ultimately, I determined that my time was better spent maintaining a single version of code (I was also running an OpenSim grid) and the current version of OpenSim has correct handling for asset transfers as well as updated code for inventory, profiles and groups. It also includes many new features like animesh and very soon PBR materials. This version in the form of the OpenSim NGC project has been my focus. Its been updated for security and to run under dotnet6 and in the future will get a port of current (v5) PhysX and Phlox.

life777eternal commented 1 year ago

@Ana-Green https://github.com/HalcyonGrid/halcyon/issues/71#issuecomment-1741702642 was your original long comment/letter, and https://github.com/HalcyonGrid/halcyon/issues/71#issuecomment-1741876709 is another with some SL messages from what I would assume would be the FS Support group in SL, with the text from the one above added under it. Although from those time stamps, it would seem that you had just copied your original message here and pasted it into the FS Support group, and then copied it back to here. (that might be how you duplicated it all) If you can try to clean it up, edit your messages, remove the duplication and move the comments related to #103 to that one, that would make it less confusing. Thank you, Shabbat Shalom

appurist commented 1 year ago

@Ana-Green has contacted me outside this issue so I'm going to pipe in here quickly (and only once).

@mdickson is accurate above, everyone should be listening closely to what he say. (!)

Except for one detail, LibraMetaverse (LMV) is Cinder's fork of OpenMetaverse (OMV) with updates and is still around here. I don't know what the effort would be to include an updated LMV into Halcyon: the update itself would probably be easy, but it will likely change a lot of other things that would need to be taken care of at the same time (ripple effect). But it's the only real path I see going forward to address the problem on Halcyon servers.

Again, the bug is not in the Halcyon code, it does not have such limits, but Halcyon is dependent on the LMV library which has likely been updated years ago to match the SL protocol changes adopted by the viewers (years ago).

As for the other stuff, the grey textures problem is indeed a timing problem with the protocol, it's horrible, and yes Mike is correct that it may be avoidable by just not using the Aperture texture caching, or perhaps by using a single common Aperture across all regions. It is not related to this problem at all though.

One final comment is I have seen the phrase "Halcyon viewers" and there is no such thing. Firestorm is a Halcyon viewer. They all are, if the viewer supports servers other than Linden Lab servers.

So the work item here would be to update the Halcyon build to use a more recent LMV. (To be clear, it won't be me.) -Jim

sonjamichelle commented 1 year ago

I left the Discord because of the recent drama that was being stirred up. I recently moved and rebuilt all of my hosting so I thought email was sending old dead emails floating in the "ether".

But, I thought that to be too weird and decided to check here and indeed found it was a new conversation.

OK, like @appurist I'm going to "pipe in" and most likely once.

I applaud Vinhold (Bob) and @kf6kjg (Ricky) for the desire to keep Halcyon alive and I am quite impressed by Bob's work on the admin side with his MyWorld project. I do say his Mundos Market idea might not be the best (And that is just MY opinion), look what has happed to the SL Market Place. But we've had many discussions about that and he does have a plan to hopefully ensure that doesn't happen. So again kudos to him and I'll continue to support him and act as a sounding board and critic as he and I have done for each other in the past.

I also have to applaud @mdickson (Mike) for his endeavors with OpenSim-NGC, I know he caught my attention just now with the mention of PhysX (One of Halcyon's strongest points) I know his approach can be viewed as "frankensteining" code, but if you think about, isn't that the nature of open source??? I look forward to see what he has in store for his final release.

@appurist (Paul/Jim) You are and will be sorely missed, but I whole heartedly understand why you stepped back and can understand the nature of the demands from your RL employment/employer. You have helped NUMEROUS times and I think I may have even sparked a light bulb for you on an occasion or two. ;-) I do wish you the best and do hope to see you floating around the grids.

Unfortunately I do believe Halcyon has a VERY hard rocky road ahead. The handful of grids out there still running and the die-hard loyalists have my respect. When you have a good thing it is hard to see it die off, kind of like seeing a family member pass away.

Personally, myself and Nikki have moved Moonlight Estates to OpenSim. It currently offers the feature base, hypergrid, linux base and continued development and closest feature set in light with the big nasty SL. that so many "refugees" come to expect.

Unfortunately @Yichard got me looking into ChatGPT and I've been leveraging it to dive into some uncharted programming waters. In fact I've actually been able to do quite a few nifty things tis past month with it. Even managed to whip up a little Admin console to run Estate Group instances of Regions from the Linux console, and of course start Robust as a systemd service. Now I'm just working on finalizing the script to create regions. I'm down to the part where it appends the Region.ini template to the Estate's main region file. I got the important variables it there, like name, uuid, port, location, size. I took a break to do some other things on a long list of other tasks, so it isn't finished. Anyhow I digress (BTW, if this interests you, find me on Discord).

Back to the nature at had. Halcyon may not be in prime fighting form, but like good ol' Rocky we MIGHT see a come back, or we like Creed, se it's offspring rise to the occasion.

as for frank and ana, well, you kow where my feelings lie for you two!

Ana-Green commented 1 year ago

@sonjamichelle,

Indeed, we are cognizant of your sentiments towards both of us. However, it's crucial to acknowledge that feelings are inherently intertwined with emotions. Personally, I do not harbor any negative emotions towards you. In fact, it's possible that I may even hold a favorable disposition toward you. It's important to recognize that while we may hold differing viewpoints, this divergence in perspectives is a separate matter, Sonja.

Ana-Green commented 1 year ago

I thought that Halcyon .35 no issues had with 26 items in a box, is that not correct?

Yichard commented 1 year ago

The 26 bug appeared in Amaryllis or Enchanted, after a version change in Firestorm revealed it. The only Halcyon version change which happened in this period was after the WALT bug https://github.com/HalcyonGrid/halcyon/issues/118 and Halcyon became version 0.9.42. see above in this discussion. The version before, I do not remember, but last Inworldz version were 0.9.something, so that certainly not 0.35

There likely is a confusion here, as the Gem team came with a fix, that they called version 0.3 or something. Hence perhaps the source of the 0.35 figure. But this version never led to a commit (no new version in fact) and she never shared how she did. Especially I do not know if they fixed the 26 bug specifically, or if they did the library change as Jim speaks above appurist. The whole story with dates and tests is higher in this discussion.

In any case never start working from any version before the WALT bug. It was so nasty that it remains undisclosed to date.

Ana-Green commented 1 year ago

@Yichard I remember that Dad had his first Halcyon, Vinhold did set it up for Dad, but in that version you could copy your inventory lets say 370 items into a prim box, and they were all there. Now I forgot what version, I really thought 0,9,35 or earlier.
@mdickson wrote the current version of Open Sim has correct handling for asset transfers as well as updated code for inventory, profiles and groups. It also includes many new features like Animesh and very soon PBR materials. This version in the form of the Open Sim NGC project has been my focus. It's been updated for security and to run under dotnet6, and in the future will get a port of current (v5) Phys X and Phlox. And I do agree on that one,

life777eternal commented 1 year ago

@Yichard Why do you say "... version change in Firefox ..." ? I thought Firestorm uses Chromium for it's embedded web browser? How does Firefox have anything to do with HalcyonGrid?

Ana-Green commented 1 year ago

@Yichard It is NOT the viewer, can somebody remember our .35 had also this issue or not?

Ana-Green commented 1 year ago

@mdickson Open Sim NGC project has been my focus. It's been updated for security and to run under dotnet6, and in the future will get a port of current (v5) Phys X and Phlox. And I do agree on that one,

Ana-Green commented 1 year ago

@emperorstarfinder Do you remember or Halcyon .35 had also this 26 items in a prim issue?

Ana-Green commented 1 year ago

The primary OpenSim viewers used for this investigation were Firestorm versions 6.6.8 and 6.6.14. The Halcyon version employed was 0.9.45, utilized in 2021, while the OpenSim version was 0.9.2.1 (Yeti Dev 2023).

In our discussion, we have been focusing on the limitation of 26 items within a prim. To further examine this issue, I conducted an experiment in the OpenSim environment. Specifically, I created a prim box and proceeded to insert a total of 440 elements into it. Upon completion, I examined the contents of the prim box and confirmed that it indeed contained the full count of 440 elements, with no reduction in quantity.

To ensure the credibility of these findings, I utilized several OpenSim viewers, all of which consistently affirmed the presence of 440 elements within the prim box. Subsequently, I generated an OAR file, as inventory export/import functionality is unavailable in Halcyon. I then utilized a sandbox region to import the OAR file, which I had named "primtest.oar," into the Halcyon environment.

Surprisingly, upon inspecting the prim box that originated in OpenSim within the Halcyon environment, I discovered that it contained only 26 elements out of the original 440. This outcome was consistent across multiple OpenSim viewers and was observed in Halcyon version 0.9.45.

This raises a crucial question: Are there any known versions of Halcyon that do not exhibit this particular issue?

OS Pimtest Halcyon Primtest read

life777eternal commented 1 year ago

@Ana-Green I think I had noticed this on the previous AmG and it was annoying, though I'm not sure which version of Halcyon that was then. There may not be any version of Halcyon yet without this bug/limitation.

Ana-Green commented 1 year ago

@Life777eternal Thank you well in case i am going to look in the code, will yake me sometime though.

All the best, Ana Green

Ana-Green commented 1 year ago

After careful consideration, I propose the reintroduction of inventory import/export functionality into Halcyon. There are several compelling reasons for this decision.

First and foremost, the current inventory management system is rudimentary. Users often require the ability to transfer portions of their inventory to alternative avatars or create full backups of their inventory on their local computers. Additionally, users may wish to migrate their avatars to different virtual grids they've constructed. The current process necessitates requesting inventory or specific items to be placed in a prim, which is then situated on an empty region. Subsequently, users must create an OpenSim Archive (OAR) file, a process that may become complicated due to the 26-element limit. A potential workaround involves splitting the inventory into multiple OAR files, each containing no more than 25 elements. These files are then exported as regions, resulting in files such as "Patricia1.oar." These OAR files can be transferred via external storage devices or remote servers and subsequently imported, generating new regions with prim boxes. Users must then open these boxes and copy the contents into their new inventory. It's important to note that the OpenSim Archive lacks password or username protection, a potential security concern. To address this, consideration should be given to implementing a naming convention for OAR files that includes both a username and password.

However, it's worth noting that many users find this process cumbersome. In contrast, Inventory Archive (IAR) was developed alongside OAR and provides a simpler solution. Instead of navigating the intricate OAR workflow, users could employ a straightforward console command, such as "iar load/save <path/folder>" or "</ for root>" to manage their inventory. For example, "iar load Patricia.iar" would be significantly more user-friendly. This approach also aligns with the intended separation of OAR for land (regions) and IAR for inventory, streamlining processes and enhancing user experience.

In conclusion, I believe that reintroducing inventory import/export functionality, particularly in the form of IAR, is a prudent decision. It simplifies a complex and labor-intensive process, aligns with established separation of concerns, and ultimately enhances the usability and convenience of the Halcyon platform.

Sincerely, Ana

Ana-Green commented 1 year ago

Put this in a prim the script, and it will show you the correct items what you ass to the prim

// Item Counter // By Apollia Pirandello // 9/19/2007 // // Public domain. Free to use and/or modify for any purpose, // including commercial purposes. // // Once you drop this script in any prim, it will immediately // tell you in an Owner, Say how many items are in that prim, // minus 1, so the script itself isn't counted. // // It will also do that whenever the prim is touched. //SCRIPT BEGINS BELOW

//VARIABLE

integer items_contained;

//END OF VARIABLE SECTION //FUNCTIONS

CountItems() { items_contained = llGetInventoryNumber( INVENTORY_ALL ); --items_contained; //minus 1, the script itself isn't counted, since its used with the INVENTORY_ALL flag }

SayCount() { llOwnerSay( "This prim contains " + (string)items_contained + " items." ); }

//END OF FUNCTIONS //DEFAULT STATE

default { state_entry() { CountItems(); SayCount(); }

touch_start(integer total_number) { CountItems(); SayCount(); } }

You will see then the real count like this -1 we do not want to count the prim as an item.

[19:32:52] Primitive: This prim contains 0 items. [19:34:18] Grid: Dropping into a prim is limited to 48 items at a time [19:35:02] Primitive: This prim contains 49 items. [19:37:26] Primitive: This prim contains 82 items. [19:38:22] Grid: Dropping into a prim is limited to 48 items at a time [19:38:49] Primitive: This prim contains 131 items.

The problem with Halcyon is:

Halcyon and Opensim use different mechanisms to handle materials. SO those will never transfer since Opensim doesn't know how to deal with the materials' data. Mike is working on PBR for Opensim, and he will probably fix it to use his materials code in Halcyon when he does that. In that case, it will handle it ok.

The problem is the LibreMetaverse code that serializes Task Inventory when sending it is incorrect. It's missing fields and the client when it tries to parse it fails after a single packet, that's because the server is sending Malformed data for Task Inventory, it's impossible with the current DLL. Because the code for it is missing. I looked for a while and never found the code used to generate the DLL in the distribution. So you have to update LibreMetaverse from current code, which is really a good idea anyway. But that means testing all the protocol code and addressing any protocol changes present. And as expected, there are a lot of those. Halcyon is very out of date.

As for the textures, so that they will work, try this:

allow_grid_gods = true

; Do you have an aperture texture/mesh server set up?
; For more information about aperture, see https://github.com/InWorldz/aperture
use_aperture_server = no
; Port to connect to on the aperture server. Aperture is assumed to be
; running on localhost.

aperture_server_port = 8000

; Must match the caps_token stanza in aperture.cfg on the aperture server.

aperture_server_caps_token = 2960079

So aperture_server is off.

Let me know, with regards, Ana Green and Mike Chase

Ana-Green commented 1 year ago

I have considered this matter, and it is indeed quite perplexing. You select 50 items in your inventory, with the intention of placing them within a prim box (by copying), yet you find that only 26 items are visible. The discrepancy of -1 is due to the prim box itself being included in the count. However, with a straightforward script, it's possible to clearly display the accurate item count, revealing a significant error in the process.

All the best, as I believe that I am wasting my time, Ana Green

mdickson commented 1 year ago

The minus one (from the script above) is subtracting out the script itself. Its designed to give a count of the objects in a prim FROM THE SERVER SIDE. This effectively isolates the problem to the transfer of task inventory to the transmission of data from the server to the client. That is, the prim contents can clearly hold more than 26 items so its not an issue with persistence, etc. The error occurs when transferring the list of prim contents (Task Inventory) to the viewer. This is where the protocol issue is. And the reason I indicated the fix is to update to a current LibreMetaverse to get the updated message format. You still also need to make sure the server code is feeding the LibreMetaverse message correctly so there may be additional work to get it all plumbed up.

This is really what makes updating LibreMetaverse hard. There have been additional areas where messages have been changed (profiles, groups, estate management) and those would also need to be looked at and fixed. Also the version of LibreMetaverse IW was using also had some additional optimization to reuse message buffers. I think this is still in upstream LibreMetaverse but I don't know for sure. A quick conversation with Cinder would probably confirm that.

Btw the other reason I believe this is the transfer itself that's the issue is you can if you can get your hands on it and use an older InWorldz viewer I believe it will show inventory correctly. Again, this is because it doesn't have the protocol changes made. But it also doesn't have a bunch of other features that have been added to the viewer since it was released.

sonjamichelle commented 1 year ago

Well Mike (@mdickson) seems to be your lucky day, go play the Lotto or something, hehehe.

Anyhoo. The Internet Archive Wayback Machine to the Rescue. Someone recently reminded me of this age old resource, believe it or not IIRC correctly it HAS been around since the 90's. I found some archived InWorldz website stuff.

https://web.archive.org/web/20161127084402/http://inworldz.com/all-downloads.php

All the viewers are there, of course under "Viewer Downloads"

As for source, that's a it trickier:

I ultimately found this:

https://web.archive.org/web/20140427082611/https://bitbucket.org/inworldz/

Not sure how reliable the source code grabs are, but they MIGHT be useful.

mdickson commented 1 year ago

Thats a great resource Sonja. If someone can confirm that this viewer does not exhibit the 26 item bug (I dont have an active Halcyon grid to log in to) we'd know one more piece of info that would tend to confirm my comments that the issue is the protocol changes in the transfer of object contents. Unless someone shows up that is willing to put in some serious work updating LibreMetaverse (as I said the source for the current dll is no where to be found, if you track that down I AM playing the lottery) the InWorldz viewer may be the goto solution for Halcyon and where things are at feature wise for existing grids. I'm not aware of anyone willing at this point to do the development I mentioned.

sonjamichelle commented 1 year ago

Mike, I do have to admit I am not as familiar with a lot of the inner workings of the backside of the grid services. Can you expound on the LibreMetaverse stuff? Of, even point me to a good resource for a better understanding?

I DO find myself with a lot of "free" time on my hands. Mobility and getting around these days has been a challenge. Gravity and I seem to be at odd with each other. So, I might be up for a challenge. I dunno. I could at least look and see if it something I could understand. Never know until ya try, right?

Vinhold commented 1 year ago

Here is a link to download the last IW viewer, for Windows: https://www.myworldsrc.com/download/InWorldz3_RC_3_0_1_37176_x86_64_Setup.exe

I still have the installer for Windows on my desktop from when I was doing tests for this issue when it first came up. I had tested all available viewers and posted about it. It was thought at the time it was a viewer bug, but then turned out to be a protocol change as Mike and Appurist have elaborated on.

I had taken a copy of the "fix" Haycinth had created in Enchanted, but I was also informed that it was an incomplete correction. No info about what was actually changed by her. And I cannot find where I had saved that code copy. Sigh. Hoping it may still show up at some point.

Vinhold commented 1 year ago

I did check and using the InWorldz viewer, I can see all the items in a prims inventory >30 of them. So that question is answered. It works with the old protocol since it also has not been updated since the last Halcyon update. :) Sigh, it also does not support the BOM process which was implemented subsequent to when this viewer was last updated. So it will not be a suitable viewer for general use.

mdickson commented 1 year ago

LibreMetaverse is a library that contains Type definitions as well as protocol parsers and so on for all the llsl protocol handling between the client and the server. Most of it is client/viewer focused but the protocol and type code works from both ends of the connection.

https://github.com/cinderblocks/libremetaverse

There is a really large file that has the entirety of the protocol parser in the LibreMetaverse dll (the library is made up of a number of DLL's). This is where the protocol handling is done. It would be nice to be able to compare the source code for what Halcyon currently has with the current state of the project version. Unfortunately as I said in spite of hunting I'm afraid the source for the dll binary halcyon uses now is lost. Anyway here's the packet processor code:

https://github.com/cinderblocks/libremetaverse/blob/master/LibreMetaverse/_Packets_.cs

The job at hand is to replace the current LIbreMetaverse with this project version. I can say I did some work on it but there is some fairly extensive changes that went in around the time Cinder ported this to dotnet6+ that will require significant surgery. In particular there are a number of the network code portions that have been deprecated and replaced with new mechanisms.

Its not a small project unfortunately and this was probably the last straw that convinced me I wasnt going to have time to maintain to source bases and run my OpenSim NGC project alongside Halcyon. But if someone wants to try it I can at least offer some sideline encouragement and advice here and there if it helps.

mdickson commented 1 year ago

One more thing... The Commit History is helpful here.

https://github.com/cinderblocks/libremetaverse/commits/master/LibreMetaverse/_Packets_.cs

Note there are a couple of commit messages saying that a new file was generated from the linden messages file. The Packets.cs file is generated from a source definition. But there actual commit logs may help show whats changed. The message_template.msg is the source file that defines the protocol messages so diffs against that might also show what needs attention. In particular the changes in 2017 look to include object inventory changes that might be the culprit.

Ana-Green commented 1 year ago

@Edward Ashford#4188

@Cisco8676 @Ana Green IT

Subject: Regarding LL Protocol Compatibility Claims

Dear @vinholdstarbrook ,

I hope this message finds you well. I recently looked at your website and felt compelled to reach out to you about a particular matter that has been bothering me.

I must admit, I'm starting to become quite frustrated. You see, I believe that the website you've created could benefit from some improvements, and I can't help but wonder if there's room for enhancement. But that's not what truly irks me.

What has me scratching my head is the information regarding viewer compatibility in the Second Life & Opensim environment. Specifically, your claims about the ability to log in without encountering the notorious 26-item limit issue have raised my eyebrows.

From Opensim 8.0 all the way to the current Opensim version, I've found that I can seamlessly log in using both Firestorm from 2019 and Firestorm Opensim from 2023, namely Firestorm 6.6.8 and Firestorm 6.6.14. It doesn't make sense to me that these recent versions wouldn't be able to overcome the 26-item limitation, as you suggested.

What truly perplexes me, @vinholdstarbrook , is your assertion that one can achieve this feat using a viewer dating back to 2012—InWorldz 1.4.4 (1) Mar 20 2012 22:13:20 (InWorldz Release). What's more, this viewer doesn't even have a Grid Manager, yet you claim it can log in to your Halcyon Grid without succumbing to the 26-item problem. It's as if, magically, all the Halcyon issues disappear when using this decade-old viewer, despite it likely being created for Inworldz at the time.

I can't help but wonder why such an exclusive issue, as you suggest, would affect Halcyon but not Second Life (SL) or other Opensim (OS) versions. It's almost as improbable as my grandmother watching black and white TV in color—now, that would indeed be a remarkable day, wouldn't it, @vinholdstarbrook ?

I hope my concerns come across clearly. Please understand that I'm genuinely interested in your perspective and would appreciate any insight you can provide to shed light on this matter. There might be some typos but I am working.

Best Regards, Ana Green 70 West Tasman Drive San Jose, CA 95134-1706 USA