Getting name of corpse before they were killed?

I'm trying to get the name of someone from a corpse in OnLootEntity using JavaScript - can this be done?

Also, what the best value for target to test against? Just using target seems to bring up all sorts of weirdness.

Thanks in advance,


Tony.

 

I would say you could do entity.OwnerID with entity being the corpse but im not sure if a corpse has a ownerID.

 

I tried target.OwnerID and it returned a number in some instances - but it was something like 16.343345454234e12 - didn't look very useful to me.

 

I'm confused by your post's title, how are you wanting to get the name? You say in the post using OnLootEntity, but how is this going to be called before the person is killed? The corpse doesn't spawn until the death.

For OnLootEntity, this should work:

Code:

     void OnLootEntity(BasePlayer player, BaseEntity target)
        {
            var corpse = target?.GetComponent<PlayerCorpse>() ?? null;
            if (corpse != null)
            {
                var name = corpse?._playerName ?? corpse?.playerName ?? corpse.lootPanelName ?? "Unknown";
                SendReply(player, "Looting " + name + "'s corpse");
            }
}

EDIT: Woops, somehow missed the JavaScript part in the OP. Hopefully this still gives you an idea, but probably not.

 

I would just use C#(if you don't know the language just look at a bunch of plugins) since javascript can't store OwnerID correctly and will run into issues with that eventually.

 

This isn't entirely true.
You need to convert the ownerID to a string using a C# wrapper and then work with the string in JavaScript.
Oxide has a wrapper for that:
Oxide/Rust.cs at develop · OxideMod/Oxide · GitHub
rust.OwnerIDFromEntity

 

It's true in that it can't handle the number directly, using strings works but it's also not ideal IMHO. UserIDs aside almost all the existing oxide rust plugins are written in C# and C# runs the fastest of the languages. In the long road if he ever wants to do some tricky stuff he'd be lot better off with C#.

 

For most plugins (in fact, I can't think of any popular plugin where this isn't true), the bottle neck is somewhere else.
JavaScript, Python and Lua aren't used in their "base" implementations either, I think all the implementations Oxide uses are interpreted to the same bytecode as C#.
Using C# instead of any of the scripting languages for performance isn't a strong argument.
If you're looking for static typing, covalence support and a cleaner Oxide API however, then C# is the language to go.
The scripting languages are mostly a lot more expressive, though (at least Python is, not so sure about JavaScript/Lua).

That being said, not all digits of a steam ID are significant.
Only the last 10 digits are actually distinct.
According to ECMA, numbers in JavaScript are precise up to 9007199254740991, which is 16 digits.
The actual steam id however is 17 digits, so it isn't precise.
If you're looking for efficiency, you can convert the ID to a string and cut off the first 7 digits, only using the last 10 digits, and then convert that back to a number.

 

Quote from Wulf: "plugins can now be written in C#/CSharp, Lua, JavaScript, or Python! While C# will be the fastest as it's essentially native code, you're free to write in your language of choice!" Also I never heard anyone saying out of the gate increased performance that's free isn't a strong argument?

Other languages can tap into oxides covalence as well, Oxide API for Rust

That's interesting, and an option, but I personally try and avoid hackish code/solutions when I can

Also again given how almost all the existing plugins are written in C#, and the fact the documentation for oxide isn't completed, C# is IMHO easily the most ideal language to go with, across the board. Believe me, having such a strong javascript background myself I opted for that at first as well but quickly realized I was making things more complicated for myself. I don't even know C# really, but the language is easy enough that i've managed to write plugins i've wanted to without much struggle. Some of which I plan on contributing to oxides list, fairly soon.

 

Because even while faster, the speed gain isn't that useful for most plugins.
This is why it's pointless to write every application in C, because not every application needs real time like performance.
There are loads of programming conveniences you need to get rid of to achieve maximum performance, and this is somewhat true for Oxide as well (Python being incredibly more expressive than C#, for instance).
Most plugins work when a command is called or using a hook that is rarely called and don't do much work (some simple lookups, maybe some work with the Unity & Rust API, maybe some I/O).
Anything Unity/Rust is already being run in C#, so the things that are actually sort of expensive computationally (such as raycasts) are already using C#.
When you do any kind of I/O, any slowdown a plugin can cause becomes completly negligible, as I/O is so incredibly slow that the tiny bit of overhead one of the scripting languages causes doesn't matter.
The problems that Oxide plugins are trying to solve are mostly absolutely trivial.
Plugins that are computationally heavy however should be C#, like plugins that run OnTick, because in these cases the performance actually matters.

You can use the covalence library, but not the full covalence API, and some parts of that API are crucial for your plugin to really be a universal plugin.
C# covalence plugins inherit from CovalencePlugin, and as such, every hook provided by Oxide is automatically generalized. These hooks sometimes have the same name and the same arg length, meaning a scripting language wouldn't be able to distinguish between the two without type annotations.
As such, you can only use the "explicit" hooks for each game.

I agree with your arguments at the end. As I said, there are a bunch of other advantages for using C# other than performance. That being said, C# is still pretty verbose, which is the main reason why I don't use it unless I need it for performance reasons or for Covalence.

 

What I meant was, what the players name was before they became a corpse I'll see if I can get some ideas from this snippet...


Thanks.

 

With regard to the rest of the conversation - I'm more than happy to slog away with JavaScript. Maybe one day I will be able to share my findings as others do with C# etc.

So far the only major issues I've had are with the lack of documentation and the fact all the reference code is in C#. Specifically the lack of a comprehensive list of properties; although I know I can get these from the decompiled code in Oxide, it's less than ideal as I use a Mac most of the time.

At some point I might shove my plugin into a GitHub repo so you can point and laugh at my code but for me the main thing is I've really enjoyed writing it, and my players seem to really like it too.