FP issue on beta world

[CastleBig]

I noticed a few days ago that when I entered a GB, the fps from the tool would disappear, it says I have no fps, even though I do.

[Gindi4711]

Daran arbeiten wir gerade: #1044

Inno überträgt die FP im Inventar nun nicht mehr beim Öffnen eines LGs. Diese müssen in Zukunft über das Inventar getrackt werden.

[scibuff]

I have a fix for the zeroing (of the FP Stock when a player open a GB window) and for tracking the FP stock when used for research. Still needs to update when a GB is level (and invested FPs are returned to the stock)... then I guess I'll refactor it out to its own file

p.s. ... and I'm sorry I accidentally committed it to an existing pull request so had to revert

[Gindi4711]

@scibuff The Fix for 0 is the easy part, but tracking GBs that are leveled is a lot more complicated and requires permanent listening on the websocket. I think I already have a fix working, but stillneeds a bit of testing.

[scibuff]

@andrgin Yeah. I saw that the Infobox does it but the amount of return FPs is not always correct. Research tracking is a bit of a pain but i think I have that figured out too. I haven't looked at all at packs from quests but I hope that's as simple as figuring out the correct class/service names and the json path to the data

[Gindi4711]

It is a bit more complicated in this case as the previous implementation had several problems:
1.) FP packs add up until you go to inventory and NoticeIndicators are removed. So you have to track the remove as well.
2.) When using a FP packed the amount of packets in stock is transmitted so you have to constantly track the FP packets, only FP sum will not do the job => fine for the infobox, but not enough for the FP bar
3.) You can get FP packets (like the 5 FP one) that are currently not in the inventory. In this case you have to track the getItem from the websocket as well.

[scibuff]

@andrgin OK, so just to summarize, after the initial inventory stock value is set, we need to track all + and - of FP packs.
What are the scenarios where FP packs can be used/removed? I think these are

• adding FPs packs to great buildings but that triggers the GreatBuildingsService.getAvailablePackageForgePoints event correctly (Inno has not removed that)
• using FPs packs for research; that can be tracked with ResearchService.spendForgePoints and comparing the saved currentSP in Technologies.UnlockedTechologies.inProgressTechnologies with the one after the event is triggered (and adding ResourceStock.strategy_point) - I think I have this working; or is there a better/easier way?
• anything else?

The scenarios where FP backs are added:

• GB leveled; I just tested this piece of code and it seems to work

FoEproxy.addHandler('BlueprintService','newReward', (data, postData) => {
    console.log('Received: ', data.responseData.strategy_point_amount);
});

• quest rewards -> I'm not sure about the best way of handling this one
• any others?

[Gindi4711]

I just pushed my fix to beta branch.

The important listeners are:
.) InventoryService.getItem and InventoryService.getInventory: Full transfer of the whole inventory (ID, Name, Stock)
.) InventoryService.getItemAmount: Transfered every time you open a FP packet and maybe if you get one without leveling a GB: Contains Item ID and stock
.) NoticeIndicatorService.getPlayerNoticeIndicators over Websocket: Transfered every time a GB gets leveled, contains item ID and amount since last reset.
.) InventoryService.getItem over Websocket: Transfered before getPlayerNoticeIndicators if an item is not in stock yet (this is very important, otherwise you can not recognize new Items as FP packets)
.) NoticeIndicatorService.removePlayerItemNoticeIndicators: Transfered when opening inventory. When this happens NoticeIndicators start from 0 again.

[Gindi4711]

Update:
Still not perfect yet. I am currently 7 FP off.

[scibuff]

I get several bugs with the update actually. Once the counter is off, it keeps adding/subtracting values from the wrong number. I think it might be a good idea to just take all the code into a separate file which is what I've done (without changing any of your code and just printing the FP Stock value to the console). To test the gb leveling is a pain though (it's a slow time of the day).

[Gindi4711]

I have 2 more fixes:
.) If you receive an FP packet and use it before opening the inventory there could be wrong values.
.) When receiving a packet that was not in the inventory yet (for example 5 FP packet) the GetItem already transfered the received amount and the NoticeIndicatorService added the amount a second time on top which leads to too high values until you use one of those packets.

I will test with the current version tomorrow and see if my values stay correct.

Btw. we have a new debug flag. Set Infoboard.DebugWebsocket to true and all websocket communication is dumped to the Console

[scibuff]

Yeah, I'm seeing quite a bit of count duplication. Especially, if you level a GB yourself or you get two GB leveled one after another

@andrgin I think your getItemAmount handler needs to loop through the data as there can be more than one type of fp pack; e.g. if I add 9 fps it may deduct 1 5fp pack and 2 2fps packs; that's probably why you were 7 FPs off before. The data array structure is [id, value, id, value ..., id, value]

[scibuff]

• Receiving FPs after a building has been leveled is sometimes doubled
  

