Auto-evo exploring tool

Programming
29

Got the hex

image
image1712×1022 136 KB

1 Like
30

That can be exclusive to the exploring tool. I don’t foresee it being a wanted feature elsewhere, at least for now. But putting it in its own scene and script would be helpful in case anyone ever wants it to be available somewhere else as well.

31

What is ‘history’ on the side? Do you mean ‘generation’?

32

I turned to directly use PhotoStudio, but multicellular editor generates light cells image Exploring tool generates dark cells like this

image
image839×1249 30.1 KB
Why?

Anything wrong with the generation code?

        if (previewSpecies is MicrobeSpecies microbeSpecies)
        {
            task = new ImageTask(new CellType(microbeSpecies.Organelles, microbeSpecies.MembraneType));
            PhotoStudio.Instance.SubmitTask(task);
        }

EDIT: I switched to use new CellType(microbeSpecies) and now it works.

33

I think instead the microbe species should be made IPhotographable than trying to use a later stage feature to create images of them here.

34

image
image1618×976 128 KB

What about this one? (Compared to the previous viewer)

(I’m so amazed to see that auto-evo has added a nucleus)

35

I assume you can only select a single species to view at once, which would mean that radio buttons would be the right GUI control to use and not checkboxes. Does Godot not have radio buttons?

36

Thrive theme has no radio buttons.

37

Someone should request them, then. Also I’d rather use the right control type even if it is unthemed. The theming can be easily enough added in a later PR.

38

And in Godot, CheckBox and RadioBox is the same thing. When a CheckBox is assigned with a ButtonGroup, it turns to a RadioBox. When I wrote CustomCheckBox, there was no radio box related texture so I just ignored that part.

APPEND: Will make a pr after radio button textures are added so that CustomCheckBox turns to CustomRadioBox.

1 Like
39

Here goes the auto-evo exploring tool part II.

Things that I’m going to do:

Design problem I’m facing now:

  • With the world-control buttons added, I’ve got nowhere to show stats… except in a new tab.

image

  • Should we save all data for each world for viewing? Or we only save key data? (Then which are those?)

  • Same problem for exporting. I need someone who is dealing with auto-evo to tell me what data you need and what you don’t. Or maybe I can make a popup (or even another tab) for users to select what they need?

3 Likes
40

It might be good for you to look into my predation PR. It hooks into a system that already exists. It might be better for you to create a similar system (That would probably be best for me to use as opposed to the current one.) It’s the best method I could find at the time to pass info from an auto evo run to a species.

Doing that was quite annoying as auto evo is very sectioned off from everything else.

41

And for the data, I really want the option to be able to dump as much data as possible, though that definitely should not be the default.

1 Like
42

image
image1285×724 58.3 KB

Idk whether these are enough. (Surely not because multiple-worlds ones haven’t been implemented.)

Update: Settings are merged into a menu button.

image
image1208×687 46.7 KB

43

I think a new tab or a popup would be a good idea.

I mean for a csv file, wouldn’t it be better to just dump everything and whoever is dealing with the file can then just ignore some columns if they want. I think it would be a bit of a wasted effort to make a GUI for selecting which columns to export.

44

I put a sample output folder (zipped up) in programming channel. There are literally too many things to export, and many of them can’t be easily put into a spreadsheet.

Such as: Map → Patches (This can be row header) → Basic stats (This can be column header), Species in patch (This is dynamic so I wrote some code to generate it) → Species stats (I have nowhere to put this); → Patch history data (So does this)

45

I see, so the problem is that the data would fill multiple tables?

Then maybe it makes sense to select the dataset to export. Or maybe we’d need an ods file exporter library (I don’t want the game to export in a proprietary format).

46

That would probably be better.

Could you put some of them into json files? Not everything has to be csv. Also, for many of these, the format you chose is not great. If you agree it might be worth it for me to go through and change the way stuff is outputted. For example, per patch history could easily be two tables with fewer columns.

47

One other thing I also thought of is that what if the export was done by selecting a folder in which the game would then dump various separate .csv files with specific names? That way the problem of dumping data that doesn’t make sense to be in the same table can all be output at once with minimal effort. I imagine that arrangement would also be pretty good for example using python to process the files in some way as such a script would just need just a path to the folder to find the various data files in.

48

It’s currently dumped in a ton of different tables, as you would see in that zip.

On second thought, maybe I should reformat the tables to show, at least what I think, is best. I would struggle to describe it, but I see a few ways they could be much improved.