New: Instant Palace Fix (V3) By Dr@ke

[Lawlasaur]

Quote: Originally Posted by theturtle32

I'm actively developing a flash-based palace client... you're welcome to check it out at openpalace.org -- It's open source, so you're welcome to download the source code, play around with it, and submit patches and improvements.

Brian

I'm glad to see people are still wanting palace to stay alive and putting effort into it, congrats Brian that looks pretty sick, i can't wait till it's done keep going att er!

[rentahero]

That flash client really looks promissing Brian! Is there Any chance that in the future you can enter an chatname as a parameter and not be able to change your chatname after you have entered the palace like in the java client? For us that is very important because we like to use the community login usernames for our palace as well and we don't want a seperate login when users want to enter our palace. This ofcourse only will work when you can enter our palace only from our entry page and not from a public entry link.

About the java client by heini and updated by drake... i also noticed that gif's didn't work, and that it had nothing to do with upper/lowercase. I noticed however to my surprise that gif's did work when this java client is connected to a windows palace server. I have an exact copy of my linux palace on a windows palace server.
When i look in the error logfile of the apache logfiles on my linux palace server, i also noticed to my surprise that when a gif is requested by the roomsfile (ie roomleft.gif), a request is done for a jpg (roomleft.jpg). This java client connected to a windows palace server doesn't seem to have this problem.

So with the new java client connected to a linux palace server, every gif request from the roomsfile is converted to a jpg request. And when ofcourse the jpg is not in the media directory, it can't be loaded. Copying every gif to jpg in your media dir. is one way to fix this problem.

Searching and replacing every .gif to .jpg in the roomsfile (.pat file) and renaming every gif to jpg in your media directory however is the easiest and best way to fix this problem. So you don't have to convert every gif to jpg.. renaming is enough. The transparency of the gif will be kept this way.

I hope this is some use to somebody.

[Heini]

Could you look with a browser what you get when you request a picture which doesn't exist? It should give you a 404 File not found-page, or a white page without any error.
Java Palace works like this: when it finds a picture to load in the roomsfile, it cuts of the extension (roomleft.gif to roomleft) and then it appends its own extensions. First it tries roomleft.jpg, then roomleft.gif (it appends the extension always in lowercase letters, thats why i mentioned it the other post). The problem for the javaclient is, to decide if the first request (the one with jpg) is a picture or not. As far as i remember in case of a non-found picture it wants an empty website (look at windows pserver, what it gives back as errorpage). Depending on the configuration of apache, java thinks the errorpage is a picture and tries to load it, which won't work, and doesn't try to load the gif afterwards, because it thinks it allready loaded a picture.

I think they programmed it like that, because they wanted to make it easier to transform older palaces with just gifs to newer palaces with jpg's, which werent supported by older palaceclients. They also made sure, an old palaceclient loads a gif, and a new palaceclient loads the jpg (which has better quality).

I thought of changing that behaviour, so that Javapalace loads just whats written in the roomsfile, and no automatic file ending anymore.

Quote: Originally Posted by rentahero

About the java client by heini and updated by drake... i also noticed that gif's didn't work, and that it had nothing to do with upper/lowercase. I noticed however to my surprise that gif's did work when this java client is connected to a windows palace server. I have an exact copy of my linux palace on a windows palace server.
When i look in the error logfile of the apache logfiles on my linux palace server, i also noticed to my surprise that when a gif is requested by the roomsfile (ie roomleft.gif), a request is done for a jpg (roomleft.jpg). This java client connected to a windows palace server doesn't seem to have this problem.

So with the new java client connected to a linux palace server, every gif request from the roomsfile is converted to a jpg request. And when ofcourse the jpg is not in the media directory, it can't be loaded. Copying every gif to jpg in your media dir. is one way to fix this problem.

Searching and replacing every .gif to .jpg in the roomsfile (.pat file) and renaming every gif to jpg in your media directory however is the easiest and best way to fix this problem. So you don't have to convert every gif to jpg.. renaming is enough. The transparency of the gif will be kept this way.

