The optimizer is a tool for optimizing solutions of a level. It will reduce the number of moves and/or pushes of a solution. If you don't want to reduce the moves or pushes of solutions you don't need the optimizer tool. It's a tool for professional players.
You can open the optimizer by pressing F5 or through the optimizer menu.
The optimizer GUI (click image to see an enlarged version of the image) shows the level at the top left, so you can always see which level is currently opened for optimizing.
At the top right a log is displayed showing information about the optimizer process.
Below the level display and log display there are several input elements which can be used to adjust the optimizer.
At the top right a log is displayed:
While the optimizer is running some information are displayed in the log. When the optimizer is opened deadlocked box configurations that can occur in the level are identified in a background task. You can see the progress in the log. If the deadlock detection has finished the message "Deadlock detection has finished." is displayed. The detection runs at most 3 seconds. Howerver, it's possible to start the optimizer even when the deadlock detection hasn't finished, yet (prior to version 1.69 this isn't possible).
The deadlock detection has only to be done once when the optimizer has been opened.
In the "Solutions" list all solutions of the level are shown:
You must select a solution here for optimizing it. The list has the same context menu as the solutions sidebar. See description of solutions sidebar for more information.
The optimizer uses the selected solution as basis for the search for a new better solution. You can select more than one solution at a time. Then the optimizer tries to combine them while searching for a better solution.
Note: selecting multiple solutions at once for optimizing them needs a lot of RAM and the optimizing run takes a long time.
After the optimizer has finished the optimizing process the new found solution is added to the solutions list and automatically selected. If the new found solution is already stored in the solutions list the new solution isn't added but the already stored one is selected.
The optimizer can optimize a solution for the shown metrics:
The optimizer algorithm searches all possible path to a new better solution. However, such a search would take far too long in most of the levels. Hence, this search must be restricted. This can be done by setting the "vicinity squares":
This restricts the search to the "vicinity" of the basis solution which has been selected to be improved. The more boxes and the more vicinity squares the more RAM the optimizer will use and the longer the search will last. For huge levels only one box should be selected. For smaller levels 2 boxes with a small setting for the vicinity squares may be a good choice. For instance: 2 boxes which each have 10 vicinity squares.
The program can't automatically determine the perfect settings for a level. The perfect setting depends on the available RAM, on the level and on the solution. Hence, it's necessary to try several different settings for optimizing a solution.
Note: the more boxes and the higher the vicinity squares values are the better the results will be (but the longer the search will take). For a quick result use low values and just one box. Then increase the values and the number of selected boxes. If the optimizer log should display the message "Insufficient memory. Optimizing is done in stages." you should stop the optimizer and use lower values / less boxes until the optimizer doesn't show this message anymore.
The following topics are only for users who want to tweak the optimizer to its best. It's not necessary to understand or use these features for optimizing solutions when you are only interested in "quite good" solutions.
The optimizer normally optimizes the whole solution. If for instance it's sure that the first 10 pushes of a solution are already perfectly optimized, it's possible to set the pushes range to be optimized from 11 - "end of solution".
The "optimize pushes range" can be used to restrict the search for a better solutions to a part of a solution which can be set by a "from" push and a "to" push.
The optimizer automatically creates a new level from the pushes in the selected range. Boxes which aren't pushed in this pushes range of the solution are converted to walls in order to reduce the number of boxes in the level.
JSoko tries to calculate the needed RAM before the optimizer starts. Depending on this the maximum number of box configurations is calculated. However, usually this calculation is just a rough estimation. In the log the optimizer displays the available free RAM after the optimization has been done. If there is still a lot of free RAM after the optimization has finished, it may result in better solutions when the maximum box configurations is manually set to a higher value.
Note: Due to 32 bit variables used in the program JSoko has internal limits. Hence, the maximum number of box configurations used by the optimizer may be less than the manually set value. The log shows which value is used in the search.
For the new optimizer methods Pushes/Moves/BL/BC/PS and Pushes/Moves/BL/BC/PS there is no 32bit restriction. JSoko tries to use as much RAM as available.
If the optimizer finds a new solution having less or equal metrics compared to the best selected solution this new solution is saved for the level. It's possible to use this new solution as new basis solution the optimizer should use for searching for further improvements. This iterative optimizing is done automatically when "Iterative optimizing" is selected. The optimizer then will optimize the selected solution and all better solutions it will find as long as further improvements can be found.
While doing this the optimizer will save all found solutions by adding them to the solutions of the level. This may result in a lot of new solutions. If "Only save last solution" is selected the optimizer will only save the last (=best) found solution.
Note: the optimizer also continues the search when the new found solution has the same metrics as the solution that has been selected to be optimized. This is due to the fact that even small changes in a solution can result in further improvements in the next iteration run.
However, the optimizer will of course stop immediately if the new found solution is identical to the solution selected to be optimized.
This is a special checkbox for users who split levels manually for a better optimizing result. In these cases it may be helpful to set this flag:
If this flag is set, all new solutions the optimizer will find have the same player position at the end of the solution (= when the level is solved) as in the selected solution to be optimized.
The optimizer can use multiple CPUs/cores while generating box configurations and for the "Pushes/Moves/BL/BC/PS" and "Moves/Pushes/BL/BC/PS" optimizer methods. As default JSoko uses all CPUs for these tasks. However, if this slows down the computer too much the maximum number of CPUs JSoko is allowed to use can be set here.
Some levels are very huge and contain many boxes. Therefore the optimizer can only be used with small settings for the vicinity squares.
However, often improvements of a solution can be found by only rearranging pushes of boxes in a small area.
It's possible to mark the area the optimizer shall use for optimizing. This can be done by simply marking an area in the displayed level graphic at the top left of the optimizer GUI.
To select an area to be optimized just click into the level graphic and while holding the mouse button down move the mouse. This way a rectangle is drawn representing the area that will be marked. When the mouse button is released the selected area will shown highlighted.
If at least one square has been selected this way and the optimizer is started then the optimizer will only optimize the selected area. Due to the smaller area to be optimized the number of generated box configurations is lower than it would be when optimizing the whole level. Hence, it's possible to increase the settings for the vicinity squares without increasing the number of generated box configurations too much.
A selection of an area can be removed by using the right mouse button or the ctrl-key while selecting an area.
Strictly necessary cookies guarantee functions without which this website would not function as intended. As a result these cookies cannot be deactivated. These cookies are used exclusively by this website and are therefore first party cookies. This means that all information stored in the cookies will be returned to this website.
Functional cookies enable this website to provide you with certain functions and to store information already provided (such as registered name or language selection) in order to offer you improved and more personalized functions.
Performance cookies gather information on how a web page is used. We use them to better understand how our web pages are used in order to improve their appeal, content and functionality.
Marketing / Third Party Cookies originate from external advertising companies (among others) and are used to gather information about the websites visited by you, in order to e.g. create targeted advertising for you.