BadgerCode/tttdamagelogs

QOL: Show other entities in death scene.

Opened this issue · 7 comments

Going to be making a Pull Request for this but I want to get come input from everyone.

I plan on making a configurable list of entity classes, that will show up in death scenes like props do. For example, grenades that are thrown, or C4. Another example is thrown knifes or Traitor Turrets on some servers. (I have this working on the server I a staff member of and also on the dev team.)

Initially I was going to make it just a lua file in the config folder that holds the list, but then I though about using a json file in the data folder to allow for direct editing and also potentially editing from ingame using a simple GUI.

Another idea if I just go with the GUI would be to store the data in the database.

Below is the code I use to add the entities to the death scene in the recording timer's function call. Where Damagelog.AttackingEntities is the list of entity classes.

for _,class in ipairs(Damagelog.AttackingEntities) do
        for _,v in pairs(ents.FindByClass(class)) do
            if IsValid(v) then
                table.insert(tbl, v:EntIndex(), {
                prop = true,
                model = v:GetModel(),
                pos = v:GetPos(),
                ang = v:GetAngles()
            })
            end
        end
    end

Mostly I want to get input on the configuration side of things. (I am also thinking of making these entities there own entry type instead of re-using prop.)

Makes sense!
Players may act strangely in a death scene, due to there being an entity not shown, influencing the player's behaviour.

A list of types of entities that should appear in the death scene may be hard to get right, due to there being so many TTT addons with custom entities.
But I think the opposite, a list of entities that should not appear in the death, could be even harder?

A list of types of entities that should appear in the death scene may be hard to get right, due to there being so many TTT addons with custom entities. But I think the opposite, a list of entities that should not appear in the death, could be even harder?

This is true, for the configuration GUI, it would have all the gmod building entities and then use file.Find( "entities/*", "LUA" ) to find all the entity classes registered by addons. (I have this in my implementation right now but as separate addon since we (server I am part of the dev team on) don't normally modify configs directly on the main server, only on our dev server. )

Where the configuration GUI basically just provides a list of entities and a checkbox by which ones to enable.

Or just going to directly typed in config in a lua file, you would have to just find the entity class for each entity manually.

A list on entities not showing would definitely be hard then of what to show.

I've wanted to add an actual GUI for the configuration, backed with SQLite or files for some time now #60

The config lua file approach doesn't work for the workshop and users risk losing their configuration every time they update the addon.
Plus, having a GUI to configure it would make it a lot easier.

I have this basically ready, but I want to wait till the config PR is done before making this one.

Going to be working on this soon. Now that the config changes are done. Question should the list of entities to display be in its own JSON file? Or should it be an entry in the config?

I am thinking that a configuration GUI may be best as its own PR since it can be made to include all the configs. (Normal config, the entity list and also the sql config.)

Are you thinking of using a whitelist or blacklist for the entities?

Blacklist- a list of entities that should not appear in the death scene
Whitelist- a list of entities that should appear in the death scene

For the server owner, a blacklist would possibly be easier to maintain.
Anytime they add a new addon, there could be new entities that should appear in the death scene (e.g. custom entities for custom TTT weapons)
Once the blacklist is created, they probably wouldn't need to change it often.
And we could default the blacklist to some common things that shouldn't appear in the death scene

A whitelist would be more accurate, but would take more effort for the server owner to keep up to date (they will probably forget).


An optimisation from the original code snippet:
We should use a dictionary lookup to see if an entity class is on the whitelist/blacklist.
This will save us looping over the entire whitelist/blacklist every time, which might happen a lot?
E.g.

Damagelog.EntityBlacklist = {}
Damagelog.EntityBlacklist["prop_physics"] = true
-- In the JSON config, this would look like this
-- { "prop_physics": true }

-- Check if an entity is on the whitelist/blacklist
if Damagelog.EntityBlacklist[entity:GetClass()] then
-- entity is on the list
end

Using the blacklist would definitely be simpler, main reason I initially used a whitelist was due to worrying about memory foot print.

Also I forgot about the dictionary lookup style of doing things when I initially wrote my code snippet. I will probably write it using the blacklist since that should be able to cover a lot of things.