[MOD 0.13] Black Market (sell and buy on the market)

[binbinhfr]

thx for the return, I have a look at this right now.
there are so many mods with so many recipes, and looped recipes, and resources that are not always declared as resources...

[depeter]

Giving a special price to "gem-ore" (the basic "unsorted gem" that you get as a side-effect from handling ores, and from which you can sort and refine all the other gems) was enough to bring back all the gems and their derived resources (unless they required other things that got blacklisted).

They were not blacklisted : they were not detected as resource, because something must be missing in bob's prototype. Or in agle ore, because if I just install bob's ore, I see the gems. It's when you install angel ores that something is uncorrect concerning the gems.
But it's the same for vanilla water that is not considered as a resource by the game. I had to enter its value manually. I guess that there will always be a few items to enter manually because modders are not always respecting the strict prototype definition.

Concerning Zrecycle, I made a detection on name recipe, as every other strange mod, but I am working on another more general solution.
All unknown items are now set to 999, I can recognize them easily.
Please update and tell me.

Bonsoir!

Are you french ?

Yeah, I didn't mean you blacklisted them manually, but your original code detected that something was wrong (loop and/or no ingredients and/or ingredients without price) and blacklisted them automatically. At least that's what it looked like based on the debug_print statements after I uncommented them

Can confirm that it sometimes seems to get in a seemingly infinite loop, not just with Bob's Greenhouse, but also with at least one of Angel's weirder processing chains.
Seems to be the "while new_price" loop in update_object_prices2, based on the logging.
I'm not 100% sure (as I only tested it with the full set), but I'm pretty sure you should be able to reproduce it with the 2nd zip from yesterday (+updated BlackMarket of course )
I experimented a bit, and ended up just limitting that new_price loop to 25 iterations (though you'll no doubt be able to find a better fix, as this one is rather crude, and might exclude some cases where you could eventually find a better price than the unknown this ends up defaulting to).
Also, in the first for-loop after that, I think there's a mismatch between name_ingr in the for statement and name in the for body?

After my little loop change, I was able to try a complete load, and your changes work pretty well! The 999 may not always be very fitting, but the most important thing is that they're buyable, after all. The price being a bit high doesn't matter that much, that could be justified as those black market guys abusing their quasi-monopoly

I'm from belgium, so I know some french (mais je suis flamand, donc ma langue maternelle est le néerlandais, mais je me souviens encore un peu de mes cours de francais, et il y a aussi Google Translate pour m'aider )

[binbinhfr]

1.0.7 - unofficial test version
- correct a problem with random product recipes.
- at the beginning, try to identify and separate original resources/undeclared resources/free items/unknow items
- include a max loop number in the main scan process
- export now generates a list of these special items, ready to be edited and included into config.lua .

Hi, thx for your patience.
Not easy to find a general scheme / algorithm tobuild this prices list, because a lot of mods includes looping recipes, or no ingredients, or random products, or undeclared resources, or even vanilla resources that are redefined as something else... so many cases.

But keeping this new algo, I think I found a way to identify and isolate the special cases. I made quite a lot of tests with all these mods and it seems to work, but I do not have all your special mods combination, so please test this and tell me if it works with all your mods ... (i'll publish it only when it will be tested as stable)

BlackMarket_1.0.7.zip

PS: @depeter, i included a max loop number, just in case...

> Also, in the first for-loop after that, I think there's a mismatch between name_ingr in the for statement and name in the for body?

what do you mean ? what line ? (in the 1.0.7)

When this code will work, I deserve a good belgian beer !!!

[depeter]

For the mismatch, I meant line 509 in the zip you uploaded here. The loop on line 508 uses name_ingr, but line 509 uses name, which seemed a bit odd. Might be perfectly alright, as I don't really understand the full code well enough to judge, but just seemed strange
Just did a quick load, and the game didn't crash, didn't hang, seemed to load faster than earlier. All items seem to be present, some basic items with the appropriate resource_price_new, some weird/complicated items with unknown_price (which, for some of them, is a bit too cheap for balance, but they're uncommon cases, and it's up to the player to not abuse them in-game, or take the specials file and edit better values into his config.lua).
I'll do a bit more testing now, and let you know if I see anything odd, but then I'll be away from the computer for a week

I'ld say you deserve plenty of good beers, for all those nice mods, and your patience with people with too many other mods to interfere

[binbinhfr]

For the mismatch, I meant line 509 in the zip you uploaded here. The loop on line 508 uses name_ingr, but line 509 uses name, which seemed a bit odd. Might be perfectly alright, as I don't really understand the full code well enough to judge, but just seemed strange

You are right. I correct this. But it does not change the list build.

But with all bobs and reverse and everything, the loading time is high for me, because a lot of recipes to scan.
I do an automatic rescan each time mods config is changing (install or uninstall), to rebuild recipe list, but it can be hard for users that like to install/uninstall a lot of mods for testings... I could let this rescan manual, but then users will complain that a lot of prices are just unknown...

[depeter]

Some extra observations : I removed some of the special cases we talked about earlier from config.lua, because I was wondering if the mod could now handle them too. But it seemed to cause a very slow load again. Enabled debug output again, and it looks like it's partly the lack of small_alien_artifact triggering a massive amount of items (because it's needed for catalysts, which are needed for tungsten, which is needed for tons of items). Because of that, it has to go through the loop the full 50 times, with a large amount of items to check every time. It gets through in the end, but only after like 20 minutes, and with almost 500 items in specials file with unknown (and not quite ideal) prices.
So it's probably best to leave those pseudo-resources in config.lua, then the mod can swiftly handle all the rest For comparison : the downloaded version loaded in only about 5 minutes, with about 50 items in specials.
Note that I did have to make that edit to line 509, because otherwise it gave an error about nil index (probably previously, with the specials, it ended up never actually going through that loop, but without the specials, it did, and then it errored).

