Jimlad's wire addons

[ZeikJT]

Hmm, okay cool. Then could we also merge the text receiver and remove that lib? It is practically the exact same code I used for the emarker.

[tomb332]

Text receiver might need it as it is tracking a global list of receivers to distribute chat message to all of them.

[ZeikJT]

Text receiver might need it as it is tracking a global list of receivers to distribute chat message to all of them.

I was using the same system for mine... if it found that any of the emarkers in it's list had it's target removed it would tell that one marker to update... I don't know why Syranide didn't like it.

I guess you could make it so every single emarker adds itself to the EntityRemoved gamemode hook but that just makes more work for every emarker as they will ALL check to see if it was their own entity instead of one place handling all the data. Plus, it adds a lot more calls to the hook itself.

EDIT: I guess for chat it is best if one place handles it all for the asterisking of characters and such...

[Syranide]

Just to make it clear, the only reason you want to put something in autorun is because you want to create a "lib", something that many tools can use. The only thing that really differs between putting code there and in a SENT/SWEP is that autorun will be run before the SENT/SWEP. Thus, it can safely be utilized by many SENTs/SWEPs, there is no point in putting something there if it is only used by a single SENT/SWEP.

That's why wirelib is there, because all tools need it to some extent, so it needs to be run before all SENTs/SWEPs are activated.

[ZeikJT]

Just to make it clear, the only reason you want to put something in autorun is because you want to create a "lib", something that many tools can use. The only thing that really differs between putting code there and in a SENT/SWEP is that autorun will be run before the SENT/SWEP. Thus, it can safely be utilized by many SENTs/SWEPs, there is no point in putting something there if it is only used by a single SENT/SWEP.

That's why wirelib is there, because all tools need it to some extent, so it needs to be run before all SENTs/SWEPs are activated.

As far as I know, the only thing using the textreceiver library is the textreceiver. If the hook can be thrown into the STool instead then we should do that. It seems like it should work anyways.

[Bobsymalone]

What to do next:

• Find a way to make applyForce work more like a thruster (always on), rather than only

ApplyForce works just as it does in lua. Thrusters are always on because they run on a set interval that all wire components besides expressions work on.
If you made it automatically toggled internally, that would bring a lot of flexibility problems (ie, there would be none).

For example, use as a thruster isn't the only use of applyforce. You might not want it to work like a thruster. It's impossible to know what someone might use it for, so the best idea is always to leave it in an unspecialised state.

Look at the adv pod controller inputs (most of which are automatically togglable), and see how awkward it makes things.

I like what you did with entity markers, much more intuitive. Also if you get wirelinks to dupe all the time, you get sexual favours.

If you get wire components to keep their nocollide on duping, make sure there's a way to remove the nocollide. Right now the only way is to dupe it, and that doesn't even work on vector thrusters.

[Jimlad]

Yeah, you're right in some ways about the applyForce stuff - which is why I had in mind just adding a new command, for instance "applyThrust" or something like that. The point is, the "problem" exists because of the very reason you mentioned - the interval works differently for the expression chips.

I'm not sure I understand what you mean about the whole "flexibility" thing though. How would it work any differently to the current system, besides being more consistent and "always on"?

I've been building stuff with applyForce and it seems workable, but a bit unreliable - you'll get varying amounts of thrust out of them depending on what server you're on, which makes creating precision stuff quite difficult. I can get around this by running a calibration step on each server, but it's not exactly ideal!

EDIT:
It seems that other people are starting to run into this problem in the E2 forum as well. For a while I was thinking I was the only one who noticed the issue!

[Bobsymalone]

Yeah, you're right in some ways about the applyForce stuff - which is why I had in mind just adding a new command, for instance "applyThrust" or something like that. The point is, the "problem" exists because of the very reason you mentioned - the interval works differently for the expression chips.

I'm not sure I understand what you mean about the whole "flexibility" thing though. How would it work any differently to the current system, besides being more consistent and "always on"?

I've been building stuff with applyForce and it seems workable, but a bit unreliable - you'll get varying amounts of thrust out of them depending on what server you're on, which makes creating precision stuff quite difficult. I can get around this by running a calibration step on each server, but it's not exactly ideal!

EDIT:
It seems that other people are starting to run into this problem in the E2 forum as well. For a while I was thinking I was the only one who noticed the issue!

Well, force acts differently server to server no matter what. Thrusters included. Anyway all I meant by E2 having a different interval to the rest of wire is that you specify the interval yourself with interval(N).

if(On)
{
   interval(40)
   Ent:applyForce(Force)
}

This should apply force at the same rate as a thruster. It'll also run whenever an input changes though, but you can fix that with:

if(On)
{
   interval(40)
   if(clk()){ Ent:applyForce(Force) }
}

[Jimlad]

ok, I won't be working on the applyForce function - I'll gladly leave that to ZeikJT. My computer seems to be dying at the moment, but while it's still going I'll be testing out his applyForce test version, and start working on getting those keypad commands going.

[ZeikJT]

Alright I've committed the entity marker updates.
Thanks dude.