[QUOTE=FPtje;49751789]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.[/QUOTE]
Who cares if an owner fucks over their own server? As long as you make usage of a feature clear, then any problems boils down to the owner's incompetence. Anyway, no typical DarkRP manager is going to be touching features that require a pretty good understanding of hooks if that is what you mean.
[QUOTE=FPtje;49751789]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.[/QUOTE]
The argument was that with something to set the amount of times it calls that hook you could avoid disgusting workarounds such as yours [URL="https://github.com/FPtje/DarkRP/blob/master/gamemode/modules/base/sv_gamemode_functions.lua#L281"]here[/URL]. That's a lot of overhead that could be avoided with a function or convar.
[QUOTE=code_gs;49751854]Who cares if an owner fucks over their own server? As long as you make usage of a feature clear, then any problems boils down to the owner's incompetence. Anyway, no typical DarkRP manager is going to be touching features that require a pretty good understanding of hooks if that is what you mean.[/QUOTE]
The one who is asked to implement that convar should care, or at least I would fucking hope so. Why on earth would you want to implement a convar that addon developers can't use and server owners can really only use to fuck their own server up? Really, would you expect anyone to benefit from such convar?
[quote]Oh I have a server with addons X, Y and Z. Addon Z uses a heavy PlayerCanHearPlayersVoice hook, so let me just decide to set that convar to once per second.[/quote]
Says no server owner ever, unless they're the author of addon Z.
[QUOTE=StonedPenguin;49751870]The argument was that with something to set the amount of times it calls that hook you could avoid disgusting workarounds such as yours [URL="https://github.com/FPtje/DarkRP/blob/master/gamemode/modules/base/sv_gamemode_functions.lua#L281"]here[/URL]. That's a lot of overhead that could be avoided with a function or convar.[/QUOTE]
That's not disgusting, that's a low level optimisation. Localising global variables is common practice. Also, if you're talking about the 0.5 second timer: that timer affects [B]my[/B] code and [B]my[/B] code only. If you want to put the entire PlayerCanHearPlayersVoice on 0.5 seconds, then functional wise you're doing the [I]exact same thing[/I], with the big difference that you affect [B]all[/B] code instead of just your own.
The fact that [B]YOU[/B] need an expensive calculation for calculating voice, doesn't mean that [U]every other hook[/U] should suffer from it. Don't solve it globally when you can do it locally. You're affecting things that have nothing to do with your problem. It's an unnecessary shotgun approach. It does more than is needed.
Fuck, let's continue the reasoning, StonedPenguin has an expensive voice algorithm. How about he lowers [I]the entire tickrate[/I] of the server. It solves his problem because his expensive algorithm will be called less, and it's even [I]more[/I] of a catch-all than reducing the amount of calls to PlayerCanHearPlayersVoice. It's the exact same step, but then repeated. It even has the exact same consequences, but then on a bigger scale.
[QUOTE=FPtje;49752056]The one who is asked to implement that convar should care, or at least I would fucking hope so. Why on earth would you want to implement a convar that addon developers can't use and server owners can really only use to fuck their own server up? Really, would you expect anyone to benefit from such convar?
Says no server owner ever, unless they're the author of addon Z.[/quote]
So developers can't be server owners? That's who the ConVar is made for; but I guess if they just don't exist in your book, we can just end this entire argument. And like YOU said: addon developers could change the ConVar in their code making it so your gamemode would have to hack around it
If you have a gamemode in an extracted addon folder inside /addons/folder name/gamemodes, all entities, effects and weapons inside gamemodes/name/entities will not load. Is this something that is fixed with the new loading order? If not, can we get a fix to this? Same thing happens with everything in the contents folder.
[QUOTE=code_gs;49752475]So developers can't be server owners? That's who the ConVar is made for; but I guess if they just don't exist in your book, we can just end this entire argument. And like YOU said: addon developers could change the ConVar in their code making it so your gamemode would have to hack around it[/QUOTE]
Developers can be server owners. I did not say they couldn't be, nor did any of my arguments imply that. I don't know which arse you're pulling that out of, but it's not mine. I'm saying it's an overkill solution that benefits only those who are too incompetent to apply the strategy in their own script. Let me take you through my thinking:
It would be bad for addon authors (I count gamemodes as addons in this discussion) because of conflicts: one addon wants it slow, the other wants it fast. It was argued that addons should not be able to set the convar (by [url=https://facepunch.com/showthread.php?t=1497739&p=49751678&viewfull=1#post49751678]you[/url]), which would limit its use to server owners.
Servers would have to know which addons use the hook and how expensive they are in using it to even be able to think of a sensible value for that convar. As such, server owners who don't know Lua cannot even work with the convar.
What is left is server owners who know Lua and are both willing and able to investigate the addons they install to figure out a valid value for that convar. Then you have the next variable: some addons have competent developers and have applied a solution locally. Other addons just aren't expensive (e.g. team based voice chat). The ConVar would thus only even have an effect on those addons which have an expensive algorithm inside the hook.
So, the "PlayerCanHearPlayersVoice tick rate convar" applies to people who are both developer AND server owner, who are competent enough to identify slow algorithms in the very few addons that may have them, but [I]not[/I] competent enough to apply a proper, local solution, or even to understand how much of an overkill the convar is.
Related to the PlayerCanHearPlayersVoice stuff I opened an issue/request that I think would solve some of the other issues with the voice system. Not sure how optimistic I'm being though.
[url]https://github.com/Facepunch/garrysmod-requests/issues/647[/url]
[QUOTE=FPtje;49752056]Also, if you're talking about the 0.5 second timer: that timer affects [B]my[/B] code and [B]my[/B] code only. If you want to put the entire PlayerCanHearPlayersVoice on 0.5 seconds, then functional wise you're doing the [I]exact same thing[/I], with the big difference that you affect [B]all[/B] code instead of just your own.[/QUOTE]
How does affect your code only? You're not the only one who has to do work arounds like that and yes it absolutely disgusting the way you do that. The way the voice system in gmod needs to be fixed whether it how Willox describes fixing it or a complete overhaul like mcd suggested.
[QUOTE=StonedPenguin;49753685]How does affect your code only? You're not the only one who has to do work arounds like that and yes it absolutely disgusting the way you do that. The way the voice system in gmod needs to be fixed whether it how Willox describes fixing it or a complete overhaul like mcd suggested.[/QUOTE]
How does my timer affect my code only? The timer holds a local function. That local function merely calculates distances and stores that in a DrpCanHear table on every player. DarkRP is the only addon to use the value DrpCanHear. Considering the "Drp" prefix, that's very reasonable to assume.
I could have also gone with storing everything in a local table, but that would require me to deal with player disconnects and the like. I couldn't be bothered, and it honestly doesn't make much of a difference.
The standards by which you call it disgusting can be disregarded until they are defined and justified. Until then, I maintain that the solution is a good one because:
- the update rate of the data is under my control
- it is efficient as it doesn't calculate things needlessly often
- it doesn't affect global shit (like how often the hook is called).
- other addons see no effect of this design choice (unless they fuck around and start using the same var and timer names, which can also be fixed)
I mean fuck, I could have done it a million other ways. I could have done a simple time check in the hook and return a cached value if the hook was called too often for my liking. It would get me to practically the same result. Would that be as disgusting to you?
What strikes me most is that you call my "[I]update every x seconds[/I]" timer disgusting exactly one page after requesting an "[I]update everything voice related every x seconds[/I]" global convar.
Also, MCD and willox seem to have good ideas. I agree with that part of your post.
If PlayerCanHearPlayersVoice continues to work the way that it does, then a global setting to control how fast the hook runs is probably a good idea, compared to each and every addon having to have their own sort of localized workaround.
At the end of the day, it should 100% be up to the server owner whether they want to sacrifice performance for voicechat precision or vice versa, and be able to take into account things that you just can't do from your perspective of developing DarkRP for [I]everybody[/I].
Examples. A server that's designed for lower playercounts. Owner could understandably increase voicechat precision because the performance loss at low player counts is more negligible. Or, for servers that hit 115 players daily to go with something more extreme like 1 full calculation per second because they can't afford that lost performance. Your code isn't capable of a dynamic like that because you simply don't know the circumstances that the server is running under. Fix: a convar! And if they manage to fuck it up, it's not your responsibility to fix it for them in the least. Let them be retarded.
Also, the code you've written for DarkRP to handle PlayerCanHearPlayersVoice is fugly as hell. D3's contribution to Drakehawke a few years ago is probably lightyears faster than what you have here. You are splitting the workload unevenly for one, and adding even more overhead while you do it by creating #players timers. What the hell is this? Players don't connect at even intervals so with these lopsided timers you've gotta know that you probably make the server FPS jitter even worse with this setup than if you had the entire calculation running all at once. Fix that shit man.
FPtje's right on this one. While adding a convar would offer a solution to users, it's very likely that addons with different requirements would conflict.
Creating a timer can achieve the same result, and it's much less likely to conflict with other addons.
As for the definition of disgusting code: just because someone's code achieves a solution in a roundabout manner or using unorthodox methods does not make that particular solution inferior to any other. What matters is efficiency and stability, both of which are afforded by his algorithm.
If server owners want to modify this setting, then individual developers can create convars to modify their timers, that way there's still no conflict.
Christ you guys are passionate about your voice chat.
That said I wouldn't mind the ability to control how often PlayerCanHearPlayersVoice gets called but then again I'm not the person trying to run costly operations in a hook where it [I]probably[/I] shouldn't be getting called anyways.
My pov is I run a server where while voice is a nice thing to have, I don't need the level of accuracy that it provides so to have some improvement in performance would be nice. However if the cost is negligible in its current state and is only made worse by adding costly code then that is arguably not the fault of Source.
[QUOTE=Willox;49745928]words[/QUOTE]
Will mcore see some love anytime soon? The test command works fairly well and helps performance a bunch (for me at least)
[QUOTE=kpjVideo;49755048]Will mcore see some love anytime soon? The test command works fairly well and helps performance a bunch (for me at least)[/QUOTE]
It seems to crash on Mac from what my friend told me. Also, I got some weird tearing on Windows when I was using my GT9600
So how about a new subject to banter about? Can we have FastDL support for gmas? It'd make content management much easier and faster for those of us who don't use workshop.
[QUOTE=code_gs;49755199]It seems to crash on Mac from what my friend told me. Also, I got some weird tearing on Windows when I was using my GT9600[/QUOTE]
Yeah, Only issues I've seen (on a GTX980) are issues rendering car colours and some menus flickering in some circumstances.
[QUOTE=StonedPenguin;49755230]So how about a new subject to banter about? Can we have FastDL support for gmas? It'd make content management much easier and faster for those of us who don't use workshop.[/QUOTE]
Why would you fast dl .GMA files? You wouldn't be able to update them once they are downloaded. I don't see why you can't use resource.AddWorkshop()
[QUOTE=AJ10017;49756398]Why would you fast dl .GMA files? You wouldn't be able to update them once they are downloaded. I don't see why you can't use resource.AddWorkshop()[/QUOTE]
Good point regarding updating, but mainly GMA's are used for models/materials instead of lua that'd need frequent updates. Plus workshop sucks.
[QUOTE=AJ10017;49756398]Why would you fast dl .GMA files? You wouldn't be able to update them once they are downloaded. I don't see why you can't use resource.AddWorkshop()[/QUOTE]
It's a lot easier especially when you have a lot of small files that need updating.
GMA files would be great for things like model packs - a single http request instead of hundreds of requests, which is where one of the big speed bumps in fastdl exists.
You also get to use, iirc, lzma instead of bzip2, which comes with slightly ( <5% at max settings, varies based on content and dictionary ) better compression and better performance than bzip2 when decompressing.
Overall, it'd make life easier for hosts too - they don't have to extract each and every addon that they want to put on fastdl to avoid the workshop shitting the bed when someone joins.
It's not something that can be fixed on the client end, but even just searching the workshop I sometimes have to refresh the page three or four times to get my search to return results - it will just crap out and return no results, when the last page told me I had at least a few more pages of stuff.
[QUOTE=StonedPenguin;49756543]It's a lot easier especially when you have a lot of small files that need updating.[/QUOTE]
you cant update files once they are downloaded through fastdl. the way source works the client ignores downloading files if they already have the file, this wouldnt be the case if source compared the checksums to check for mismatches, but sadly it isnt that way. if you need to update files constantly then you currently [i]have[/i] to use workshop to host your files, as clients will always download the newest version, even if they already have an outdated version.
can we possibly get a hook that is called every so often even when there are no players on the server?
[QUOTE=AJ10017;49759743]can we possibly get a hook that is called every so often even when there are no players on the server?[/QUOTE]
What for? Willox added this a week ago.
[quote]
• Added sv_hibernate_think & sv_hibernate_drop_bots ConVars
[/quote]
[QUOTE=Jvs;49759753]What for? Willox added this a week ago.[/QUOTE]
oh shit, didnt see that. thanks!
[QUOTE=AJ10017;49756398]Why would you fast dl .GMA files? You wouldn't be able to update them once they are downloaded. I don't see why you can't use resource.AddWorkshop()[/QUOTE]
In case workshop goes offline I imagine. It does that a lot.
[QUOTE=Giraffen93;49751750]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]
i've made some more "debugging" on this, and yeah every time you leave the pvs all the submaterials are reset, even if they're set from the server
only applies to players
[editline]ye[/editline]
and it also breaks/removes at least dynamic materials when setting submaterials on another id
[vid]https://my.mixtape.moe/bapswx.webm[/vid]
[editline]ye[/editline]
and oh yeah of course, ply:GetSubMaterial() doesn't return a value for those that don't work
Can [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/NextBot/BecomeRagdoll]NextBot:BecomeRagdoll[/url] please return the ragdoll created?
Is it possible to have [url=http://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/vsr]VSR[/url] support or is it an engine thing that won't happen?
[QUOTE=LUModder;49762640]Is it possible to have [url=http://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/vsr]VSR[/url] support or is it an engine thing that won't happen?[/QUOTE]
I'm pretty sure VSR is entirely up to your graphics drivers.
-snip okay im actually kinda glad gmod stays 1080p with vsr-
Sorry, you need to Log In to post a reply to this thread.
