I'm Matthias Meger, the author of JSokoApplet (which is hosted at
sourceforge.net)
I like you programs. Especially BoxSearch and AutoSweeper.
BoxSearch has a very good goal room recognition.
At the moment I try to add an optimizer to my program. This seems to be
a hard task because it also should handle larger levels (like the
original Thinking Rabbit ones). So I have to get a better performance
in my program.
My first tests show that it might be the best to take the box paths
from the given solution as basis and count the number of boxes that are
off their paths.
Is this the way BoxSearch optimizes a solution ?
I'm very interested in algorithms for optimizing (and solving as well).
I hope you can give me some advice. Maybe we can exchange some ideas.
< This may prevent you from give me advice, bug report, etc.
Yet I haven't found any bug! It's a very good program!
But there are two things I like to see improved:
- After having solved a level with "Method5" for example, no other
solver can be used. When I test your program I often solve a level with
all solving method to see how fast your program is. In order to do this
I have to load the level every time I want to use another solving
mehtod.
- In "Edit"-mode I like to have a feature: When the mouse button is
pressed and the mouse is moved this should be treated as single click
on every reached square. With this in place it is easier to set a line
of walls (one just has to click onces and the move the mouse to all
squares that are to be come walls).
Keep up programming such great programs!
Matthias Meger
I did post a reply a regarding the bug I've reported in the
supersoko forum, not sure if you've read that or not. I will just
summarize it here in case you haven't.
I did test with 1.9G RAM and the bug did not occur. If 2G or more (or
just take the default 0), I get the error.
I suggested that maybe you can add a "continue" feature to the answer
optimization option.
>From my observations, it seems like BOXSEARCH's memory drops down to
zero (or close) and then restart for every "certain interval" of step
of optimization. If that's true, then it's probably possible to write
the "current" state of the optimization and save it to a file and later
load it back to resume the optimization.
I am suggesting for a "save/resume" option because it normally takes a
long time to run some of the answer optimizations. It would be nice to
have this feature if feasible.
Back to the bug....
I know that sometimes it's difficult (or impossible) to debug a problem
without stepping thru the code in a IDE or debugger, but sometimes it
might help if you can think of things that you might want to see at the
point where BOXSEARCH failed (returns an invalid answer during
optimization). Since you know your program best, I really can't
suggest much info on tracing other than:
-- how many states has been searched
-- memory usage
-- total time it took (this is helpful for me, at least I know how
long it takes to hit the bug)
-- any internal variables that you might be interested to echo out the
value
If you have any new code that you want me to run, feel free to send it
to my gmail or yahoo account.
Great job with BOXSEARCH. I will definitely test out the new
boxsearch v5 pre 1 when I get the chance.
Thanks!
-- Ming
I have some questions:
(1) How does the program discover new levels ?
I played around the "additionalCollecitonX.zip" files a bit and I
think it reads those zip files on startup. I tried to move a levels
from collection3 into collection1 and it displays the GRIGoRusha levels
right below "Brian Damgaard" instead of the normal "author->collection"
(i.e. Evgeny Grigoriev -> GRIGoRusha).
How do you determine & setup the level menu ?
Can you add an option for the program to re-read the zip files without
restarting it?
(2) What's the skin format ?
I noticed that those provided by Jerry W. and Bjorn K. are
different.
Do you plan to add support for the existing skin formats out there ?
Thanks!
> Hi Matthias Meger, I just tried out JSokoApplet, I think it's a very
> nice sokoban implementation.
Thanks!
> I have some questions:
> (1) How does the program discover new levels ?
> I played around the "additionalCollecitonX.zip" files a bit and I
> think it reads those zip files on startup.
That's right. The problem is:
An applet can't read files it doesn't know the name of. So I have to
put all levels in one file which always has the same name. For users
who don't have a high speed interent connection that would be a bad
idea, because all levels had to be loaded into memory although just
some of them are used at the moment.
Hence, I decided to split the levels into several files.
This all is just be done for supporting the program started as applet.
You can start the program as application (simpley with. "java -Xmx256m
-jar JSokoApplet.jar") and then load new levels by using a file dialog.
The applet can also load new levels. You have to paste them into a
textfield (Level -> Load level -> Import from clipboard).
Now the answer to your question:
The author of a level is identified by the folder the level is located
in.
If the levels are in the folder "test" the program will display a new
author "test".
If there is no folder for the levels they are just displayed in the
level menu without an extra menu for the author.
> Can you add an option for the program to re-read the zip files without
> restarting it?
Usually these files don't change much, so I haven't implemented such an
option yet. The applet usually is started in the internet where the
user doesn't has access to the server where the levels are stored. When
using the program locally I recommend to start it as application for
being able of using the file dialog for loading new collections.
Nevertheless, if you think such an option would be useful I can add it,
of course.
> Do you plan to add support for the existing skin formats out there ?
It's difficult to support all the skin formats. Some use animated
graphics, for example. I think I will improve the skin support step by
step. The first step has been to separate the graphics from the jar
file so the whole graphic data mustn't be loaded at the start of the
program.
Do you have any skin you like to be supported soon ?
Matthias
> Hence, I decided to split the levels into several files.
I think that's a good idea.
> This all is just be done for supporting the program started as applet.
> You can start the program as application (simpley with. "java -Xmx256m
> -jar JSokoApplet.jar") and then load new levels by using a file dialog.
> The applet can also load new levels. You have to paste them into a
> textfield (Level -> Load level -> Import from clipboard).
Yup, this is the way I am running it.
I use the included batch file to launch it.
> > Can you add an option for the program to re-read the zip files without
> > restarting it?
> Usually these files don't change much, so I haven't implemented such an
> option yet. The applet usually is started in the internet where the
> user doesn't has access to the server where the levels are stored. When
> using the program locally I recommend to start it as application for
> being able of using the file dialog for loading new collections.
> Nevertheless, if you think such an option would be useful I can add it,
> of course.
It's true that it doesn't make sense for the applet.
It a nice option to have when started it as an application.
> Do you have any skin you like to be supported soon ?
Yes, I have one that I like.
I attached it to this reply.
The bottom four rows are animations when the "man" is selected, "man
on goal" is selected, "box" is selected, "box on goal" is selected
respectively.
It's a Ysokoban skin based on SOKOFUN. This skin works with SokoYASC as well.
It's ok if Jsokoapplet doesn't support animation (just ignore the
bottom 4 rows).
Thanks!
> It's a nice option to have when started it as an application.
Ok, I check if I can change the program so that it always checks if
there are new collections available when the "load level" menu is
opened. Do you really change these files very often while the program
is open ?
> It's ok if Jsokoapplet doesn't support animation
Without animation it's easy to do. But I don't know if the skin is free
of copyright. So I won't publish it together with my program.
Here is a quick and dirty version of my program with that skin:
http://jsokoapplet.pytalhost.com/JSokoApplet_1.17.zip
I just converted the graphic to jpeg and overwrote the skin file from
Gerry Wiseman :-)
(so if there should be any problems when downloading this special
version you can just do the same).
If you also want to rename the menu text you must do the following:
open the file JSokoApplet.jar with an program that can handle
zip-files.
There is a file named settings.ini. You can change the texts there.
(search for the string "skin1")
I don't know when I will publish a new version with the support for
this skin. At the moment I'm working on an optimizer and the program
code isn't "ready for publishing". It's very complicated. BoxSearch
already has a very good optimizer. I hope I can also program such a
good one :-)
Matthias
> Ok, I check if I can change the program so that it always checks if
> there are new collections available when the "load level" menu is
> opened. Do you really change these files very often while the program
> is open ?
Mostly, when I play with levels and I might want to add more levels to
the zip file. But that probably dont' happen often. It would be an
overkill to check for new levels when "load level" menu is opened.
Originally, I was thinking of a "refresh level" button. That's
probably not needed if there's not enough demand for it.
I would like to suggest something similar and that should be enough to
address collections other than the included ones.
When JSokoApplet is launch as an application, the user can do:
Level -> Load level -> External levels
to load other level collections.
It would be nice if it can keep a history of recently loaded/opened levels.
Preferably, put the history list under Level->Load level -> Reopen
levels, or Level->Load level->External levels->Reopen
Possibly even allow the user to set how big the history can be.
The reason I suggest this is because I have levels spread over
different directories.
If you keep a history, it makes it very easy to reload some levels
without doing too much navigation.
> Without animation it's easy to do. But I don't know if the skin is free
> of copyright. So I won't publish it together with my program.
> Here is a quick and dirty version of my program with that skin:
> http://jsokoapplet.pytalhost.com/JSokoApplet_1.17.zip
I just tried it and it works great. Thanks!
As for copyright of the skin... it's a hard to say.
As far as I know, the skin in question has been modified by a few people.
Originally, I downloaded off Ysokoban's site, I did some modification on it.
Gerry W. also did some rework on the skin. I did some more
modification to it and we end up with skin we have now. I think it's
probably ok to put it up until someone complains. It's up to your
whether you want to put it in your next release or not.
>
> I just converted the graphic to jpeg and overwrote the skin file from
> Gerry Wiseman :-)
> (so if there should be any problems when downloading this special
> version you can just do the same).
> If you also want to rename the menu text you must do the following:
> open the file JSokoApplet.jar with an program that can handle
> zip-files.
> There is a file named settings.ini. You can change the texts there.
> (search for the string "skin1")
Yup, that works great. RAR works perfectly for this job.
>
> I don't know when I will publish a new version with the support for
> this skin. At the moment I'm working on an optimizer and the program
> code isn't "ready for publishing". It's very complicated. BoxSearch
> already has a very good optimizer. I hope I can also program such a
> good one :-)
Keep the good stuff coming. :)
Good luck!
-- Ming