Next Update v6.0 - October 2016

[Rubat]

[QUOTE=geferon;51272695]It literally happened to me every time i was connected to a server and i suscribed to a collection with more than 5 addons[/QUOTE]

OK I will try that.

[editline]28th October 2016[/editline]

Ok I know what he problem is but it will be a bitch to fix.

[kpjVideo]

[QUOTE=Robotboy655;51272704]OK I will try that.

[editline]28th October 2016[/editline]

Ok I know what he problem is but it will be a bitch to fix.[/QUOTE]

Sheeit,

I'm not sure if this is a Steam or GMod issue (I'll assume Steam though) -- subscribing to quite a bit of content will usually crash Steam for me as well.

[Jcw87]

[QUOTE=Robotboy655;51268051]

* Removed the unnecessary check for whether the user owns Source SDK Base 2006

[/QUOTE]

I seem to recall that there was a requirement of owning a Source engine game to buy and play garrysmod. Is that still a thing? If it is, that 'unnecessary check' might be required as part of an agreement with Valve. You might want to check with Garry on that (if you haven't already).

[Rubat]

[QUOTE=Jcw87;51276932]I seem to recall that there was a requirement of owning a Source engine game to buy and play garrysmod. Is that still a thing? If it is, that 'unnecessary check' might be required as part of an agreement with Valve. You might want to check with Garry on that (if you haven't already).[/QUOTE]

Garry's Mod is a standalone game and does not require any other game run or be played.

It has always worked like that, but recently that piece of code seems to causing problems as Steam doesn't return correct values in some cases or something.

The check was for running HL2 mods.

[Rubat]

[QUOTE=kpjVideo;51276911]Sheeit,

I'm not sure if this is a Steam or GMod issue (I'll assume Steam though) -- subscribing to quite a bit of content will usually crash Steam for me as well.[/QUOTE]

Try to replicate the issue now on Dev branch and see if it still gets stuck in the update/extract loop.

[url]http://wiki.garrysmod.com/page/Dev_Branch[/url]

[YoutoYokodera]

The subscribing - crashing thing has been occur for a long time for everyone
If only gmod is down I'm ok but it has to take steam with it :cry:
When I sub like about 20 big addon, it will download as usual, then when it extract it still go as normal, but when it done extracting it start to show the extracting again, and every thing just stay at 0 - 1 % and it keep looping between addon trying to extract
Then it ded

[kpjVideo]

[QUOTE=Robotboy655;51277571]Try to replicate the issue now on Dev branch and see if it still gets stuck in the update/extract loop.

[url]http://wiki.garrysmod.com/page/Dev_Branch[/url][/QUOTE]

Just another thing I've thought of.

Generally for me, my game will sometimes freeze for up to 5 minutes after launching (for what I assume is mounting addons) Sometimes if I close the game and open it back up, it doesn't happen.

Is there an ability to prevent that lag by not mounting workshop addons until they're necessary from the server? Maybe caching them?

[Rubat]

[QUOTE=kpjVideo;51278633]Just another thing I've thought of.

Generally for me, my game will sometimes freeze for up to 5 minutes after launching (for what I assume is mounting addons) Sometimes if I close the game and open it back up, it doesn't happen.

Is there an ability to prevent that lag by not mounting workshop addons until they're necessary from the server? Maybe caching them?[/QUOTE]

-noworkshop. Do I have confirmation that the issue you were having is solved?

[kpjVideo]

[QUOTE=Robotboy655;51278700]-noworkshop. Do I have confirmation that the issue you were having is solved?[/QUOTE]

It appears to be fixed, I was able to subscribe to ~230 collection items with no crashes at all.

Thanks!

[NeatNit]

I just noticed that [url=https://github.com/garrynewman/garrysmod/blob/784cd57576d85712fa13a7cea3a9523b4df966b0/garrysmod/lua/includes/util.lua#L268-L273]TimedSin[/url] has a mistake:
[lua]function TimedSin( freq, min, max, offset )
return math.sin( freq * math.pi * 2 * CurTime() + offset ) * ( max - min ) * 0.5 + min
end[/lua]
Should be:
[lua]function TimedSin( freq, min, max, offset )
return (math.sin( freq * math.pi * 2 * CurTime() + offset ) + 1) * 0.5 * ( max - min ) + min
end[/lua]

The sin part is 'normalized' to the range -0.5 to 0.5, instead of 0 to 1, therefore the min and max arguments don't work as expected.

So, two questions:
1. how the fuck does something like this happen?
2. can it even be fixed? (breaks anything that ever used it)

if the answer to 2 is no then this function is more trouble than it's worth.

[editline]31st October 2016[/editline]

Maybe deprecate the old one and make a fixed CurTimeSin, and then also RealTimeSin?

All above applies to TimedCos as well

[Donkie]

[QUOTE=NeatNit;51286081]I just noticed that [url=https://github.com/garrynewman/garrysmod/blob/784cd57576d85712fa13a7cea3a9523b4df966b0/garrysmod/lua/includes/util.lua#L268-L273]TimedSin[/url] has a mistake:
[lua]function TimedSin( freq, min, max, offset )
return math.sin( freq * math.pi * 2 * CurTime() + offset ) * ( max - min ) * 0.5 + min
end[/lua]
Should be:
[lua]function TimedSin( freq, min, max, offset )
return (math.sin( freq * math.pi * 2 * CurTime() + offset ) + 1) * 0.5 * ( max - min ) + min
end[/lua]

The sin part is 'normalized' to the range -0.5 to 0.5, instead of 0 to 1, therefore the min and max arguments don't work as expected.

So, two questions:
1. how the fuck does something like this happen?
2. can it even be fixed? (breaks anything that ever used it)

if the answer to 2 is no then this function is more trouble than it's worth.

[editline]31st October 2016[/editline]

Maybe deprecate the old one and make a fixed CurTimeSin, and then also RealTimeSin?

All above applies to TimedCos as well[/QUOTE]

Best to just document this oddity on the wiki imo

[NeatNit]

[url]http://wiki.garrysmod.com/index.php?title=Global/TimedSin&curid=2732&diff=25774&oldid=24423[/url]

I feel dirty.

[Rubat]

[QUOTE=NeatNit;51286081]So, two questions:
1. how the fuck does something like this happen?
2. can it even be fixed? (breaks anything that ever used it)[/QUOTE]

1) As the comment above the function definition implies, it was copy-pasted from somewhere, before the code was put on github. Either the original person who made it didn't pay attention, or it was poorly modified when it was copied.
2) Well the obvious answer is yes, the real question is "[b]SHOULD[/b] this be fixed?"

[c👌de_g🎷]

I personally didn't know this function existed, but since this issue is with math and not some weird functional behaviour, this should immidiately be corrected.

[NeatNit]

The problem is that it does change the output of the function. If anyone was using it, fixing this function WILL change the size of their stuff.

So one solution is to take the php approach, deprecated TimedSin and replace it with TimedSin_Real :v:
This is basically what I suggested, expect to name it CurTimeSin (which also correctly implies that it uses CurTime), and at the same time we can add RealTimeSin that uses RealTime with the same formula.

I don't think there's a point to do the same with TimedCos, as the result is basically the same as TimedSin with an offset of half pi or something like that

[aStonedPenguin]

[QUOTE=Noi;51287065]Deprecate TimedSin and put a proper one into math or util lib?[/QUOTE]

There's no point in deprecating shit in this game if it will never be removed.. which is the current attitude.

Something that I've suggested in the past would be a nice middle ground:
[QUOTE=StonedPenguin;50855887]Garrysmod needs a lua Warning function much like oxide has for rust to use on all this deprecated shit.[/QUOTE]

[NeatNit]

[QUOTE=StonedPenguin;51287577]There's no point in deprecating shit in this game if it will never be removed.. which is the current attitude.

Something that I've suggested in the past would be a nice middle ground:[/QUOTE]
Sure, it's, very easy to add an [url=http://wiki.garrysmod.com/page/Global/ErrorNoHalt]ErrorNoHalt[/url] as the first line of every deprecated function. OTOH, many of the deprecated functions are actually still used within gmod itself, which is just an example of how painful/pointless it is to 'fix what ain't broken'. There's different reasons for deprecation, some of them are deprecated just because they're 'out of style' or considered bad practice, and others actually have issues. -brb-

[aStonedPenguin]

The function would need spam protection for functions that call in HUDPaint and ideally its own color to distinguish it so ErrorNoHalt wouldn't work.

[NeatNit]

-back-

As I was saying, not all deprecated function should actually be removed. [url=https://wiki.garrysmod.com/page/surface/ScreenHeight]surface.ScreenHeight[/url], for example, does no harm existing as a mirror of [url=https://wiki.garrysmod.com/page/Global/ScrH]ScrH[/url]. However, [url=https://wiki.garrysmod.com/page/IMaterial/SetShader]IMaterial:SetShader[/url] obviously has no reason to exist and any occurrences of it in code are necessarily wrong and should be removed.

Therefore I would use this hypothetical deprecation warning on SetShader, but let ScreenHeight exist just fine until the next major update to gmod.

See my point? Not ALL deprecated functions should be removed.

[aStonedPenguin]

[QUOTE=NeatNit;51287905]-back-

As I was saying, not all deprecated function should actually be removed. [URL="https://wiki.garrysmod.com/page/surface/ScreenHeight"]surface.ScreenHeight[/URL], for example, does no harm existing as a mirror of [URL="https://wiki.garrysmod.com/page/Global/ScrH"]ScrH[/URL]. However, [URL="https://wiki.garrysmod.com/page/IMaterial/SetShader"]IMaterial:SetShader[/URL] obviously has no reason to exist and any occurrences of it in code are necessarily wrong and should be removed.

Therefore I would use this hypothetical deprecation warning on SetShader, but let ScreenHeight exist just fine until the next major update to gmod.

See my point? Not ALL deprecated functions should be removed.[/QUOTE]

No, they should be if they're deprecated or redundant. But they can't simply because backward compatibility is a major priority which is why a Warning function would be a fantastic middle ground.

[NeatNit]

A warning is just as bad as removing them, it just gives the dev a grace period.

[YourStalker]

[QUOTE=NeatNit;51287988]A warning is just as bad as removing them, it just gives the dev a grace period.[/QUOTE]

Yeah but warnings are annoying and gets people to replace them. No gmod programmers ever go and say "hmm I wonder if my function calls are deprecated better go see" two years later.

[aStonedPenguin]

[QUOTE=NeatNit;51287988]A warning is just as bad as removing them, it just gives the dev a grace period.[/QUOTE]

A warning only nags devs and server owners. Players won't be upset their add-ons suddenly stopped working which is the point of maintaining backward compatibility.

[TheMaster111]

When killing npc_combine_camera and npc_turret_ceiling
Its not calling the function OnNPCKilled

[Rubat]

Ok, so, some news for server hosts, I have pushed an update to Workshop for srcds that uses the new ISteamUGC API alongside Steamworks API update to v1.38a.

Benefits are:
1) Addons from linked collections are now also downloaded
2) You should no longer have any problems with downloading large addons
3) You no longer need an API key to use Workshop on srcds

