The first version you had worked for me. Your recent commits don't.
I get the "couldn't load XML file" error, too, when trying to run pywse-fb. When running pywse I get:
$ python pywse
Traceback (most recent call last):
File "pywse", line 10, in <module>
from lib import webkit
File "/home/j/Arbeitsfläche/pywse-master2/lib/webkit/__init__.py", line 19, in <module>
import webkit
ImportError: /home/j/Arbeitsfläche/pywse-master2/lib/webkit/webkit.so: falsche ELF-Klasse: ELFCLASS32
The last part is German and means "wrong ELF class".
By the way, I released version 0.3.0 today. Maybe you want to update?
Should be fixed now and I updated to 0.3.0 too. Reading the Green Monster's text gives me flashbacks of youtube commentary
We're back to a second and half delay to give the web server time to start. I implemented a few WebKitWebSettings into the code by enabling cacheing and a few others by using
http://webkitgtk.org/reference/webkitgtk...tings.html as a reference. I've also been messing around with C in an attempt to rewrite the client - we'll see where that goes. I could maybe use something like mongoose for the web server side.
I also want to write a demo game for pywse to show off the features of WSE that can be used with it, especially the sound effects and music. I'll start looking over the Lemma Soft Forums' Creative Common Forum to see what I can find
Btw, I'm having a slight issue with music. I can see it's looping in the terminal, but it just stops in my client. I'm pretty sure it's related to ALSA though. I'll have a look at it later.
Finally got the web server threaded! Now to move on to stage two of development and start porting it to Windows
Any feature requests you have in mind?
Good to know it's working now.
Did you get audio to loop, too? If the WebKit version is a little older, it might be that it's the same bug Chrome had until a few versions ago... the bug was basically that setting the loop attribute on an audio element didn't work at all. That's why I had to write my own looping function in the last version of the engine. But when I last checked in the new Chrome version, the loop attribute worked as expected, so I decided to use that in 0.3 instead.... maybe that's why?
Feature requests... hm... no, not really. But if something comes to mind I'll let you know.
I tested it with midori and tazweb too and the same problem comes up. It seems related to my libwebkit or gstreamer package. What it does is lock the alsa device which prevents it from playing the second GET of the song. Since I setup my alsa to use multiple streams, this is actually a very annoying habit. I'll have a look at each package to figure out why this is. Incidentally, I found a wrapper to embed chromium's api (stand-alone) into python while trying to make pywse work - maybe that will be a better api to use in the future instead of webkit.
I fixed my audio issue (it was related to gstreamer using oss instead of alsa), but there cropped another issue related to SimpleHTTPServer not being able to handle Ranged GET and HEAD responses, meaning I had to extend both with my own Request Handler. Now the music loops without any further problems.
As for the Windows Executable - There is a tiny hitch. PyInstaller can only generate exe files from a Windows system. This is a pain in the ass, but I'll see what I can figure out...
Anyway, get the latest code from
https://github.com/Trixarian/pywse like usual
EDIT: I also made the port random between 4000 and 4999. Now you can run multiple instances of pywse at the same time so you can play more than one game at once.
Yeah, I know about these deployment problems with Python. I mean it's not a problem on Linux at all since most distributions have it installed anyway, but Windows sadly is another story.
Unfortunately, your current version on GitHub doesn't play sound at all on my Ubuntu 12.04 machine. There's no error message reported.
I would also recommend disabling the right-click menu in production. It doesn't serve any purpose for playing the story.
I changed the code a bit, so see if it gives you an error when you run it in terminal now. I fear it might be related to file type guessing (sigh, can't SimpleHTTPServer do anything right?). Since we have the same python version (2.7.3), it probably isn't related to that. I can't seem to break it even if I uninstall gstreamer's alsa support, but without the alsa support, there are times when if you run the game, it doesn't start the music - but only happens 1 times out of 10.
I disabled the right click menu and did a new demo based on the 0.3.0 one, but using CC or Public Domain assets.
I just tested the new version. I have to say, the assets look a lot nicer than the ugly stuff I crammed in there.
Unfortunately, sound still doesn't work. I started the game multiple times and still got the same result: No errors related to the audio and SimpleHTTPServer says it delivered the audio just fine.
I have a theory. One of the biggest changes I made was make the SimpleHTTPServer able to deal with multiple connection using SocketServer's ThreadMix function. Since most of the errors explicitly mention SocketServer and we really don't want to serve more than one client, I went back to old way of doing it. I also created pywse.sh which runs pywse in "Basic Mode', which just means it uses SimpleHTTPRequestHandler over the one I wrote.
Try testing both pywse.sh and the normal pywse executable script to see which works. If both work, it was clearly SocketServer's fault. If only pywse.sh works for you, then it's my new Request Handler that's at fault. If neither works, then I have no clue why
Edit: An online copy of the demo I made can be found @
http://brenton.nom.za/demo/ with an ogg version of Barren uploaded for other browsers.