[We the People] Development "diary"

[Nightinggale]

I looked at a bug report, which states that cargo sold in Europe is reset on tax changes. This makes it very hard to finish the quests for being the first to sell X amount. Indeed this turned out to be correct. I just just remove the line pointed out as the issue and then... oh wait that will mess up calculations for price changes.

I examined the problem further and the more I looked into it, the bigger the issues became, so I ended up doing a complete rewrite of how traded cargo is stored and accessed. It is now split into 4 different "memories". Sold and bought in the player, used for quests. Sold and bought in one number in the king used for price changes and value of cargo traded stored in king, used for tax changes. I also had to redesign how to update those counters because the old system was so confusing that at some point somebody will use them incorrectly....again. In the end this quick fix ended up taking a week to complete, but at least now quests should work as intended.

As a bonus I added a new page to the domestic advisor, which shows amount sold and bought at the 3 locations for exports. We now finally have a screen where quest progress can be monitored. It doesn't say what the quest goal is, but you can at least see the current number.

Also sales only counts goods coming from the new world. Anything bought off map will be marked and not count in the sales statistics. This way you can't cheat completing a quest by buying and instantly selling again in Europe. I noticed that I had created this loophole by accident and then fixed it before even committing, so it never even existed at any point in the develop version.

 

[XSamatan]

Good news!

Thanks for going down the rabbit hole

Regards
XSamatan

 

[Jaded1]

Hmmm.... has development of We the People Mod stopped? It's been over 3 months since anyone posted anything about the development progress for the next update. I know there is a massive code rewrite going on but it is nice to know that it is still progressing.

 

[Kendon]

Hmmm.... has development of We the People Mod stopped? It's been over 3 months since anyone posted anything about the development progress for the next update. I know there is a massive code rewrite going on but it is nice to know that it is still progressing.

Day to day discussion is on Discord. Right now the new design is aiming at the code being able to set the graphics by allocating C++ classes, and the exe is still slow to handle python graphics, but progress continues.

 

[ev0lyeti]

I looked at a bug report, which states that cargo sold in Europe is reset on tax changes. This makes it very hard to finish the quests for being the first to sell X amount. Indeed this turned out to be correct. I just just remove the line pointed out as the issue and then... oh wait that will mess up calculations for price changes.

I examined the problem further and the more I looked into it, the bigger the issues became, so I ended up doing a complete rewrite of how traded cargo is stored and accessed. It is now split into 4 different "memories". Sold and bought in the player, used for quests. Sold and bought in one number in the king used for price changes and value of cargo traded stored in king, used for tax changes. I also had to redesign how to update those counters because the old system was so confusing that at some point somebody will use them incorrectly....again. In the end this quick fix ended up taking a week to complete, but at least now quests should work as intended.

As a bonus I added a new page to the domestic advisor, which shows amount sold and bought at the 3 locations for exports. We now finally have a screen where quest progress can be monitored. It doesn't say what the quest goal is, but you can at least see the current number.

Also sales only counts goods coming from the new world. Anything bought off map will be marked and not count in the sales statistics. This way you can't cheat completing a quest by buying and instantly selling again in Europe. I noticed that I had created this loophole by accident and then fixed it before even committing, so it never even existed at any point in the develop version.

Thanks so much for this @Nightinggale, I greatly appreciate the effort you have put into this (#1031 was my bug report).

I also wanted to add that I am very excited about the new domestic advisor screen you have added which will make quest progress easier to check up on! I had been making do with local modifications to the python script that checked against quest progress so that it would spit out the current count / target - but having to search through debug spew on EOT was cumbersome at best.

 

[Nightinggale]

Time for a much overdue update.

As a few posts have indicated, we released 4.2 as a pre-release on discord only. The plan was to get it tested, fix whatever got reported and then release 4.2.1 to the public within a week or two. We have had bugs discovered just after releases in the past, so this time should be different.

I can now say for sure that 4.2.1 is going to be delayed, but that's surprisingly a good thing. The issue is that network sync issues has required a lot of detective work to figure them out and it feels like whack a mole. Sure enough reports showed up for 4.2 and I started to really investigate. I not only found the cause of the reported issue, I figured out the pattern to OOS bugs and how vanilla code structure makes them hard to avoid. Redesigning the code structure would be an epic task, so I came up with a plan B. Since I figured out the most likely pattern of causing OOS issues, I'm adding assert checks to detect if such conditions trigger. This will allow us to play in singleplayer and get notifications like "if this was multiplayer, the would likely have gone out of sync now". This will allow testing without setting up multiplayer and even better, to some degree it will detect the issues even in autoplay, as in playing a game with only AI players. Autoplay will however not uncover bugs in the user interface, so it's not a replacement for regular testing.

The most significant finding in this is that the randomness in random events can trigger OOS. It's not specific to just one event, but rather a group of them. Some have been found earlier and marked as singleplayer only, but the majority seems to have not been noticed until now. Even worse, it seems there are events, which can trigger OOS while testing if they can trigger meaning it might even happen when they fail to trigger. That would be hard to figure out through gameplay.

No ETA on 4.2.1. For now the OOS detection system needs to be finished and then events needs to be fixed and whatever else will be pointed out by the detection system.