New Feature/Toolset: Paradox Bar! #104
Comments
|
Heads up, I'm working on improving the LOC text support for notifications, so please hold off on anything related to this PR for a few hours while I polish this up, changes will be breaking |
|
Okay, I've overhauled the AddNotification method somewhat, this should be the last truly breaking change, since the new way of providing properties is ordering agnostic |
|
Also added better LOC support so it should be considerably easier to create a template string now while filling in the blanks at time of instantiation with a property override upon the new ttprop table |
|
Got some time to try it out in civ today, and have some comments. Lets say you create 3 notifications in the same group and remove one and then add new ones the position gets messed upp: The animations look a bit yanky, especially when removing a notification. Right now it goes over the top bar might look better if it started to fade out as well or if it went under the top bar. It would be nice to be able to remove an entire group with one click, so maybe add an X button or something like that. When all buttons are added to the worldtracker the notifications overlap the hide worldtracker checkbox. Also I'm wondering if not AddNotfication might need another parameter or so. Say we want to create a notification for city growth, this notification should on left click take you to the city in question. To do this we need to have a city id or something like it. Otherwise we would need to pass a function for in the func parameter and then we can't have a default which we want to still have right click to remove and so on. Otherwise I think the look is spot on! Great work. |
|
Yeah, in terms of the animation I wasn't entirely happy with it, but I was hoping it was just because I was being critical, now that I have some feedback I'll look into smoothing it out a bit. I'll probably just swap it out for a alpha transition instead, because I think that will bypass the second visual issue you describe. Speaking of appearance, do you guys think it looks better without the background banners? I'm very back-and-forth on the subject As for the parameter suggestion, the params table effectively allows passing whatever arbitrary data you want. The params table is accessible from any given func as the third parameter being passed to it, so it should be a relatively simple proposition with the tools already available. I'll see about adding a close button to the group instance I don't think it's possible to design a foolproof safety against notifications showing for the wrong player. Really, it's up to whomever is programming a specific notification to filter events so that only relevant ones eventually create a notification. |
|
Ah, the weird animation behavior has to do with some instancemanager behavior I did not expect! As it turns out, releasing an asset from a given IM just hides and disables the element. The created instance lives on in memory and will return next time a new instance is needed. This leads to some funny side-effects, like the janky positioning you noticed, if you aren't careful to restore any mutable states to their defaults at the time of summoning |
|
Overlooked the prop parameter, this will do what I asked very well. I like the background banner, it feels like it matches up nicely with the civ icons on the right. Edit: local textureOffsetX, textureOffsetY, textureSheet = IconManager:FindIconAtlas(iconName,38);
if (textureOffsetX ~= nil) then
Controls.ReportsImage:SetTexture( textureOffsetX, textureOffsetY, textureSheet );
end |
|
Do I have to activate somthing? Nothing happens here... |
|
Okay, no idea how that works... Use Firetuner only for logging... |
|
I can probably fix some informative screen shots later today. |
|
First you want to select the correct state, in this case cqui_toplayer: Now you have access to all functions declared in that state. So we can write |
|
Did some testing with icons and have some more feedback:
|
|
I'll see about possibly autodetecting the image/icon difference. Worst case scenario: I think we could get away with just attempting both functions blindly and swallowing any exceptions. The background banner needs to be at least a certain width, otherwise the transparent textures on the bottom overlap and look ugly like that. I'll look into widening those banners slightly, as well as nudging the icons a bit up relative to the banner |
|
Okay, I've further tweaked the AddNotification method and also changed how new stock notification types are added so that they can be extended if a similar type already exists. These are breaking changes, so sorry about that! Aside from that, you can see two new notifications have been implemented! Now you'll be alerted whenever a city grows or shrinks. Unfortunately, the game isn't very descriptive about what happens when a city population changes, so this relies upon a nasty heuristic. Keep an eye out for this notification since my personal testing can only do so much! |
|
I'm traveling this weekend and we are painting in the computer room so won't be able to test for a while. |
|
Started a new game today with this on and have found some bugs/problems:
|
|
Thanks for testing! The initial notifications are indeed a bug, just one I haven't gotten around to addressing since it's helpful for testing purposes. The second issue is because toplayer doesn't respect BulkHide yet, but because the worldtracker keeps bugging us, I think I'll just move the notifications to the same "layer" as the worldtracker, bypassing the positioning and hiding issues entirely Third and fifth issues are caused by the unfortunate fact that there's only a populationchanged event (we have to infer if this is a growth or shrink event by the city growth, which isn't always accurate, like here), the best solution to this specific issue is probably ignoring growth/shrink events that happen during your turn, since we're mostly concerned with notifying about growth/shrink events the player doesn't directly cause. |
|
True, I wish the API:s where better :( I guess we need to store that information our self if we want a better check. We could store current population for each city on end turn, then we can check against that. Or something like it, but it would take a bit of work ofc. One more thing I wonder how it would work when a city gets nuked (not that the AI have nuked me yet but I guess it could happen). |
|
I'm not sure what to do with this, I like the idea of having a more flexible notification system but I would greatly prefer to find a way to integrate this in the base game notification panel and not create a whole new paradox games like panel. |
|
Any updates on this? The base notification system is pretty terrible and many people, including myself, would be ecstatic to have this kind of inclusion. |
|
I was trying to test another system, stacking notification in another way that what the default game does but in the same place not in Paradox game's way. I was in the "messing around" part but then the fall update came and I did not work on it afterwards. This Paradox bar solution however is working and already advanced but we'll need more review on it, for me it feels "odd" to have the notification like this, but maybe most people like it. |
|
Some user input, without testing, just my 2 pennies worth (IMNSHO):
Anyway, that's my user input, other than to say THANKS!!!! |
Sunday Apr 30, 2017 at 00:40 GMT
Originally opened as CQUI-Org/cqui#514
What is this?
Okay, so there's the name... It's basically an imitation of the the notification scheme found in the grand-strat games published by Paradox, like Crusader Kings, Europa Universalis, and Stellaris. It looks like this if you're drawing a blank.
Right, so that's the idea, implementing a saner notification scheme that's easier to read. How far along is this pie-in-the-sky dream? It's complete! So, why is this a PR instead of just going direct-to-game? Well... there's only two notifications implemented so far, and they're both purely for debugging purposes. That being said, the internals have been tested extensively and the "API" of this element has been engineered specifically for robustness, flexibility, and ease of use. It's ready for people to start throwing things at it now!
Seeing as we've run short on low-hanging fruit recently, which has dried out the flow of commits somewhat, I've decided to put this PR up as an additional avenue for both the @CQUI-Org/feature-team and outside contributors to quickly and easily extend CQUI.
So, what's the plan?
The plan is to implement notifications that do not exist currently into this new notification system. Once we're confident with the number of notifications implemented, we'll soft-launch this while keeping the old notification system. This way we'll have a chance to gather some user feedback on performance, bugs, and usability without really risking bricking up the notifications that already exist in the base game. After that, we'll see about moving over all notifications to this new notification platform, along with implementing much-requested features like snoozing notifications and muting specific notification groups
Why abandon the existing notification bar?
It's difficult to mod, plain and simple! The difficulty present in extending the existing notification system makes it a very unpleasant proposition and is the reason we've been unable to tackle the many existing requests for adding new notifications. It's at the point where we had to instead hijack the gossip popups instead, even when they weren't necessarily the best choice. Moving over to our own custom solution also comes with the added benefit of being able to add notification stacking, a much requested feature.
Beta
It's been too long, I've been putting off the beta tag since November. Let's finish up this last feature and finally release the first beta build 😎
chaorace included the following code: https://github.com/CQUI-Org/cqui/pull/514/commits
The text was updated successfully, but these errors were encountered: