E2 sentSpawn function.

[deltamolfar]

• Finally a way for E2 to spawn sents.
• For QoL, limited to wire/native gmod sents + entity tab entities, if wire_expression2_propcore_whitelist <= 0)
• Thirdparty addons support (ability to add/remove ents to be able to be spawned within whitelist + a hook with same logic as Expression2_CanEffect
• Entity registration is straightforward, and the sentSpawn does all the E2 to Lua castings itself (No need to put every check in _preFactory'ies).
• Ability to spawn ALL wire entities (if I didn't forget any).
• Few helper functions to sentSpawn.

I've tested all registered by defaults sents. (The only sent I couldn't get to work is gmod_wire_dynamic_button.)

While most of registration code/logic is from starfall prop_sent.lua, I've found and fixed ~10 sents + added ~6 that weren't originally there.

The only "problem" there currently is, is that undo for some reason doesn't return E2 sent (classname), but e2_spawned_sent.

[wrefgtzweve]

This should be a separate core or some kind of workshop addon core.

[deltamolfar]

Why? With whitelist convar on (which is on by default) - you can spawn only wire entities + a few basic gmod sends (lamp, button, etc (And i'm okay with removing that as well)). You can't spawn a weapon/vehicle/etc with that. So it's essentially just gives more room for E2 creators to quickly spawn whatever they need, instead of pre-spawning all the ents they need, and then having to spawn their code as dupes, and not as code. If you don't turn off the convar, you're guaranteed not to have any issues with models, ents, etc (apart if they change or brake, and no one changes their registration).

Also, this was requested for a ton of time + there is ton of people that went from E2 to SF mainly because of that feature being absent.

[Zenius07]

Cool, this is very useful

[Swanchick]

Hell yeah, these things should have been added before!

[wrefgtzweve]

Asking your friends/alts to reply/upvote your post does not make it any better.

[deltamolfar]

???. I shared my PR to my old server, where I often drop my projects. Why do you think I care about upvotes on github's PR page? + If we're talking about votes, you and charity "downvoted" without ever elaborating ;/

[wrefgtzweve]

Yeah we downvoted it because we don't want this on our server, as it seems like a major security/abuse risk that neither of us want to deal with. Calling your friends to offset the balance and act like people do want it only makes you seem immature. I suggested this to be its own core so server owners can toggle it whenever they want. At least there's a hook that allows you to disable it.

[deltamolfar]

Can you elaborate how an ability to spawn, say, a button, a security risk? And about abuse - same goes to propspawning explosive barrels? There is way more and way stronger ways to abuse then spawning wire elements. If you really want, I can easily add additional convar, to disable sentSpawn, but I can't see, how spawning a wire element can be security, or abuse risk, except for maybe spawning a wire explosive, but you already can pre-spawn and reuse it, or spawn an explsoive barrel?

As I said, I did not deliberately call anyone, but sent it to my old dev team to review the code, and PR in general. Or do you hold responsibility for actions of everyone else you know?

Also, I may be wrong, but why you and other people that use sf often use ability of spawning sents as one of major advantages, and tell how E2 is bad because of absence of that feature, but now you against it being added?

I can move it to separate core, or add a convar to outright disable it, but I still see no sense in that, as it is way more logical to stay in propcore, and I can't really picture a situation where you would allow prop spawning, but not ent spawning. (They have shared throttle limits)

I also think that ability to spawn regular gmod sents (regular buttons/lights/etc) is excessive, and I would remove that, as people could use that as a way to bypass wire limits a bit, but that is nothing major. I decided to put it because that is how it is in sf, but I'm completely okay, and maybe even pro removing that.

[wrefgtzweve]

I don't see a big issue with default/wire ents as long as they're specifically filtered like they are in starfall. The security risk was aimed at the wire_expression2_propcore_whitelist which at first face seemed like it allows players to spawn any entity CreateConVar("wire_expression2_propcore_sents_whitelist", "1", FCVAR_ARCHIVE) -- 1: Players can spawn sents only that are added to the default sent list, 0: Players can spawn any sent (no way to make players not spawn errors then though!) which would've been a major issue. However it seems like it only allows you to spawn props from the spawn menu. Having a way to toggle sentSpawn on/off with a convar would be great though.

[deltamolfar]

Yeah, comment is a bit misleading, will fix that. Alright, I will add a convar to disable sentSpawn altogether. Also I will comment default gmod ents from whitelist, as I think they don't fit well there, and may lead to some form of light/effect abuse (as wire and native light/emitters are not sharing same limit).

[wrefgtzweve]

As long as the entities follow the prop limit (which i think this does) it should be fine.

[deltamolfar]

Added the convar to outright disable sentSpawn, and done some cleaning. Found out that while gmod_emitter and gmod_camera spawn as expected, they just don't want to work. Sadly I will have free time in few days-week. Until them I've left them commented

[wrefgtzweve]

For wire_expression2_propcore_sents_whitelist you should use :GetBool() instead of :GetInt() would make more sense

[deltamolfar]

Fuck. Accident lmao, will re-pr in a sec