Extending factorio-mod-api

[Builditluc]

Hey @MForster,

in the last few days, I've looked at some factory mod managers but all of them were either archived or the last commit was made years ago. I'll have to write my own mod manager I thought, but then I've stumbled across your repo.

I wanted to know if I could contribute to the factorio-mod-api and the factorio-cli respectively. I have some experience in rust (currently working on something called wiki-tui), but I'm still learning so I'll give my best and a bit more. I would also love to throw some ideas out in the wild if that would be okay.

- @Builditluc

One more question though. Have I understood correctly that the factorio-cli serves as an interface for the mod api and the exporter? So when adding new features to the mod api we have to update the cli.

[MForster]

Hi @Builditluc,

yes! Contributions are welcome.

Let's not worry too much about the CLI. The only reason why it exists is as a test bed for the libraries. I don't think that it has to support all features of the mod api. I just added an interface for every api feature, so that I could play around with it. As long as we don't break the CLI, it's totally fine to add API features that it can't exercise.

My primary goal is to build a fully automatic recipe calculator/analyzer where you can specify mod sets declaratively, and it does the dependency resolution, and download for you.

What is it that you would need from factorio-mod-api? My intention for that crate was a rather direct Rust implementation of the Mod Portal API (including downloading mods) and the Web authentication API as a dependency. I might also want the DownloadAPI, but I haven't fully decided on that, yet. Do you need any of the others? The current status is that the "full" info and downloading works, the rest doesn't. But it's also not fully spec-ed out or tested. I'd be happy for you to help fleshing that out.

Would that vision match what you need? Any ideas beyond that?

[Builditluc]

The only reason why it exists is as a test bed for the libraries

Ah okay, so it's just used to test the API libraries.

My primary goal is to build a fully automatic recipe calculator/analyzer where you can specify mod sets declaratively, and it does the dependency resolution, and download for you.

Oh wow, that sounds great! I thought of some sort of package manager thingy that lets you install mods and also self-defined modpacks but that is even better. Maybe we can add features to the cli (or create another one) that applies change like the way nix does it.

What is it that you would need from factorio-mod-api?

Just downloading mods and searching, but you're right. It would be better to create a direct rust implementation of the API and then create some sort of "frontend" that implements it.

I'd be happy for you to help fleshing that out.

I would love to do that! I have some ideas/questions regarding the code format. I think that the structs of the library (ModMetatada, FullModSpec) should be returned so that the user can deal with them more easily. I think I would create another issue, then I could explain / we could discuss it better. Or is this structure fixed?

Would that vision match what you need? Any ideas beyond that?

Yes. More than that. I don't know, I think it would be also cool to have some sort of library where we can read / load blueprints or manage to save them. So for example, if we have factorio-blueprint-api that can interface with the blueprints stored in the user factorio folder, we can write programs that automatically backup blueprints or maybe download them from a third-party site and store them.

[MForster]

I thought of some sort of package manager thingy that lets you install mods and also self-defined modpacks but that is even better. Maybe we can add features to the cli (or create another one) that applies change like the way nix does it.

I'm happy to start experimenting with that, either in the CLI, or in a new one. It's ok if the vision evolves over time.

The one thing I do like is that I'd want all functionality available in well-structured and cohesive libraries that can be accessed programmatically. For example, I'd see that you'd want to use the "mod manager" features from a command line, as you say, but then a calculator/analyzer needs to access a subset of those features as well. So my initial focus is on the libraries.

Same with the "exporter" library. I suspect that a "blueprint" feature would also need some of that, because blueprints will contain the entities that get exported by the exporter.

I have some ideas/questions regarding the code format. I think that the structs of the library (ModMetatada, FullModSpec) should be returned so that the user can deal with them more easily. I think I would create another issue, then I could explain / we could discuss it better. Or is this structure fixed?

No, the structure is not fixed. There wasn't even too much thinking that went into it. The main thing is that I tried to build the structs in a way that they can be shared between the three APIs (only one of which is implemented at the moment).

Yes, please go ahead and file targeted issues. I think I should do the same, actually, for the things that need further design. For example, the resolver is rather limited at this point.

[MForster]

I'm going to close this issue. Let's have follow-up discussions on targeted issues.