Thesis: 100% Dynamic Aristocracy

[Lav]

Okay, what follows is definitely not a working code, but just a lot of theorising and untested ideas. Therefore criticism and comments are extremely welcome.

It is theorized, that it's possible to create a working framework supporting a fully dynamic aristocracy system for Warband, with possibility to have NPCs 100% dynamically-generated from mod-defined templates.

To a certain extent this has been done before by "rewriting" a hero troop record with new name, xp/level, attributes, skills, proficiencies and equipment. However this method does not allow for face randomization, as even tf_randomize_face hero troops only get their face randomized at the beginning of the game, and never afterwards. So any replacements in the existing pool of heroes will inevitably have the same face as their predecessors. This fact imposes and additional limitation on the amount of heroes of different nationalities - if you need more Sarranid heroes than you have hero troops defined, you are out of luck.

As someone who is not satistifed with half-measures, I've been trying to devise a way to have fully dynamic heroes, up to and including a unique randomized face for each and every one of them. For quite a time I considered the idea of not using hero troops at all (with the exception of the player), but this idea was eventually scrapped due to two major problems: leveling of player's companions, and party skills.

However after some consideration, I came up with similar, but entirely different idea: instead of substituting hero troops with randomized DNA-generated regular troops, we should only substitute their looks.

Hero troops remain in the game and function absolutely identically to how they always worked. What changes are implemented, however, are as follows:

1. All hero troops become associated with an "image-troop" - essentially a 1st level regular troop with a defined face range for face generation. Essentially, this boils down to two slots: one referencing the image-troop ID, and another containing the unique hero DNA.
2. Actual hero troops are used in real parties and party templates, as well as for inventory handling and auto-resolve calculations.
3. For all tableau-related scripts generating a picture of the hero, instead of the hero troop him/herself, his/her image-troop is used (with overridden equipment). This includes party window ("tableau_game_party_window"), inventory window ("tableau_game_inventory_window"), character window ("tableau_game_character_sheet") and troop notes window ("tableau_troop_note_mesh"). Face generation interface in Edit Mode will not be affected, therefore it becomes impossible for player to change hero faces in Edit Mode.
4. Agents generated from image-troops with overridden attributes, skills, proficiencies and equipment are used in actual missions. The easiest and most generic way to achieve this is to make a basic on_agent_spawn trigger shared by all missions in the game, which will replace the generated hero agent with a DNA-initialized agent spawned from associated image-troop.
4.1. Since all image-troops are level 1, an additional trigger is necessary to grant extra HP to the spawned agent, as well as to render him/her unkillable (or a different trigger handling the death of said agent in order to support the lord permadeath feature).
4.2. Since all image-troops are level 1, an additional trigger is necessary to grant extra XP to whoever defeats the agent.
4.3. Since actual agent is replaced, any mission-caused changes to troop health and equipment must be handled by a separate script at the end of the mission.
4.4. Since regular troop cannot be correctly handled by tf_civilian flag in mission template, any missions involving enforcement of civilian-only grade clothing must be handled by a separate trigger and/or script.
5. All dialogs with the hero-troop must initialize the appropriate variables and immediately proceed to the dialog with image-troop, which will then proceed as normal, while pretending to be the actual hero troop. Note that dialogs will need additional support for quest handling - to retrieve the hero-associated quest in the actual hero dialog at the beginning of the conversation, as well as to ensure that any hero-related dialog gets created with association with appropriate hero by assigning the quest through an auto_proceed dialog with the actual hero troop.

It is theorized, that once implemented, this set of functionality will grant the modder with complete freedom with using it's hero troops - essentially, absolutely any hero troop record can be used to create absolutely any type of hero - kingdom monarch/lord/lady, village elder or arena master. Essentially, the mod will contain the list of potential heroes, and use it dynamically to allocate heroes and create new ones, changing their faction, age, gender, face, attributes/skills/proficiencies and equipment as necessary.

Spoiler: The sensible question

Is it worth the effort, though?

Spoiler: And the answer seems to be

No.

 

[Jarvisimo]

I will be soon working on a system where when a lord dies he is replaced by a new lord with a different name and face.

Not sure if that's similar to what you're doing but this would probably help - so I'll be showing particular interest with this thread.

 

