Super Wire Mod

[Lexic]

[QUOTE=BoingBoing;17935215]Here's the indicator made with SuperWiremod:
[lua]AddCSLuaFile( "cl_init.lua" )
AddCSLuaFile( "shared.lua" )
include('shared.lua')

function ENT:WireInit()
self.Entity:CreateInput("Switch")
self.Entity:HookFunction("Switch",ChangeColor)
end

function ChangeColor(ent,arg)
if arg then
ent:SetColor(0,255,0,255)
else
ent:SetColor(255,255,255,255)
end
end[/lua]

Here is normal Wire:
[lua]AddCSLuaFile( "cl_init.lua" )
AddCSLuaFile( "shared.lua" )

include('shared.lua')

ENT.WireDebugName = "Indicator"

function ENT:Initialize()
self.Entity:PhysicsInit( SOLID_VPHYSICS )
self.Entity:SetMoveType( MOVETYPE_VPHYSICS )
self.Entity:SetSolid( SOLID_VPHYSICS )

self.a = 0
self.ar = 0
self.ag = 0
self.ab = 0
self.aa = 0
self.b = 0
self.br = 0
self.bg = 0
self.bb = 0
self.ba = 0

self.Inputs = Wire_CreateInputs(self.Entity, { "A" })
end

function ENT:Setup(a, ar, ag, ab, aa, b, br, bg, bb, ba)
self.a = a or 0
self.ar = ar or 255
self.ag = ag or 0
self.ab = ab or 0
self.aa = aa or 255
self.b = b or 1
self.br = br or 0
self.bg = bg or 255
self.bb = bb or 0
self.ba = ba or 255

local factor = math.max(0, math.min(self.Inputs.A.Value-self.a/(self.b-self.a), 1))
self:TriggerInput("A", 0)
end

function ENT:TriggerInput(iname, value)
if (iname == "A") then
local factor = math.Clamp((value-self.a)/(self.b-self.a), 0, 1)
self:ShowOutput(factor)

local r = math.Clamp((self.br-self.ar)*factor+self.ar, 0, 255)
local g = math.Clamp((self.bg-self.ag)*factor+self.ag, 0, 255)
local b = math.Clamp((self.bb-self.ab)*factor+self.ab, 0, 255)
local a = math.Clamp((self.ba-self.aa)*factor+self.aa, 0, 255)
self.Entity:SetColor(r, g, b, a)
end
end

function ENT:ShowOutput(value)
if (value ~= self.PrevOutput) then
self:SetOverlayText( "Color = " .. string.format("%.1f", (value * 100)) .. "%" )
self.PrevOutput = value
end
end[/lua][/QUOTE]
Well done, you have made an entity which snaps from white to green and used less code than an entity which fades from one user-selected colour to another user-selected colour and displays information when looked at.
...What's your point?

[BoingBoing]

Oh, fine.

[lua]
AddCSLuaFile( "cl_init.lua" )
AddCSLuaFile( "shared.lua" )
include('shared.lua')

function ENT:Initialize()
swire.RegisterEntity(self)
self.SuperWire:CreateInput("Switch")
self.SuperWire:HookFunction("Switch",ChangeColor)
self.a = 0
self.b = 0
self.aCol = Color(255,255,255,255)
self.bCol = Color(255,255,255,255)
end

function ChangeColor(ent,arg)
if arg == self.a then
ent:SetColor(aCol)
ent:SetNWString("WireBubble","[b]Color:[/b] ("..aCol.r..","..aCol.g..","..aCol.b..","....aCol.a..")")
elseif arg == self.b
ent:SetColor(bCol)
ent:SetNWString("WireBubble","[b]Color:[/b] ("..bCol.r..","..bCol.g..","..bCol.b..","....bCol.a..")")
end
end[/lua]

Hell, it's only smaller since its the same basis and could be done on the regular wire.

[Lexic]

[QUOTE=BoingBoing;17942622]Oh, fine.

[lua]
AddCSLuaFile( "cl_init.lua" )
AddCSLuaFile( "shared.lua" )
include('shared.lua')

function ENT:Initialize()
swire.RegisterEntity(self)
self.SuperWire:CreateInput("Switch")
self.SuperWire:HookFunction("Switch",ChangeColor)
self.a = 0
self.b = 0
self.aCol = Color(255,255,255,255)
self.bCol = Color(255,255,255,255)
end

