• Next Update v6.0 - October 2016
    1,799 replies, posted
[QUOTE=kpjVideo;51957190]While we're here, could we possibly get a function to determine the length of a timer before it was ran?[/QUOTE] Timers are defined in terms of when they end. Not in terms of when they were created and how long they last. For the very specific use case [I]you[/I] have, [u]all[/u] timers would have to store that information. It's easy enough to do this on your own. Write wrapper functions around the timer creating functions that return the length. You have the information to do it.
[QUOTE=FPtje;51957964]Timers are defined in terms of when they end. Not in terms of when they were created and how long they last. For the very specific use case [I]you[/I] have, [u]all[/u] timers would have to store that information.[/quote]Not true, the interval is obviously relevant for timers that repeat more than once and is probably stored anyway for all timers. [QUOTE=FPtje;51957964]It's easy enough to do this on your own. Write wrapper functions around the timer creating functions that return the length. You have the information to do it.[/QUOTE]Yeah, this part's right. I can't even conceive a situation where this would be relevant. I mean, you're probably the one who started the timer in the first place, wouldn't you already know?
If I was insistent on using timers, I could just save the time started to a variable. If I wanted to ditch the timers (which is near always), I'd roll my own solution with a table that stores the current time, the desired time, and put that in a hook that checks for time before issuing a callback.
[QUOTE=wauterboi;51958429]If I was insistent on using timers, I could just save the time started to a variable. If I wanted to ditch the timers (which is near always), I'd roll my own solution with a table that stores the current time, the desired time, and put that in a hook that checks for time before issuing a callback.[/QUOTE] The timer module literally works by doing this. I believe it works near the Think hook, but on the engine's side. Sources: [url]http://wiki.garrysmod.com/page/Prediction[/url] [quote][b]That's stupid, it's redundant code, timers are like 1 line of code![/b] How do you think timers work internally? It's literally the same thing but with prediction support in this case, also for your information everything in source works like this.[/quote] [url]https://garry.tv/2012/10/30/optimising-gmod/[/url] [quote][b]TIMERS[/b] I then moved the timers module to the engine. The timers module is really very simple, so it was easy to move. The performance increase wasn’t massive, but I was happy because it’s made the module feel less fragile.. and any gain is a gain. This took the FPS from 135 to 137.[/quote]
[QUOTE=FPtje;51957964]Write wrapper functions around the timer creating functions that return the length. You have the information to do it.[/QUOTE] Sorry for throwing the thread off track a bit, I just wasn't really sure how data about timers were saved. (I'd assume most of that information is built into the game and not anywhere on github). I also somewhat assumed that all timers are stored in a table where the key is the identifier and those values are held inside. Anyways, The usage was to pass the timer as a variable in a function for some HUDPaint stuff (Lerping the current time/initial time and multiplying that by the length of a RoundedBox so it makes a some what of a backwards progress bar) But I guess I could always just have a separate variable for the time or attempt your approach.
C# module base wrapper plz
[QUOTE=StonedPenguin;51959893]C# module base wrapper plz[/QUOTE] Would definitely open some creative avenues up.
[QUOTE=Rocket;51960531]I believe cartman300 was working on that. [url]https://github.com/cartman300/gmsv_gsharp_win32[/url] [url]https://facepunch.com/showthread.php?t=1547198&p=51749418&viewfull=1#post51749418[/url][/QUOTE] I think his is more a proof of concept.
[QUOTE=Willox;51955773]Does anybody have requests for [url]https://github.com/Facepunch/gmod-module-base[/url]?[/QUOTE] Name all exported functions, no hidden ones. (And add explanations to the Wiki.) Maybe create a function that returns void * to an internal class/array. For example LUA->GetPointer("IVEngineServer");. (Note my original naming scheme.) Maybe create a GMOD_MODULE_THINK. I am sure people can think of way better things to add.
Is there a way that we could someone use the better voice codec (CELT) that was implemented in CSGO, TF2 and now most if not all Source Engine games, including the 2013 SDK (as of today)? It doesn't make sense to have such low quality voice chat in a game anymore. I know this was discussed before but starting today other Source games like CS:S benefit from it, and the Source SDK might have the code for it.
Hey GMod Devs, It's been quite a while since Garrymod received a new game-related patch. The most recent [B]game [/B]update was on December. Wouldn't it be better if you guys could ship updates periodically(monthly preferred) to not only provide the best experience to the players, server owners and as well as the contributors whose PR are accepted to the next update but not knowing when it's going to get shipped. The timeframe of getting the updates shipped which is currently amounted to approx. 3 months, deprives the motivation and excitement for us(the contributors) and as well as players who are promised that bugs are going to be fixed in the next gmod update, but it's certainly hitting the verge of our patience. On the plus side, if we had shorter 'cooldown' period between updates, that means quicker patches and customarily we would have shorter list of changes, wouldn't it be easier to keep track of the bugs, debug the issues in a shorter time and possibly better maintain the source codes? That said, I really appreciate and grateful for what you guys(you all!) have done for us. A 2006 game still receiving the loves it needs but don't deserve(heh) to this day. You guys effing ROCK! Please, I really hope we could see changes handling the updates that would be a true win-win situation for the devs and community owners.
What important changes have been implemented but not yet released? I forgot where that pre-release changelog site thing was.
[QUOTE=FPtje;51975036]What important changes have been implemented but not yet released? I forgot where that pre-release changelog site thing was.[/QUOTE] I believe there's only a dev branch changelog (in the OP). I'm personally looking forward to the lighting changes, 3000-range anim events being passed, and the global state bindings.
[url]http://wiki.garrysmod.com/changelist/[/url] These are all the changes that are not on the live version. I am sorry for there not being an update for so long, we do plan to push this update soon-ish. There are currently some issues with the build server for the prerelease branch, and previously we had issues with Dev branch build server which were resolved. All in all, I'd estimate next update probably hopefully next month.
[QUOTE=Robotboy655;51975149][url]http://wiki.garrysmod.com/changelist/[/url] These are all the changes that are not on the live version. I am sorry for there not being an update for so long, we do plan to push this update soon-ish. There are currently some issues with the build server for the prerelease branch, and previously we had issues with Dev branch build server which were resolved. All in all, I'd estimate next update probably hopefully next month.[/QUOTE] I'm really looking forward to that player.GetCount() EDIT: I'm serious.
[QUOTE=bobbleheadbob;51975399]I'm really looking forward to that player.GetCount()[/QUOTE] Nah. I prefer to keep my code as convoluted as possible... On the other hand the GlobalStates look like they could be fun to play around with.
[QUOTE=bobbleheadbob;51975399]I'm really looking forward to that player.GetCount() EDIT: I'm serious.[/QUOTE] Still waiting on ents.GetCount() :(
[QUOTE=code_gs;51975996]Still waiting on ents.GetCount() :([/QUOTE] plz rubat or willox [URL]https://github.com/Facepunch/garrysmod-requests/issues/867[/URL]
what about [url]https://github.com/Facepunch/garrysmod-requests/issues/738[/url]
[QUOTE=StonedPenguin;51976160]plz rubat or willox [URL]https://github.com/Facepunch/garrysmod-requests/issues/867[/URL][/QUOTE] [QUOTE=code_gs;51975996]Still waiting on ents.GetCount() :([/QUOTE] Your wait is over. [url]http://wiki.garrysmod.com/page/ents/GetCount[/url]
[QUOTE=Robotboy655;51976868]Your wait is over. [url]http://wiki.garrysmod.com/page/ents/GetCount[/url][/QUOTE] You're the man
Is ents.GetCount useful for much?
[QUOTE=Willox;51976968]Is ents.GetCount useful for much?[/QUOTE] I iterate over all entities each time a bullet penetrates for a trace filter, so for me, it's a pretty noticeable gain.
[QUOTE=code_gs;51977020]I iterate over all entities each time a bullet penetrates for a trace filter, so for me, it's a pretty noticeable gain.[/QUOTE] but how do you use it for iteration?
[QUOTE=Willox;51976968]Is ents.GetCount useful for much?[/QUOTE] Drawing operations and any logic that gets called often would benefit a fair bit. #ents.GetAll() is just needlessly expensive if all you need is the count.
[QUOTE=Willox;51977029]but how do you use it for iteration?[/QUOTE] Not sure what your question exactly means, but I do a for loop starting at ents.GetAll's last entry and move back until I find the penetrated entity and remove it. This is so the trace can find the exact exit hole of the penetration.
[QUOTE=code_gs;51977057]Not sure what your question exactly means, but I do a for loop starting at ents.GetAll's last entry and move back until I find the penetrated entity and remove it. This is so the trace can find the exact exit hole of the penetration.[/QUOTE] So you'd be better off with a request for trace filters to be able to work as whitelists?
Is anyone else having problems with ent:SetMaterial()? It's simply not working for me. Even the material STool isn't working.
[QUOTE=Willox;51977093]So you'd be better off with a request for trace filters to be able to work as whitelists?[/QUOTE] I thought it would be not feasible with the current trace system, but I'll do that. Thanks
A completely unrelated question from a noob coder, but are you going to push the "game.AddAmmoType" fix in the next update? It was requested a year ago, and it still isn't in the main branch. I uploaded the fix to the workshop (I hope you don't mind) and posted the link in one of my mods because people kept asking why the weapons didn't work. It's a really simple change that will fix 90% of swep problems when you have too many of them installed.
Sorry, you need to Log In to post a reply to this thread.