Hello everybody,
I am sorry that I haven\'t updated the thread in so long. I have had to put this on the back burner for a bit, because I am doing a lot of things in real life. I also have been on a KSP kick, so I haven\'t played Starmade in a while. I won\'t promise anything, but I might try to get some development done this weekend. Now, to address some comments. First, Reida:
This program is really useful for people who are build reactors for massive ship, but the problem is how do i use this program i mean i\'m still figuring out how the the view look like even after 3 days of googling but don\'t a guide on it, would kind soul care to guide me?
I really need to begin working on a guide for this. I added a Wiki to the project page, but I am yet to populate it. By the way, the view is kind of like a cake: each slice is a layer, and you build each previous layer on top of the subsequent one.
You start the program then go to create theres a population size what is that?
Population size is the maximum number of reactors that the program considers in any one generation. In fact, the program considers exactly the number of reactors in the population. The idea is that more successful reactors will hang around longer and will have more chances to have offspring. How you determine population size is basically determined by how long you are willing to wait versus how much RAM your computer has. Generally, smaller populations mean there\'s less initial variance in the population, so large populations may be better; but for large reactors, it will take more time to perform the calculations, so a larger population may slow things down. Some fiddling around with the parameters can give you a good idea of what the best balance is.
Next, Kupan:
1. I would love to be able to put in a couple of reactor designs, have it create the rest of the population as normal then run it to see what it does with a few hand crafted variants to start, It would also be easy to tell when it surpasses my personal designs.
I thought about adding a facility to seed the population with known good reactors, and I may in fact allow for this. The only drawback that I can see is that the algorithm may enter into a local optimum that might be very hard for it to get out of because of lack of genetic variance; but it is worth looking into for the future.
2. When looking at the visualization sometimes it doesn\'t update the visual when I click on a different variant. This is easily worked around by clicking on a few other variants till it updates the display and then it will work for a few clicks then stops again. This may be aggravated by the fact that I am running 10x10x10 256 pop 50000000 epoch .4 mutation runs.
This is a known bug, and it is something I hope to fix soon. There is a reasonable question as to how frequently the visualization should update, however. Drawing is computationally expensive (so much so that most computers have specialized hardware for it), and could become a bottleneck given a sufficiently fast simulation. I probably need to make better use of events, since that can leverage multithreading and possibly reduce contention, but I\'ll need to look into this.
3. I would second the request for Power : Block Count ratio options, but more importantly (to me) would be a Power : Cluster Number ratio. Maximum power for the least amount of clusters. This could be weighed in a couple of ways. You could have it exclude all clusters of size of 1. It could have a weight applied to each cluster after the first user defined number to decrease the value of anything after that either by a weight that increments by cluster count or by something like (cluster number*cluster number penalty weight-(cluster block count * block count bonus weight)+(Cluster Power Gen - Worst Power Gen of Top X% Performing Power Cluster)) with a max of no change. This would ideally be aimed at allowing higher performance clusters and larger clusters to be present and encouraged. Currently (in my personal runs) it seems to prioritize 1 large cluster and a few medium and mostly pretty small ones to generate high counts. It would seem beneficial to encourage larger clusters or optimized power efficiency in the clusters to a larger degree than purely by the total reactor result. Or at least it would be fun to play with.
I might add these fitness functions in the next stable release. The reason why ReactorBreeder tends to prioritize 1-block clusters it is difficult to fit larger clusters into the provided space; in many cases, the extra 1x1x1 clusters are superior (in that they provide more power), but they are admittedly difficult to build and look somewhat ugly.
4. As someone who tends toward OCD tendencies I would like to see 1 or 2 way mirror mode. It would be interesting to see what designs can come from that constraint and would probably tend toward higher populations of long clusters (minimum of 4 on 2 way mirror would be significantly higher than I am seeing so far). This also seems like it would be more likely to generate reactors that would seem more user made and be more readily understood by most people trying to build them or modify them slightly for unusual shapes . To be clear by 2 way mirror mode I mean like in advanced build, the number of mirrored axis.
Mirroring could be a possibility, but it might be later down the road; still, I will consider this as a potential feature, as I know one of the bigger complaints is that the reactors generated from ReactorBreeder are difficult to reproduce and that they are ugly. Mirror mode might be fairly easy to implement, so it might be worth looking into.
Great program, I hope the fact that it doesn\'t appear to have updated since 2013-07-11 doesn\'t mean it was abandoned. Thank you again for sharing.
Thank you for the positive and detailed feedback! I have not completely forgotten about RB; I just haven\'t had time to develop it much lately. But I will try to do some more work with it, and will probably work on the two fitness functions that you suggested. Next, Brevillance:
brilliant idea, though im curious. Does this thing compile and save information? For instance, when it comes to the conlcusion that a 7x7x7 space should be filled in such a way, will it save that data? When you think of clever bot everything that is ever said is kept and used to grow. For a \"genome\" project such as this wouldnt it be helpful for the program to understand where a 7x7x7 block should start rather then having to go through thousands of generations to get back to that same design? It could also help if it saved a bluprint of it for having it handy at a later date.
The version in testing supports saving and loading, but you have to do so explicitly, and the interface needs a small amount of work. However, if you find (for instance) that you need to shut the program down, it is currently possible to save, reload, and pick up from where you left off. I will definitely need to document this more thoroughly.
1. When you go to \"visualization\" i would love for the program to render every layer to have an \"underlayer.\" That is, the layer that came before, in a slightly watered down red, or a more pinkish color. That way, its easier to tell where to build (and makes it easier to keep track of where you should be placing blocks). Just something to help in building the reactor.
This is a feature called onion skin, and I have thought about the very same thing myself. When I get around to resuming work on this, count on it being a feature.
2. When you scroll through the steps, i think it would be a nice addition to have arrows for 1 layer up, and 1 layer down. This way, again, if it were to be a large reactor (i made one 100 in length) scrolling through each layer is less of a precision thing. Keep the scroll bar there if possible, but i think a quick +1/-1 would be a handy button to have indeed.
I don\'t see why this couldn\'t be added, or for that matter, why it shouldn\'t. I\'ll tweak the UI to contain something like this.
3. Less of a ease of use thing and more of a possible problem. When i click 9786, and then click 9999, it still displayed 9786 (in the visualization pane). Im not sure if this is a bug/glitch or a \"in the works\" deal, but if i clicked 9999 (assuming its the best out of all of them), it wouldnt show it. May be a problem when making large epoch cycles. (if you need more clarification please ask)
This is the same bug (I think) that Kupan mentioned; it has to do with the fact that the order of the reactors is changing with each step. The best rank, by the way, is rank 0; that is the one with the best power output.
4. For ease of use, a possible hover over or \"spoiler\" box for descriptions would be a nice addition. (for instance, mutation rate. What does higher numbers or lower numbers do to the formula)
Tooltips are something I do need to add, in addition to other forms of documentation. Part of the issue is that the program is nondeterministic; picking appropriate values can be a matter of experimentation, and I might be able to help people understand the model better by adding a page on the Wiki explaining it in some detail. Nonetheless, it can sometimes be difficult to predict what the best set of parameters is, as they all work together in some very subtle ways. But I will look into adding tooltips for the fields, as this should be easy to do.
5. Would i be possible to have a \"estimated\" power output or some such box at the bottom? i tried out various numbers, and 20x20x100 was what i stopped on, but i have no idea how much power it gives or how many power blocks it is. I can roughly estimate 20x20x100*.12 (.12 to accomodate emty areas, randomly selected number for sake of argument) but that wont give me a detailed idea. Possibly add a \"information\" tab that gives the total number of power blocks, empty space and theoretical power output, if possible. Just to have more info on the reactor itself because atm, it doesnt tell us much for large scale reactors.
This is in the current testing version; in fact, the visualization now has a table that (in addition to total power) shows individual power statistics for each reactor.
6. For the \"ranks\" i think it would be nice to re-word that to something more...easy to understand. im not sure if 9999 is the bottom or the top for example. If at all possible a change in the amount of blocks/theoretical power would be cool too, just to see the progress the forumla has made in making amore efficient core.
Yes, the terminology is probably a barrier to understanding it. The best rank is rank 0, and rank 9999 is the worst; so most of the time, you are interested in the top of the list. If anybody has a better suggestion for what this should be called, let me know!
7. When scaling the screen, there becomes a giant white empty square. I think a fixed frame size may help alleviate any excess space when scaling the program. (a banner, information about the program or something could go in this white box. But i would try to elimate that giant blob from showing up :P
Can you elaborate, or perhaps post a screenshot? It sounds like the visualization is not redrawing, but I am not sure. As for the frame size, it is supposed to be resizable on purpose, so that you can scale it to whatever size works best for you.
8. When creating a new \"genome\" (im not sure what youd call it) the box that appears for inputting data is always to small for me. I would suggest to locking that to being the size to fit all the inputs and no more, but no less because i always have to scale it, and its kinda annoying lol. (or you could make it remember the last size used, if possible.)
I could possibly do the latter; it sounds like you may be using the last stable release, which (contrary to the top post) is not the best one at the moment. But I will do my best to address your concerns here, since usability is very important.
Next, Hindos:
I\'ve been trying to use the reactor breeder program for some time now, however I consistently get the following error message when trying to open the .jar file:
\"Could not find the main class: com.wheefun.reactorbreeder.Driver.
Program will exit\"
That is extremely bizarre, and I am not sure why it is doing that. The manifest must be intact for it yield that error message, so perhaps it is the case that one of the classes is missing. Has anybody else encountered this problem?
Finally, Steelrose:
Interesting concept. Can you set it up so that it make better usage of multi-core processers? Also knowing that the program is attempting to use childs from the previous parents, is there a way to insert a stricter x,y,z preference into the code?
It may be possible to parallelize; the issue is that some tasks do not gain much from parallelization. Generally, we programmers shoot for something called linear speedup (where throwing n processors at the algorithm makes it n-times faster), but there are many cases where it is either not theoretically possible to obtain linear speedup, or that the sped-up algorithm does not scale well with different parameters. I have been considering the parallelization issue since the development of the program, and I am convinced there are some parts which can benefit from this, so the question is whether or not the gains will make it worth it.
As for X-Y-Z preference, I\'m not sure what you mean, but I am assuming you might mean the production of cleaner and tighter clusters. If you do, then the \"Max Block Dimension\" fitness function may give you what you want.
Lastly, thanks all for your enthusiasm and your constructive feedback! I will do my best to implement some of these changes and get a proper release out; again, sorry for the delay. Hopefully, I will be able to add some of the featues in the new release, and others may come in subsequent releases.
