[We the People] Development "diary"

[Kendon]

Hello, I can translate to Spanish.

I just finished revising the English version of Game Concepts. It went on GitHub this morning. Sometimes the Spanish version, along with the Italian, simply repeats the unrevised English. Having a complete Spanish Colopedia would make the game easier for a lot of players.

The new revisions recognize some changes to gameplay. Check the English as well as German texts.

 

[Nightinggale]

Sometimes the Spanish version, along with the Italian, simply repeats the unrevised English.

Ideally we should delete those. They are from a time when the game would crash if a string was missing. I updated it to use English instead. The game also logs all missing strings from the translation in question making it easier for future translators to find those strings.

Having a complete Spanish Colopedia would make the game easier for a lot of players.

I agree. Ideally we maintain at least the 5 languages, which comes with vanilla, though even more would be good. No I still haven't forgotten about Russian.

 

[Fürstbischof]

Sometimes the Spanish version, along with the Italian, simply repeats the unrevised English.

Ideally we should delete those. They are from a time when the game would crash if a string was missing. I updated it to use English instead. The game also logs all missing strings from the translation in question making it easier for future translators to find those strings.

On several occasions I've spotted "translations" which covered only a few words and then disregarded the entire English text. Maintaining non-translated texts is quite cumbersome since these are .xml files. Notepad++ doesn't help you much beyond its obvious qualities.

Having a complete Spanish Colopedia would make the game easier for a lot of players.

I agree. Ideally we maintain at least the 5 languages, which comes with vanilla, though even more would be good. No I still haven't forgotten about Russian.

Translating WTP is not an easy task if you can't rely on native speakers. I've done this nonetheless for the VIP mod for the old Paradox title Victoria. I'd to rely on machine translations which are today surprisingly good but, sadly, sometimes fail utterly. Quality control would have been nice but the huge amount of translated text involved scared interested parties away. I've added French, German, Spanish, Italian and Portuguese translations.

If you'd like to give a try I'd recommend DeepL which is better than Google Translate.

 

[Nightinggale]

Hello, I can translate to Spanish, if needeed.

Also, the new ideass of great rivers, military upkeep are great.

That would be most welcome. You can join our discord and we can talk about how to get you started.

On several occasions I've spotted "translations" which covered only a few words and then disregarded the entire English text. Maintaining non-translated texts is quite cumbersome since these are .xml files. Notepad++ doesn't help you much beyond its obvious qualities.

It would be awesome if we could have a better interface for translators, but that would require somebody with time to program it. Would be awesome if we would have a system to keep track of translations.

 

[Maximus123]

That would be most welcome. You can join our discord and we can talk about how to get you started.

Great, I´ll join soon.

 

[CurtnoAnna]

I just finished revising the English version of Game Concepts. It went on GitHub this morning. Sometimes the Spanish version, along with the Italian, simply repeats the unrevised English. Having a complete Spanish Colopedia would make the game easier for a lot of players.

The new revisions recognize some changes to gameplay. Check the English as well as German texts.

Where do I download this

 

[Kendon]

Where do I download this

Go to the "Grammar, Style and the Colopedia" thread, page 2, about halfway down. The download includes updates to all English text, not just Game Concepts.

 

[CurtnoAnna]

Go to the "Grammar, Style and the Colopedia" thread, page 2, about halfway down. The download includes updates to all English text, not just Game Concepts.

Got it, thanks. I appreciate your effort doing the work on this !!!!!

 

[Nightinggale]

CvUnit::canHaveProfession partly broke the world builder feature, which allows changing professions on units on the map in WB. This was noted because people can't use WB to create settlers. I now disabled the check for "is unit in colony" and for available yields as well as changing yields when changing profession, obviously only when inside world builder. This allows world builder to change a unit into a settler. Is it cheating? yes, but all of world builder is cheating.

I have to say that I think canHaveProfession is a bit messy. That's not great because it's important and it's performance critical. I would like to clean up profession restrictions, add whitelist and blacklist to which professions a unit can have and a whitelist to professions, which then tells which units can have it. Post xml loading, those 3 lists can then merge into one list for each unit to tell if the unit can have each profession. This way when checking if a unit can change profession during the game (read: time critical for AI), a lot of the checks can be replaced with checking that EnumMap (of bools). Much faster than the current "if fishing boat, then, else if whaling....). It also makes it more clear for xml modders how to handle such restrictions.

Same with being able to change profession outside colonies. That should be a bool in xml rather than hardcoding checking for certain units.

Looping yield costs should be done using InfoArrays rather than JIT arrays. That way they will loop all non-zero values instead of looping everything. Skipping looping for professions without any cost was my first Colonization modding optimization. Reduced AI time from 40 to 33 seconds in my test savegame, hence a very time critical part of the code. However it seems that there is even more time to save here.