[Lav]

I will be soon working on a system where when a lord dies he is replaced by a new lord with a different name and face.

Not sure if that's similar to what you're doing but this would probably help - so I'll be showing particular interest with this thread.

Ah, but that's the point - you cannot change the face of a hero troop, at least according to the results of my testing runs. Even for tf_randomize_face NPCs, it is randomized at the beginning of your game, and remains static forever. So the only way to get a new face is to use a troop.

Unless I made a mistake in my tests somewhere, of course.

 

[Jarvisimo]

Hmmmm. Hmm diddlie-hmm.

There's no way to assign a specific face code in-game?

In edit mode you can change the faces of NPC's as you would in character creation halfway through the game - perhaps that could have clues. Maybe you could make a bunch of faces you like, then just make a randomiser to assign them to the newly created hero.

This is all hypothetical. No idea if it'd work.

 

[Lav]

Hmmmm. Hmm diddlie-hmm.

There's no way to assign a specific face code in-game?

In edit mode you can change the faces of NPC's as you would in character creation halfway through the game - perhaps that could have clues. Maybe you could make a bunch of faces you like, then just make a randomiser to assign them to the newly created hero.

This is all hypothetical. No idea if it'd work.

As far as I know, it won't. You can do a lot of stuff in Edit Mode, this doesn't mean you can do the same stuff through scripting. And heroes with randomized faces get their faces randomized when you start a new game, and from then on they persist through savegames. The only way to get a new face through scripting is to spawn a regular troop with a different DNA code.

 

[Jarvisimo]

What about making lots and lots of new lords as entries in module_troops (say, 150), and adding them as troops which are never used.

Then when a lord dies, make his fiefs belong to the new lord and assign the new lord to the old one's faction?

 

[scrdest]

What about making lots and lots of new lords as entries in module_troops (say, 150), and adding them as troops which are never used.

Then when a lord dies, make his fiefs belong to the new lord and assign the new lord to the old one's faction?

You could probably look into the code for lords going into exile outside of Calradia and try to reverse it with pre-made lords.

 

[Lav]

What about making lots and lots of new lords as entries in module_troops (say, 150), and adding them as troops which are never used.

Then when a lord dies, make his fiefs belong to the new lord and assign the new lord to the old one's faction?

That is possible, and AFAIK has been done on a few occasions. You will need a large enough pool of lord entries for every available culture, and a player dedicated enough to eradication of lords from a specific culture eventually will still be able to exhaust a list of lords of any size. Of course, by that point you'll probably be able to start re-using earlier entries as such a player is unlikely to remember the face of each and every lord he slew.

Of course, this solution will result in kilometer-long list of lord entries in module_troops, and technically you are not dynamically generating new faces on demand, you just pick them from a large enough supply. So from a certain perverted point of view, this solution is thus much less elegant. Hell of a lot easier to implement than mine though.

 

[Jarvisimo]

Yeah, well, it's the only way I can think of. But then, I've never been the best coder. 

Let me know if you get it working, I'd love to use it in my mod if you make it OSP!

 

[Lav]

Yeah, well, it's the only way I can think of. But then, I've never been the best coder. 

Let me know if you get it working, I'd love to use it in my mod if you make it OSP!

This is mostly a mental exercise for me. And even if I ever make it a reality, which I doubt, it definitely won't be OSP - because one of the steps for installing such a pack would be "and now throw away your entire module_dialogs.py and re-write it from scratch".

 

[Jarvisimo]

Why is that necessary?

P.S If you're not doing it I'll do it, if you're willing to help me out when I inevitably get stuck.

 

[Lav]

Why is that necessary?

Because:

5. All dialogs with the hero-troop must initialize the appropriate variables and immediately proceed to the dialog with image-troop, which will then proceed as normal, while pretending to be the actual hero troop. Note that dialogs will need additional support for quest handling - to retrieve the hero-associated quest in the actual hero dialog at the beginning of the conversation, as well as to ensure that any hero-related dialog gets created with association with appropriate hero by assigning the quest through an auto_proceed dialog with the actual hero troop.

This might not look like much, but is actually a hell of a work. Not really something I would wish to do with an already working and debugged dialog system. Start from BareBones though, and everything becomes much easier.

