quyxkh wrote: ↑Thu Jun 16, 2022 6:15 am
you're so volubly and endlessly demanding
I’m not demanding jack. I’m defending my (revised) request against people saying my request is not needed because I can hack together my own solution. Seriously, how many things have the devs added to this game over the years that weren’t
needed because the modder could do it themselves, but by the devs adding it things were made simpler? It’s
2 lines 1 line of code in the base game (per object that is currently missing it: 1 to define it in the object definition (with a static value),
and 1 to actually set a value while they’re compiling the data.raw objects into them) that won’t hurt anything by including.
Look, you want to always have to build your own solutions for things? Feel free to not use many of the APIs and properties available to us that made modding easier for this game.
It doesn’t matter to me if it’s only a 5 ms savings. It’s still a savings that most likely doesn’t even have a measurable impact on the base game, let alone any impact felt would only be at the end of the data stage while they’re compiling them into their final objects. And I’m sorry, but I do not think in the mindset “it’ll only be me that needs this.”
If the devs ultimately decide they don’t want to do it, fine, but the arguments I’m seeing so far on why they
shouldn’t don’t hold any water.
Edit: Updated “2 lines” of code to “1 line” and altered the rest to reflect that. /Edit
—————————————
Rseding91 wrote: ↑Thu Jun 16, 2022 12:52 pm
A small addon to the conversation
Yeah, I think I get this. I’m revising my ask to being: can you include the .type property on LuaTilePrototype (and any other prototype, really, where type could be valid on) with a valid return value?
I realize that means for (example) all LuaTilePrototype objects the value would just then be “tile”, but I do believe it would be easier just being able to query .type on all prototypes in generic functions. This avoids having to do any of the following:
a) Have additional logic to first query .object_name and sort out what object it is, then if it’s a LuaEntityPrototype query .type anyway, but also ultimately having to store this result in a separate variable for future reference for the life of the function.
b) Run extra code on every game load to (re)populate a table of name/type pairs, which will require doing the first part of (a), that then you reference with the object’s .name property to get the paired type.
c) Spilt some of your code out into separate specialized functions, essentially duplicating some of the code, but will still require doing the first part of (a) so you can sort them out to the correct functions.
Again, I just want to make it clear: I’m no longer asking for the return of nil if the property does not exist (or run-time compilation that checks for if the property is valid on the given object). I’m merely asking for .type to be included and populated on all prototype objects instead of just LuaEntityPrototype.
Edit2: Also, want to point out, while I still believe it’d be a “nice have”, if the
other suggestion thread I linked to in an earlier post were to be implemented, then my use case for this would be removed.