Using GLOBAL.ModManager when adding recipes?

[outseeker]

Just wondering if anyone can advise me here- when adding custom recipes to the cookpot or to recipe tabs in general, do we need to interact with ModManager to ensure all custom recipes play nice together? or is the client's inability to craft custom items I constantly find caused by something else I can somehow remedy?

 

Specifically at the moment I'm looking at The Gentlemen's Mod (aka Tungsten mod). It works perfectly well on its own but when I enable all the other mods I want, clients can't build the custom items any more. It just does a bit of the animation for building and stops dead.

 

When I only enable the Tungsten Mod and one other custom recipe mod, it's ok. For example, I can enable DST Freezer mod and clients can craft everything; if I then also enable DST Advance Farm though, clients can no longer craft any custom items. Same goes if I try to add Craftable Gears instead of Advance Farm.

 

I have a poor memory but I remember something about the clients having a recipes list in a different order or something, causing them to attempt to craft the wrong item according to the server, resulting in nothing being crafted, but I can't remember if there's anything I can do about it.

 

Thanks <3

Edited January 25, 2015 by outseeker

[rezecib]

@outseeker, Recipes are a little broken right now. Basically what it's doing is each time a recipe is created, it gives them a sortkey; starting with 1 for the first recipe, and increasing by 1 each time.

 

When a client says "I want to build a firepit", it only sends the sortkey to the server "I want to build recipe 46" (or whatever the sortkey for firepit is).

 

The problem with this in terms of mods is that they might load in a different order on the client and the host, so let's say the client says "I want to build a tungsten spear", so it tells the server "build recipe 224"; the server says "um... recipe 224 is health potion, and you don't have any red mushrooms, so nope!".

 

Edit: About the only thing you can do about it is hardcode sortkeys... but this is still susceptible to clashes, since there's no organizing body of mod developers keeping track of what sortkeys are hardcoded. If we had an organizing body though, it would probably be better to have every mod have a different priority so they load in a consistent, predictable order.

Edited January 25, 2015 by rezecib

[outseeker]

That was the gist of what I could sort of remember reading, ty for the clarification @Rezecib

 

I am kind of considering (something perhaps way above my abilities, but interesting all the same) making a mod to sift through recipes, identify custom ones and match up sortkeys somehow; worth pursuing do you think? or better to just chill out and see how Klei handles it?

I know I can check to see if a mod is loaded / which mods are loaded, though I don't necessarily understand the method behind the order in which things are assigned their sortkeys- is it simply the order in which the mods are loaded and the order in which the recipes within are added? So I could read the host's recipes, revert client's recipes to default and then re-add the custom recipes to clients in the same order as the host?

 

I figure I can give the theorhetical mod the lowest priority to have it load last, or maybe just hook into the add recipe function to make a temporary table, then do the comparison and reordering upon player join?

Edited January 25, 2015 by outseeker

[rezecib]

@outseeker, Hmm, interesting idea. Recipes are all uniquely keyed by their name in a (local) AllRecipes table. So you could probably just run a sort on that which resets all the sortkeys (setting your priority really low or embedding it in a function that runs later on in the Sim, e.g. AddWorldPostInit), something like this:

local recipenames = {}local last_default_sortkey = AllRecipes.book_tentacles.sortkeyfor k,v in pairs(AllRecipes) do    if v.sortkey > last_default_sortkey then        table.insert(recipenames, k)    endendtable.sort(recipenames)for i,v in ipairs(recipenames) do    AllRecipes[v].sortkey = last_default_sortkey + iend

Klei might do something like this themselves, but I'd guess they're looking for a more robust approach. I think the recipe system needs a bit more of an overhaul, seeing as how the old practice was to put recipes in character prefabs, and now that's a guaranteed way to mess up the client-vs-server recipe tables.

[Jjmarco]

@rezecib, this is assuming book_tentacles is the recipe with the highest sortkey, which may change if an update adds more recipes. But I guess there's no other ways of doing it until Klei does something about it, and it's pretty unlikely that they'll add any new recipes until then anyway. Otherwise, I believe this may work!

 

[rezecib]

@Jjmarco, Yep, meant to explicitly say that somewhere but forgot. That's one of the things that makes this approach not so robust