I hope this is some use to somebody.

[rentahero]

Thanks for explaining, that makes it a bit more clear. I thougt it was really strange behaviour. You're right that jpg's for backgrounds are better quality but for buttons, when transparency is needed, gif's are still the only option. I also think it's a bit confusing and not logical anymore to keep that behaviour than looks for both jpg and then gif.. you just want what is requested in the roomsfile.

On the windows server i get exactly the same 404 error as on the Linux server when i request a picture in a browser that doesn't exist in the media dir.

And when i do a request in the roomsfile for a picture that doesn't exist on the windows pserver.. in the error log file this is logged:

Quote: Originally Posted by

[Mon Sep 28 17:13:04 2009] [error] [client 192.168.1.7] File does not exist: /palacechat/palace/media/roomrigh.jpg
[Mon Sep 28 17:17:56 2009] [error] [client 192.168.1.7] File does not exist: /palacechat/palace/media/roomrigh.gif

So you are right and you can see the win pserver looks first for jpg and then for gif.

I thought at first it was perhaps an Apache configuration difference, but as far as i know i couldn't see it. BTW On my linux server i don't use the the http server of the palace server but the one that came with the linux installation.

Until now we've used our own sun compatible Instant Palace java client which i decompiled an compiled again after removing some programming code which were causing problems. I don't really know what i was doing however.. i'm not a java programmer and it was pure luck that it worked again with java sun ;-).

The only problem with this client we had until a few month ago (now we have more problems) was that chatters freezed on prop changes and they had to log in again. Not a really big problem for us because our chat is only accessible for the java client. The only thing we couldn't do anymore was pin a chatter because a pinned chatter wears a prop. Your java client doesn't freeze up with prop changes i noticed. Our Java client BTW didn't had any problems loading gif's on both the linux and windows pserver.

I tried to switch to your java client version because the last few month some chatters freeze after a while, ie when they open the roomslist or the userslist or going private and they have to log-in again. Also loading takes a very long time for some chatters. Other chatters (including me) don't have that problem at all. Not much luck with your client however.. still the same problems althoug room changes are faster. Some chatters have more problems with your client, others don't. I decided to make both clients available for chatters.

I don't know if these problems are caused by a different JRE sun version or a problem on my server. I don't use the standard 512x384 room format but widescreen 640x400. But i switched to that format more than a year ago and didn't cause any problems then.

I do however get an error message in the sun java console when i enter the chat with your and my client, i however don't have any problems with freezing or loading:
With My Java client:

Quote: Originally Posted by

Exception in thread "AWT-EventQueue-3" java.lang.NullPointerException
at sun.font.FontDesignMetrics.stringWidth(Unknown Source)
at af.a([DashoPro-V1.0-0420])
at ck.c([DashoPro-V1.0-0420])
at cz.paint([DashoPro-V1.0-0420])
at sun.awt.RepaintArea.paintComponent(Unknown Source)
at sun.awt.RepaintArea.paint(Unknown Source)
at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilter s(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(U nknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarch y(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

With Your Client:

Quote: Originally Posted by

Exception in thread "AWT-EventQueue-3" java.lang.NullPointerException
at sun.font.FontDesignMetrics.stringWidth(Unknown Source)
at communities.pob.User2D.draw(User2D.java:60)
at communities.pob.Room2D.draw(Room2D.java:269)
at communities.Palace2DCanvas.paint(Palace2DCanvas.ja va:92)
at sun.awt.RepaintArea.paintComponent(Unknown Source)
at sun.awt.RepaintArea.paint(Unknown Source)
at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilter s(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(U nknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarch y(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

I also notice in the sun console that all the 104 avatars are loaded before entering the chat, but i think this was allways the case.

[Heini]

My version still has problems with some props created by the propbag-converter of phalanx. Those props have some illegal (at least for javapalace) values which are to big for some variables. In two cases i found the values because i got an "evil" test-prop from which i know it crashes. But i guess there are still some possibilities open where it could crash.