• New Horizons on Maelstrom
    Maelstrom New Horizons


    Visit our website www.piratehorizons.com to quickly find download links for the newest versions of our New Horizons mods Beyond New Horizons and Maelstrom New Horizons!

Fixed Trade Screen Shift/Alt modifiers broken

CaptnLysop

CaptnLysop

Sailor Apprentice
Version used: Build Mod 3.1 6th December 2013
(need to d/l me the newest Version)

The Shift (100 Units per click) and Alt (10 per click) modifiers are broken when using them on the Trade screen, allowing to buy a cargohold of Gold/Silver/etc. insanely cheap when using Shift; lowering the amount of wares (without the modifier button held down) to buy creates the paradox of buying wares but receiving money.

To easily visualize how the shift/alt modifiers are broken, a test:
1. Go to store and start trading wares
2. Select Gold or other high-value Ware
3. Click to buy, and Hold shift, then click the "increase" Arrow or hold "Right Arrow".
Wait until your cargo hold is full.
Total Price will be only a fraction of the actual price.
4. Now reduce the amount to buy again, hold "Left Arrow", you know how, but dont hold down shift or alt with it.
Watch the money go down rapidly, even into minus values. DON'T let it hit zero, if it does, the money you pay/receive of course resets to 0 as well; obviously the correct price is now used as the money goes down correctly according to the actual ware price.
5. NOW click "Buy", and voila;
6. You actually RECEIVED a lot of money for BUYING the stuff.

I gave the workaround (so the buttons dont change the multiplier any more), changing in "store.c":
change all
Code: 
    if (GetQuickControl("alt")) mult = 10;
    if (GetQuickControl("shift")) mult = 100;
to
Code: 
    if (GetQuickControl("alt")) mult = 1;
    if (GetQuickControl("shift")) mult = 1;
 
I tried this one time so far but forgot which buttons to hit. Will keep trying.
 
I'll set the multiplier to 1 as suggested in the next modpack update, so we can consider this "fixed".
Technically we do lose a feature, but I fear it wouldn't be a quick fix.

It might be related to the fact that the Buy/Sell prices are recalculated WHILE you are in the interface, rather than after the fact.
The multipliers might make this calculation work differently if used and mess things up if you combine using/not using these.

Ideally I figure that the Buy/Sell prices should be recalculated AFTER the transaction, since that seems to make much more sense to me.
But that might require some substantial reworking of this code.
 
Just for the sake of it, I had a quick experiment to see if I could get the prices to remain fixed during a business transaction.
As expected, that didn't really work out and I really don't understand the relevant coding. Looks complicated.
So since that system is not technically broken, it might be best not to touch it and potentially make things worse. :facepalm
 
Anno and powder code hasn't been changed from last update.

Haven't heard that problem you described yet.
 
About the shot and powder costs, they are still messed up and it can wipe out your wallet buying that stuff.
 
Hylie Pistof said:
About the shot and powder costs, they are still messed up and it can wipe out your wallet buying that stuff.
Click to expand...

Pieter Boelen said:
Posted somewhere is the Beta 3.3 version of the relevant file. @pedrwyth was looking into it.
Click to expand...

I am looking at it. I have fixed the problem with buying individual gunpowder rather than units but as I said before there are other issues (with the way the selling price is derived) so as I suggested the original prior to my tampering (actually from 3.5 but the same as 3.4 anyway) needs to be put back for now. I posted one here a couple of pages back.

pedrwyth said:
post: 507840:sick
Click to expand...
 