Cons, due to how the new API works:
1) You will have to deal with extra files in your server setup. By default, it stores the Steam cache into a folder called steam_cache/ next to srcds.exe. This is where Steam downloads the addons from their servers to.
In future you will have the ability to customize where the cache is stored via command line parameter, to potentially share it between multiple server instances or something.
2) [b]Unfortunately for all "old API" addons, that means that it will store an extra compressed copy of each newly downloaded addon.[/b]
I could possibly manually delete the compressed files, but I am not sure how good of an idea it is for now. Maybe in the future. This will not be a problem for addons uploaded with the new API when we update the client to support them, since we would not have to manually extract and move them around, they will always be in your Steam cache folder.

For those that care, I urge you to test this new system on your server and provide feedback, especially if something doesn't work as it should.

[FPtje]

Huh, I'd have to update GMosh I guess (when the client is released). Haven't touched that in ages.

[YourStalker]

How would you go about updating an addon to use the new api, just a reupload.

[Rubat]

[QUOTE=YourStalker;51301930]How would you go about updating an addon to use the new api, just a reupload.[/QUOTE]

No reuploads, eventually when we switch the client to the new thing, the tools will be updated to the new API as well, so that all you have to do is update your addon like you normally would and it will be switched to the new format for you. The new format is not backwards compatible ( so you can't download new format addons with old API ) so that's why its not happening just yet.

[MattJeanes]

[QUOTE=Robotboy655;51301282]Ok, so, some news for server hosts, I have pushed an update to Workshop for srcds that uses the new ISteamUGC API alongside Steamworks API update to v1.38a.

Benefits are:
1) Addons from linked collections are now also downloaded
2) You should no longer have any problems with downloading large addons
3) You no longer need an API key to use Workshop on srcds

Cons, due to how the new API works:
1) You will have to deal with extra files in your server setup. By default, it stores the Steam cache into a folder called steam_cache/ next to srcds.exe. This is where Steam downloads the addons from their servers to.
In future you will have the ability to customize where the cache is stored via command line parameter, to potentially share it between multiple server instances or something.
2) [b]Unfortunately for all "old API" addons, that means that it will store an extra compressed copy of each newly downloaded addon.[/b]
I could possibly manually delete the compressed files, but I am not sure how good of an idea it is for now. Maybe in the future. This will not be a problem for addons uploaded with the new API when we update the client to support them, since we would not have to manually extract and move them around, they will always be in your Steam cache folder.

For those that care, I urge you to test this new system on your server and provide feedback, especially if something doesn't work as it should.[/QUOTE]

This is great, been waiting for this stuff to start being integrated properly! Quick question though, is this on the main branch or only on the dev branch?

[Rubat]

All changes since October 2016 update 2 are obviously on Dev branch only.