[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.

 

[Jaded1]

This is great news. I've been holding off playing WtP for months knowing there is a major overhaul being worked on. And for months I've been checking this page to see if there are any updates. Now I know that it could be a matter of weeks before I get to jump back in to one of my favorite mods. So thanks for all your hard work.

 

[Nightinggale]

One of the huge issues holding back development and sometimes bugfixes is XML. XML is a good tool to configure game setup data without having to validate new code. However the problem is that we do have a lot of it. Say we want to change something about events and then we need to update every single event in XML to reflect this change. We currently have 1464 entries. That's a lot if each has to be updated manually.

I have now added a bit of C++ code called XMLUpdater, where it is possible to in simple terms write what you want to update (change value, move, rename, delete etc) and those instructions are then called on each entry in whatever XML file is specified. As proof of concept I changed required PlotType for event triggers from a single entry to a list of valid PlotTypes (it can now trigger on both hills and mountains). That works, so we are off to a good start.

This will help to clean up xml files and add new data. This can be used to make events more configurable, which in turn will allow configurations, which solves some of the current issues like land units spawning on water. Of cause there are plenty of XML files to work on with this, but events and event triggers are the most obvious candidates because those are the ones with a massive amount of entries, through units (292 entries) and buildings (234 entries) would also be good candidates where this can be a huge time saver.

Part of the beauty of the XMLUpdater design is that it relies exclusively on tinyxml2. This means no exe or mod specific files. Any mod including BTS mods should be able to use this, through it does rely on the schema to set the tag ordering, which means it excludes any mod, which uses a different schema format (looking at you C2C).