Well, you'd need a way for the player to tell you want they want to 'buy' (the selling part could be as easy as whatever is placed in an "exports" chest, or as 'complicated' as the buying). There are a couple ways that I can think of off the top of my head.
- Remote interfaces (annoying to use)
- GUI with textfield and/or buttons (see TestMode)
- An entity with filters (or circuit conditions) and getfilter/setfilter, getrequestslot/setrequestslot, and/or getcircuitcondition/setcircuitcondition (depending on entity/filter type).
Obviously choosing the entity type that you use matters, a requester chest could interfere with the player's network, whereas a new 'smart' inserter probably wouldn't and would allow using both the pickup filter and the circuit conditions as an interface for the player.
I'd probably use the GUIs myself for a couple reasons. Doing so lets you stay consistent with other features that you might want to implement later (instead of using various different hacks that could confuse the player when they try to interact with them), they're more flexible since you write the code that interprets the data (precise values for how many items for example), and they are likely to be improved eventually anyways.
Xecutor wrote:All this happens periodically, like 4 times a day, for example.
a simple "if event.tick % some_constant == a_valid_result then runImportExports() end", within ontick allows that. some_constant would be the number of ticks in a day (I... don't actually know that, it'd be the number of seconds * 60 though) divided by the number of times in a day you wanted it to happen (and a_valid_result would be in the range (0, some_constant-1) since some_constant % some_constant is 0). and runImportExports would of course be a function that checks "import" and "export" chests (found and stored in the glob table via onbuiltentity) against the import/export data (also stored in the glob, but from the GUI) and inserts/removes as necessary.
Xecutor wrote:I hoped to calculate prices for resources based on mining hardness and prices for other items based on cost of basic resources multiplied by production time and may be some constant.
if you are implementing only a small number of trade items then you can do that with hard coding, but if you really want it to
work then you'd need a way to get those values during runtime. The only way that I currently know is the hack I described earlier and used when creating the framework for DyTech's
modular tools, and in this code I wrote for a never released
belt replacer mod (the other side of that code, to read the recipes, is in the
control.lua). I did implement it slightly differently in each (DyTech only looks at valid recipes since it expects mods to make their parts modular (by creating a valid recipe), belt replacer looks at all entities of type "transport-belt" and uses a default value if it doesn't find a recipe) but it's the same technique.