ExtraModMod
- Thread starter Terkhen
- Start date
ArkhanTheBlack
Warlord
- Joined
- Sep 29, 2008
- Messages
- 150
Wow, a new release with Erebus Continent map script included. Many thanks for considering my wish. 
I'll have LAN session saturday next week with a friend and will give the new version a try.
I'll have LAN session saturday next week with a friend and will give the new version a try.
Wow, a new release with Erebus Continent map script included. Many thanks for considering my wish.
I'll have LAN session saturday next week with a friend and will give the new version a try.
You are welcome
As usual, any feedback is welcome! No one found any bugs so far? :O
Not a bug but oversight...attaching and deaattaching great generals causes "events with pictures" annoing as long as all general with names are cycled through.
Rangers are too expensive 150 hammers, and rathas too - 180
champions and horse archers and chariots are 120 for instance...
Govannon is insanely expensive 480 hammers
Although it is not the main goal, ExtraModMod includes most of the changes of Erebus in the Balance v9, which are meant to improve balance. Since my mod adds extra features that have not been taken into acount by EitB, ExtraModMod has worse balance than EitB.
@Terkhen: This issue doesn't appear in events enhanced, obviously because great generals and commanders are different units in MNAI and only Commanders have names and therefore images in the mod. I can't think of an easy way to prevent this from happening, since the mod actually should take great people from events into account. If detached commanders lose their names (I don't know whether they do), you could just stop the generic popup for nameless great people.
But scutarii, what do you mean by "as long as all general with names are cycled through"? Do more than one popup appear?
Sorry, I missed this post while checking the thread from my phone
I'm giving priority to this bug, I'll try to solve it as soon as I have some time.
In general, I prefer to not tweak balance besides the changes already included in EitB, unless they are changes to features modified by ExtraModMod exclusive features. Otherwise it feels as if I'm doing the same work twice, and also adding noise that would make merging new EitB versions more complicated. Personally I don't find those units too expensive, although honestly since I don't play at higher difficulties usually unit costs are not an issue for me.
But in vanilla MNAI, Great Commanders can also be attached and deattached. How is this issue solved for them? I failed to spot it in the merge, and since Great Generals and Great Commanders are nearly identical, the same solution should work in my case.
Oh, right. I forgot that you can also attach commanders. So the issue is probably present in my mod, too (I just tested Great Generals). I'll think about it. Maybe RifE has a solution, but if I remember correctly, they have a totally different General system.
Edit: I'll also look into the Event bug when I have time.
I have finally reproduced this issue and found the cause. It will be fixed for ExtraModMod 0.3.1. Sorry for the delay, and thank you!
Thank you
I hope to have some time this weekend to give both of these issues a look too. I plan to release 0.3.1 soon with a few bugfixes and "backports" of the MNAI 2.5 bugs that are already fixed in the MNAI SVN repository.
I also talked with Tholal a bit on the first issue; there are several problems around the SDK/python mix of commanders, unit naming etc.
I tried it again and I think there is no way to solve it without adding a parameter CvUnit::init() respectively CvPlayer::initUnit():
Both unit creation and the unitCreated python event are done in CvUnit::init(). The Great Person naming happens between these two, and it must stay there; because the python event is used by the greatpersonmod and it expects the unit already to be named (and this could be the case in other mods, too).
I already have a more or less complete solution in mind, but I've no time to write it down now; anyhow, it would include the mentioned parameter addition to two important methods and additionally some new C++ methods and exposed methods. But it should easily allow some fancy things like preventing two Barekes (you know, from event and city).
The alternative is to disable commander popups; and let commander names change and go waste through detaching.
I will try to code the first and propose it (maybe partly) to Tholal if it works. However, it could really increase the work for guys merging the mod.
Since you are actually the only one I know merging the mod periodically
:What do you think?
I assumed that there would be some way to prevent the "new unit event" from happening when recreating a unit after detaching it from another unit (as it is not really a new unit). If that is possible then we would not get new general/commander names in existing units after detaching them. To finish the solution, CvUnit could get a new attribute similar to the one that already exists for joined unit artwork (see http://sourceforge.net/p/tholalsffhaimod/bugs/149/) but that would store the joined unit's name. After a detach, the detached unit would get the name stored in the unit it was joined to in this new attribute.
I'm considering a release for next wednesday or thursday. Since the issue seems quite complicated, I don't think that we will be able to come up with a "proper" solution by then. If we don't, I'll probably adopt this as a temporal solution.
I will try to code the first and propose it (maybe partly) to Tholal if it works. However, it could really increase the work for guys merging the mod.
Since you are actually the only one I know merging the mod periodically
What do you think?
Your solution seems to require mostly DLL changes. Besides your own work and possibly EitB, I'm not aware of any other MNAI modmodmods that include DLL changes. I don't know what merge process is used by Sareln for EitB (based on his posts I guess he does it manually with winmerge or some other similar tool) but if I understood your change correctly it won't be a lot more intrusive than the usual changes that Tholal does between versions. In our case, Tholal has added new attributed and exposed them to python in the past and they have not been a big headache to merge. A Mercurial merge of this change from MNAI would probably be trivial and Mercurial should handle it automatically.
I actually just tried it, and it seems to work. I uploaded it here and here.
The functionality of picking a random name is outsourced from CvUnit::init() to the new function CvGame::getNewGreatBornPersonName(). Instead, CvUnit::init() and CvPlayer::initUnit() get the new parameter szName.
CvPlayer::createGreatPeople(), which is used (obviously) by the standard GP system and also when a player gets a free GP from researching a tech, uses the new function and parameter.
The second commit fixes the commander (not the general) beavior python-only (with the new variable thing you mentioned and scriptdata, so I had not to expose getter and setter of a CvUnit variable).
There are several side-effects; great people not created via CvPlayer::createGreatPeople() will not get a random name. I searched in python and XML and found the following cases:
... I just noticed the typo getNewGreatBornPersonName(). Will fix it soon.
The functionality of picking a random name is outsourced from CvUnit::init() to the new function CvGame::getNewGreatBornPersonName(). Instead, CvUnit::init() and CvPlayer::initUnit() get the new parameter szName.
CvPlayer::createGreatPeople(), which is used (obviously) by the standard GP system and also when a player gets a free GP from researching a tech, uses the new function and parameter.
The second commit fixes the commander (not the general) beavior python-only (with the new variable thing you mentioned and scriptdata, so I had not to expose getter and setter of a CvUnit variable).
There are several side-effects; great people not created via CvPlayer::createGreatPeople() will not get a random name. I searched in python and XML and found the following cases:
- Kidnapped GP - I think that's fine. They at least shouldn't get a new name.
- Unnamed GPs in scenarios - Also fine. I don't think there are any in the official scenarios.
- BigGoodLair GP "Prisoner" Reward - Probably should get a random name. It is handled by activation a "GoodyInfo" (GOODY_EXPLORE_LAIR_PRISONER_XXX), and should be a minor DLL change.
- Free Scientist from Secret Codes UC Resolution - I think this is also a minor DLL change just using getNewGreatBornPersonName()
- GPs from Events - Several Prophets, the Artist from the Clairone (Harpy) Event, and Bareke. I'm thinking of adding the <Name> and <bGreatPerson> (for a random name if <Name> is empty, the addition to the used GP names and maybe the global message) tags; exposing CvGame::isGreatPersonBorn(), addGreatPersonBornName() and getNewGreatBornPersonName() would offer more control to python and allow f.e. preventing the Bareke event if he's already born. But I doubt any changes here will make it to MNAI. At least for Bareke and Clairone no names are better than random names anyway.
I thought about that, too; but it would also require a new parameter in CvUnit and I think it could have larger side-effects or provoke mistakes, because a modder expects unitCreated to be fired every time a unit is placed on the map.
As I said, I did that for the commander. You merged the two, right? So you use the General "lead troops as a warlord" action and not the commander spell? If so, my solution (in the second revision) won't work; you'd have to do that variable and expose at least a getter to python, since "split general" is a spell.
OK then
... I just noticed the typo getNewGreatBornPersonName(). Will fix it soon.
ArkhanTheBlack
Warlord
- Joined
- Sep 29, 2008
- Messages
- 150
Tried it last weekend, but we couldn't get it to work in multiplayer. No LAN games were shown from each other. We just copied the new version over the old one which was working. We checked the folders from both computers and both were identical.
When we went back to the old version by using a backup copy we could play without problems again. No idea what's causing the problems.
When we went back to the old version by using a backup copy we could play without problems again. No idea what's causing the problems.
The Event Bug posted by scutarii is not in events enhanced. Looking at your repository, it seems you accidently left out the following line at the beginning of the function "canTriggerEsteemedPlaywright":
Code:
kTriggeredData = argsList[0]
player = gc.getPlayer(kTriggeredData.ePlayer)
I would recommend changing the 'Organized' w/ Cassiel to something else ...
say Cultural, Ingenuity, Agrarian, back to Industrious perhaps, maybe even Sage even though it overlaps with Philosophical.
Something other than Organized ... b/c Organized is just completely useless in the first 75 turns (and doesn't really fit in with Grigori lore any more than cultural would)
say Cultural, Ingenuity, Agrarian, back to Industrious perhaps, maybe even Sage even though it overlaps with Philosophical.
Something other than Organized ... b/c Organized is just completely useless in the first 75 turns (and doesn't really fit in with Grigori lore any more than cultural would)
Similar threads
