slutils-0.2

Uploaded a latest version of slutils to SecondTux Linux Client page.

Added scripts are slid, slupload and slnoidle. Annoyingly, slnoidle needs xse, and slupload needs xte. Should really ponder redo'ing these in another language at some point soon, like maybe C or something.

http://stux.wikiinfo.org/moin.py/LinuxClient

Nice job!

It seems to supercede my simple SLInstaller.pl script, and does much more, too!

*shrug* Was running out of things to work on with the linux client being down, so started working on the other items being brought up in the threads.

Now if I could just figure out a way to hijack streamed audio url's I would be set.

Found one bug... slid fails if you don't have the client's resolution set to the default. I'm running it at 1024 x 720 (the 720 is to account for my panels) and slid fails. I patched it, in my case, like this:

--- slid        2006-06-03 11:42:16.000000000 -0400
+++ /home/darkside/bin/slid     2006-06-06 03:34:13.000000000 -0400
@@ -5,6 +5,6 @@
 if [ -z "${SL_ID}" ]; then
        exit 1
 else
-       xwininfo -id "${SL_ID}" -children | awk '/800x600/{print $1}'
+       xwininfo -id "${SL_ID}" -children | awk '/\(has no name\):/{print $1}'
        exit 0
 fi

Of course, I'm not sure how robust this solution is, either, but it worked in my case, since no other line from the output has the colon in it.

Also, slupload doesn't recognize quotes for me. Might be because of my keyboard layout, however...

{edit}: Doesn't seem to be keyboard layout. The error is
Unable to resolve keysym for "quote".

{another edit}: Okay, xte is parsing " as the keysym quote, which X doesn't know about. If I force quotedbl with it, I get a single quote instead. Looks like a flaw in xte. Suggestions?

Okay, more input:

To use your sl and sldb scripts correctly, you really have to run slupdate to get the client, or at least conform to it's standard. You don't mention this in the docs! Threw me off until I read through the scripts, maybe it should be mentioned? I expected it to want

~/sl_path/

not

~/sl_path/SecondLife_1_10_1_0

and it was confusing to me. The easiest solution is to just run slupdate with ~/sl_path empty, of course. But I didn't know that at first, and it wasn't intuitive...

I actually have a patch to xte for this that I totally forgot about. Basically there are quite a few key types that for some reason xte uses in its US keymap, but X doesn't recognize the Keysym for.

diff -ruN xautomation-0.96.orig/kbd_us.h xautomation-0.96/kbd_us.h
--- xautomation-0.96.orig/kbd_us.h	2003-02-10 17:54:08.000000000 -0600
+++ xautomation-0.96/kbd_us.h	2006-06-03 14:17:52.000000000 -0500
@@ -27,8 +27,8 @@
 char *problems[] = { " ", NULL, "space",
 		     ":", "Shift_L", "colon",
 		     ";", NULL, "semicolon",
-		     "<", "Shift_L", "less",
-		     ">", "Shift_L", "greater",
+		     "<", "Shift_L", "comma",
+		     ">", "Shift_L", "period",
 		     "?", "Shift_L", "question",
 		     "/", NULL, "slash",
 		     "+", "Shift_L", "plus",
@@ -36,7 +36,7 @@
 		     "-", NULL, "minus",
 		     ".", NULL, "period",
 		     "!", "Shift_L", "exclam",
-		     "#", "Shift_L", "number",
+		     "#", "Shift_L", "3",
 		     "$", "Shift_L", "dollar",
 		     "%", "Shift_L", "percent",
 		     "&", "Shift_L", "ampersand",
@@ -45,6 +45,7 @@
 		     "{", "Shift_L", "braceleft",
 		     "}", "Shift_L", "braceright",
 		     "|", "Shift_L", "bar",
+		     "^", "Shift_L", "6",
 		     "~", "Shift_L", "asciitilde",
 		     "'", NULL, "apostrophe",
 		     "*", "Shift_L", "asterisk",
@@ -80,7 +81,7 @@
 		     "X", "Shift_L", "X", 
 		     "Y", "Shift_L", "Y", 
 		     "Z", "Shift_L", "Z", 
-		     "\"", "Shift_L", "quote",
-		     "\t", NULL, "tab",
+		     "\"", "Shift_L", "apostrophe",
+		     "\t", NULL, "Tab",
 		     "\\", NULL, "backslash",
 		     NULL, NULL, NULL };

Unfortunately, yah, I am in agreement. My wording often is less then clear when attempting to explain how to use something I wrote.

The slupdate client tries to keep all copies of SecondLife in a common location all of its own. So ${HOME}/SL/SecondLife_1_10_1_0 and such. It doesn't nuke old copies on the pressumption that wontonly deleting stuff for people is not very polite. That and on optional updates, it might not be exacly desired incase the update breaks things.

Will make an attempt to clean up the docs on that and make it a bit more clear though.

That patch fixed it up. For anyone out there running gentoo, I have a modified ebuild + patch file that will install the nice, happy version of xautomation.

Seems to behave strangely with tabs, now, but it copies over functional code, which is all I needed. Thanks!

Hope you're not getting tired of the feedback. More is always better, right?

slnoidle isn't functioning for me. SL_NOIDLE=1, still get logged off after 30 minutes of idle time. I didn't see any of your "Lost the window" warnings, which it looks like slnoidle would throw if it couldn't find an SL window.

No idea what's causing this; I'll experiment more when I'm coherent.

Always interested in feedback. Curious about the idle thing. It might be the checking for an 800x600 window. slnoidle should show up in the ps listing properly, and periodically your avatar should look up at the top of the window briefly. Would be cute to tie slnoidle into the xscreensaver or something so that it only pets the window when your idle. I have run into issues with it popping my view periodically when I am doing stuff. Bleh.

