- Use give_midgame_initial_units() (from patch #3812) to give units for newly created player. This also corrects behavior so that Leader units are given instead of GameLoss ones (if this ever makes any difference)

I now also tested this. It works at least technically - I'm not sure if everything makes sense for the gameplay, but I consider this ready for initial commit. We can improve it later.

(file #17648)

- Added cleartext names for values to be used in ruleset
- Added gameloss_style entries to rulesets, with comments documenting it
- More minor style fixes
- Detect the case when there's more tokens in ruleset than maximum handled
- Do not log "Empire is too small for civil war" when in fact civilwar effect for gameloss was not active
- Changed wording of log message when no more tech loot is available - it used to imply that no techs were got even if some, but not requested number, were got

(file #17585)

> - Updated to apply on svn HEAD (r22531)

Thank you for that. I guess it would have been exceedingly more trouble for me than it was for you.
(I have found other ways tho apply patches than "svn patch" but, I haven't tried them yet and I see a risk to mess up my working copy with all of my current changes.)

So now, how do we proceed? I see you fixed that capstr, too.

Can I do anything now on this topic, or should I wait for your comments after you did some testing?

(It worked for me on many games, but I don't have the latest version from trunk, and I have quite a lot of other changes in my working copy by now. There was a typo in my last post, instead of "I have /no/ more than one patch" it should read "I have /now/ more than one patch" ... .)

OK, here comes the next try.

It still doesn't contain the capstr thing, and still is against r22446.

Last time I updated to the trunk version it took me short of a day to cope with all the changes and to get everything working again, so I am very reluctant here.

Further, I have no more than one patch and many debugs in my working copy, so I have to clean each svn diff manually, which naturally is error prone. (No, svn patch does not work on my system.)

(file #17450)

Excuse me, I had a concussion and still have trouble concentrating, so I probably make even more mistakes as from natural dumbness alone.

I try to include missing packets_gen but fail, because it "is not under version control", not even when I use the original code:

$ cp common/packets_gen.h common/Imhotep_packets_gen.h
$ svn up -r22446 packets_gen.h
At revision 22446.
$ svn diff server/unittools.c server/ruleset.c server/maphand.c server/maphand.h server/barbarian.c server/barbarian.h server/plrhand.c common/packets_gen.h common/fc_types.h > gamelossStyle22446_v4.patch
svn: 'common/packets_gen.h' is not under version control

OK, I see we were talking about different things.

But I still have no idea how this patch would affect any client side capabilities.

All new features, as far as I can see, are handled exclusively on the server side.

Or has it to do something with the synchronizing issue I mentioned?

This "submit" is clearly an error, I fixed it in my working copy.

The effect is that the cities submitting are not randomly chosen, as intended, but, after the first one, picked in the sequence order the iteration provides.
So the game is playable as it is.

I will submit the correction together with potential future corrections or for this change aalone, if anyone urges me to.

I doubt if the capstr change is really worth it.

The patch is on an already old version of the quickly changing trunk, probably the whole patch will need extensive rework for the version it will finally be merged to.
(The trouble I had upgrading to r22446 was nearly more than the time it took to write the code. (I'm working on a separate modpack.))

The change is downward compatible in that a missing parameter just works out as if 0 was given, for the "classic" style.
Old versions will silently ignore this option.

So as I see it, a new capsrting will only harass any modpack developers, being forced to do replacements in many files, untimely, and, without any benefit for the final standard users.

I am more concerned about the synchronizing issue. An observer would not see a new palace nor any new GameLoss units until the next turn.

And again a new version.

On server start, not only the requested ruleset is loaded but another one before that. I was not aware of that and don't know if this is a bug, but it really did cost me a lot of time.

I still have no idea what to do with "network capstr bump needed".

Palace is removed when the cities are transferred. There is code to build a new one for the new player, along with any GameLoss units. New Palace is even built for barbarians, and I'm not definitive if this is really a good idea.

One known bug is that the Palace as well as the GameLoss unit(s) are only visible next turn. They are effectively there, but invisible. I haven't yet fond the proper functions to call for synchronization.

The player was killed ("pplayer->is_alive = FALSE;") even before I touched the code. But the civil_war-method won't work for a dead player.

The entry in game.ruleset now looks like

gameloss_style = "GAMELOSS_STYLE_BARB|GAMELOSS_STYLE_LOOT|GAMELOSS_STYLE_CWAR"

and I don't know how to get rid of the "GAMELOSS_STYLE_" prefix in the ruleset but keep it in the code (without introducing something new that probably already exists somewhere).

(file #17415)

- As new value is transferred to client side, this changes network protocol -> network capstr bump needed

ouch, yes, right one comes here

(file #17399)

here is a new version of the patch

I did a lot of debugging on other issues and I hope I did not mix in other changes, or leave out something.

There is still a known bug: neither the new GameLoss unit nor the new Palace are visible immediately but only after the next turn.

I would like a feedback soon because I am on other things and want to settle this matter to "clear my table" before differences to the trunk will make new changes necessary, and, before I get confused with the many changes on the my local version.

(file #17395)

When I tried to make a new modpack based on Ancients, I stumbled on an option "gameloss_style".
According to the comment, cities conquered from players still alive were given back to the previous owner. (So far, I found this already coded).
Depending on the parameter value, the remaining cities are either destroyed or fall to the hands of some barbarians.

On a local copy based on version 2.4.99-dev, revision 22214, I implemented some code to do this.

There is also code to have civil war (before any cities fall to barbarians or vanish without a trace).
The new player gets a palace of its own, and, a Leader (it would be unfair if the AI had no GameLoss unit to trigger all this features when we have chased them down).

Also, I coded some benefits for the player "who liberates the oppressed people from the enemy leader":

up to 3 techs are stolen

a random amount of gold is taken ("in compensation of the war efforts"), from 0 to the amount of gold the victim has had

using some interrogation, we press a (distorted) map from the captured leader

a random number of cities (about a quarter on average, with lesser probability on higher numbers) can be convinced to "join the righteous cause" of the victor

It worked on my copy on a few games, but probably has lots of yet unknown bugs (I'm new to the code and this is my first try).