I think that in the end, this is a very good compromise.
The current mod code with your initial vanilla config can handle everything (albeit slowly because of crazy mod recipies, and with prices that are sometimes a bit too cheap).
The mod config with the current specials section (with a handful of entries for Bob/Angel tricky cases) handles things relatively fast, for most cases (because it allows the code to go through the loop less times and/or with less problematic items).
The player can edit/expand the specials section to get more realistic prices for his mod set, if he wants, or to speed up loading. Because you can't be expected to come up with good configs for every possible combination.

One possible extra enhancement you could make (not really needed, but to make keeping a custom specials config easier), would be to have the specials imported from a separate file inside your main mod.
Then you can update the main config without problems, and the player just needs to copy/paste his custom specials into the separate file (instead of into an array in the main file).
Alternatively, you could just have optional dependency on, for example "BlackMarket_PlayerCustomization" where player can place his specials into a new config.lua. That mod never needs updates from you (the player just creates and maintains his own), so player's specials never get overwritten by updates

But like I said, it works well enough the way it is now I think, with some pseudo-resources in config.lua to make things reasonably fast.

Automatic vs manual rescan is a good question, I think most people play with relatively stable mod set though.

[NekoDwarf]

It seems that I found a bug: when trying to buy simething from bottom of the item list (I have a bunch of mods bob. yuoki etc), I mean changing new buy order, mod just cancaling order itself.

[binbinhfr]

It seems that I found a bug: when trying to buy simething from bottom of the item list (I have a bunch of mods bob. yuoki etc), I mean changing new buy order, mod just cancaling order itself.

I do not understand. Could you please rephrase ?
What version do you use ?

[binbinhfr]

Note that I did have to make that edit to line 509, because otherwise it gave an error about nil index (probably previously, with the specials, it ended up never actually going through that loop, but without the specials, it did, and then it errored).

I changed this.

I think that in the end, this is a very good compromise.
The current mod code with your initial vanilla config can handle everything (albeit slowly because of crazy mod recipies, and with prices that are sometimes a bit too cheap).
The mod config with the current specials section (with a handful of entries for Bob/Angel tricky cases) handles things relatively fast, for most cases (because it allows the code to go through the loop less times and/or with less problematic items).

could you send me this new config.lua so that I integrate it ?

One possible extra enhancement you could make (not really needed, but to make keeping a custom specials config easier), would be to have the specials imported from a separate file inside your main mod.

I add this to the todo list.

Automatic vs manual rescan is a good question, I think most people play with relatively stable mod set though.

I came back to manual, but with a message to the player when detecting mods changes, advising to rescan if he install/uninstall recipes.

Here is new version :

[depeter]

could you send me this new config.lua so that I integrate it ?

I actually just meant your 1.0.7 config.lua (which has those handful of items we talked about yesterday, like gem-ore, small-alien-artifact, etc). When I removed those for a temporary test I had the 20 minute, 500-specials case, but with your 1.0.7 version I had the 5 minute, 50-specials, which is I think good (as the player can always tweak a bit further).

Thanks for your great work! I'm offline for a week now, but I'll definitely check back when I return, and this mod is sure to become a standard part of my collection

If I end up making extra custom tweaks to config.lua then, I'll make sure to also share them with you, in case you might be interested in integrating them.

[binbinhfr]

I had the 5 minute, 50-specials, which is I think good

5 real mins ! it's still huge...
And it does not hit the 15 loops limit ?
I'll have to find a way to scan in background, not blocking the game.

for small-artifact, I made an error, you can now delete it from the config.lua, it will be detected as a undeclared resource.

BlackMarket_1.0.9.zip

Have a nice week. See you later.

[Wtcan334]

Crash when selling the starting coins: Can't perform arithmetic on tax1 since it has a nil value... It doesn't crash when including other items worth more than 1 coin.

[binbinhfr]

Crash when selling the starting coins: Can't perform arithmetic on tax1 since it has a nil value... It doesn't crash when including other items worth more than 1 coin.

Hi, thx for the report,
I corrected the bug and will post a version soon.

[binbinhfr]

1.0.10 - scan recipes in background, using on_tick, showing progress so that user can be patient...
- correct bug on tax on ucoins selling.
- do not "unknown" remaining ingredients that are correct but linked to recipes with missing ingredients or
looped ingredients.

recipe scanning is automatic every time you change any mod, but in background in several passes (max 15), so that you can see progression while starting playing.
tell me if there is still some problems with missing or incorrect prices.

[Qon]

Are there any cost associated with having lots of buying and selling chests? If you can have 1 ore buying chest for every furnace then you have elimitaed the need for long and short distance logistics. Doesn't the crooks take a fee for every new location they have to deliver too? At the moment it seems like you are encouraged to use as many chests as possible because it means you can buy every 24h and still have enough buffers and abuse the crooks for replacing all kinds of logistics, not just trains. You can even sell your plates and buy them at another location to transfer items around within your base instead of logistics robots.

The buying and selling chest could be some kind of rocket platform/helipad that's at least 7x7 to discourage using one or 2 for every assembly machine. That's still much smaller than a train station. And each chest could have some running cost in Ucoins or energy like 200 kW for every trading chest that isn't next to another trading chest.

I haven't tried it in game yet but from the numbers it seems that this is how it would play out.

[binbinhfr]

Hi Qon, these good remarks have been written in previous posts. Effectively, you can use these chests for a lot of things, and also for transportation. But remember that there are taxes (i.e. loses) , and a delay. So it's not so smooth or "free" as you may think. That's why I introduced these frequencies and increasing taxes.

To counter chests multiplication abuse, I had in mind the idea of putting a fixed base tax for every transaction : so the cost of a transaction will be A + B x sum_of_prices, where B is the actual tax rate. "A" could be proportional to the average techno level of traded items.

In the todo list there is also :
add a law of "supply and demand", with diminishing prices if player sells always the same items, of increasing prices if he buys always the same items. Prices slowly returns to normal if items are "abandonned" for a while. Other players on the map should influence prices too.

The actual difficult part is to generate the prices list for any mods/recipes combination and it's not easy. If you have 5 mins, please install it temporarly on your base and tell me if the prices are build without problems on your personal set of mods.

When this will be stable, I'll go into further developments.

[Qon]

Hi Qon, these good remarks have been written in previous posts. Effectively, you can use these chests for a lot of things, and also for transportation.

Well I did read the thread and didn't see any in depth discussion of this.

But remember that there are taxes (i.e. loses) , and a delay. So it's not so smooth or "free" as you may think. That's why I introduced these frequencies and increasing taxes.

Well I talked about how this taxation system actually encourages the opposite. More chests = more buffer storage --> less need for frequent buying and selling. So having 1 chest for each machine isntead of 1 chest for each outpost is actually cheaper and easier. I'm not talking about using the buying and selling for logistics primarily in this case.

In the todo list there is also :
add a law of "supply and demand", with diminishing prices if player sells always the same items, of increasing prices if he buys always the same items.

If you use the crooks for logistics then the supply and demand rule has no effect on the cost since you buy and sell equal amounts. Only taxation matters here. If you can live with 24h buffering then 5% tax is not much if you use 1xPM1 in your machines to offset the cost. It's a bit more than the cost of transporting with robots if you use coal power I guess but still not that much different. The 5% tax is probably fine, the problem isn't that the tax is too cheap but that the chest spam has no downsides.

The actual difficult part is to generate the prices list for any mods/recipes combination and it's not easy. If you have 5 mins, please install it temporarly on your base and tell me if the prices are build without problems on your personal set of mods.

I'll do that when I'm at my gaming rig :]

[binbinhfr]

All this makes sense. That's why I also want this fixed fee per transaction that will encourage less chests and bigger and slower transactions. And I will put a power consumption on the todo list, that's a good idea.
Then some people already use this mod as a paying transportation tool, and why not. Factorio is a game where it is very easy to "cheat" : everybody put his own limits to what he accepts or not.

[Airat9000]

All this makes sense. That's why I also want this fixed fee per transaction that will encourage less chests and bigger and slower transactions. And I will put a power consumption on the todo list, that's a good idea.
Then some people already use this mod as a paying transportation tool, and why not. Factorio is a game where it is very easy to "cheat" : everybody put his own limits to what he accepts or not.

hello find bug

and please where in link new test version

price in alien, resource - small

[Airat9000]

and items

station mk1 999u
station mk4 101u


items old price more - items new pice in small