Feature #1375
openIntroduce superspecialists
0%
Description
Superspecialists are specialists that (1) are not counted within city population and (2) can not be assigned to or from by player or CMA.
In attached main patch, basic support for superspecialists is added (only ability to declare in rulesets and manually insert into savegames). Each city can have up to 255 superspecialists of each type. They are displayed in main citizens roster (but not in happiness rosters); probably something should be done in the future to diisplay great amounts of them since currently rosters are limited to 255 sprites and that is already not always comfortable. Probably I missed something in ruledit.
Patch requires appropriate protocol and dff version bumping.
Note that requirements of superspecialists are never checked. In my original idea, superspecialist should disappear if their reqs fall out of being fulfilled. But normal specialists seem to persist even in that case, so I did not make it. Don't know should that be a bug, seems like AI considers it impossible.
Future plans - adding superspecialists:
a) Direct Lua city:add_specialist(sp_type);
b) Defining unit specialist property, allow adding to cities units without pop value but with superspecialist value;
c) player:give_specialist(sp_type), then players can settle the specalists (not necessary super, may also add a citizen) via city interface.
(b) and (c) require AI understanding (AI any way needs a procedure to add to city useless migrants). (c) also requires GUI works I am not ready for.
Files
Updated by Alexandr Ignatiev 27 days ago
Updated by Alexandr Ignatiev 27 days ago
- File sandbox2.tar.xz sandbox2.tar.xz added
Updated by Alexandr Ignatiev 27 days ago
+ (d) changing superspecialists for cities and players in editor, that also needs GUI magic.
Updated by Marko Lindqvist 17 days ago
- Target version changed from 3.3.0-d3f to 3.4.0-d3f
- A couple of comments have a typo "superspecalist" (missing 'i')
- is_normal_specialist() beginning '{' not in a line of its own
- Does not compile:
../../src/client/gui-qt/citydlg.cpp: In member function ‘void city_dialog::update_citizens()’:
../../src/client/gui-qt/citydlg.cpp:2899:38: error: ‘pcity’ was not declared in this scope; did you mean ‘city’?
2899 | = city_try_fill_superspecialists(pcity,
| ^~~
| city
As this is beginning of a completely new feature, dropped stabilizing S3_3 target.
Updated by Marko Lindqvist 17 days ago
Some though might need to be given to the case where a ruleset changes between saving a game and loading it so that a specialist is turned to a superspecialist, or vice versa. Or does it work correctly already?
Updated by Marko Lindqvist 17 days ago
- Blocks Feature #1410: Document [super_specialist_???] section names added
Updated by Alexandr Ignatiev 17 days ago
Marko Lindqvist wrote in #note-5:
Some though might need to be given to the case where a ruleset changes between saving a game and loading it so that a specialist is turned to a superspecialist, or vice versa. Or does it work correctly already?
You will in most such cases get a warning of wrong city population. What actually could be repaired here better?
Ah, the patch brings sigsegv for rulesets where there is no superspecialists. Any way, better to be rebased over #1400, #1401.
Updated by Marko Lindqvist 14 days ago
- Blocked by Bug #1400: ruleload.c: correct error message for no default specialist added
Updated by Marko Lindqvist 14 days ago
- Blocked by Bug #1401: citydlg_common.c: correct parameter names in get_city_citizen_types() oxygen doc added
Updated by Alexandr Ignatiev 14 days ago
Hope I have corrected the patch though I tested only in gtk4.
Updated by Alexandr Ignatiev 13 days ago
Actually, more attention should be given to VUT_SPECIALIST related code. That place touched in military ai function should probably be ruled out in a separate patch at all since that function is called without filling specialist in contexts. In other places there should be probably another separate patch that will hint that superspecialists are script-regulated (when API is developed) unless a player control is currently available (that should also be developed).
Updated by Alexandr Ignatiev 12 days ago
Well, I have checked the code, likely dai_can_requirement_be_met_in_city has some useful job with specialists in adjust_iprovement_wants_by_effects (if some building provides extra specialist output). Just for the reason mentioned above we should consider present superspecialists pinned even if their reqs fall out of fulfillment. If something like this should be done to normal specialists, it is a question of a separate patch.
Updated by Alexandr Ignatiev 12 days ago
Updated by Alexandr Ignatiev 11 days ago
Alexandr Ignatiev wrote in #note-11:
Actually, more attention should be given to VUT_SPECIALIST related code.
Looked through the occurencies, likely, really nothing to change there for this case.
Updated by Marko Lindqvist 9 days ago
- Blocks Feature #1399: Lua API: specialists control added
Updated by Alexandr Ignatiev 8 days ago
Updated by Marko Lindqvist 8 days ago
- Status changed from New to In Review
- Assignee set to Marko Lindqvist
Updated by Marko Lindqvist 6 days ago
- Status changed from In Review to In Progress
- Assignee changed from Marko Lindqvist to Alexandr Ignatiev
../../../../src/server/ruleset/ruleload.c: In function 'load_ruleset_cities':
../../../../src/server/ruleset/ruleload.c:5944:6: error: 'ssec' may be used uninitialized [-Werror=maybe-uninitialized]
5944 | if (ssec) {
For some reason meson based build does not give that error, but I see it with the autotools based one.
Updated by Marko Lindqvist 6 days ago
Marko Lindqvist wrote in #note-19:
For some reason meson based build does not give that error, but I see it with the autotools based one.
gcc detects the situation with optimization level 2 that autotools build uses by default, but not with optimization level 0 that meson based build uses by default. Also meson based build gives the error when configured with '-Doptimization=2'
Updated by Alexandr Ignatiev 5 days ago
Marko Lindqvist wrote in #note-20:
Marko Lindqvist wrote in #note-19:
For some reason meson based build does not give that error, but I see it with the autotools based one.
gcc detects the situation with optimization level 2 that autotools build uses by default, but not with optimization level 0 that meson based build uses by default. Also meson based build gives the error when configured with '-Doptimization=2'
idk, I use meson and changed nothing in configuration, it runs somehow... well, initialized ssec, is the problem gone?
Updated by Marko Lindqvist 2 days ago
- Status changed from In Progress to In Review
- Assignee changed from Alexandr Ignatiev to Marko Lindqvist