Instant Crafting

by Tixout

Makes crafting instant, but not free

Content
5 years ago
0.16
56
Cheats

i Code optimizations...

5 years ago

Not that i want to spoil your modding experience. But instead of trying to reimplement ingredient consumption you could simply use LuaControl.character_crafting_speed_modifier (or the force equivalent) to give the player a very high crafting speed (e.g. 10000). Which would be far less code :p.

5 years ago
(updated 5 years ago)

This is in fact what I was doing at start. The issue with doing so is that crafting is not instant and is actually capped at one craft per tick (as far as I observed). Getting a a higher crafting speed only allows for reducing crafting time down to one tick. When crafting a whole lot of items (as I like to do) it can sometimes still takes a few seconds to get them (like, 20 - 30). So i decided to mod that.

However, you are right saying that re implementing ingredient consumption is a tad overkill. I recently found a way to do it otherwise and am currently working on it :)

5 years ago

Ah yea, the speed limit. There's always a caveat to everything. :/
Makes me wonder what your solution is. I'm not aware of a way to cancel the crafting queue without getting the ingredients back, so maybe some black magic with temporary enabling cheat mode which doesn't have a speed limit?

5 years ago
(updated 5 years ago)

I just rewrote the mod to be more efficient and to use the built-in events much better. To be short, whenever the player queues a craft, it get cancelled. On the craft cancelled event, I store in a list the products that were to be added if the craft was completed, and the ingredients the game is trying to add back into the player's inventory. Then, out of the event (actually is the pre crafting event), I add / remove these items from the player.

They code is way more clean right now, and as you have coding experience you should easily understand what I did.

No magic, no original idea, just a simple tweak.

5 years ago

I see. Not a huge fan of the use of that many globals (both global functions and "global") but better than before i guess. Not sure if you won't get race conditions when several players craft in the same tick. You should at least =nil the "global." storage after it has been processed once. To use local functions you need to define the functions before using them in script.on_event(). (No idea if you have sufficent coding experience to understand what i'm talking about, so don't be afraid to ask.)
Also with adding products before removing ingredients i bet there'll be some mod that causes spilling due to large number of output items. Adding after will cause problems with sub-crafting though. I did use a temporary inventory size boost in the past to prevent that. (i.e. char_inv_bonus + x, dostuff, char_inv_bonus - x). But then you have to care for controller types. (Also i wouldn't be suprised if there were weird cross-mod interactions when another mod starts to cancel crafting due to earlier load-order. Fear! Uncertainty...and Doubt! :p)

5 years ago
(updated 5 years ago)

I am also against global variables and global functions. I just did not bother looking up on the internet how to manage the scope of functions in Lua. I will modify my code to be more inline with good uses of functions, thanks.

Also, for global variables, i couldn't find any other way to solve my problem. The issue is that the cancelled crafting event is triggered before the items are added back to the inventory, and I have no way (as far as I know) to temper with that. Thus, as I wanted to simplify my code and use the parameters given in the cancelled crafting event, I went with the global variables. However, you are right and my management here is lacking, i will as you suggested turn them to nil at the end.

I am not sure about what you mean by race condition however. I would instinctively think about the fact that several mods may be triggering on a same event and therefore, if the processing were to be too long, my code might be interrupted. In this case, I would have yet to think of a solution, but I have never encountered that yet.

Finally, you are once again right with adding and removing and this reminds me that i did not handle sub-crafting. I will work on that also. When it comes to cross mod interaction, there aren't many mods out there interacting with crafting that I know off (and none that I use), so I will have to do case by case bug fixing. One of them is handyhands, and it will not work with my mod. I plan on making a compatible copy in the future.

Thanks a lot for your feedback, it is really helpful to receive especially from an experienced modder :)

Edit : For item spilling, I do not think there is an easy fix for it unfortunately. I will look into it but i would rather not have to spend too long on such a simple mod. The one you mentioned is partial as some sub recipes might produce more than the parent recipe uses.

5 years ago

Managing scope is trivial. You just put a "local" in front of the function definition so it becomes "local function blabla(a,b,c)". The only thing that changes is that you need to put the script.on_event at the "end of the file" to that it can "see" the local functions (the technical description is that the local function becomes an "upvalue"). I.e. every function has to be defined before it is used.

Writing code that tries to "connect" two events like you did is always a pain. And "global." is a good place to store the intermediate values. It's just not a "nice" thing to do in the first place. (And if i had a really good idea to solve it better i'd have already written that :p.)

Race conditions /could/ occur because every event is sent to every mod that listens to an event, so there's no guarantee that you're the first to get the event, even if you yourself cause it by canceling the queue. That was more of a theoretical comment, as it depends on too many factors to be generally solved (unless you want to go back to handling everything in a single event).

The buffer solution i suggested (i.e. increasing the inventory by i.e. 100 slots while processing) was meant to provide some specific intermediate spilling cases, ofc it can't prevent spilling if the end result of the craft produces too many items. But it's not really nice if it can't be removed before the tick ends because then the user might see it. Btw vanilla seems to do that now, it stops crafting when the result wouldn't fit. Which i love because i think the whole concept of spilling is a design failure :P.

But ofc one can overengineer everything. I guess if your goal is to cover most cases and at least not delete/create items out of thin air that's fine :).

Also thanks for the thanks, not everyone appreciates feedback.

New response