Friday, November 20, 2009

No More MyProxy! for a while.

HOLD! Don't scream in panic!!! It's not forever...

Baby Borg is coming between now and next weekend, so I won't be doing any work on the proxy between now and around the first weeks of december.

Yesterday I went online and tested each one of the v2.14 commands, and everything seemed to be working fine. At least from the "beholder's eye" perspective.
I have tested the AO, exporting assets, shape backup, demo shopping, asset import, texture download, and so on.

At some point I was able to replicate an issue where I was trying to use /load to load assets I've had saved, but those assets were not showing up on the inventory.
This happened on a crowded and laggy place, so I think it is related to the speed of the connection.
I have added some flags to the code and noticed that the proxy does exactly what it is supposed to do: sends the packets with the asset towards the server. But the assets just won't show up at the inventory.
As I could see that the MyProxy code was behaving as expected, I then believe this was being caused by the internal LibOpenMetaverse code losing track of the packets at some point.
April Swift had a similar issue even when using the LibOpenMetaverse proxy, so it(unfortunately) may not be related to MyProxy code.

Here's what I've used as a workaround to the problem, which may or may not work for you:

1 - Create and use an avatar that has absolutely no attachments. You will look like a complete noob (which is fun by the way) but you will also not generate any overhead to your viewer, making things become a bit faster. Remember, the proxy and the viewer are running on the same CPU, so every load that you can take out of it would help. I was amazed by the difference of performance I've got between loading my Ubber-detailed-full-of-attached-weapons-and-animated-textures avatar and the one I created with absolutely nothing attached.

2 - Do the things in batch. Instead of using /store directly at the crowded (laggy) place, just use /save instead, or /export or /exportall, teleport to an empty (I mean REALLY empty) sim, disconnect (close BOTH the viewer and the proxy) and then reconnect, so you will be freshly connected to a fast sim without anyone around (no lag?). Now you use /load and it should work. Worked for me. Be aware that, if the number of prims on the parcel has been reached, you won't be able to import any objects.

3 - Try to speed up your internet connection as much as possible, for proxies there are no "retries", a lost packet is lost forever, finito, caput, so try turning off anything that would be consuming bandwidth while you're using the proxy. Listening to internat radio, seeding some bittorrent or downloading the latest episode of Heroes while trying to use MyProxy is a big No-No-No.

I have tried to tamper with the proxy as much as possible, trying to break it, and it didn't break for me, but I can't still guarantee it is perfect, as some people is still experiencing problems.
So I would ask you guys to post here who is having problems, and who is not having, then let me know the speed of your internet connection, and the capacity (cpu/gpu power) of your computers.
The only way I think it will be possible to fix these problems is to establish some pattern, find some behavior that would be triggering the issues.

Cheers,
The Borg.

Ps.: Resistance is Futile

10 comments:

  1. Hey mr Mockba i wish you all the best with lil Mockba on the way i hope it all goes well.
    I already have 2 kids of my own so i know the feelin .

    ReplyDelete
  2. Good luck with the Baby Borg and have a nice break for MyProxy. :P

    I've been thinking, is it possible to copy animations with MyProxy? I managed to download one to my harddrive but there's no way to upload it again. :S

    ReplyDelete
  3. Hi Freeballer ... this inconsistency on the /store and /save commands may be a result of bad network throughput. As I said before, I send a packet to the server, if the packet will get there, no one knows.
    There's no easy way (as far as I know) to detect that it didn't get there, and then re-send it.
    What I have noticed right now is that people with faster internet connections is having less trouble.

    This _128 thing is also a mistery to me right now. I don't know exactly what this attachment point is.

    /store won't save anything on your hard-drive. /save will, on the same folder you're running the proxy from, and this should work, as long as you have visual contact with your target.

    When you copy from yourself, try doing that with the LL viewer. The lack of protection there may make things work better.

    ReplyDelete
  4. Hey Hina, thanks...

    Baby Borg is still in there, but the official due date is tomorrow, so he must be out anytime now. What a stubborn little guy ... :-)

    I haven't still figured out how to convert a binary SL animation back to its original BVH format, even though I am sure it can be done, it's just complicated, but its on my plans.

    You cannot upload an animation back to the SL server, because animations, and also images and sounds, are paid for when uploading. So there's no way to overcome the pay-to-upload process.
    You can, however, download an animation from SL and upload it to OpenSIM, it works just fine.

    Have phun...

    Cheers,
    The Borg.

    ReplyDelete
  5. when you upload an animation to the sl server it converts it to .animatm file format. If you look at the debug packet, it has asset download before crash of the. And .anim files along with .wav files are stored in the cache file or neillife. Just grab those and reupload.

    ReplyDelete
  6. This comment has been removed by the author.

    ReplyDelete
  7. Thanks for clarification Neil.
    I'd do it that way but I don't understand how to get anything from cache anyway. .-.

    ReplyDelete
  8. Just confirming, that even when using all the workarounds, and tested with neillife, emerald and the official viewer, I didn't achieve to /load or to /store previously saved assets and attachemnts in the SL-grid (agni). However, it worked fine loading into OSGrid. Now that's interesting...

    ReplyDelete
  9. Hey K-Werk.

    It's really cool to know that /load is working for you on OSGrid.
    Couple things worth mentioning:
    There's no way for MyProxy to import image (texture), animation or sound assets back to SL-Grid.
    These assets are supposed to be paid for uploading, so I cannot overcome that with the proxy. The upload will silently fail, as the packet is rejected by the SL server.
    I could try uploading things on temporary mode, but I still coudn't figure out how this temp thing works, and you would lose these assets anyway when closing the viewer.
    Other than images, sounds and animations, all the other assets, like skins, shapes, hairs, etc. seem to be uploading just fine.
    For the attachments, they get saved to a .XML file (it goes by default to the MyProxy folder) and then re-upload that by using NeilLife or other emerald based viewer that has an import-linkset option.
    But remember, you can only import something back when you're on a SIM which allows rezzing objects.
    Also make sure that the sim you're now has room for enough prims. A messed-up, filled-up SIM is likely to make the import fail.

    Hope it helps.

    Cheers,
    The Borg.

    ReplyDelete
  10. Hi The Borg

    First, warmest greetings and best wishes for you, your family and its youngest member. Enjoy the little copy of yourself :-)

    Back to your proxy: yes, i know which assets are not uploadable (at least not without paying for it), and this is why I wondered about shapes, skins and cloth wearables: I only could import them into OSGrid but not back in SL, from where I saved them. While the command /load returns a successful action message with those assets, nothing appears in my SL-Inventory.

    On the other side, I was not able to download tga-textures (with correct type set) by UUID, but it works with other images; maybe an issue with the problematic openjpeg lib? or my 64-bit Win-7?

    Btw, anims and textures are easily down- and uploaded with a slightly modified TestClient. But here again: uploading (not sure about downloading) tga-textures leads often to wrong alpha channel data, so they may become unuseable. Seems to be again a very annoying issue of the openjpeg lib, so you have to go back with cumbersome upload through a viewer with the kakadu j2k-library (most have it). Does any one has better experiences or some hints for correctly mass uploading tga-textures?

    Greetings
    K-Werk

    ReplyDelete