Anyway .. if your not running the window at 800x600 it will likely fail I suspect. Will see about adding the fixup to that here in a few.

On a second note, going to add an slurl script for handling the network.protocol-handler.app.secondlife config option in firefox so stuff like secondlife://Elpenor in the location bar works correctly.

Will see about getting all this stuff done real fast and popping an 0.3 release.

That doesn't make sense, though, because you've delegated "finding the window" to slid, and slid succeeds given the patch I posted above.


slnoidle is running, but I never see any movement in-game.


Hmm... not as useful for me. I often hop over to another workspace, hack on scripts for a while, then hop back to do uploading. That's where the noidle script is most useful for me.


While I don't see anything that should make that the case left in your scripts (post-patch), I'll keep exploring.

Hmm .. okay .. fair enough. Wonder if it is a window manager oddity. Kinda hard to believe though. At the same time, slnoidle is just using xse to do a MotionNotify on the window. Technically slid is returning the window manager window id and no the SDL window id. Might cause the difference maybe, but I found that MetaCity behaves REALLY poorly if you try to send events to the SDL window w/out going through the WM window to get there.

Hmmm .. Yer focus behavior follow pointer?

Seems to be normal. I dropped the sleep duration in the script to 1, and my av was predictably jerky... so the script is doing it's thing, but I'm still getting logged off after 30 minutes. Even weirder? Maybe it doesn't work if I'm in another workspace? Next time I go idle I'll leave SL running and in focus, and see what happens.

Yah, that makes some bit of odd sense:

Check out the mapable state of the window from the desktops:

xwininfo -id $(slid)

I suspect the desktops are the culprit. Likely can't do a mouse motion over it while the xwinfo data reads:

Map State: IsUnviewable

Okay, this is so counter-intuitive it isn't funny, but it seems to work well enough.

Try adding this just before the xse line in slnoidle:

id="$(xwininfo -tree -id ${id} | awk '/Parent window/{print $4}')"

I say this is counter intuitive because, technically, the Parent window is unmapped at this point and time, while the SDL_app window is mapped, but unviewable. To me it would have made more sense for the XSendEvent to work on the mapped/unviewable rather then having it work on the Unmapped window. But oddly .. it seems to work in my little 2 minute idle time-out with slnoidle sleeping for 1 minute.

If you are familiar with C programming and the pcap library IM me and I can show you how to capture stream URLs.

Yah, I am pretty familiar with both, just been short of gunshy about plucking anything off the network as that kinda gets weird in regards to the terms of service. Though at the moment, I don't see many other options.

FWIW, it looks like you'll be fine as long as your intent isn't malicious. Look at the libsecondlife project, for example. They seem to have LL's blessing.

Yes. AFAIK, Eddy Stryker is (one of?) the main dev(s) for libsecondlife.

With this sort of encouragement from the Lindens (hey we're nice people!) I'm prepared to risk reporting on some experimentation with ngrep that finally offers a work-around for a big gotcha for my use of the linux client.

The musical environment of SL is really important to me but it's frustrating to always ask for the URL of the stream thats playing at a venue.. this can be very bothersome on a night out club-crawling with my pals. It makes me feel like a second -class 'lifer always having to explain the deficit in the linux client to the club owners. In the case of streamed musical performance its even more problematic cos the last thing the performer has time for is to type out a URL and they may often be the only person in possession of this knowledge.. So I whinge and wine and have generally put up with this...

Unlike the video stream the audio stream is not logged so it can't be found there. The solution is to use ngrep which enables text strings to be searched from incoming payloads from the network. The port for this info can vary but seems to be something in the 30000 range. Fire up secondlife then once everthing has settled do an ngrep -q html.

Change parcel or pehaps more simply the stream URL if you can. This shows a packet declaring the parcel name and URL as an http address where the transaction is assoicated with a particular port.

You will want to tighten the search conditions so that all your normal http transactions dont appear. The best way is to add the port as a filter, e.g. ngrep -q http port 32771 where the port number will vary as obtained in the previous step.

In Fedora Core 4/5 ngrep can be installed with yum and needs to be run as root
su -
yum install ngrep
ngrep -q http
ngrep -q http port 32771

It is not really the intention of this post to ignite a discussion on the legitimacy of the use of these tools. The spirit of the exercise is to use freely accessible information to provide a work around for standard SL feature. My reading of the above and the encouragement given to the libsecondlife project is that we are expected to want to learn about the protocol. I can also imagine this debate going quiet in the long term as it is certainly conceivable that the information your client will have access to is the information *you* should have access to.

Amba

Download not working

I said the same thing in another thread, I guess it's down for repairs or something?

I managed to track it down and have uploaded the file. Vinci must have forgotten to move the file when he updated the pages of the Wiki.

Some kepresses are missed, Is there anything specific I can tweak to improve this? (well speed maybe) But I figured I'd ask anyway just to get some of that arcane wisdom that only comes with trial and error.
Also I've made a .deb package for xautomation with Major's patch.
Being the first package I've ever made, I'm pretty sure It will work on pretty much any recent version of ubuntu, or debian. Well it will probably work with alien -r for everything else to, but idk.

Maybe applying a patch, compiling, and installing is a trivial thing for most, but for those who can only take so much learning before growing the "Just work damnit" mentality (like me), Is there a place I can upload this? Was thinking second Tux, linked from the slutils page. But dont want to make anyone mad.

I would suggest the wiki.. keep it all in one place!

http://stux.wikiinfo.org/moin.py/SlUtils