Ivelieu

Thank you, SlotModified is pretty much exactly what I was looking for in combination with RegisterCallback. After thinking about it a while, I agree that it the process doesn't need to be centralized. I can think of edge cases where I might be transferring hundreds of itemstacks per tick and may want to use a lower-overhead approach for situations like that. That would be pretty far away, though. If I want to detect blocks placed/broken, items dropped/picked up, or other custom block entity activity in a large range (e.g. 10x10x10), I don't think I can rely on the existing behaviors API, but now I have a good idea of how it can be done efficiently with an event system. It would make sense to share listener k-d trees in a cluster, but even this can be decentralised. Although that optimisation is probably not necessary.

There's definitely a wide spectrum based on how the events are handled higher up, what I have in mind is not with a tick system under the hood. Certainly nothing like a TickListener. A specific example of what I have in mind: I have a machine next to an item pipe. The machine, because it has an item input inventory and a list of recipes, needs to do recipe checks to see if it can craft anything. Rather than check at some time intervals, it has public "notify inventory changed" function which causes it to recipe check. When the pipe registers a connection to the machine, it will notice the notify function and optionally store a reference to it. When the pipe wants to push an item to the machine and it knows the machine has capacity by checking its IInventory, it will insert the item into the machine, and then immediately calls the machine's notify function. The machine callback could internally ignore frequent updates in a small period of time; for example if it recieves 100 notify callbacks in 2 seconds, it might process the first callback, set a RegisterCallback for 5 seconds later, discard all callbacks it recieves before that time, then process its callback again after the buffer delay. One step further would be an option for the machine to instead provide a "notify delta" function that explicitly sends the list of transferred items to the callback. Having access to the delta list allows optimizing the recipe checks. The ultimate goal here is to be able to completely eliminate any tick function for both the machine and the item pipe, with the item pipe using a combination of notify callbacks and RegisterCallback delayed checks to attempt continuing a preexisting transfer over time. Machines from any mod can choose to opt-in to this event system or use a tick system. Why I'd want this kind of pure event listener system to be part of the base game or a core mod is for extending this to use k-d trees to scan events among a larger area for listeners to push to or cache, that could be used for a wider range of events like blocks getting placed/broken, or items dropped. In the Behaviors API for example I could use OnNeighbourBlockChange, but what if I want to detect changes that are further away? For even a modest area like 10x10x10 busy looping every tick becomes very inefficient by comparison. For checking multiblock controller formation there is also a world of difference between busy looping to check the structure is valid, versus having a callback to notify the structure was changed. My desire for this level of efficiency is motivated in part by seeing how inefficient big modded minecraft servers are; how it's technically a fixable problem there, but that game has far too much technical debt to realistically make big changes like this. It would truly be awesome to have tens of thousands of different machines active with minimal performance impact. What I mean by harmony seeming unsustainable is I can expect these things to probably get revisited in the core game and it would be unsustainable to repeatedly rewrite the hooks to be compatible with engine changes. Since these areas in particular I can easily imagine getting refactored in the base game.

This game has been in development for 10 years now! I've heard about it years ago, but it never quite seemed ready to devote a lot of time to modding. I've played a lot of very heavily modded minecraft and I was interested to see this game's potential for developing big tech mods equivalent to gregtech, applied energistics 2, enderio, thermal expansion, and the like. I decided to start having a proper look at it a few days ago, doing a survival run up to iron and finishing all the modding tutorials, and these are my impressions at the moment: The vanilla gameplay progression has great theme, immersion, direction and (where appropriate) realism. The in-world crafting is truly iconic, and the crafting systems are all well thought through. I do think it is excessively reliant on rng for progression though; cattails are a random spawn, clay is a random spawn, surface copper is a random spawn, underground ore is a random spawn, and I would like to see in future more ways like the prospecting pick and mounted tamed animals to mitigate these sources of randomness tied to progression. json with variants is a very well designed system for adding recipes, tools, items, mobs and blocks. I can see there's this big desire to make as much as possible available without code mods and it is a huge improvement from modded minecraft. The VS model creator is not perfect but it's getting meaningful attention and there is a huge number of really high quality textured, animated models in both vanilla and mod db. Blockbench compatability seems a little unclear to me (I can see many people who've given it a go, but there seems to also be missing features/bugs) and I hope it works out. The vanilla mini/map and handbook are great inclusions, but miss a fair bit of feature parity compared to the innumerable nei/jei forks. This need is filled to an extent by a couple of small mods(tei and improvedhandbookrecipes), but there is from what I can see no substantive autocrafting (think AE2) in this game. That being said, this is a ripe area for modding, but there are some missing features from the API's recipe system (I was lucky to get a quick developer reply on the discord confirming these missing features) that would make large scale modding difficult. The provided patching system can change virtually anything in a content mod, and virtually nothing in a code mod. I have not used harmony before and it does not seem a sustainable option to fill gaps. Map sizes are huge on disk and even vanilla eats an insane amount of ram (I don't understand why, if it is mostly cached atlases, shaders, or something else). There is a lot of diligent work to fix memory leaks, and it does run at a high framerate, but it calls into question how viable it would be to hypothetically have thousands of machines, some multiblocks, all with their own entities, some with animations, doing many recipe pattern lookups and running simultaneously. Ideally, I was hoping this game's API would be amenable to an event-listener-subscriber system for core entity functionality (like what is done in AE2) rather than a tick-based system that minecraft almost entirely uses, but it's not clear to me how much engine support there is for registering custom event listeners/subscribers. There is no dimension (e.g. nether) system and adding one seems a herculean task unlikely to ever happen. Genuine distinct biomes of some form seem on the roadmap but far away. Networking serialization is really easy! No point and click GUI designer is rough. The api-provided multiblock system is limited to 5x5x5 and pollutes the item ID space. It's true that people have worked on making core mods for multiblocks (in vintage engineering) and electricity (vintage engineering + electrical progressive + older ones) and they have come very far in only a couple of years. But this game still seems very far away from something with equivalent feature parity to minecraft's modular machinery, with recipes and multiblock templates of arbitrary size and shape that don't cause endless problems on loading/unloading chunk boundaries, can be generated using ingame tools and share optimisation benefits. I see no straightforward ways to change world gen algorithms significantly (biomes, terrain shapes, cave generation, rather than just adding structures or replacing blocks) and I am reluctant to try patching with harmony to make it work. Regarding the vintage story roadmap, I can see modpacks, improved performance, animals and more methods of low-tech crafting are on the horizon. I can see some of this making it easier for me to make my dream mods. I can also see that the low-tech theme of this game is a central aspect, and I feel that my wanting to turn it into a tech progression modpack is unaligned and only tangentially possible in the game's vision - what draws me in the most is the hugely modding-positive culture. Did I miss something? Did I get something wrong? What do you think about the future of large scale tech modpacks in vintage story?