function ChangeColor(ent,arg)
if arg == self.a then
ent:SetColor(aCol)
ent:SetNWString("WireBubble","[b]Color:[/b] ("..aCol.r..","..aCol.g..","..aCol.b..","....aCol.a..")")
elseif arg == self.b
ent:SetColor(bCol)
ent:SetNWString("WireBubble","[b]Color:[/b] ("..bCol.r..","..bCol.g..","..bCol.b..","....bCol.a..")")
end
end[/lua]

Hell, it's only smaller since its the same basis and could be done on the regular wire.[/QUOTE]
Just a FYI: entity:SetColor() takes r,g,b,a rather than a colour object, because Garry likes pointless inconsistencies.

[BoingBoing]

I might as well make an ent:SetColorC() that does it for me :B but its not so difficult to type in aCol.r,aCol.g etc.

I wrote it in notepad in the morning on a school computer so you get the point, but it should work with minor changes.

I could practically create a GUI for Wiremod, but where's the fun in that?

[Netheous]

How many tools u made already ?

[Night-Eagle]

[QUOTE=Lexic;17943122]Just a FYI: entity:SetColor() takes r,g,b,a rather than a colour object, because Garry likes pointless inconsistencies.[/QUOTE]
Color objects tend to create more garbage, so there is an advantage to not using it. Precedents kind of screw everything up, though.

[Lexic]

[QUOTE=Night-Eagle;17970980]Color objects tend to create more garbage, so there is an advantage to not using it. Precedents kind of screw everything up, though.[/QUOTE]However, they're also the easiest way to store the 4 values you need to store if you want to set colours from variables.

[TomyLobo]

[QUOTE=pedroion;17929578]Back to the topic:

Are you re-doing the entire Wiremod from scratch?
If you are (IF), why don't you just add comments, while keeping the original Wiremod engine?[/QUOTE]

wiremod itself already has support for comments.
it's just that most inputs are uncommented :D

[editline]12:52AM[/editline]

[QUOTE=| FlapJack |;17934557]Nothing done in wire can't be done in Vanilla GMod. It's just a lot harder, and you feel better about making simpler contraptions.[/QUOTE]

hover vehicles.
the variety that keeps the distance to the ground

[editline]12:53AM[/editline]

[QUOTE=Gbps;17934788]I'm all up for a new wiremod. I'm sick and tired of having the wire keyboard run a console command every other frame even when it isn't on the map at all >_>[/QUOTE]
It's not supposed to do that and I thought I fixed that some months ago.
I'll look into it later.

[editline]01:03AM[/editline]

[QUOTE=BoingBoing;17935215]It does that already. The buttons are just fancy-painted VGUI inside a DPanelList.

I will hopefully comment every basic thing for a beginner to start wiremodding.

A new wired keyboard could easily be done by hooking onto the gamemode's KeyPressed instead of concommands.

Edit: Nevermind, KeyPressed is for IN_'s only. I guess you could datastream :P
Ooh, that gave me an idea. I'll convert all my usermessages into datastreams. I feel that is easier to handle then making a bunch of overcomplicated tables and then converting them into strings and then sending them over to the client and finally to have them slowly parse it.

Here's the indicator made with SuperWiremod:
-code-[/QUOTE]
Indicator isn't the best example of good Lua coding.
But it's kept that way because it works perfectly and doesn't have any side-effects either.
And as you can probably see it has lots of features yours lacks:
- duplicator support
- the ability to form a 7-seg together with other indicators (including proper DOR)
- color selection

I do like your input registration scheme though.
It lacks some kind of type system, however.
And one problem with that kind of system: Since the hook is registered in an Initialize function, it won't be updated by lua_reloadent (which doesn't call Initialize)

an alternative idea which I've had on my mind (for wiremod) for a while:
[lua]function ENT.TriggerInput:InputName(value)
--stuff
end[/lua]

EDIT: wee, got the first dumb rating while I'm still writing this post!

[editline]01:33AM[/editline]

wire indicator that actually works, but with about the same amount of functionality as yours:
[lua]AddCSLuaFile( "cl_init.lua" )

include('cl_init.lua')

ENT.WireDebugName = "Simple Indicator"

function ENT:Initialize()
self.Entity:PhysicsInit( SOLID_VPHYSICS )
self.Entity:SetMoveType( MOVETYPE_VPHYSICS )
self.Entity:SetSolid( SOLID_VPHYSICS )

self.Inputs = Wire_CreateInputs(self.Entity, { "A" })
self:TriggerInput("A", 0)
end

function ENT:TriggerInput(iname, value)
if iname == "A" then
if value == 0 then
self.Entity:SetColor(255, 0, 0, 255)
self:SetOverlayText( "Color = 0%" )
else
self.Entity:SetColor(0, 255, 0, 255)
self:SetOverlayText( "Color = 100%" )
end
end
end