Since those updates relies on InforArray, I better start with my planned update to that one to make it cause a compile error is type is mismatch rather than runtime assert failure.

Yeah this isn't likely to be in the next release. Still it would be good to add eventually as better performance and more automated error detection would be good.

Speaking of automated error detection, I have added some to make the compiler not accept mixing enum types. It has already caught one vanilla bug where if two players are on the same team, if a player does something (trade in Europe I think), updating the circles on the map is done for only one player when it should be for both. Somehow it doesn't seem like a serious bug as I can't really tell when it would trigger and if so, it will only last until the player selects a new unit. However I still consider it an important bug fix because nobody spotted the bug. Instead I taught the compiler to look for certain types of bugs and it found this one for me. As such if a modder creates a new bug of the same type (mixing types, like BuildingTypes == BuildingClassTypes), then the compiler won't accept it because we know it's a bug. It makes the code more resistant towards introduction of new bugs.

 

[raystuttgart]

@Nightinggale @Schmiddie @Kendon @Mr. ZorG @Raubwuerger @devolution

As it seems, @Nightinggale has merged "Large Rivers" with the current Release candidate.
It seems that he created a new branch for that, which we will use to finish the upcoming release together.

Thus for the moment, please everybody who has been working in "Large Rivers" until today or now wanted to continue working on it,
please hold your commits until @Nightinggale has told us where we will work for the upcoming release.

I suspect it will be the newly created branch "river_merge", but I simply do not know yet for sure.
Maybe this is also just a temporary branch and another merge with other branches of @Nightinggale and @devolution may happen.

Once this is clarified we will of course help everybody not experienced with GIT to set up their new local repository again, do not worry.
If needed we can also make e.g. a Zoom session to guide you all through with screen sharing.

Summary:

Let us simply wait for @Nightinggale (our GIT expert and admin) to explain us all what to do.
Thanks in advance for your patience and sorry for this small inconvenience.

----

Further information will surely also be available soon in WTP Slack team chat and in WTP discord.

 

[Nightinggale]

We are back to developing on just a single branch again. I merged large rivers with release candidate 2.8. Due to being careful, assuming something could go wrong, I made a new branch called river_merge as this would allow me to discard the merge and start over if something went wrong without messing up the git history. That's still an option, but it looks like it went fine.

The plan from now on

• Make sure river_merge is working as expected
• Apply the fixes, which were not done earlier due to fear of merge conflicts
• Fix whatever issue we encounter. This can be skipped if it's time consuming and not critical
  
• Release river_merge as the next release
• Delete branches we no longer need and update others to allow us to return to branch naming convention

New feature development
Work on new features will resume once this is done. However stricktly speaking it's not impossible to make new features in a new branch, which we then merge after releasing. We will consider that on a case by case basis.

Text updates
Text updates (text xml) is an ongoing process and can continue. That doesn't count as "new features".

Savegames
Savegames from last release should work fine and so should savegames from the Release Candidate 2.8 branch. Savegames from Large Rivers won't work. Obviously savegames from before large rivers was added won't have large rivers in them.

Features unlikely to be included in the next release

• Large rivers in random maps
• Fix for the ongoing OOS issue

There is work going on for those and including them will be nice. However without knowing if they will be ready in a week or 3 months, releasing now and then releasing again once they are done seems to be the proper plan.

New long term plans
What to do now that large rivers are done? That's always up for debate, but a candidate is technological progress. This concept has a technical plan (programming and xml), but lacks a gameplay plan. It would be nice if we could debate this and figure out how we want to progress through techs from a gameplay perspective before we reach the point where programmers will need a new task.
I'm not sure if that will be the next big thing, but I know it won't if we still can't figure out or agree on how it should unlock from a gameplay perspective.

 

[Schmiddie]

How do I get the current version for testing?

 

[Nightinggale]

How do I get the current version for testing?

You switch to the river_merge branch and then you compile the dll or get somebody to do it for you.
I have written a guide called How to play the development version. Assuming you have the compiler and perl as told by the guide, you should be able to double click the compile release bat file and get the dll. I have made some changes since you last tried. Now it is better tested to be auto configuring and it has worked for multiple people, including me when I borrowed a computer without any compiler on it.

Good question btw. It will likely be easier to get feedback if people know how to playtest.

 

[raystuttgart]

We are back to developing on just a single branch again. I merged large rivers with release candidate 2.8.

Finally we are on track again and work on one main branch to hopefully soon publish a release.

Due to being careful, assuming something could go wrong, I made a new branch called river_merge ...

Yeah, better be a bit careful than later regret hastiness.

The plan from now on