P.S If you're not doing it I'll do it, if you're willing to help me out when I inevitably get stuck.

Sure, go ahead.

 

[Lumos]

I have thought about this, and I unfortunately think it's not really worth the effort. But then, I'm a lazy wanker, so you shouldn't probably listen to me.

I did, however, think about scrapping the entire tf_hero flag and all its uses, because if your code is foolproof enough, you won't be spawning extra copies of that troop where they shouldn't be, and as far as I remember, party leaders can be regular troops as well. Then, the regular hero troop lists can be reused to repopulate them with new entries, though there may be a problem with saving the data, as the game didn't save something that was not on a hero troop... was it the inventory? Was it the name after it gets changed? (It's 02:00, I should NOT be posting so late...)
I'll dig into this a little bit more tomorrow and finish my thought then, because if this can get pulled off, the only non-procedural thing left is the map itself.
And whether it's worth it be damned. Challenges are meant to be broken.

Please excuse me if this post was a load of crap. I blame the time for being late. (If that makes any sense.)

 

[Somebody]

You wouldn't necessarily need to scrap the entire dialog - most of the calculations are done using the generic globals conversation variables $g_talk_troop, etc., which you can override from the top level.

 

[Lav]

I did, however, think about scrapping the entire tf_hero flag and all its uses, because if your code is foolproof enough, you won't be spawning extra copies of that troop where they shouldn't be, and as far as I remember, party leaders can be regular troops as well.

Note that you'll also lose the party skills information that the game provides to you in the party window. Actual effects can be recreated with scripting, but that tiny bit of information unfortunately cannot.

Then, the regular hero troop lists can be reused to repopulate them with new entries, though there may be a problem with saving the data, as the game didn't save something that was not on a hero troop... was it the inventory? Was it the name after it gets changed? (It's 02:00, I should NOT be posting so late...)

Well, it's not difficult to test. Inventory and name changes do not persist through the savegame. Attribute/skill/proficiency changes persist. As a test, I also gave some xp to the regular troop - and the troop did increase it's level/HP and got all those extra attr/skill/prof points and all this information also persisted through the savegame. Nice thing is that such a regular troop can be leveled up in the character screen just like a normal hero, and the player will never know the difference.

As for inventory and name, they do persist until the player saves the game. Which means you would have to regenerate the names each time the game is loaded (by detecting this event somehow) and you would have to implement some kind of inventory storage for your regular-troops-turned-heroes (either with slots, or with "hidden" hero troops).

And whether it's worth it be damned. Challenges are meant to be broken.

Yep, that's the spirit.

 

[Lav]

P. S.

Which means you would have to regenerate the names each time the game is loaded (by detecting this event somehow)...

Actually, since items added to regular troops inventory do not persist - detection of the game being loaded should be rather simple. Make a single "trp_savegame_detector" and give him some useless item that would normally stay in his inventory (trade good or book or something similar). After that, just check it regularly. If it disappeared - voila, that dirty cheater of a player apparently loaded a save! So add the item back and continue detecting.

 

[DerGreif]

That would all be so easy if the operation troop_set_face_key_from_current_profile would work in single player, too. I do not think that this would need a lot of coding by taleworlds to open up this possibility. I always wonder why the game lacks so much dynamic. There are so many things which would be great if you could change or add them in game by scripts.

But interesting idea for a work around.

 

[Jarvisimo]

Well, as I said I'll have a crack soon enough. Got a lot of stuff on in real life over the next few days but hopefully the week after next I'll be going full speed ahead.

 

[Dusk Voyager]

Inventory and name changes do not persist through the savegame.
[...]
As for inventory and name, they do persist until the player saves the game. Which means you would have to regenerate the names each time the game is loaded (by detecting this event somehow) and you would have to implement some kind of inventory storage for your regular-troops-turned-heroes (either with slots, or with "hidden" hero troops).

Playing with header files, maybe you could try creating a copy race with an ID equal to the value of tf_hero so that you can turn them into heroes when changing their race and back.

PS. you'll have to remove the gender mask though.

 

[Computica]

Wow, I'm glad I'm not the only one that thought about this but I have to admit that I'm ahead of you all on this. My version is to make the entire Hero NPC system to be randomly generated from troop sets and code rules.