function ENT:SpawnFunction( ply, tr )
if (not tr.Hit) then return end
local ent = ents.Create("gmod_wire_simple_indicator")
ent:SetModel("models/props_wasteland/coolingtank02.mdl")
local SpawnPos = tr.HitPos-tr.HitNormal*ent:OBBMins().z
ent:SetPos(SpawnPos)
ent:Spawn()
return ent
end[/lua]

And cl_init.lua:
[lua]-- shared part
ENT.Type = "anim"
ENT.Base = "base_wire_entity"

ENT.PrintName = "Simple Wire Indicator"
ENT.Author = "TomyLobo"
ENT.Spawnable = true
ENT.AdminSpawnable = true

if SERVER then return end

-- client part
ENT.RenderGroup = RENDERGROUP_BOTH[/lua]
I don't think yours works, unless you moved all initialization to the tool code.
which you shouldn't really do if you want duplicator compatibility and have generic tool code like wiremod
generic tool code means we have one file for many tools, saving the user download time.

[Overv]

I'm looking forward to this, Wire needs to be easier to get into for new people and generally some parts need to be redone.

Also, where did you get those icons? Or did you make them yourself using the silkicon set?

[Lexic]

[QUOTE=TomyLobo;17997018]And one problem with that kind of system: Since the hook is registered in an Initialize function, it won't be updated by lua_reloadent (which doesn't call Initialize)[/QUOTE]
I think you should fix that, because lua_reloadents does.

[TomyLobo]

lua_reloadents also breaks most entities along the way, because it only calls Initialize and not whatever else a tool might call.
In wiremod's case that's the Setup function most entities have.

[Lexic]

[QUOTE=TomyLobo;18005383]lua_reloadents also breaks most entities along the way, because it only calls Initialize and not whatever else a tool might call.
In wiremod's case that's the Setup function most entities have.[/QUOTE]
While I am not denying that your tool has use, not calling the Initialize function is stupid as entities tend to set up instance specific variables in it.

[TomyLobo]

lua_reloadent does not make a new instance.
It merely overwrites all the functions (and other fields that your entity has) in all existing instances.
This works most of the time, unless your member variables describe an irrecoverably invalid state, in which case you'll have to make a new ent or somehow reset them manually.

[lua]for _,ent in ipairs(ents.FindByClass(entname)) do
local table = ent:GetTable()
if table then
for k,v in pairs(metatable) do
table[k] = v
end
end
end[/lua]

[Lexic]

[QUOTE=TomyLobo;18005571]or somehow reset them manually.[/QUOTE]
with lua_reload_ents. :v:
Anyway, I see.

[BoingBoing]

I think that hooking functions instead of using TriggerInput is easier, but that's my opinion. Anyone else want to share theirs?

[QUOTE=Overv;18003905]I'm looking forward to this, Wire needs to be easier to get into for new people and generally some parts need to be redone.

Also, where did you get those icons? Or did you make them yourself using the silkicon set?[/QUOTE]
I made them myself.

[TomyLobo]

[QUOTE=BoingBoing;18017199]I think that hooking functions instead of using TriggerInput is easier, but that's my opinion. Anyone else want to share theirs?[/QUOTE]
what if you have 10 inputs that basically do the same, but just assign to different variables?
your current system requires one to register the 10 different functions one at a time.
if you changed it to provide the input name to the hooks, you'd still need to register the same function 10 times, which is 10 lines vs none

You could, of course, still have both systems:
If a hook was registered, you use that, otherwise you call TriggerInput.

[BoingBoing]

My way doesn't save space, its more organized rather than sticking everything inside the same function.

You could also have a function that does whatever you want with parameters to change the value. You can then hook an input to another function and inside there you would call the function that does whatever you want.

[TomyLobo]

writing something 10 times isn't primarily wasting space.
It's primarily unorganized, cumbersome and harder to read.
more organized would be having a table of hooks that is always found in the same place, like ENT.InputHandlers.inputname.
If you still want to register random functions as hooks, you can just assign them:
ENT.InputHandlers.On = myfunction

