NineChime forum

Nullig wrote:

Also, I noticed some commented code for saving the "chi" file and was wondering if you've tried saving and reloading from the "chi" file?

At the moment, no.  The "chi" file is not an animation file, but a custom image format.  Whether or not it would be a good idea to support it depends on whether it will ever become an animation format.  According to Codexus, the author of Chibi Paint, it's likely animation data would be saved in a different format.

Ashass wrote:

I still have an sql error while archiving/unarchiving items

Yeah, that's another bug with the log system.

I have a new 1.3.14 beta available that fixes this and a few other things.  I'm getting closer to making the board XHTML compatible, too, so things like Lightbox/Slimbox will work properly.

If you have a modified board, you can disregard the new index and header files.

Ashass wrote:

Retouch also does not work correctly, it saves the new image, however it still displays the image that was done before the retouch.

That is a caching issue, and requires a code rewrite.  Reusing file names is generally a bad thing in web applications.

How did you update recover.php? Did you add some other code?

Just updated my sites to add ChibiPaint and noticed that the ChibiPaint was missing in the recover.php file. If you try to recover a chibi draw, it just bombs out.

Had to add:

            case '4':
                $use_app = 'chibipaint.php?';
                break;

To the:

        // Get applet type
        switch ($row['datatype']) {

function.

Also, I noticed some commented code for saving the "chi" file and was wondering if you've tried saving and reloading from the "chi" file?

Nullig

hmm... strangely enough... chibi paint is suddenly working now. It's submitting perfectly fine, no issues or anything. Shows up on the index just fine as well.

It's designed to be integrated with an oekaki board, a web server running dedicated software.

It really shouldn't matter whether you're using dedicated or shared hosting, because this issue doesn't involve sending data to the server.  The only thing I can think of is a really obscure Java security issue, along the lines of the SocketPermission() problem.  In other words, if Java can't verify that the server connection is authentic, Java may refuse to handle internal paths correctly, and thus, the reflection request to the path "cello.tablet.JTablet" will result in an exception.  I don't know much about Java, but I do know that it can be a real pain in the butt at times, and having looked at the Chibi Paint source code, it appears the applet is appropriately testing for the tablet plugin.  The only suggestion I'd have is that if the JTablet test fails, the applet should not try to test for it again.  The problem is that Chibi Paint is testing for the tablet every time the mouse cursor moves, because of the way the GUI listener works.

Why Java is putting up a fight is beyond me, though.  But then, I've seen all sorts of strange things in the last few years.  I wouldn't be surprised if this issue it fixed by updating to the new Java plugin when Firefox 3 is released.  If that's the case, then this issue is almost certainly related to the SocketPermission() problem.