Code center > Suggestions

Should we do away with settings files?

(1/5) > >>

EricL:
Settings files today are essentially a sim file without the bots (and without shapes and teleporters and so on).  I think one of the original intents was to provide a meachanism for saving an 'empty sim' that could be used as a starting point over and over with different organisms.  Perhaps also as a small size way to pass around settings and also to re-loaded the settings used at the last exist so settings are "sticky"

To be clear, it is currently *not* the set of settings (such as poff shots on/off, impact dots on/off, etc. ) that are sim independent.  I will likely propose something on that issue separatly - this poll is about the utility (or lack there of) of user savable/loadable settigns files).  But today, settings files are basically a sim file, but without the bots and other stuff.

Personally, when I want to start a new sim with the same settings as an existing one, I load the existing one and then "Start New".  If I want different organisms, I delete the species and then start new and then add the new species.  Basically, personally, I don't use settings files at all.

Most of what the default.set file has been used for in the past I.e. setting reasonable default settings, has recnetly gone internal to the code and future versions will likely do away with default.set independent of whatever is decided here (indeed, as of 2.42.9, a default.set is no longer necessary).

As above, the concept (though perhaps not the actual implementation) of a lastexit.set is worth keeping in that I think it makes total sense to re-load the program using the same settings that were used last time.  So, independent of this decision, program settings will continue to be "sticky" across invocations, though I may do it with sim files or registry settings or something else instead.  And yes, I know there are gaps with this today - settings that don't carry accross invocations becuase they are not put into the settings files at all.  I will address this soon.

But personally, I think having user saveable/loadable settings files AND sim files is confusing, particularly since sim files can pretty much be used instead of settings files.  I may be missing something, in which case I'd love to hear what, but I would like to do away with settings files in the code, in the UI, etc.  It would be less confusing to new users and make the new self-contained setup code I'm working on easier (one less directory to create, etc.)

Numsgil:
I'd like to see the settings files altered in the following ways personally:

1.  Non sim related options should be seperated.  This means things like internet sharing settings, database recording, etc.  They need to be seperate so that people can quickly make different simulations and have them use similar connection settings, or database recording techniques, etc.

2.  Robot DNA files need to be included in the settings file.  This would allow settings and simulations to be shared across users more easily.  At the moment, if a simulation tries to repopulate a veggy that's not in another user's robot files, it crashes.

It would also be nice to be able to load any robots in a sim into your robot folder.

Sprotiel:
For me, settings files are simulation templates, and therefore a distinct concept from sim files. In concrete terms, if I load and run the same sim 10 times, I expect to get the same outcome every time, while if I do the same with a settings file, I expect 10 different outcomes. Also, the way you use sim files to get settings seems rather contrived to me and I wouldn't really like to have it imposed on me.
I don't much like the idea of hardcoding default settings either.

I agree more or less with Numsgil's points, though I'd find it more practical to keep autosave names in the settings file: it's not something that affects the simulation, but it's still something I like to change every time I start a new one.

EricL:
It is precisely because settings files are supposed to be sim templates that I think we should unify the two concepts.  Sim files contain everything settings files do plus a lot more.  This more includes both extant organism information and various sim artifacts that are not stored in the settings file today.  Perhaps if we added an option to save a sim without the live state such as the extant bot information or load a saved sim as a 'template' I.e. paused, without the extant organism information...

Shapes and teleporters and internet settings are not saved in settings files today (internet setttings use their own file).  Should they be?  If you say "yes, they are part of what I think of as a sim template" then I would ask besides the extant organism information, what is the difference between a sim and a settings file supposed to be?  We should just use sim files and add whatever load/save options are needed.  If you say "no, I don't think of those things as part of a sim template" then I don't see how a settings file can be thought of as a sim template.

FYI. loading and running the same sim over the same period of cycles 10 times over will not and should not give you the same result each time.  Random numbers are used all over the place - for mutations, for bot placement, etc. - and the seeds are different every time.   DB is nondeterministic by design.

I completely agree with the comments about bot DNA files going into sim files.  I will work on this.

I also agree about non-sim settings being separated to a point, but this is not what settings files are today.

To be clear, the internal defaults I refer to are only used for first time users, replacing default.set, not lastexit.set.  I have some recent settings to add still, but if you change a setting and exit without saving, that change will and should still persist for next time if you start up without a sim.

Numsgil:

--- Quote from: EricL ---FYI. loading and running the same sim over the same period of cycles 10 times over will not and should not give you the same result each time.  Random numbers are used all over the place - for mutations, for bot placement, etc. - and the seeds are different every time.   DB is nondeterministic by design.
--- End quote ---

This is true only if you don't seed the random number generator.  If you do that, the simulation will run identically on every instance.

However, even seeding a simulation, if you save and reload it, you'll get a different result than if you save and keep running it.  The random number generator loses its current state information and gets "reseeded" back to the start of its sequence.

Navigation

[0] Message Index

[#] Next page