GMod - What are you working on? May 2017 (#69)

[cogg]

[QUOTE=JasonMan34;52277833]For real. When I first got into Lua and modding it was such a pain.
Make a thread requesting help with something extremely simple, like a timer on a ulx command
Get the following response:

Jesus Christs dude just link the fucking timer library, ain't nobody gonna read your 300 line, every-variable-has-12-underscores [B]example _system[/B][/QUOTE]

Acecool aside, it seems like there are a lot of people who enjoy over-engineering things in the GLua community.

I think Icarus's code was fine though. Even given my unpopular opinions about OOP in Lua, I think chaining is a perfectly nifty pattern.

Fun fact, Dart has a special operator for this kind of thing: [URL="http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html"]Link[/URL]

[NeatNit]

I'm neutral about chaining, I think it's nice but personally don't see myself using it (I like to be explicit).

Regarding Acecool, I loved everything about that guy except his coding style. He would always have a solution, he was always friendly. He really was a really good coder. The style was the only issue - and Lua doesn't even have a style guide in the first place, so you can't even say his style was 'wrong'. Where did he go? IIRC some people were not too nice to him.

Edit: oh and the fact this his guides did too much demonstrating and not enough explaining, and often linked to his mirrors of things like steamcmd instead of the official site. I mean, he was obviously doing everything he could do to be helpful, but it just wasn't up to par.

[DrVrej]

Aside from the NPC Controller, I have been working on a Nazi Zombie styled addon. It's still WIP, so a lot of props used are just placeholders. Also this isn't a gamemode, instead it's a addon that comes with an entity. With this entity you can press E on it and it will dynamically load in all the objects and of course it will only work with supported map. But all the tools are there for people to create their own for any map they want and save it.
Here is the video:
[video=youtube;TLaYX-vRGKk]http://www.youtube.com/watch?v=TLaYX-vRGKk[/video]

[xav]

[QUOTE=Nookyava;52277648]The main issue is you're taking a language which is not supposed to be that style, and changing it.

It's sort of like when Acecool kept trying to force his coding style on everyone. It just confuses newcomers and makes them believe Lua is a lot more confusing than it actually is.

Great that you created something new, but I think it's overcomplicating Lua.[/QUOTE]

To me it seems like Lua was designed to be a tortured whore. That's why I like it.

[Apickx]

[QUOTE=VIoxtar;52276732]I'm kind of curious at the reason for all those dumbs
[t]https://cdn.discordapp.com/attachments/316871149491322881/317618402292137985/unknown.png[/t]
from the looks of it the final result is quite interesting, I may be completely missing something[/QUOTE]

He could have just done it in a lua-like way:

    local prototype = {
        x = 5 + pageX,
        y = 5,
        width = pageWidth,
        text = i,
        font = "Icarus.UI.Page",
        renderVector = self.renderVector,
        renderAngle = self.renderAngle,
        onClick = (pnl) =>
            self.cache[self.activePage].color = nil
            self.activePage = i
            self.cache[i].color = Icarus.theme.outline
        end
    }
    self.cache[i] = self.cache[i] or Icarus.UI.Button()
    for k,v in pairs(prototype) do self.cache[i][k] = v end
    self.cache[i]:render()

imho, oop chaining methods was just a hack to get around limitations of various languages, we don't have those limitations in lua, so we should be as clear as possible in our code. Doing `x=5` means you really know x will (should) be 5. When you call setX(), what happens? Will it resize the box instantaneously? Will the box be resized next render()? Will it automatically reflow the children? Who knows! It's OOP! Spin the wheel and find out!

[Ott]

[QUOTE=Apickx;52279783]He could have just done it in a lua-like way:

    local prototype = {
        x = 5 + pageX,
        y = 5,
        width = pageWidth,
        text = i,
        font = "Icarus.UI.Page",
        renderVector = self.renderVector,
        renderAngle = self.renderAngle,
        onClick = (pnl) =>
            self.cache[self.activePage].color = nil
            self.activePage = i
            self.cache[i].color = Icarus.theme.outline
        end
    }
    self.cache[i] = self.cache[i] or Icarus.UI.Button()
    for k,v in pairs(prototype) do self.cache[i][k] = v end
    self.cache[i]:render()

imho, oop chaining methods was just a hack to get around limitations of various languages, we don't have those limitations in lua, so we should be as clear as possible in our code. Doing `x=5` means you really know x will (should) be 5. When you call setX(), what happens? Will it resize the box instantaneously? Will the box be resized next render()? Will it automatically reflow the children? Who knows! It's OOP! Spin the wheel and find out![/QUOTE]

What if you want to make sure x is positive? You can't do that if you always set the value directly.

[MysteryPancake]

I'm probably just stupid, but does => even work in Lua when declaring a function? Is that even Lua? I've never seen that before.

[Apickx]

[QUOTE=Ott;52279805]What if you want to make sure x is positive? You can't do that if you always set the value directly.[/QUOTE]

It should error when I try to :render() it with a helpful message about x not being positive.

Should a button that will never render (for whatever reason) still error when it was passed bad values?

[sannys]

[QUOTE=Apickx;52279783]When you call setX(), what happens? Will it resize the box instantaneously? Will the box be resized next render()? Will it automatically reflow the children? Who knows! It's OOP! Spin the wheel and find out![/QUOTE]

Presumably if you are calling a function, you know what it does. The function creator has the responsibility of documenting the function's behavior. The responsibility of the caller is to know the behavior by reading the documentation. I don't see how any of that even relates specifically to OOP. That's just common sense in programming.

[Apickx]

[QUOTE=sannys;52279881]Presumably if you are calling a function, you know what it does. The function creator has the responsibility of documenting the function's behavior. The responsibility of the caller is to know the behavior by reading the documentation. I don't see how any of that even relates specifically to OOP. That's just common sense in programming.[/QUOTE]

What a nice world that would be.

Unfortunately, the documentation for `setX()` is probably "Sets the X position of the button", if it exists at all. Most people (me included) are not going to go scrounging around in the source code to find out what `setX()` /actually/ does, we're just going to test it and see if it works.

[rebel1324]

still mortar
[media]https://www.youtube.com/watch?v=6lD1bZ0PlGA[/media]

[FPtje]

[QUOTE=sannys;52279881]Presumably if you are calling a function, you know what it does. The function creator has the responsibility of documenting the function's behavior. The responsibility of the caller is to know the behavior by reading the documentation. I don't see how any of that even relates specifically to OOP. That's just common sense in programming.[/QUOTE]

What a nice world that sure wouldn't be. Besides being shorthand for blocks of code, functions are abstraction mechanisms. Well written functions just take some worry away from the caller, especially when they are part of some API. They follow the law of least surprises. When using well written functions, you don't come across weird caveats that can only be explained when one understands the actual implementation of the function.

With SetX, ideally you shouldn't have to know whether it does it immediately, in a render hook, with or without coroutines or by sending a support mail to Microsoft. Ideally, you can call SetX, look at the UI and find X to be set. You wouldn't expect things like stack overflows because you're calling it in the wrong hook, because that behaviour can only be explained by looking at the implementation.

Good interfaces hide implementation.

[NeatNit]

[QUOTE=Apickx;52279880]It should error when I try to :render() it with a helpful message about x not being positive.[/QUOTE]
Absolutely not. It should error when you set x negative in the first place. If it only errors after the fact, if you have more complex code you have no way of telling when or where X was set to negative, and you're screwed. Errors should occur at the moment they're made, not after.

[c👌de_g🎷]

[QUOTE=FPtje;52280112]What a nice world that sure wouldn't be. Besides being shorthand for blocks of code, functions are abstraction mechanisms. Well written functions just take some worry away from the caller, especially when they are part of some API. They follow the law of least surprises. When using well written functions, you don't come across weird caveats that can only be explained when one understands the actual implementation of the function.

With SetX, ideally you shouldn't have to know whether it does it immediately, in a render hook, with or without coroutines or by sending a support mail to Microsoft. Ideally, you can call SetX, look at the UI and find X to be set. You wouldn't expect things like stack overflows because you're calling it in the wrong hook, because that behaviour can only be explained by looking at the implementation.

Good interfaces hide implementation.[/QUOTE]

Good *abstractions hide implementation, but interfaces should be clear about the general approach they take, or at least well documented, to allow the developer to be properly and easily informed of efficiency concerns and possible leaky abstractions.

[ZeMysticalTaco]

[QUOTE=rebel1324;52280070]still mortar
[media]https://www.youtube.com/watch?v=6lD1bZ0PlGA[/media][/QUOTE]

I'd make a North Korea joke but it'd make too much sense, these look nice.

[IcarusCoding]

[QUOTE=Apickx;52279783]
Doing `x=5` means you really know x will (should) be 5. When you call setX(), what happens? Will it resize the box instantaneously? Will the box be resized next render()? Will it automatically reflow the children? Who knows! It's OOP! Spin the wheel and find out![/QUOTE]

In OOP you dont do object.x = 5
You use setters/getters outside of the object, while inside you variables.

[editline]27th May 2017[/editline]

[QUOTE=MPan1;52279830]I'm probably just stupid, but does => even work in Lua when declaring a function? Is that even Lua? I've never seen that before.[/QUOTE]

I use a transpiler to make it work in Lua.

[editline]27th May 2017[/editline]

[QUOTE=Apickx;52279880]It should error when I try to :render() it with a helpful message about x not being positive.[/QUOTE]

Since theres no clipping, you can do negative X and Y as its relative to a certain position and angle. You have to find the point you want to start drawing from using :setRenderVector() and :setRenderAngle() then you can use setY and setX to offset the point.

[FPtje]

[QUOTE=code_gs;52280237]Good *abstractions hide implementation, but interfaces should be clear about the general approach they take, or at least well documented, to allow the developer to be properly and easily informed of efficiency concerns and possible leaky abstractions.[/QUOTE]

Of course, as long as the general approach stays general. Things like O notations and naming of underlying data structures and algorithms. Stuff that shouldn't surprise the reader.

One must always keep in mind that documentation is not a proper solution to bad design decisions. With the SetX stack overflow example, the caveat not to run it in certain hooks would most likely end up in the documentation, but not before someone struggled with the question "[I]Why is a function this simple causing a damn stack overflow!?[/I]" and dived into the implementation to find out.

People don't read the documentation of every single function they use either, for that would be extremely inefficient. You find a function with a name, set of parameters and return values that fit your need and you throw it in, until you face problems. As such, many people would be bound to hit the same SetX stack overflow. The good coders find out which function call is causing the stack overflow and open up the documentation, the beginning ones might have trouble finding out it's SetX causing it and will get yelled at online for not reading the function's documentation.

Of course the experienced programmers have faced the issue before with SetY and happen to remember its caveats. They see the issue immediately or prevent hitting it in the first place. They have accepted it. "[I]It's not bad design, that's just how it works, it's in the damn documentation. Read it, you lazy bum[/I]".

[c👌de_g🎷]

[QUOTE=FPtje;52280351]Of course, as long as the general approach stays general. Things like O notations and naming of underlying data structures and algorithms. Stuff that shouldn't surprise the reader.

One must always keep in mind that documentation is not a proper solution to bad design decisions. With the SetX stack overflow example, the caveat not to run it in certain hooks would most likely end up in the documentation, but not before someone struggled with the question "[I]Why is a function this simple causing a damn stack overflow!?[/I]" and dived into the implementation to find out.

People don't read the documentation of every single function they use either, for that would be extremely inefficient. You find a function with a name, set of parameters and return values that fit your need and you throw it in, until you face problems. As such, many people would be bound to hit the same SetX stack overflow. The good coders find out which function call is causing the stack overflow and open up the documentation, the beginning ones might have trouble finding out it's SetX causing it and will get yelled at online for not reading the function's documentation.

Of course the experienced programmers have faced the issue before with SetY and happen to remember its caveats. They see the issue immediately or prevent hitting it in the first place. They have accepted it. "[I]It's not bad design, that's just how it works, it's in the damn documentation. Read it, you lazy bum[/I]".[/QUOTE]

I am not using documentation as an excuse for bad implementation, but in every complex programming scenario there will be a case where some function has an odd quirk or bug that has to be noted -- it is just the nature of natural, imperfect creation. Regardless of how well an interface is presented to someone unfamiliar with the documentation, it should always be backed with clear and easily accessible details, so in that regard, I agree with you.

I simply brought up the documentation point in response to your last line about hiding implementation in that it can be a double edged sword. Hiding implementation may be great for widespread libraries close to the metal that need to be compatible with a variety of instruction sets, but higher level interfaces will almost always carry the flaws and leaks of its abstracted target, and in that case, knowing implementation is extremely important. Any security expert or programming language designer will tell you that hiding details makes building on top of or knowing every facet of an interface extremely difficult, and thus while it may be useful to the average developer, it makes some jobs extremely difficult if not impossible.

[sannys]

[QUOTE=Apickx;52279898]What a nice world that would be.

Unfortunately, the documentation for `setX()` is probably "Sets the X position of the button", if it exists at all. Most people (me included) are not going to go scrounging around in the source code to find out what `setX()` /actually/ does, we're just going to test it and see if it works.[/QUOTE]

Because it probably is as simple as that, and you don't need to search the source to find what it does. If I'm a coder that publishes a script of mine and intends for others to use it, it's common sense that I make documentation for it. If I don't do that, that's just shit decision making. Has nothing to do with the function.

[QUOTE=FPtje;52280112]They follow the law of least surprises. When using well written functions, you don't come across weird caveats that can only be explained when one understands the actual implementation of the function.[/QUOTE]

I never said you need to understand [B]how[/B] a function works, I said you need to understand [B]what[/B] a function does. What you say assumes that technical limitations don't even exist.

Is [url=http://wiki.garrysmod.com/page/Panel/Dock]Panel:Dock[/url] a poorly written function because the panel's bounds are only updated on the next frame unless you call some other function?

Is [url=http://wiki.garrysmod.com/page/Panel/GetNumLines]Panel:GetNumLines[/url] a poorly written function as well? It, too, is only updated on the next frame, and yet, if I didn't read the documentation, I would never know.

Chances are, both of these caveats are a result of some underlying limitation or behavior in the source engine.

[quote]With SetX, ideally you shouldn't have to know whether it does it immediately, in a render hook, with or without coroutines or by sending a support mail to Microsoft. Ideally, you can call SetX, look at the UI and find X to be set. [B]You wouldn't expect things like stack overflows because you're calling it in the wrong hook, because that behaviour can only be explained by looking at the implementation.[/B][/quote]
Why would you need to see the implementation...? If a function is capable of causing bad behavior when used in a certain context, that should be [B]documented[/B] (see os.date below). You don't need to go into the source code. If that [I]isn't[/I] documented, again, that is shit decision making on the author's part.

[url=http://wiki.garrysmod.com/page/os/date]os.date[/url] can cause crashes on Windows if you use an invalid flag, and yet you just said that this sort of unexpected behavior can only be explained by looking at the implementation? I just did it by reading the documentation. It's inappropriate that os.date has this behavior, but I'm mentioning it to show you that you do [B]not[/B] need to see the implementation.

[quote]People don't read the documentation of every single function they use either, for that would be extremely inefficient. You find a function with a name, set of parameters and return values that fit your need and you throw it in, until you face problems.[/quote]You mean like in the documentation? Where are you finding a function's name and all of its parameters and returns from if you're not finding them from the documentation?

[rebel1324]

Am I only one who gets weird trace if you do more than two trace simultaneously?
It can't detect the displacements.

[editline]27th May 2017[/editline]

Warning, Spaghetti ahead: [url]https://pastebin.com/0PMEMfGn[/url]

[FPtje]

[QUOTE=sannys;52280527]
I never said you need to understand [B]how[/B] a function works, I said you need to understand [B]what[/B] a function does. What you say assumes that technical limitations don't even exist.[/QUOTE]
What I say does not assume that technical limitations don't exist. Technical limitations [I]do[/I] exist, but they don't have to surprise the caller of functions bound by them. Also, make sure not to confuse technical limitations with design flaws. With certain program design, some features can become really hard or even impossible to implement without certain limitations. These limitations could vanish when a (sometimes radically) different design is chosen.

Here are two brilliant examples:

[QUOTE=sannys;52280527]
Is [url=http://wiki.garrysmod.com/page/Panel/Dock]Panel:Dock[/url] a poorly written function because the panel's bounds are only updated on the next frame unless you call some other function?

Is [url=http://wiki.garrysmod.com/page/Panel/GetNumLines]Panel:GetNumLines[/url] a poorly written function as well? It, too, is only updated on the next frame, and yet, if I didn't read the documentation, I would never know.

Chances are, both of these caveats are a result of some underlying limitation or behavior in the source engine.

[/QUOTE]
I wouldn't know either. I would expect a get after a set to reflect the changes in the set. The fact that it doesn't is very surprising and blatantly undesirable. After all, its return value cannot be trusted to be correct if you don't know whether the state has been modified. I can guess that if you look at the [I]implementation[/I], you might find that the author of the function hit some infinite recursion, or hit some [I]other[/I] dependent value that doesn't update until later, something like that. They worked around it by having the getter update the next frame.

In general, such problems are typically caused by keeping track of the same state in multiple places in the implementation. When the state is updated in one place, all the parts of the state that are "derived" from that state must also be updated. You have to be [I]very[/I] careful not to have update cycles there. Such problems are rife in derma because every little element has its own state, every parent element has state about its children. To thread shit around you need to read the states from different elements and combine that in order to do shit with it. That's a nightmare to manage. It's really easy to work around synchronizing issues by letting the state "settle" for a frame before allowing further actions on it. That is a [U]conscious design decision[/U], and one with serious flaws.

There's a reason things like Facebook's React and the Elm programming language generally don't have these issues. They made different design decisions. Specifically, they made it the highest priority to have state defined only in [I]one[/I] place. That design decision was made with the exact purpose to solve the root cause of the problems Dock and GetNumLines have.

[QUOTE=sannys;52280527]
Why would you need to see the implementation...?
[/QUOTE]
To explain not [I]that[/I] a function has certain behaviour, but [I]why[/I].

[QUOTE=sannys;52280527]
[url=http://wiki.garrysmod.com/page/os/date]os.date[/url] can cause crashes on Windows if you use an invalid flag, and yet you just said that this sort of unexpected behavior can only be explained by looking at the implementation? I just did it by reading the documentation. It's inappropriate that os.date has this behavior, but I'm mentioning it to show you that you do [B]not[/B] need to see the implementation.
[/QUOTE]
The documentation tells us [I]that[/I] it crashes, but not [I]why[/I]. Again, it's probably easy enough to explain why it happens, but not without explaining what os.date does internally.

[QUOTE=sannys;52280527]
You mean like in the documentation? Where are you finding a function's name and all of its parameters and returns from if you're not finding them from the documentation?[/QUOTE]
autocomplete

[rebel1324]

Okay, gmod's trace is bitch.
If you go outside of the skybox by an unit, It will fuck up the trace mask so It will go through freaking displacement of the map.
solid part is okay.

So, I had to do some math
and the code is now nasty as hell

Don't ever use ignoreworld in trace
it's broken
it will make you angry

whoever added this feature, fuck off.
[thumb]http://i.imgur.com/Kbcbvka.jpg[/thumb]

[editline]28th May 2017[/editline]

[media]https://www.youtube.com/watch?v=MKwoG4CCIFs&feature=youtu.be[/media]
post merge

[SirRanjid]

Not much progress due to real life. So I obviously won't realease my mod yet.

[img]http://i.imgur.com/bNYCSBp.gif[/img]

But hud panels are draggable now and even rotateable. (Panel:Make3D(true, Angle(p,y,r)))
[img]http://i.imgur.com/0leg5AN.gif[/img] (more images here: [url]https://imgur.com/a/7fNqE[/url])

And I'm experimenting with dimming the hud (May be more useful for car huds but I want it anyways.):
[img]http://i.imgur.com/rxpKlDC.gif[/img]

[Pugsworth]

[QUOTE=SirRanjid;52281042]Not much progress due to real life. So I obviously won't realease my mod yet.

But hud panels are draggable now and even rotateable. (Panel:Make3D(true, Angle(p,y,r)))
(more images here: [url]https://imgur.com/a/7fNqE[/url])

And I'm experimenting with dimming the hud (May be more useful for car huds but I want it anyways.):
[img]http://i.imgur.com/rxpKlDC.gif[/img][/QUOTE]

If you take a ton of damage, all the panels should move and rotate wildly like in the pictures, then reassemble themselves. :v:

[G😹nz😻]

Fidget spinner hud incoming?

Come on, new page in my phone?...cool a reason to wake up from the bed
TBH i have not been working on nothing from a while...

[IMG]http://i.imgur.com/ZlNeLuZ.png[/IMG]

[vid]https://dl.dropboxusercontent.com/s/jr9qtq5ia26a0ds/coin.mp4[/vid]

[sharknado]

[IMG]https://image.ibb.co/fJLRJF/Untitled_1.png[/IMG]

Managed to implement rayleigh atmospheric scattering shader for gmod. Water doesn't interact with it, and it sometimes flickers (bug?).

[cogg]

[quote][img]http://cogg.rocks/uploads/hl2_2017-05-27_21-10-41.png[/img][/quote]

Greedy meshing. Annoying borders on textures are just to make it more clear where each quad is. Only works on the Z axis right now and I have not added texture repeating to the shader yet.

[Tenrys]

[QUOTE=MadParakeet;52283067]Greedy meshing. Annoying borders on textures are just to make it more clear where each quad is. Only works on the Z axis right now and I have not added texture repeating to the shader yet.[/QUOTE]

looks like old roblox

[Hnaknaw]

[B]Player death menu. [/B]

Will only popup when the player is killed by another player and/or an entity.

Automatically pulls the "attacker" from a net entity and updates the "Killer:" text box with the name and/or entity (also does props, but eh...)

[video=youtube;GlHw8GLm5Qw]https://www.youtube.com/watch?v=GlHw8GLm5Qw[/video]

[Nookyava]

[QUOTE=Richtofen;52283566][B]Player death menu. [/B]

Will only popup when the player is killed by another player and/or an entity.

Automatically pulls the "attacker" from a net entity and updates the "Killer:" text box with the name and/or entity (also does props, but eh...)

[video=youtube;GlHw8GLm5Qw]https://www.youtube.com/watch?v=GlHw8GLm5Qw[/video][/QUOTE]

I really like the whole effect thing you have going on. It's subtle, but still draws attention.