• Collecting quest rewards (5 fp pack from the recurring quest) messes up the calc completely. It triggers NoticeIndicatorService.getPlayerNoticeIndicators as well as InventoryService.getItemAmount

• Opening the FP purchase screen can recalculate/correct the amounts, use InventoryService.getItemsByType

• Calculations are completely off when there are "new" packs on load (but we initialize the new value to 0); might have to use localStorage as I don't see the info in any raw data that's loaded at start

All my progress is here in my branch for this bug

[scibuff]

I think I got it working in all cases now (subject to more testing). Branch updated

[Gindi4711]

* 1) Receiving FPs after a building has been leveled is sometimes doubled
  ![image](https://user-images.githubusercontent.com/722049/82902598-f89d7680-9f5f-11ea-9e70-b331db16aea5.png)

* 2) Collecting quest rewards (5 fp pack from the recurring quest) messes up the calc completely. It triggers `NoticeIndicatorService.getPlayerNoticeIndicators` as well as `InventoryService.getItemAmount`

* 3) Opening the FP purchase screen can recalculate/correct the amounts, use `InventoryService.getItemsByType`

* 4) Calculations are completely off when there are "new" packs on load (but we initialize the new value to 0); might have to use `localStorage` as I don't see the info in any raw data that's loaded at start

5. All my progress is here in my branch for this bug

1. Did you level another GB with 144 reward before or is it really doubled? Is this the current beta branch?

2. This is a real pain. Unfortunately I cant test this with my main account because in SAAB you get 10 FP rewarded to the bar instead, but this will be real trouble for the recurring quest users that get a lot of FP every day with their Frontenac.

3.) Nice to know, but I dont think we can rely too much on that.

4.) I have not thought of that yet. localStorage is not an option, because if the player has used another PC or the app before, NoticeIndicators will be wrong.
getNoticeIndicators is transfered in the StartUp packet before the actual items, but this time not via websocket, but a normal request.

5.) Yes I think with that many events to handle another file would be a good idea.

6.) I think using the NoticeIndicators will be a much bigger pain than I thought. I will try using newReward instead. Now that we know we will receive getItem via Websocket, we can be 100% sure the item is in MainParser.Inventory. All we have to do is split the reward into the 3 packets (if reward is uneven there must be one 5FP packet, rest is 10FP and 2FP. Then we can search the items per name.

[Gindi4711]

Update:
Instead of creating a new file why not stuff all that into strategypoints.js?

[scibuff]

6. But the reward data is just (inventory) id and amount. It doesn't tell you how many FPs you get. I mean, this will be fairly rare occurrence, but still, if you have 0 FPs in your packs, and the newReward data is just [{12345,1}] you can't tell if you got a 5-pack, a 2-pack or a 10-pack. OK, maybe there really isn't a way to get a single 2-pack (afaik 2-pack rewards are usually 3x) but there's seems to be no way to differentiate between a single 10-pack and a single 5-pack if you don't have the same id in the inventory already (e.g. you have 0 packs).

In any case, I'm creating a pull request as my current code seems to be handling majority of these issues (the only other problem I saw a while back - so might be fixed already - was several GBs leveling in a quick succession which threw the calculations off, but that was a dozen commits ago and it's very hard to replicate)

[Gindi4711]

BlueprintService.newReward gives the total amount of FP. As long as you know you have all FP packets in inventory you can find them and split the total amount into packets.

Every reward needs to be at least 5FP. There is noe reward below that.

[scibuff]

BlueprintService.newReward gives the total amount of FP. As long as you know you have all FP packets in inventory you can find them and split the total amount into packets.

Every reward needs to be at least 5FP. There is noe reward below that.

Good idea, that should work as long as the decomposition into packs is guaranteed i.e. that 10fp reward will always be given as 1x10pack and not 5x2pack or 2x5pack, which I believe is the case.

[scibuff]

Oh, the issue with using BlueprintService.newReward is the while we can decompose the total into 2s 5s and 10s, if one of those is not already in the inventory, we don't get the inventory item id under which to store the pack. That comes from the InventoryService.getItem ws so need to check in which order they come. Might have to store the data from the reward until the getItem is triggered and then set the inStock to the correct number of packs instead of 0.

[scibuff]

@andrgin Managed to get this working properly without the newReward and Indicators (don't need to track new packs at all). It was damn simple - stupid Inno just sends Inventory services through regular services (json) as well as raw WS so we need to handle both:

• when a player receives a new pack which is not yet in the inventory InventoryService.getItem is triggered via FoEproxy.addRawWsHandler for FPs returned when a building has been leveled but via FoEproxy.addHandler for FPs from (quest) rewards

• in a similar manner, InventoryService.getItemAmount is triggered when a player uses FPs (e.g. research, buildings etc.) but InventoryService.getItemAmount is done via WS when receiving FPs from buildings. So we can just use that instead of getPlayerNoticeIndicators and the returned data has the total number of packs (instead of the new number)

[Gindi4711]

Wow I really missed the getItemAmount via Websocket. It really makes sense now.