The NotificationTypes enum is garbage

whoward69

whoward69

DLL Minion
Joined
May 30, 2011
Messages
8,728
Location
Near Portsmouth, UK
G&K, with/without mods

Code: 
[ Lua State = WorldView ]
> for k,v in pairs(NotificationTypes) do print(k, v) end
 WorldView: NOTIFICATION_EXPANSION_PROMISE_EXPIRED	232828272
 WorldView: NOTIFICATION_AUTOMATIC_FAITH_PURCHASE_STOPPED	-2062740077
 WorldView: NOTIFICATION_LEAGUE_CALL_FOR_PROPOSALS	755914060
 WorldView: NOTIFICATION_TRADE_ROUTE_BROKEN	-344621894
 WorldView: NOTIFICATION_RELIGION_ERROR	1903739133
 WorldView: NOTIFICATION_INTRIGUE_SNEAK_ATTACK_ARMY_AGAINST_UNKNOWN	-265092093
 WorldView: NOTIFICATION_LIBERATED_MAJOR_CITY	1317680804
 WorldView: NOTIFICATION_PEACE_ACTIVE_PLAYER	-2028078871
 WorldView: NOTIFICATION_ENEMY_IN_TERRITORY	-1633735706
 WorldView: NOTIFICATION_FRIENDSHIP_EXPIRED	-454166953
 WorldView: NOTIFICATION_PLAYER_DEAL_RECEIVED	-1168514695
 WorldView: NOTIFICATION_SPY_CANT_STEAL_TECH	240697813

they should correspond to the database entries
 
Ignore the code that was here, as while it fixes the association between the enum for the Lua and the database, it then breaks as the game core C++ is still sending the garbage codes to the Lua UI code.
 
In theory, it should make something like this
Code: 
Players[Game.GetActivePlayer()]:AddNotification(NotificationTypes.NOTIFICATION_WONDER_COMPLETED, text, text, -1, -1)
not work anymore.

However, I just saw this exact line of code work in my mod. And it works from tuner (change text to "test"). It generates the notification with the proper graphic.

> NotificationTypes.NOTIFICATION_WONDER_COMPLETED
2091697919

Strange...
 
If you just work with the NotificationTypes enum you are OK.

But if you try to use it as a reference into the Notifications database table, or need the value from NotificationTypes.NUM_NOTIFICATION_TYPES (which is currently nil) or you assume that notifications are sequential (so you can assign new ones) then your mods are currently broken
 
It's clearly intentional, or something like 2091697919 wouldn't work.

Other than breaking existing mods that assumed sequential enums, does this change what we can/can't do via mods?
 
Given value -2028078871, please find the corresponding row in the Notifications database table.

Short of iterating the all the enums via pairs() to find the corresponding text key for the value and then using that key to find the row (as opposed to just using the notification number as a direct lookup against ID) you can't do it.

And if that's intentional, then ... !~$##!$%###
 
You could cache those values in the mod, so not much extra overhead. Of course, I'm assuming that the values don't change during the game.

Are the wacky values related to the arbitrary integers we see for iUnit and iCity? They look a little more extreme. I always assumed these arbitrary values corresponded to some C++ key or memory location for optimization. There's hardly any reason to optimize player UI though.
 
Of the 35+ enums used in the various Lua files in my mods (eg DirectionTypes, CommandTypes, et al), that's the only one with non-sequential numbers and numbers that don't directly correspond to IDs in the database.

Yes we could cache those values, but why should that be necessary, just make them the same as the database values.

It's broken. Firaxis, just fix it.
 
You haven't done a total conversion mod, I see...

I was pretty sure that none of the data identifiers correspond to the DB after mod changes. ImprovementTypes, FeatureTypes and ImprovementTypes certainly don't, to name a few off the top of my head. Of course, with those you can use GameInfoTypes instead, which is updated for the DB.
 
I was just looking at the NotificationTypes enum and saw this comment

Code: 
//  !!!!!!!!!!!!!!!!!!!!!!! 
//  IMPORTANT - the ordering of NotificationTypes enums must EXACTLY match the order of NotificationSounds.xml.
//  If the order is wrong everything will play incorrectly.
//  !!!!!!!!!!!!!!!!!!!!!!! 

// @@@@@@@@@@@@@@@@@@@@@@@@@@
// EVEN MORE IMPORTANT!
// DO NOT REMOVE ENUMS, DO NOT MOVE ENUMS!  ONLY APPEND ENUMS!
// These enums are used by CvNotifications.cpp in a poor manner and their numeric value is serialized out to a file.
// While we can modify and fix CvNotifications, WE MUST RETAIN BACKWARDS COMPATIBILITY.
// @@@@@@@@@@@@@@@@@@@@@@@@@@

It sounds like we may be able to fix whatever is wrong once we get the updated source, as CvNotifications is in the DLL.
 
Sorry to commandeer this discussion, but is what you're talking about also affecting this:

Code: 
NotificationPanel.lua:545: attempt to perform arithmetic on field 'NUM_NOTIFICATION_TYPES' (a nil value)

That's from the Lua.log and this is the code it refers to:

Code: 
Game.CustomNotifications.NotificationTypes[g_notificationTypeTab[#g_notificationTypeTab].type] = NotificationTypes.NUM_NOTIFICATION_TYPES + numNotiTypes;

It comes from the CivUp package but I'm not sure if Thal or someone else coded it originally.

The error only started after the 'PitBoss' patch.

Thanks.
 
I worked a lot on the NotificationTypes enum as a part of my Custom Missions and Notifications mod component. The Notifications DB table is basically never actually used. It's loaded and then ignored. In fact, I found out (by relying on new notifications corresponding the correct way) that there are G&K notifications in the game that aren't present in the DB. (4 to be precise, 2 of them are close to the end of the enum, the other 2 I was never bothered to work out which was missing, I just put in some placeholders) Feel free to check out my code, but I largely left the existing notification code in tact and hooked a more modular system on top of it.
 
You must log in or register to reply here.

Similar threads

whoward69
NotificationTypes enum is garbage
Replies
0
Views
764
whoward69
whoward69
Back
Top Bottom