Right as I said I have fixed my self induced problem of munitions costing the earth. I have also increased the price you get for selling to the average of the first unit and last unit prices for the cargo quantity you have on-board. This gives a closer match to the sums you would have received previously in the non-linear version (since it's hard enough to make a profit on trading anyway).

In trying to use the file (made by editing the latest version of 3.5) with build 14 3.4 saves for comparisons I spent a while looking at what else I had done wrong when it crashed the game on calling the interface. With the help of Winmerge I found the SupplyScalar concept had been added (not a problem to work round) but I know that that was not in the rollback version I posted earlier so hope that has no knock on effects on anyone who used it? The rollback seemed to work alright in the latest version for me.

During testing I found that AutoBuy (which I don't use normally) does not check that the store actually has the goods you need. So Sovereign of the Seas wiped out the gunpowder stocks of one store and left them -5800 for gunpowder. I don't suppose it is a very frequent scenario but perhaps should be prevented? Looking at the code there also isn't a check that the town has its minimum food left either. I haven't done either of these changes as it stands.
 

Attachments

  • store.7z
    9.4 KB · Views: 138
pedrwyth said:
Right as I said I have fixed my self induced problem of munitions costing the earth. I have also increased the price you get for selling to the average of the first unit and last unit prices for the cargo quantity you have on-board. This gives a closer match to the sums you would have received previously in the non-linear version (since it's hard enough to make a profit on trading anyway).
Click to expand...
That is cool, that is!
Do you reckon it would be possible to make the buy/sell prices just use the value when you START the transfer and to have the price update only afterwards?
It doesn't make sense to me when you can get a good price for a certain cargo and you sell a lot, you suddenly start getting less money because the price is changing while you sell. :facepalm

pedrwyth said:
In trying to use the file (made by editing the latest version of 3.5) with build 14 3.4 saves for comparisons I spent a while looking at what else I had done wrong when it crashed the game on calling the interface. With the help of Winmerge I found the SupplyScalar concept had been added (not a problem to work round) but I know that that was not in the rollback version I posted earlier so hope that has no knock on effects on anyone who used it? The rollback seemed to work alright in the latest version for me.
Click to expand...
The SupplyScalar thing isn't actually used for anything right now. I put it in place for this mod:
http://www.piratesahoy.net/threads/include-cannon-weight-and-number-in-cargo-capacity.24953/
However, that whole thing has been shoved on the backburner for now because it would require a substantial amount of further work to get it right.
At least the concept has been proven.... :shrug

pedrwyth said:
During testing I found that AutoBuy (which I don't use normally) does not check that the store actually has the goods you need. So Sovereign of the Seas wiped out the gunpowder stocks of one store and left them -5800 for gunpowder. I don't suppose it is a very frequent scenario but perhaps should be prevented? Looking at the code there also isn't a check that the town has its minimum food left either. I haven't done either of these changes as it stands.
Click to expand...
Negative values at stores have indeed been reported to occur. If you can do something to fix that, it would be much appreciated! :woot
 
Pieter Boelen said:
Do you reckon it would be possible to make the buy/sell prices just use the value when you START the transfer and to have the price update only afterwards?
It doesn't make sense to me when you can get a good price for a certain cargo and you sell a lot, you suddenly start getting less money because the price is changing while you sell. :facepalm
Click to expand...
Well anything's possible but unfortunately the "buying price" (ie what the storekeeper sells at) is dynamic in the same way (depending on how much they have for sale) and you can end up being paid more per unit than it costs to buy some back - not good mercantile practice by the storekeeper.

The current average is only produced by adding the top and bottom and dividing by two -it would be simple to add another scalar there instead which could be played around with if a global set in internalsettings to move nearer or further from the storekeepers initial one unit price. One problem I found was that different ships cargo levels meant different prices applied (that is still true). I set the price shown in the first screen before you choose buy or sell to be what you would get (the average) but each ship showing a different price looked odd so I reverted to first unit price.

I think of it like this. you say what's your price for buying "good_a". he says 100. You say great cos I've got 6000. he says 6000 eh? well I can only give you 69 per unit for that many - I'll have difficulty shifting that mush etc etc. After that ship you say what's your price now for "good_a" he says .......

Ideally the logical negotiation should be on your full squadron quantity instead of ship by ship. I guess that could be done if some global variables were used rather than local - you would still need a mechanism for choosing to except ships you didn't want to sell their cargo. A step too far at this time I think?

Pieter Boelen said:
Negative values at stores have indeed been reported to occur. If you can do something to fix that, it would be much appreciated! :woot
Click to expand...

OK I'll look into quantity checks in what I think is AutoBuy (although it seems like it re-uses the code for sell all somehow)
 
pedrwyth said:
Ideally the logical negotiation should be on your full squadron quantity instead of ship by ship. I guess that could be done if some global variables were used rather than local - you would still need a mechanism for choosing to except ships you didn't want to sell their cargo. A step too far at this time I think?
Click to expand...

Although the function GetSquadronGoods in characterutilite looks like some of that work is already done. I guess what would be needed would be a "sell squadron quantity" button appearing on the sell goods screen to update the amount to squadron quantity (from that function call) instead of the standard nTradeQuantity.Most of the rest of the code should be re-usable as is. It would be all or nothing with no choice to leave out ships but it would save trawling through four different ships if they all had the good you wanted to sell. What do you think?

One snag may be the large quantities could make price change even more of a problem.
 
Last edited:
That is why I'm thinking of not applying the price change until after the transfer has been done.
Though I'm not sure how feasible that is.
 
Pieter Boelen said:
That is why I'm thinking of not applying the price change until after the transfer has been done.
Though I'm not sure how feasible that is.
Click to expand...
On the selling side it is absolutely straightforward now I have changed the transaction to a linear base. I haven't played anyway near enough to know how robust the economy is but it would be a significant shift in balance. Given Hylie Pistof's comments I would tread warily

Hylie Pistof said:
It isn't so bad now but it used to be possible for a colony to collapse and then not to be able to trade with them again. I used to do lots of charity runs to failing colonies trying to keep them afloat and only actually lost one. That has been fixed now tho.

Making money isn't everything. After a while I reach the point of "why bother"? If I play a game long enough I always end up downsizing to small fast ships. It all works better that way.
Click to expand...

Anyway here is an amended file with a check against store quantity (and town population for food) in Auto mode. I tested it against the example I had and it stopped that gunpowder trade dead. Like the money check it doesn't issue warnings though so a player could be caught out thinking they had re-supplied - as I say that's what not enough money did already. Perhaps you have a fast way of destocking a store to check it out further?
 

Attachments

  • store.7z
    9.5 KB · Views: 140
Last edited:
There might be a way I suppose, but I don't know how and I can't check for a while either I'm afraid.
 
I guess once happy that the above store.c file does the job this thread (multipliers) is done as a "bug", I can't see turning on the *100 since buying will always have to be dynamic (since you can't know the quantity to be bought) and going up in jumps but down in units will always distort the sums. However I have been looking at interfaces generally to try to work out how buttons are assigned and "discovered" some sliders in the options screens have multipliers (which I hadn't seen before) so for consistency I suggest changing to "control" for the 10 multiplier in store.c ie putting

if (GetQuickControl("control")) mult = 10; //-rather than my use of shift (it never was "control" for some reason?)

in
ProcessTradeDecrease() and ProcessTradeIncrease()

The remnant of the thread about which trade price and squadron selling could become a feature request in the brainstorming section? On that side I have realised that problems with changes in the buying price whilst bulk selling can be addressed by checking what the new buying price will be once you have sold the whole batch and ensuring the selling price is just slightly less than that. I suspect the sell all button could be re-badged once you have chosen a particular good to be "all ships" (or something like that) ie sell squadron quantity. But is this something players would value/use?
 
Last edited:
Eh?

I have had a very poor running computer for some days due to AVG Antivirus getting updated and then deciding to quarantine a bunch of files as malware. I just got it working again properly.

Anyhoo, I have not played anything for days and so have no opinion until I can start playing again. I can say that I was happy with the trading system except for the bug with the price of shot and powder. I do not know if I installed that store.c or not.

The biggest problem I have is selling goods to smugglers and getting paid and also keeping the goods. I was just sailing around selling the same goods over and over last week.
 
pedrwyth said:
I guess once happy that the above store.c file does the job this thread (multipliers) is done as a "bug"
Click to expand...
Looking at your code changes now to add it into my game version. Query on this line:
Code: 
              if(GetStoreGoodsQuantity(refStore, i) < buyQty) buyQty = 0; //PW check store has quantity required
Perhaps that can be changed to:
Code: 
              if(GetStoreGoodsQuantity(refStore, i) < buyQty) buyQty = GetStoreGoodsQuantity(refStore, i); //PW check store has quantity required
Then you still get some goods, just not more than the store had. Right?
I didn't actually test this though....
 
I just set the autotrade to zero because that's what not enough money did. That's fine for money since if you are strapped for cash you should be taking control and deciding how much of what to buy. In the case of the store not having enough you still want to buy what little they have so your tweak to the code is logically correct (except if you would be better putting it on a different ship whose need was greater - but again you should be keeping clear of autotrade in such circumstances). So all fine so far.

Pieter Boelen said:
Looking at your code changes now to add it into my game version. Query on this line:
Code: 
              if(GetStoreGoodsQuantity(refStore, i) < buyQty) buyQty = 0; //PW check store has quantity required
Perhaps that can be changed to:
Code: 
              if(GetStoreGoodsQuantity(refStore, i) < buyQty) buyQty = GetStoreGoodsQuantity(refStore, i); //PW check store has quantity required
Then you still get some goods, just not more than the store had. Right?
I didn't actually test this though....
Click to expand...

So - Yes (and I have tested the line in Gunpowder against my overbuy example - fine). With WHEAT it would need to be set to ensure it did not overwrite a rejected purchase because of town population. It could be reworked such that you could still buy some if the store has slightly more than the town needs. Now comes the BUT..

BUT I started on this as "minor" corrections in the normal buy/sell process in order to put back multipliers. I think I need to step back (again!) and consider some wider functional issues.

As I said before I don't use "sell all" or autotrade so had not really looked at them. Now I have a little and !?! (I am somewhat confused). Nothing reported as bugged (as far as I know) but :-

  1. Repeat sell all / autobuy cycles have potentially similar problems to where I started in normal buy/sell in jumping to the full quantity transacted (which can be like a 100+ multiplier),
  2. unitsize isn't considered as far as I can see so you can buy any quantity - I'm not sure if the "need" equations can generate other than unit size blocks of requirement (but I would guess the answer to that is yes). Does this matter - No as long as the price is factored accordingly (it is based on a whole unit as I messed up before). So that needs checking out
  3. what is PRICE_TYPE_SELL doing in the check as to whether you can afford to buy goods in autotrade? Does this mean I don't even understand this function properly?
  4. and finally because I would have altered the normal buy/sell routines cycle and "sell all" / autotrade uses different there would be a new potential for "manipulation" which needs exploring.
If there is a potential to work a fast buck through cycling through the interface someone will always find it.

So I'm afraid I think I am back to keeping the original for now and leave this as Fix in Progress.
 
You must log in or register to reply here.
Back
Top