by arookas » Wed Sep 07, 2016 4:49 pm
			
			
			I'll admit, suddenly making all actors spawnable by name seems a bit overkill, and making them selectable in a hierarchial treeview sorted by inheritance solves only half of the problem.
Maybe extend the MAPINFO doomednums block (or make a new one) to accept named doomednums, which would then be used as a sort of whitelist for spawnable actors using classtype? Something like this:
Code: Select all
doomednames {
  "MyImp" = DoomImp,
  "YourImp" = HereticImp
}
In this example, classtype would only search for names given through this block, using the same overriding logic as the doomednums block. Adding a whitelist to classtype wouldn't be hard. Maybe the name of the field would be changed, as well.
This way, editors wouldn't need to change how a user selects a thing (it'd still have just the spawnable actors in the normal list, grouped by category), the list wouldn't be immediately spammed with unspawnable junk actors, and the actual doomednum/doomedname could be hidden from the user (except for, e.g., search/analysis functions). I wouldn't advise putting the standard actors in there, as to mantain cross-port compatibility, and since they're always define in g/zdoom.pk3, they're going to have doomednums regardless. This would be ideal for custom actors in the future.
Editors could have a named doomednums LUT alongside their numbered doomednums LUT. GZDB has 
named/numbered scripts as constructor overloads, which is another possiblity.
I think this would be a lot better for everybody. MaxED and Gez, what are your thoughts?
Gez wrote:Collision in a group of 255 possible numbers are a lot more likely than collisions in a group of 32767 possible numbers.
True, but note that a considerable range of those numbers are taken by the loaded game/engine. Also to consider is that a good number of mods don't spread out their ranges too far. I often see them start at nice round number ranges in the middle. An example would be 16nnn for items, 17nnn for monsters, 18nnn for decorations.
I'll admit, suddenly making all actors spawnable by name seems a bit overkill, and making them selectable in a hierarchial treeview sorted by inheritance solves only half of the problem.
Maybe extend the MAPINFO doomednums block (or make a new one) to accept named doomednums, which would then be used as a sort of whitelist for spawnable actors using classtype? Something like this:
[code]doomednames {
  "MyImp" = DoomImp,
  "YourImp" = HereticImp
}[/code]
In this example, classtype would only search for names given through this block, using the same overriding logic as the doomednums block. Adding a whitelist to classtype wouldn't be hard. Maybe the name of the field would be changed, as well.
This way, editors wouldn't need to change how a user selects a thing (it'd still have just the spawnable actors in the normal list, grouped by category), the list wouldn't be immediately spammed with unspawnable junk actors, and the actual doomednum/doomedname could be hidden from the user (except for, e.g., search/analysis functions). I wouldn't advise putting the standard actors in there, as to mantain cross-port compatibility, and since they're always define in g/zdoom.pk3, they're going to have doomednums regardless. This would be ideal for custom actors in the future.
Editors could have a named doomednums LUT alongside their numbered doomednums LUT. GZDB has [url=http://svn.code.sf.net/p/doombuilder/code/branches/GZDoomBuilder/Source/Core/GZBuilder/Data/ScriptItem.cs]named/numbered scripts as constructor overloads[/url], which is another possiblity.
I think this would be a lot better for everybody. MaxED and Gez, what are your thoughts?
[quote="Gez"]Collision in a group of 255 possible numbers are a lot more likely than collisions in a group of 32767 possible numbers.[/quote]
True, but note that a considerable range of those numbers are taken by the loaded game/engine. Also to consider is that a good number of mods don't spread out their ranges too far. I often see them start at nice round number ranges in the middle. An example would be 16nnn for items, 17nnn for monsters, 18nnn for decorations.