-
-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Indicate which mod was used to create each blueprint. #19
Comments
Should we consider having the user enter which mods were used? I guess they could do tags for that. |
I do want to display which mods were used. I'd rather not have the user have to enter them. Take a look at this blueprint as an example. https://factorioprints.com/view/-KYeFKED3KeFyTMyexzO Now that we're parsing the blueprint string, we can see all sorts of entities that aren't in vanilla. The title says Bob's so I know some entities come from there. But since I don't play Bob's myself, I don't know if all entities are from Bob's or if I need more mods. I feel like it can be as simple as a map from entity name to mod. Keeping the reference data up to date would be a pain. BTW, this is why I don't use factorio-blueprint by @demipixel even though I really like it. It halts when it doesn't recognize an entity name. If you're laying out a full blueprint spatially, you need to know dimensions of every entity. But I'm just using the entity names, so I don't want to have to configure every possible entity up front. |
I don't think that factorio-blueprint supports books anyway. Unless the blueprint or blueprint book itself contains information on which mods the user has installed I wouldn't go down this road. If you create some sort of mapping of mods to entities you'll forever be broken whenever the mod changes an entity name or adds a new entity. It's nice that it displays information from the blueprint on the page, but really when someone adds a "Bob's Blah Blah Blueprint" it points to the fact that the user needs Bob's mods. If anything we should just offer tagging so people can label the thing as "Bob's mods" |
Using the same blueprint as an example, we'd presumably have static reference data like this.
For every entity in the blueprint, we'd look up the mod. If the key is missing, we'd map it to 'unknown mod' I guess. Then we could come up with a distinct list of mods. Let's say 'y-inserter-fast' is either new to Bob's or in another mod so it gets mapped to 'unknown-mod'. We'd say this blueprint includes entities from Vanilla, Bob's, and at least one unknown mod. We'd need to keep the list of vanilla entities relatively up to date, but there's no pressure to keep all mods up to date. |
No need to keep vanilla entities up to date, vanilla should be assumed, no special stuff needed. What needs to be kept up to date is normal entities from other mods, like power poles, belts, assembly machines and inserters. Ultimately, it won't be a problem if we miss something because defaulting to vanilla is just as good as what we have now. |
It's probably worth reaching out to Bilka, the wiki admin, about this. There is lots of automation behind the wiki and I wouldn't be surprised if there's one to extract all the entities from a modded installation. |
Now that we're parsing the contents of each blueprint, I can see that blueprint books created by different mods have differences in their content. It's possible that an export from one plugin won't import cleanly into another plugin. It would be good to look for the differences between the data and indicate to the user a guess about which mod was used to create the blueprint.
We could also consider displaying the decoded data to the user, or just logging it to the console as a json object.
The text was updated successfully, but these errors were encountered: