Wire: Implement modularity: E2 functions to spawn the other E2s with the different code along with the other wire-entities

Created on 24 Nov 2018  Â·  9Comments  Â·  Source: wiremod/wire

[Suggestion][Epic] Implement E2 functions to spawn another E2 with the different code => Modularity

This would allow to make programs that use 'multiple threads', and do not require any further user interaction (i.e. to spawn and wire other chips). Multithreading can be useful not only for performance reasons, but also to easily overcome the E2 code length limit

E2 Suggestion

Most helpful comment

To be honest I've always thought propcore should be extended to allow any wire entity to be spawned.

All 9 comments

https://github.com/wiremod/wire/blob/master/lua/entities/gmod_wire_expression2/core/custom/remoteupload.lua

Already possible, partially.
If you want it full-automatic, just combine E2 remoteupload core (extension) functionality with entSpawn(string, vector) (hard locked to admin-only tho).
If you want it semi-automatic, just spawn your 2nd chip manually and link it to the main thread/chip (you could use wiring core [extension] functionality to hook them up automatically).

Here is my quick example code of that setup (didn't test ingame):

#ifdef entSpawn(string, vector)
local SubThread = entSpawn(entity():type(), entity():toWorld(vec(0, 0, 20))) # Spawn another E2.
if (SubThread)
{
    print("2nd thread created.", SubThread)
#ifdef entity:remoteSetCode(string)
    SubThread:remoteSetCode("print(\"Your another E2 code...\")")
#endif
}
#else
# Use inputs...
#endif

easily overcome the E2 code length limit

Just use #includes, and properly organize your code.


Hope that helps.

To be honest I've always thought propcore should be extended to allow any wire entity to be spawned.

I don't think it's a good idea. A nice way to open up a can of worms.

To be honest I've always thought propcore should be extended to allow any wire entity to be spawned.

Every entity has a different set of parameters required to set it up. Unless we hard code every entity there's not really a safe way to do this.

I don't think it's a good idea. A nice way to open up a can of worms.

Well.
propcore has anti-spam in place, if this were implemented properly with 'limit' console variables (ConVars) for each "wire entity" at the same time.
I just see a small problem, propcore is particularly around for prop_physics (and seatSpawn entities), perhaps this should be done in a completely new core (extension) rather than banging everything into propcore. That way it could be disabled by default, too. I'd name it wirespawn.
Given that, what sort of harm could it possibly do? So, it is only possible to abuse it by triggering anti-spam, and if this is the case, could easy auto-shutdown/halt E2 chip, too.
Indeed, I could push this out as a separate extension, if anyone is interested.
It will save time & allow for primary job automation scripts (all-in-one E2), and more.
(I know Divran is not really fond about realizing such a thing. But, it has a good spirit and may as well motivate people to learn more about E2. But, above all, could also enable migration of multiple dupes to a single E2 "builder chip".)

Every entity has a different set of parameters required to set it up. Unless we hard code every entity there's not really a safe way to do this.

Doesn't mean it is not possible.

If you want it to work with every entity, you'd need to emulate the toolgun. There was an addon back in 2010 that did that so it's not hard. This would definitely be a big extension addition though and would need heavy testing. I'm not planning on working on it anytime soon so I'll stick a label on it.

If you want it to work with every entity, you'd need to emulate the toolgun

Well. Exactly. I made mine just use exact properties set from the owner's STOOL without extra validations performed. It worked, dangerously hacky tho. I was just playing around with extensions back then.
But, if you guys really want this. Let it become reality then. I'll be pushing a rewritten version (of mine) - soonâ„¢.

P.S. Rename this to have a better name.
@TAbdiukov Please stop with [Suggestion][Epic] prefixes, it is silly. There are labels for this purpose.

@CaptainPRICE Sure, but I don't have access to the the labels, and I'm trying to make things easier for you guys

UPDATE: Titles are fixed up now

use antcore's spawnProcessor() and then remoteSetCode() on one

Was this page helpful?
0 / 5 - 0 ratings