Next Update v4 - March 2016 Update is out! - Developers

[QUOTE=JasonMan34;49745251]+host_workshop_collection in command line[/QUOTE] for clients to download i'd assume doing that auto download thing for servers is an extremely foolish setup

Addons that have content should mark themselves for download. Automatic ways will never be as good as doing manually due to most servers extracting addons and packing them up into a single servercontent addon ( which I'd recommend you never actually do )

Hey, believe one of the newer updates broke how resource.AddWorkshop works. I uploaded an addon, let's call it version 1.0. AddWorkshop'd it, people connected and downloaded version 1.0 no issues. However two days later I updated the addon to version 1.1. The server had this new version mounted in the addons folder (also had the collection this addon was in mounted with +host_workshop_collection) Clients weren't downloading this newer version by default if they already had 1.0. Those who didn't have 1.0 were getting 1.1 but otherwise it wouldn't update for the people with the previous version of the pack, and had to subscribe manually. This used to work correctly as I have done it on other servers, have I done something incorrect or has the way resource.AddWorkshop works been changed?

[QUOTE=Splerge;49745898]Hey, believe one of the newer updates broke how resource.AddWorkshop works. I uploaded an addon, let's call it version 1.0. AddWorkshop'd it, people connected and downloaded version 1.0 no issues. However two days later I updated the addon to version 1.1. The server had this new version mounted in the addons folder (also had the collection this addon was in mounted with +host_workshop_collection) Clients weren't downloading this newer version by default if they already had 1.0. Those who didn't have 1.0 were getting 1.1 but otherwise it wouldn't update for the people with the previous version of the pack, and had to subscribe manually. This used to work correctly as I have done it on other servers, have I done something incorrect or has the way resource.AddWorkshop works been changed?[/QUOTE] I think the issue only occurs if you had joined the server [i]before[/i] the addon had updated and then joined again [i]after[/i] the addon had updated without restarting Garry's Mod first. If that's true, it should be fixed in the dev branch already. [editline]15th February 2016[/editline] There probably won't be any more non-trivial changes until the next update hits. Here's a list of the changes that might affect you: [b]Mounting order changes[/b] These have changed quite a lot. The idea is that you should be able to mod everything from within addons so that you can always delete them if you run in to issues. Just don't put your stuff in ./garrysmod directory. I made the output of the "path" console command more readable if you want to see the specifics. [code] ~new order~ ~old order~ Map Map Legacy addons Workshop addons Gamemodes Garry's Mod directory Workshop addons Garry's Mod VPKs Garry's Mod VPKs SourceSDK Garry's Mod directory Downloads Current map's game (client only) mount.cfg mounts SourceSDK Legacy addons Other mounted games Gamemodes Downloads Other mounted games (exc. mount.cfg) Fallback materials Fallback materials [/code] [b]AvatarImage changes[/b] It works perfectly from what I can tell. If your avatars end up wonky, this is why. [b]Filesystem sanity checks[/b] Trying to open files with weird names will fail. I really don't think you'd hit this problem unless you have a typo somewhere, in which case you'd be failing to open your files anyway. You'll see any of the errors pop up if you have the developer ConVar enabled. [b]Anti-speedhack stuff[/b] This should work fine as it's the exact system TF2 uses. You can control it with the sv_maxusrcmdprocessticks ConVar. Setting that to 0 will disable the system and people will be able to speedhack as fast as they want. The default value is pretty lenient though, so you may want to even turn it down a bit. [b]Player simulation[/b] Players will now 'think' all the time, even when not sending usercommands to the server. This means that where you would usually see a player floating about because they are joining/lagging, they'll just appear to be doing nothing. If this is causing issues, make sure you haven't set sv_minupdaterate to some rediculously high value. [b]UTF-8 text output on Windows SRCDS consoles[/b] (As of now, not in the dev branch. It'll be there within an hour) Should work fine, if the output is weird this is probably why.

[QUOTE=icefox;49745226]Can we get it so that we can use collection ID's for workshop downloads? instead of doing each workshop ID?[/QUOTE] Do it yourself. [url]https://lab.xpaw.me/steam_api_documentation.html#ISteamRemoteStorage_GetCollectionDetails_v1[/url] Call this web api method, JSONToTable, iterate over the workshop addons and call resource.AddWorkshop.

[QUOTE=icefox;49745226]Can we get it so that we can use collection ID's for workshop downloads? instead of doing each workshop ID?[/QUOTE] an extension exists for this: [url]https://github.com/demgod/Resource-Extension/blob/master/resource_ext.lua[/url]

[QUOTE=Willox;49745928] [b]Anti-speedhack stuff[/b] This should work fine as it's the exact system TF2 uses. You can control it with the sv_maxusrcmdprocessticks ConVar. Setting that to 0 will disable the system and people will be able to speedhack as fast as they want. The default value is pretty lenient though, so you may want to even turn it down a bit. [/QUOTE] What's the difference between this and the ConVar sv_max_usercmd_future_ticks? Is there going to be any conflicting behavior if both are set to certain values?

[QUOTE=TheDivinity;49747167]What's the difference between this and the ConVar sv_max_usercmd_future_ticks? Is there going to be any conflicting behavior if both are set to certain values?[/QUOTE] If you look a couple posts up, that ConVar is being removed.

[QUOTE=TheDivinity;49747167]What's the difference between this and the ConVar sv_max_usercmd_future_ticks? Is there going to be any conflicting behavior if both are set to certain values?[/QUOTE] sv_max_usercmd_future_ticks was a (not very good) feature bought over from Day of Defeat: Source and has been removed from Garry's Mod. It worked by just ignoring any usercommands the client sent that had a tick-count that was too high compared to the server. The new system is from Team Fortress 2 and limits the amount of usercommands that can be ran on a player per frame. There's a few things I want to change with it, but for now it is unchanged.

Can we get some sort of function or convar to set how often [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/GM/PlayerCanHearPlayersVoice]GM/PlayerCanHearPlayersVoice[/url] is called? It would make fixing all too common performance issues with it much easier and faster since there would be no need to cache it in a timer.

[QUOTE=StonedPenguin;49747540]Can we get some sort of function or convar to set how often [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/GM/PlayerCanHearPlayersVoice]GM/PlayerCanHearPlayersVoice[/url] is called? It would make fixing all too common performance issues with it much easier and faster since there would be no need to cache it in a timer.[/QUOTE] Can you just do a check to see if it has been a long enough interval since the last calculation and perform a new one, else use a cached result?

The internals a bit dodgy on that one. Ideally we'd call the hook immediately as a player begins talking and then keep calling it periodically as they continue to speak. It obviously sounds like a good idea, but don't expect any changes to it for the next update.

[QUOTE=StonedPenguin;49747540]Can we get some sort of function or convar to set how often [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/GM/PlayerCanHearPlayersVoice]GM/PlayerCanHearPlayersVoice[/url] is called? It would make fixing all too common performance issues with it much easier and faster since there would be no need to cache it in a timer.[/QUOTE] This is the worst way to solve that problem. Just because you can't optimise your calculation, the entire system for deciding who gets to hear whom is to be slowed down? You may have an expensive algorithm, but delaying the entire PlayerCanHearPlayersVoice scheme slows down the inexpensive and simple algorithms. That is noticable and it can get quite annoying. Also, to further drive down the point: substitute PlayerCanHearPlayersVoice with HUDPaint: "My HUDPaint algorithm is expensive. Can there be a ConVar to set how many times HUDPaint is called per second?" It's basically shoving the work of optimising algorithms away from the author of said algorithms and onto the event system that the author uses to trigger them. "[I]Call me less often to hide the fact that my algorithm is slow![/I]"

[QUOTE=FPtje;49748019]This is the worst way to solve that problem. Just because you can't optimise your calculation, the entire system for deciding who gets to hear whom is to be slowed down? You may have an expensive algorithm, but delaying the entire PlayerCanHearPlayersVoice scheme slows down the inexpensive and simple algorithms. That is noticable and it can get quite annoying. Also, to further drive down the point: substitute PlayerCanHearPlayersVoice with HUDPaint: "My HUDPaint algorithm is expensive. Can there be a ConVar to set how many times HUDPaint is called per second?" It's basically shoving the work of optimising algorithms away from the author of said algorithms and onto the event system that the author uses to trigger them. "[I]Call me less often to hide the fact that my algorithm is slow![/I]"[/QUOTE] Even a simple distance check * 120 players the way it is now gets stupid expensive. Willox's solution is obviously better though.

[QUOTE=Handsome Matt;49748855]people should just be doing distance checking in a different hook and using PlayerCanHearPlayersVoice with the simplest lookup "cache" table.[/QUOTE] Also getting the squared distance instead of using square root needlessly.

[QUOTE=vexx21322;49748990]Also getting the squared distance instead of using square root needlessly.[/QUOTE] Doesn't really apply in the context of absolute range checks.

[QUOTE=Handsome Matt;49748855]people should just be doing distance checking in a different hook and using PlayerCanHearPlayersVoice with the simplest lookup "cache" table.[/QUOTE] The whole point of this request is to not have to cache things and use a timer / "different hook" to do the actual calculations.

[QUOTE=Handsome Matt;49749452]but that's dumb, just have the hook called when the hook should be called?? and have developers use it properly??[/QUOTE] But it doesn't need to be or simply can't called that often for most use cases. The overhead of calling it as much as it does internally could be eliminated as well as the overhead of having to cache it.

Do your expensive calculations in a hook that isn't O(N^2), problem solved!

[QUOTE=Handsome Matt;49749452]but that's dumb, just have the hook called when the hook should be called??[/QUOTE] This is exactly what we're asking for. The hook to be called only when it NEEDS to be, such as when a player starts talking. Not EVERY SINGLE TICK. A second ago you were telling people to cache things, now you're saying the hook needs to be called when it should be? ?

[QUOTE=xaviergmail;49750258]This is exactly what we're asking for. The hook to be called only when it NEEDS to be, such as when a player starts talking. Not EVERY SINGLE TICK. A second ago you were telling people to cache things, now you're saying the hook needs to be called when it should be? ?[/QUOTE] And if the player leaves the hearing radius while they are talking? [editline]15th February 2016[/editline] While we're on the topic of PlayerCanHearPlayersVoice. How about a 3rd return value that controls volume?

[QUOTE=Willox;49745928]Players will now 'think' all the time, even when not sending usercommands to the server[/QUOTE] Wait, so now isn't it the same as Tick? [B]EDIT:[/B] Oh, so Tick only runs on SERVER ticks, got it

[QUOTE=xaviergmail;49750258]This is exactly what we're asking for. The hook to be called only when it NEEDS to be, such as when a player starts talking. Not EVERY SINGLE TICK. A second ago you were telling people to cache things, now you're saying the hook needs to be called when it should be? ?[/QUOTE] Not calling that hook periodically when players are talking would break DarkRP's local voice chat. After all, players tend to move while talking. Calling PlayerCanHearPlayersVoice only when a player starts talking is like calling HUDPaint only on spawn and assuming the HUD won't change until you die. Also, I'm not against Willox' idea of not calling the hook for players that aren't talking. I don't think that will have any effect on functionality, as such there's no convar needed for that change.

Can we have direct PVS and PAS checking? Right now we have to use a RecipientFilter.

[QUOTE=FPtje;49751310]Not calling that hook periodically when players are talking would break DarkRP's local voice chat. After all, players tend to move while talking. Calling PlayerCanHearPlayersVoice only when a player starts talking is like calling HUDPaint only on spawn and assuming the HUD won't change until you die. Also, I'm not against Willox' idea of not calling the hook for players that aren't talking. I don't think that will have any effect on functionality, as such there's no convar needed for that change.[/QUOTE] No one suggested it to not run periodically? People just suggested it be called less times since the current rate it's being called at is just ridiculous. Periodically while talking -- even every think instead of tick -- would be more efficient without the loss of effect.

Say a server has a workshop map and that map is resource.AddWorkshop()'d. If a client connects with a slightly different version of the map as a raw .bsp inside of /maps, they get kicked with the "Client's map differs from the server's" reason. Isn't it reasonable to believe that the server's workshop map should be downloaded and mounted on the client so they can play on that server, without requiring the client to manually delete their local copy of the map? Or are there implementation factors that prevent this from being possible? On a side note, it looks like having a FastDL'd altered version of the map with the same name (inside /download/maps) doesn't cause the client to be kicked, which is fortunate. However, I'm still noticing a large amount of players being kicked because they are presumably downloading different versions of the map via garrysmod.org.

[QUOTE=code_gs;49751560]No one suggested it to not run periodically? People just suggested it be called less times since the current rate it's being called at is just ridiculous. Periodically while talking -- even every think instead of tick -- would be more efficient without the loss of effect.[/QUOTE] The post I quoted suggested it: [QUOTE=xaviergmail;49750258][...] such as when a player starts talking. Not EVERY SINGLE TICK.[/QUOTE] Perhaps you're right in saying that running the hook in Think instead of Tick would provide more efficiency without affecting functionality. Regardless, it shouldn't be up to a ConVar, as StonedPenguin suggested. The GMod devs are to decide how often that hook is called. Leaving it to some ConVar will lead to convar setting wars: "Oh [I]my[/I] mod needs it to run at least every think" "Oh but [I]MY[/I] algorithm is slow, so I need it to run at most once per second!" At which point you get timers to have one addon set the convar later than the other to "fix" incompatibilities. The speed at which a hook is called is not a user setting, it's a design decision. Nothing good can come of users having control over it.

[QUOTE=FPtje;49751623]The post I quoted suggested it: Perhaps you're right in saying that running the hook in Think instead of Tick would provide more efficiency without affecting functionality. Regardless, it shouldn't be up to a ConVar, as StonedPenguin suggested. The GMod devs are to decide how often that hook is called. Leaving it to some ConVar will lead to convar setting wars: "Oh [I]my[/I] mod needs it to run at least every think" "Oh but [I]MY[/I] algorithm is slow, so I need it to run at most once per second!" At which point you get timers to have one addon set the convar later than the other to "fix" incompatibilities. The speed at which a hook is called is not a user setting, it's a design decision. Nothing good can come of users having control over it.[/QUOTE] I have to disagree with you on convars. Having locked convars that addons can't affect could be a useful solution to hook efficiency or just developer options in many cases: look at Valve's sk_ Convar set as an example. Although it probably won't happen, it's not a bad idea.

something changed in a recent update, when i set the material on a player/entity and they leave the pvs and come back, the material is reset and i can't set bodygroups on players clientside

[QUOTE=code_gs;49751678]I have to disagree with you on convars. Having locked convars that addons can't affect could be a useful solution to hook efficiency or just developer options in many cases: look at Valve's sk_ Convar set as an example. Although it probably won't happen, it's not a bad idea.[/QUOTE] The original idea of the Convar was for addons to change it. Having server owners set the convar is even more disastrous than having developers set them.