Groovy-fying the Simulation Supercomputer (and making it parallelizable)!

[AncientShotgun]

Nomi CEu Version

1.7-alpha-2a

Related Problem

I saw that the Simulation Supercomputer Multiblock (internally known as 'dml_sim_chamber') was still defined using MultiblockTweaker in this pack version.

Your Solution

I decided to rewrite the class and the recipe registration in Groovy instead. I also elected to code it as a GCYM multiblock so its operation can be easily and natively parallelized with GCYM's own Parallelization Hatches; no need to fiddle around with the Workable or coil tiers. I didn't want to clone this entire repository and then pull it onto my local system; this wasn't a large enough job for that.

How Will Your Solution Work

Enclosed here is a .zip archive containing two .groovy files: The class file for the Simulation Supercomputer controller; and the recipe registration functions. They are quite prototypical and will require some work to complete and implement, but I hope your team can make something out of them.
dml_sim_chamber_class_recipes.zip

Alternatives You've Considered

No response

Additional Information

I also engineered a formula statement to computationally calculate the percentage chance of receiving a pristine matter from any tier of DME data model; this formula can be found, commented-out, in the dml_sim_chamber_recipes.groovy file in the .zip archive I provided.

[IntegerLimit]

Unfortunately, we do not use groovy multiblocks, we use Nomi Labs instead. Its already implemented there, but it is not parallizable; although that would be pretty simple (as I learned from my endevaours in the greenhouse).

I am interested in your pristine matter thing. Will look at this later.

[IntegerLimit]

Moving to Nomi-Labs.

[AncientShotgun]

Keep in mind the formula assumes that the lowest tier of DME data model available is 'faulty' and this tier has a 0% chance to produce pristine matter. If it is not, notify me by commenting on this issue and I will provide an updated formula.

Does your team intend to use Groovy for recipe definition? If so, my next project is to code a Groovy snippet to scrape the DME config JSONs and extract model metadata directly from the configs for use in recipe definition.

[IntegerLimit]

Recipes, yes will be in Groovy.

[AncientShotgun]

Have you already solved the "increment the data model by one kill on simulation completion" problem for the Simulation Supercomputer? I have a solution if you're interested, but it might be one you already tried/found. I'm also not sure how deterministic/thread-safe it is. I'll expound upon it in a new Github issue ticket if you want to hear it.

You'll also want to make sure that only one data model exists in the input inventory at the start of each recipe process, so the multiblock doesn't perform non-deterministic processing behaviour. Programmable circuit or custom RecipeLogic, perhaps?

[IntegerLimit]

Have you already solved the "increment the data model by one kill on simulation completion" problem for the Simulation Supercomputer? I have a solution if you're interested, but it might be one you already tried/found. I'm also not sure how deterministic/thread-safe it is. I'll expound upon it in a new Github issue ticket if you want to hear it.

You'll also want to make sure that only one data model exists in the input inventory at the start of each recipe process, so the multiblock doesn't perform non-deterministic processing behaviour. Programmable circuit or custom RecipeLogic, perhaps?

I have not. I am interested in your solution.

[AncientShotgun]

The solution writeup is now in the 'issues' list for this mod's Github repository, prepended with [Enhancement]. Warning, it's quite long and thorough, but I have a tl;dr at the start. I also found a couple of additional problems that would be faced if your team wanted to make the Simulation Supercomputer perform exactly like the DME Simulation Chamber singleblock.

[IntegerLimit]

Implemented in bc138df.