• Make sure river_merge is working as expected
• Apply the fixes, which were not done earlier due to fear of merge conflicts
• Fix whatever issue we encounter. This can be skipped if it's time consuming and not critical
  
• Release river_merge as the next release
• Delete branches we no longer need and update others to allow us to return to branch naming convention

Sounds great.

Work on new features will resume once this is done.

Makes perfect sense.

However stricktly speaking it's not impossible to make new features in a new branch, ...

We should at least try to be a bit more disciplined now even if it is really tempting for myself.
Let us not start completely new big changes until we finished and published the release without really good reason.

We will consider that on a case by case basis.

Very reasonable compromise.

Everything that is bigger than 2 days and not yet started in the branch should be discussed and approved first in the team.
(Smalls stuff almost finished or only needing integration is a different story. "Low Hanging Fruits".)

• It would be unfair to the rest of the team that focusses on tests, improvements and bugfixes.
• It would also be unfair to community that had to wait for so long for a release.
• We simply need a proper and stable relase to continue development of new features again

Text updates (text xml) is an ongoing process and can continue. That doesn't count as "new features".

Absolutely.

• Text and translation improvements are improvements
• The same for improvements of existing graphics.
• Also the same for small XML balancing as result of testing or discussions in forum.

Features unlikely to be included in the next release

• Large rivers in random maps
• Fix for the ongoing OOS issue

We simply do what we can within the next weeks and then simply publish - even if it is just another "test release".
As we said, we should not wait for months anymore because of "not being perfect".

... releasing now and then releasing again once they are done seems to be the proper plan.

Absolutely, we need to move forward now again.
Step by step we will finish and improve things like we always did.

New long term plans

Yeah, we need to have an agreemenet and a plan for the next release after we published the upcoming one.

 

[Schmiddie]

You switch to the river_merge branch and then you compile the dll or get somebody to do it for you.
I have written a guide called How to play the development version. Assuming you have the compiler and perl as told by the guide, you should be able to double click the compile release bat file and get the dll. I have made some changes since you last tried. Now it is better tested to be auto configuring and it has worked for multiple people, including me when I borrowed a computer without any compiler on it.

Good question btw. It will likely be easier to get feedback if people know how to playtest.

Finally got it - thank you!

 

[Nightinggale]

I will need help with this. The guide seems to be for experts which are know what to do...

The guide is work in progress, like the planned screenshots are still missing. Some people have however managed to compile using that guide. Good, but not good enough until it can get everybody to compile.

 

[jooe]

You switch to the river_merge branch and then you compile the dll or get somebody to do it for you.
I have written a guide called How to play the development version. Assuming you have the compiler and perl as told by the guide, you should be able to double click the compile release bat file and get the dll. I have made some changes since you last tried. Now it is better tested to be auto configuring and it has worked for multiple people, including me when I borrowed a computer without any compiler on it.

A big Thank You @Nightinggale for that guide and the "compiler" git package! I had been trying to set up the compilation environment several times in the past but always something would not work - I have not really been using Windows for about 8 years, and updating everything to make Visual Studio work etc. always got me stuck somewhere and I gave up.

There were a few problems even with your guide yesterday where Github Desktop would not complete the cloning but it seems to be fixed with an update I just received. But just cloning with command line git in Linux and only doing the compiling in Windows also was an option.

Well, I just completed compiling my first own CvGameCoreDLL.dll time to reboot and try it out. BTW running Civ4Col in my GNU/Linux installation actually feels more performant than in Windows. And the fonts are more readable ...
Time to do some testing. If my job (I'm a doctor in intensive care ...) allows, I might even try to help fixing a bug or two some day ...

//EDIT: Might be a good idea to advertise that compilation guide somewhere more prominent in the forums, like an own sticky post "compilation howto" etc. ...

 

[Nightinggale]

always got me stuck somewhere and I gave up.

It might be hard to imagine now, but the first time I tried, I also gave up. Compiling the DLL is unreasonably hard. It doesn't help that not all forum posts about compiling the DLL contains correct information.

I put in the effort to write scripts because I consider it a problem if people can't compile. It hurts mod development. Also the mod is intended to be played, hence it would be best if anybody can compile.

I still need to write a proper guide on how to do it through. The one on the wiki is rushed and lacks screenshots and the text could be better. It does however serve its purpose as multiple people manage to compile without asking other people for help.

 

[CurtnoAnna]

Holy ****. I created a DLL and I'm not that great at stuff like that. I don't know if I could do it again. So I loaded 2 continents and there are rivers created. Have any other maps been set up for rivers yet?

Thanks for all the great work on this mod.

 

[Nightinggale]

Have any other maps been set up for rivers yet?

All except RAR Americas Gigantic and RAR Americas Gigantic - random have rivers added.