You are thinking in modern terms. It just didn't work like that in a feudal system with widespread usage of serfdom. If the new world recruits weavers, the number of weavers would drop in Europe. This would make it less likely for weavers to go to the new world because serfdom meant they would need a written permission from the local lord and unsurprisingly he didn't like losing the few educated people he had, particularly not losing weavers if orders from the king just took some weavers away from him. One reason why the local lord had this power was because he had the duty to ensure supply to the people. If he didn't have enough farmers, he would have to buy food from elsewhere for his own money to meet demand. Because of that he was strongly encouraged to ensure he had enough farmers.
I like this. I don't see the manpower to do it within the near future, but maybe somebody wants to do it? We will always accept help from more people. If we can have a team of a decent size, then we can do something like events where one person makes the events and another add the needed programming changes to support new ideas. In fact we can use more people for all tasks, even as non-technical as filling in more historical text for the colopedia or translating.
I would still love to include it, but it's currently not on the roadmap for 2.8. While it would be awesome to include everything we want, doing that means it would take forever to make the release ready. We have to be realistic and accept that something might be several releases into the future.
Now I start to wonder if I should write an overview of what kind of tasks there are for modders because programming is just one out of many. WTP currently have precisely 0 people who can't program and that might make the illusion that programming is everything for modding. In fact I would dare to say we need more non-programmers because we need to figure out what kind of game mechanics we want from the player's point of view and programmers tend to "pollute" the mind with "how do I code this".
Programming is kind of like driving a car. Moving to a new car with all the buttons and stuff in different locations is much less of an issue than getting into a car for the first time. Sure you need to pay attention to learn new locations, but fundamentally it's the traffic laws, same laws of physics etc. Programming is the same. If you understand the concept of programming, code structure etc, then moving from one language to another isn't difficult (as long as you aren't picking something obscene like caml).
Sounds good. Planing retirement as an endless vacation sounds nice, but within a week or two it becomes obvious that it's a plan for watching grass grow.
Perhaps you should have a background list of each unit type with a pool that tells how many Farmers, Lumberjack, etc are there in Europe at the start of the game. This is 100% of that profession.
We can use CivEffect for that. The idea is that a player has a number of CivEffects and adds the numbers from each. Take for instance the number of units on the dock. The default CivEffect gives +4. Give the player another CivEffect, which provides +1, bringing the total number up to 5. The game now know it's 5 without any looping or other code to figure out the number. This means it doesn't know why it's 5, but the knowledge of the result is enough for what it needs to do. This means (unlike vanilla), adding more CivEffects will not slow down the game. The tradeoff is that whatever it stores needs to be able to add a CivEffect and then remove that CivEffect and return to the original number. This is a problem for multiplication and division due to rounding issues.
