Thoughts on a community DLL

[S3rgeus]

Now that is actually pretty interesting, got me thinking. Perhaps this project is poorly named. Maybe community toolkit would be better. Because things like you just listed would be very valuable (things that make the lua core files more extensible and generic) community tools.

I think I will proceed that way: Finish adding iterators (I find them useful - I'm already using one in testing and wish I had it for a mod I'm working on but this DLL won't see the light of day for a long time yet, and at least nobody has said they shouldn't be in the DLL yet ). Then focus on a lua based toolkit, with it's own repository.

That way, not only do we get a more robust toolkit, but the lua code can drive what we find we need or want to do in the dll.

I'm glad this approach is one you're considering for the community DLL. I've been working on custom notifications for the past couple of days, and I think I'm most of the way to done, but it inevitably involved replacements for NotificationPanel.lua, NotificationPanel.xml, and ActionInfoPanel.lua. But it's remarkably effective:



I still need to do a bit more testing to make sure all of my XML tags work as expected. I've made a bunch of different combinations of notification types available, so there will be some fun edge cases I've yet to find.

I figure I'll roll this into my Custom Missions mod component. Again, I'm happy for all of this to be integrated into the community project. I'll release the 'final' source code once I've done a little more testing.

 

[Hambil]

This also makes a DLL change or changes? For the blocking part? And very neat btw.

 

[S3rgeus]

This also makes a DLL change or changes? For the blocking part? And very neat btw.

Thanks!

Yeah there are several DLL changes. I've changed the way notifications are stored within the DLL. They now behave much like promotions and features, where there's a std::vector in CvGlobals that gets populated from the DB. There's now a Lua event that queries if a given notification can be dismissed. There's a new end turn blocking type which is what my changes to ActionInfoPanel.lua looks out for and displays the message set in the DB.

There's also a new Lua event when a notification is activated (left clicked) so modders can do/display whatever they like. (Or do nothing and it'll center over the given X,Y coords and play that highlight effect, provided you haven't turn off that effect using the XML tag.) I'm aware this is sort of the gameplay DLL 'doing UI', but I thought that was a reasonable trade-off for the flexibility it gives. All actual UI stuff is still done in Lua, but ideally that PlayerNotificationActivated event would be a UIEvent, not a GameEvent.

For an idea of the combination of stuff available, here's the DB table that's used to define these notifications:

CREATE TABLE Notifications
(
	ID integer PRIMARY KEY AUTOINCREMENT,
	Type text NOT null,
	Welcomeness integer DEFAULT 0,
	Urgent boolean DEFAULT false,
	Message text DEFAULT null REFERENCES Language_en_US(Tag),
	Summary text DEFAULT null REFERENCES Language_en_US(Tag),
	IconIndex integer DEFAULT -1,
	IconAtlas text DEFAULT null REFERENCES IconTextureAtlases(Atlas),
	IconSize integer DEFAULT 80,
	BlocksEndTurn boolean DEFAULT false,
	BlockMessage text DEFAULT null REFERENCES Language_en_US(Tag),
	BlockToolTip text DEFAULT null REFERENCES Language_en_US(Tag),
	LargeButton boolean DEFAULT false,
	MiniCivIcon boolean DEFAULT false,
	ChecksKnown boolean DEFAULT false,
	UnknownMessage text DEFAULT null REFERENCES Language_en_US(Tag),
	UsesRuntimeIndex boolean DEFAULT false,
	ExistingIconType text DEFAULT null REFERENCES NotificationIconTypes(Type),
	DoubleCivIcon boolean DEFAULT false,
	Civ1Anchor text DEFAULT "L,B",
	Civ2Anchor text DEFAULT "R,T",
	ExpiresAtTurnEnd boolean DEFAULT true,
	PlaysFXOnPlot boolean DEFAULT true
);

This structure means you can do this to send a notification:

pPlayer:AddNotification(GameInfoTypes.NOTIFICATION_DOUBLE_TEST, nil, nil, capX, capY, 0, 1)

Where NOTIFICATION_DOUBLE_TEST is defined:

<Notifications>
	<Row>
		<Type>NOTIFICATION_DOUBLE_TEST</Type>
		<Message>Double test</Message>
		<Summary>Double summary test</Summary>
		<IconIndex>7</IconIndex>
		<IconAtlas>TECH_ATLAS_1</IconAtlas>
		<DoubleCivIcon>true</DoubleCivIcon>
	</Row>
</Notifications>

This is the notification with the two civ icons in my screenshot above. It all uses the existing Player:AddNotification function. (And all uses the same underlying data structures as default notifications, so get rebroadcast properly on game load.) If you pass a message and summary at runtime it overrides the XML-defined message (in case you need to insert a unit/leader/building/tech/whatever name into the message/summary), otherwise nil just tells it to use the XML-specified message.

 

[Hambil]

I think this is the approach we want. I wouldn't worry about doing UI - you are doing it in LUA and that's perfect. This will be a great tool.

 

[Hambil]

Proposed Feature/Fix
Workers will consider nearby combat units as valid 'cover' if under threat.

I am currently doing this is lua, but it's very messy compared to what I assume will be a rather easy DLL fix. It's on my list to look into.

I think this is possibly category to consider dll changes for - things that can be done in lua, but very inefficiently.

Edit: Shouldn't be that hard - I've noticed they do this for range units, they only run from melee. So it's just a simple check somewhere in the DLL.

 

[Hambil]

I am going to start a Community Toolkit thread in the utils subforum, outline the initial concept more clearly and list the github pages. We can let this thread die. What do you think?

The focus (in one line, I'll be more detailed in the post) is lua based tools, some which require DLL assistance. Hmmm, should it go under mod components (I think we'd need an alpha first to put it there). Let's leave it hear until we have an alpha, then move it to one place or the other depending on what mods have to say. It seems to me the clearer place for this would be the mod components forum (once it has files) and if it ever grows big enough maybe down into the community projects with its own subforum, but that's a long ways down the road.

 

[S3rgeus]

I am going to start a Community Toolkit thread in the utils subforum, outline the initial concept more clearly and list the github pages. We can let this thread die. What do you think?

The focus (in one line, I'll be more detailed in the post) is lua based tools, some which require DLL assistance. Hmmm, should it go under mod components (I think we'd need an alpha first to put it there). Let's leave it hear until we have an alpha, then move it to one place or the other depending on what mods have to say. It seems to me the clearer place for this would be the mod components forum (once it has files) and if it ever grows big enough maybe down into the community projects with its own subforum, but that's a long ways down the road.

It seems like a mod components thing, rather than Utils. I'd say Utils are things like NexusBuddy and the Tech Tree Editor, which are useful for modding but aren't actually part of any mods themselves. Either way though, I'd say this thread gets a decent amount of traffic on the main page, it might be useful to keep it alive for discussions and have an actual component thread with implementation details/guides/files.

Also, I've updated my custom missions thread with a guide on how to use the new custom notifications and what they can do. Source code and such are in the topic's first post.

 

[Hambil]

Proposal (via Gedemon)
Expose the DLL pathfinding functions.