in wiremod, when you get an error caused by triggering an input, you know exactly what to search for: the input's name.
Also, single input handlers inside TriggerInput are usually short and you can view half of the I/O of your entity on one page.
Example:
[lua]function ENT:TriggerInput(iname, value)
if iname == "Activated" then
if value == 0 then
self.Active = 0
Wire_TriggerOutput(self.Entity, "On", 0)
if not ValidEntity(self.CamPlayer) then return end
self.CamPlayer:SetViewEntity(self.CamPlayer)
self.CamPlayer:SetFOV(self.OrginialFOV, 0.01)
else
if self.CamPod then
if self.CamPod:GetDriver() and self.CamPod:GetDriver():IsValid() then
self.CamPlayer = self.CamPod:GetDriver()
else
self.CamPlayer = self.OriginalOwner
end
end
self.CamPlayer:SetViewEntity(self.CamEnt)
self.CamPlayer:SetFOV(self.ZoomAmount, 0.01)
self.Active = 1
Wire_TriggerOutput(self.Entity, "On", 1)
end
elseif iname == "Zoom" /* and not self.RT */ then
self.ZoomAmount = math.Clamp(value, 1, self.OriginalFOV)
if self.Active == 1 then
self.CamPlayer:SetFOV(self.ZoomAmount, 0.01) -- TODO: RT camera
end
else
if self.CamEnt then
self.CamEnt:ReceiveInfo(iname, value)
end
end
end[/lua]
this is from gmod_wire_camcontroller and it also shows an example of the generic input handler thing i mentioned.
more examples can be found in Wire Numpad, Expression1/2, Radio and Text Screen

[TomyLobo]

just to be clear: I don't want to keep you from doing whatever you like, I'm just trying to show you that most decisions that were made about wiremod have their reasons, and they still apply.
Whatever you're doing, once it gets as many features as wiremod, it will probably just have a different user interface and be as complex, internally, as wiremod.

[Anticept]

Continuing on TomyLobo's point: I've made a post in the hidden dev section on the wiremod forums advising the devs not to treat your project as a competitor, BoingBoing. Figured if we make it a point that you aren't going to be considered a rival, it can help prevent a stupid War-of-the-Addons. In fact, who knows, one day we might learn from each other and get new insight on making either project better, or perhaps borrow some of your UI ideas to improve wiremod's rather ugly interface. Thumbs up and best of luck!

[Matte]

I agree with TomyLobo and Anticept. I wish you good luck on this project.

[BoingBoing]

I also don't want to be the enemy of Wiremod. (A giant freaken' community.)

I might try to build on Wiremod but I really want a more efficient and organized way of making Wiremod ents.

My way isn't perfect yet, but I'd like the community's opinion on what should be added/removed.

[Netheous]

I am still waiting for this ! Wire mod already pissd me off >.<

[turck3]

[quote]
I also don't want to be the enemy of Wiremod. (A giant freaken' community.)

I might try to build on Wiremod but I really want a more efficient and organized way of making Wiremod ents.

My way isn't perfect yet, but I'd like the community's opinion on what should be added/removed.
[/quote]
Well, the whole point of Anticept's post was to say that you're by no means our enemy and that we have much to gain from one another. I was actually about to start looking into rewriting the entity system anyway (ha) when Anticept made a post on wiremod.com with a link here, hence my sending you a PM and a steam friend invite. I'd be happy to support and perhaps even work on the project.

[quote]
I am still waiting for this ! Wire mod already pissd me off >.< [/quote]
From what I've gathered I doubt that this will be a great deal different in terms of gameplay and but rather, the behind the scenes stuff will be, you're stuck. Also, I'm going to go out on a limb and say you didn't like it because you didn't understand it... we have a support forum over at [url]www.wiremod.com[/url] if you have questions, and if that's not suited to you, we have a tutorials forum, in which I've contributed some odd 80 video tutorials...

[kccool2]

Very cool shit right here. I do hope this pulls through. Also, having the wiremod creators and Boingboing work together will be a very good thing indeed.

Good luck to you Boingboing! :D

[bromvlieg]

i dont get it, theres aready wire mod, and its good enough.
just fix up the derma and its done as far i can see.
your just remaking the buttons and stuffzor that is aready made!

reinfenting the wheel?

[TomyLobo]

I'd make you an interop entity if you want
just get the api reasonably finished first :)

[AzraelUK]

Regarding the GUI: I like the white-and-green area of the box in the picture, very swish. But having it contained in a standard grey Frame just seems wrong. There's not really any need for a close button, and it just generally doesn't go with the colours.

You may want to consider making your own Derma skin which can then easily be applied to these elements (this is of course assuming you haven't already done so).

[BoingBoing]

Close button = Cancel Button.

Also thinking about creating a completely separate for wire tools, except it would be impractical and unreasonable.

Thinking about making inputs be chosen first before outputs. I'm having doubts about this because sometimes its not just if's but its also sending variables.

[DrMelon]

Terribly sorry about the bump, but I have been looking forward to this for quite some time... how is it coming along?