Edited January 25, 2015 by rezecib

[Jjmarco]

@rezecib, I just thought of something: why not just sort the whole table instead of just the mod recipes? Like this:

recipenames = {}for k in pairs(AllRecipes) do    table.insert(recipenames, k)endtable.sort(recipenames)for i,v in ipairs(recipenames) do    AllRecipes[v].sortkey = iend

If you do this the same way on both the clients and the host, this would work just as well without needing to know the last default recipe!

[rezecib]

@Jjmarco, It would work, but it would also completely change the ordering of the recipes in the tabs. Since... that's what sortkey is for. It's just now been lumped into a role for networking, too, which should really be separated out at some point.

[Jjmarco]

@rezecib, Oh, I see. Didn't thought of that. Oops.

[outseeker]

@Rezecib, @Jjmarco, This is going to be some fun!

I don't quite understand though why we need to know or even directly look at any of the sortkeys though; can I not simply overwrite the whole table for each client as they connect, with a full copy of the host's table?

Edited January 26, 2015 by outseeker

[rezecib]

@outseeker, Because sortkeys also determine the order that recipes show up in the crafting menu. I would guess most people who play a lot get pretty familiar with the exact location of recipes, so that would throw them off a lot.

 

So my code is only reassigning sortkeys for recipes added after the last recipe in the game files, to preserve the ordering for those.

[outseeker]

@rezecib, hmm for the issue of robustness though? and why would the client's crafting menu item order differ massively? It's surely like 1-2 items near the end of the list that may be in a different order to what they're used to?

Edited January 26, 2015 by outseeker

[outseeker]

Still not entirely sure why mod recipes would ever have a sort key indicating the mod recipe should take the place of a default game craftable; mod recipes always come after all default recipes in the lists?

[Jjmarco]

@outseeker, well, sending the whole recipe table would be pretty inefficient, as it's a fairly big table.

It's better to only reassign sortkeys of mod-added recipes the same way on both the host and the clients, so the sortkeys match.

The only problem, though, is indeed the fact that there is not way of knowing what is the sortkey of the last default recipe on the fly, but I don't think that's too big of an issue for now.

[rezecib]

Still not entirely sure why mod recipes would ever have a sort key indicating the mod recipe should take the place of a default game craftable;

 They wouldn't. But with multiple mods with recipes, the sortkeys for the mod recipes could be misaligned. That's why this bug only shows up if you have multiple mods with recipes.

 

Example:

Mod 1 on server adds health potion (120), tungsten spear (121)

Mod 2 on server adds fish farm (122)

 

On client, mod 2 adds fish farm (120)

On client, mod 1 adds health potion (121), tungsten spear (122)

 

So the client tries to build a health potion, and the server thinks they want to build a tungsten spear.

Edited January 27, 2015 by rezecib

[Maris]

prioriry = 0.00123456789 --where 123456789 is the steam id of the mod.

​

[rezecib]

@Maris, That could work. A temporary solution to the recipe problem could be to have that be the default priority of a mod, instead of 0 (I think that's what it defaults to, now).

[outseeker]

prioriry = 0.00123456789 --where 123456789 is the steam id of the mod.

​

 

 

mm on first impression, I like dis- seems simple, though we would then need some kind of consideration given to mods that actually require a priority in order to apply their changes properly at the right point.

 

I think it's pretty clear that it's going to be easier for the Kleichamps to implement something rather than us modify things via mod after the fact; really hope someone has the spare time and motivation to do so ASAP.

 

I never say anything is urgent really, but I think we can all agree this is pretty game breaking? I don't have any stats to back this up but I feel that most of the people playing lots of DST play it with mods.

[Maris]

we would then need some kind of consideration

 

Mods with priority > 0 will be first. They will take first numbers for their recipes. Only mods without priority probably will be broken.

​ 

[Maris]

I noticed that people add this string to a wrong file.
It should be added to modinfo.lua, and NOT to moadmin.lua

[outseeker]

I noticed that people add this string to a wrong file.

It should be added to modinfo.lua, and NOT to moadmin.lua

 

What's that? People are declaring priority in modmain instead of modinfo? Relevant to the ordering issue, or just another observation?

 

I would really love a workable solution to this issue in the short term..