Thoughts on a community DLL

[whoward69]

Proposed Feature:
Multiple leaders per civilization.

Note that the Leader key is placed into the saved game header, which is then used in the load/save screens, so although (with a serious amount of effort overriding values as the game loads) you can get multiple leaders per civ, the save game will always show the first leader in the list

 

[Hambil]

I'm starting to develop a real love hate relationship with Firaxes and modding...

 

[whoward69]

I'm starting to develop a real love hate relationship with Firaxes and modding...

Join the club, and/or stand in line

 

[Hambil]

Note that the Leader key is placed into the saved game header, which is then used in the load/save screens, so although (with a serious amount of effort overriding values as the game loads) you can get multiple leaders per civ, the save game will always show the first leader in the list

I think I have a way around this. Create clone civilizations with everything identical except the leader and UA. Basically a new civ, but we're going to treat it a bit special in that we aren't going to allow the AI to pick any of the other civs 'blocked' by the player selecting this one.

Don't know if there are still problems hidden in that, but it's another way to approach the issue. It may not even need DLL changes, depending on how easy it is to control the AIs initial civ choice.

Edit: This looks doable in game setup (C:\Program Files (x86)\Steam\SteamApps\common\Sid Meier's Civilization V\Assets\UI\FrontEnd\GameSetup) lua. but I'm not 100% sure, yet. Actually LoadScreen.lua seems to be the correct place. Yes, another mod that can be done in lua and added to my growing list and not a DLL feature. Someday, I'll find something to add to this DLL besides iterators

 

[whoward69]

Don't know if there are still problems hidden in that, but it's another way to approach the issue. It may not even need DLL changes, depending on how easy it is to control the AIs initial civ choice.

Lot of work creating the duplicate civs, but the AI selection bit is fairly straight forward as in the game setup screens you can update the DB directly (in this case AIPlayable) and the game will pick the changes up straight away (ie the DB C++ cache isn't active until the game starts) - see mods like Really Adv Setup.

Could all be done in XML/Lua this way

 

[Hambil]

Proposal:

DLL fix to keep free buildings from being destroyed on city capture. e.g.
Library -> Great Library
Wall -> Great Wall
Lighthouse -> Great Lighthouse
...

Since wonders can't be destroyed, and these buildings are granted free because of game mechanics (the Great Library is a library, etc...) then I think this is a bug we should fix. I want it done at the DLL level because the DLL does some odd stuff on city capture (it destroyed and recreates the entire city).

This is now officially a DLL proposed feature due to the inability of the lua API (as far as I can tell) to grant free buildings. It's being classified as a feature, not a bug I know there was some discussion on that at first.

 

[Hambil]

Proposed Minor Feature:
Auto-purchased faith units appear next to the city if the city is full.

 

[Hambil]

Proposed Bug Fix:
GEs complete a build/wonder immediately (if they can complete it in one turn). This stops the edge case where you can use a GE and still get beat to a wonder; losing both the wonder and the GE - which makes this a bug fix IMHO.

 

[whoward69]

There is already a mod that does this - http://forums.civfanatics.com/showthread.php?t=478971

Also, IMHO, not a bug - it's a calculated risk - so it needs to be optional. By the same logic you could argue that bought units not starting with movement is also a bug (as you could buy a unit in a city under attack, not be able to fight with it, and then lose the unit when the AI captures the city in their turn)

 

[Hambil]

There is already a mod that does this - http://forums.civfanatics.com/showthread.php?t=478971

Also, IMHO, not a bug - it's a calculated risk - so it needs to be optional. By the same logic you could argue that bought units not starting with movement is also a bug (as you could buy a unit in a city under attack, not be able to fight with it, and then lose the unit when the AI captures the city in their turn)

Someone once said one mans bug is another's feature. I hate this behavior with the passion of a thousand suns. Looks like the mod you pointed to uses UnitPanel to fix. I'll have to look into what it is doing. If it can be fixed in lua I reluctantly remove it from the proposed list though. Unless there is something we can do to make it easier (e.g. missing events) which seems unlikely or perhaps not worth it in this case.

 

[Pazyryk]

Yes, definitely not a bug. I feel the same way about 1upt for civilians: it's an annoying feature that adds not a single positive value to the game. But I don't call it a bug.

However, I like the idea very much. One thing I think Civ needs more of is instant sensory feedback. I want to see/hear that wonder popup the instant I use the GE. The "strategy" value added by the 1 turn risk is zero or close enough to zero.

 

[Hambil]

I've been thinking about this overall project, and how to explain my idea for it, and why I think it's useful/needed. A very good recent example came up. Some discussion occurred around the idea of creating a combat log. It was suggested that there is an event in the R.E.D. dll (and possibly merged with Whoward's I haven't checked) that would be very useful for this.

However, as a mod author let's say I want to write and release a combat log. I don't mind it being dependent on a dll, but it's a problem if that dll also introduces a lot (or really any) on by default functionality. Because it is now incumbent upon me to explain not only that they need to get such-and-such a dll, but that they need to customize it.

Or I need to customize it and/or release my own DLL with the mod.

A community dll, that only extends the ability to mod, and does not add functionality would solve the above problem(s).

I've been talking about adding features mostly because I can't seem to get anyone interested in the more generic and powerful (IMHO) idea and I'm trying to get people involved.

Ah well. I have time (in theory) and perhaps if I just keep plugging away trying to demonstrate what I intend, it will catch on. If not, it will just be my dll, one of many out there. But from now on, no features. If it's going to end up being my dll I guess I'll stick to my design plan until such time (if ever) it becomes our dll.

 

[Nutty]

Maybe you can explain what you intend for your vision of the community DLL. I'm personally still unclear. I don't understand, for instance, why some of the features of the other DLL mods ought not to be added, and merely disabled by default.

 

[Pazyryk]

I am interested, and intend to post over on the git. I just haven't had time lately... (And may not for a week or so.)

I have interest in both extension of modding ability and in new features. But I definitely don't want someone else's feature in my mod (unless I do want it). Your simple GE suggestion above could break 3 different things in my Lua code if it were implemented without some changes on my side.

But, assuming the new feature is tied to some xml tag, I don't really see the line between "feature" and "extending modding ability". After all, you are giving the modder the ability to do something. In fact, you should add your GE feature as an optional defines, something like FINISHED_PRODUCTION_BUILDS_THIS_TURN = 1. I wouldn't use it for GEs in my mod (they don't "sacrifice" themselves as in base), but I would strongly consider using it for my Slave unit.

 

[Hambil]

I am interested, and intend to post over on the git. I just haven't had time lately... (And may not for a week or so.)

I have interest in both extension of modding ability and in new features. But I definitely don't want someone else's feature in my mod (unless I do want it). Your simple GE suggestion above could break 3 different things in my Lua code if it were implemented without some changes on my side.

But, assuming the new feature is tied to some xml tag, I don't really see the line between "feature" and "extending modding ability". After all, you are giving the modder the ability to do something. In fact, you should add your GE feature as an optional defines, something like FINISHED_PRODUCTION_BUILDS_THIS_TURN = 1. I wouldn't use it for GEs in my mod (they don't "sacrifice" themselves as in base), but I would strongly consider using it for my Slave unit.

Agreed, the DLL can have features in that since, but they will only ever be 'seen' if a mod is written to use them. That's exactly the idea I am working toward. Building a toolkit for modders, not end users. Obviously the hope is it will end up making the life of both better in the end.

@Nutty: If a feature is added it should be of the nature of enabling the ability to do that thing in LUA or xml. The difference between, for example. R.E.D. dll having an event that tells lua what just happened in combat, then uses lua to write a combat log; vs. R.E.D. dll just writing a combat log directly itself. The reason to do it this way is simple: Compatibility, flexibility, modularity, it would greatly reduce the chances of a DLL conflict and make it more likely that modders will use your dll as it posses less of a drain on their potential user base, and how it works is under the modders control. Two modders could even use the same 'feature' in entire different (or similar) ways and the mods would still be compatible. Examples help, and I plan to code more of them. The 'alpha' for my first dll is july 1st and I might push it back some - I'm not rushing myself. But getting some of my own 'functionality' will hopefully not only show the concept, but also my willingness and ability to contribute (important to people who have done a lot of work themselves already).

 

[Pazyryk]

This approach makes it easier to test. Basically, I should be able to use the dll alone and see behavior that is identical to base, excepting a few things that every reasonable person agrees is a bug. And only a trivial effect on speed, if any (unless it is an improvement, which seems more that likely possible). Then I would feel safe adding it to my mod and, one at a time, activating various features that I want.

 

[S3rgeus]

I definitely agree with a community DLL approach that provides XML/Lua with more powerful functionality, rather than doing new things 'out of the box'.

Jumping back a few pages...

Possible Tools (I just need to make sure they can't be done in lua, and can be done in the dll):
Create ability to open any popup from a notification
Create the ability to add new end turn blocking notifications

(Just keeping track so I don't forget)

With regards to this, given that whoward already created a Lua-based solution, do we want to do something like this in the DLL? I'm definitely very tempted to use whoward's implementation for my own mod, but there's still significant overhead to adding new notifications with this Lua-based system. It's a question of if we'd want to basically rewrite the way Civ handles notifications, particularly the way it saves them, which would break compatibility between versions if it isn't 'fixed and done' all at once. (Which nothing ever is, unfortunately.)

When imagining the rewrite for my mod (before I knew about whoward's implementation), I was picturing a DB table something like this: (If replacing the notifications system, we could modify the default Notifications table instead of adding a new one, but again that's optional. It could be that portions of the old code are preserved to deal with the existing notifications (less work and probably more stable, despite the ugliness of how existing notifications are handled) and a new table is created/added to for new notifications.)

	<Table name="NotificationsCustom">
		<Column name="ID" type="integer" primarykey="true" autoincrement="true"/>
		<Column name="Type" type="text" unique="true" notnull="true"/>
		<Column name="Welcomeness" type="integer" default="0"/>
		<Column name="Message" type="text" reference="Language_en_US(Tag)"/>
		<Column name="Summary" type="text" reference="Language_en_US(Tag)"/>
		<Column name="IconIndex" type="integer" default="-1"/>
		<Column name="IconAtlas" type="text" default="null" reference="IconTextureAtlases(Atlas)"/>
		<Column name="BlocksEndTurn" type="boolean" default="false"/>
		<Column name="BlockMessage" type="text" default="null"/>
		<Column name="MiniCivIcon" type="boolean" default="false"/>
		<Column name="ChecksKnown" type="boolean" default="false"/>
		<Column name="DisplaysUnitIcon" type="boolean" default="false"/>
		<Column name="DoubleCivNotification" type="boolean" default="false"/>
		<Column name="UIContext" type="text" default="null"/>
	</Table>

With the columns doing sort of what you'd expect them to. I was planning to have a few base instances specified in XML for certain notification types. (Eg. one instance for notifications that have a single normal circular image, and optionally a small civ icon in the corner, a second for 'dual-civ' icons, like the declare war notification.) Instead of needing a separate XML declaration for each notification type, but I had yet to work out if this was 100% possible. But any changes would presumably require updating NotificationPanel.lua, which makes the community DLL require that file, which isn't a good thing.

Having talked this through, it seems like sort of a bad idea to change notifications, but let me know what you guys all think.

 

[Pazyryk]

, particularly the way it saves them, which would break compatibility between versions if it isn't 'fixed and done' all at once. (Which nothing ever is, unfortunately.)

This is a non-issue for me. I expect any new dll to break saves. Do it in whatever way is best based on other considerations.

 

[Hambil]

I thought it was just a system for turning on and off notifications. I've never used it to create or send one. I guess I should look into it more, if it does that. One of the main limitations on lua and notifications (AFAIK) is no blocking notifications. I also don't think (as in my original proposal) you can do a popup either. A quick look at the lua for Whoward's recent UI - City Expansion leaves me with the impression that you need dll changes to pull this off. And in fact, you need both DLL and lua, so it's an excellent candidate for a 'feature' if that's all true.

 

[S3rgeus]

This is a non-issue for me. I expect any new dll to break saves. Do it in whatever way is best based on other considerations.

Sounds like a plan then. I was worried about what other modders' expectations would be for something like this.

I thought it was just a system for turning on and off notifications. I've never used it to create or send one. I guess I should look into it more, if it does that. One of the main limitations on lua and notifications (AFAIK) is no blocking notifications. I also don't think (as in my original proposal) you can do a popup either. A quick look at the lua for Whoward's recent UI - City Expansion leaves me with the impression that you need dll changes to pull this off. And in fact, you need both DLL and lua, so it's an excellent candidate for a 'feature' if that's all true.

I believe whoward's mods makes adding new notification types easier, but I hadn't followed the dependencies in city extension and realized blocking the end of turn required a DLL change. In which case I may go ahead with my DLL changes to reinvent the notification system, rather than tack onto the existing one. (Whoward's code is still a very good point of reference as well.)

We'll see when I'll have time for this, but I'll give it a shot. But I would think having the community DLL dependent on a modified NotificationPanel.lua was a bad thing? While it definitely isn't much overhead, if we're approaching this as a system which aids XML/Lua modders, I would think a DLL change that causes it to be non-cooperative with base game files would be bad.