• Next Update v4 - March 2016 Update is out!
    1,930 replies, posted
[QUOTE=Noi;49797586]Well, bump textures aren't reloaded, they remain checkerboarded.[/QUOTE] [QUOTE=P4sca1;49797664]Anyone else having the problem that the game crashes after reloading many models/materials with game.MountGMA?[/QUOTE] It'd be nice if anybody could work out if they're having issues reloading specific models (or specific addons) and let me know which.
[QUOTE=Mrkrabz;49794939]If I set myself to a model that I don't have and then download it with [lua] net.Receive( "testdownload", function( len, pl ) steamworks.FileInfo( 406141562, function( result ) steamworks.Download( result.fileid, true, function( name ) game.MountGMA( name ) end ) end ) end) [/lua] My model is all stretched and broken, when I type kill in console it will crash my game with no error or dump file. Download it first, then setting my model works fine. However going from an error to the player model messes up. edit: [URL="https://dl.dropboxusercontent.com/u/4331988/ShareX/2016/02/hl2_160222_crash_2016_2_23T1_20_5C0.mdmp"]dump file[/URL][/QUOTE] The same is happening with weapons that already spawned. They start to look really weird. and get stretched etc. Respawning the weapon however fixes the problem. [editline]23rd February 2016[/editline] [QUOTE=Willox;49797667]It'd be nice if anybody could work out if they're having issues reloading specific models (or specific addons) and let me know which.[/QUOTE] I tested it with a playermodel pack containing around 80 models. (materials are splitted to other addons of course). Do you need the link?
[QUOTE=P4sca1;49797671]The same is happening with weapons that already spawned. They start to look really weird. and get stretched etc. Respawning the weapon however fixes the problem. [editline]23rd February 2016[/editline] I tested it with a playermodel pack containing around 80 models. (materials are splitted to other addons of course). Do you need the link?[/QUOTE] Looks like I'll have to look in to viewmodels and playermodels, thanks.
Since this Garry's Mod update the server had random chuggy spikes, delays, fps drops and some mad lags. Im the only one experiencing this? Made a admin of mine record for me: [video=youtube;X1hAL9blPnQ]https://www.youtube.com/watch?v=X1hAL9blPnQ&feature=youtu.be[/video] Tried updating the server, restarting twice and still nothing.
Any issues related to SetParent and entities being caught by the crazy physics crasher should be resolved in the dev branch. The physics object follows the entity around now rather than just falling out of the map. If you don't want to update, just don't call Spawn() (or any other function that create physics objects) after SetParent(). [QUOTE=Rustic77;49797915]Since this Garry's Mod update the server had random chuggy spikes, delays, fps drops and some mad lags. Im the only one experiencing this? Made a admin of mine record for me: [video=youtube;X1hAL9blPnQ]https://www.youtube.com/watch?v=X1hAL9blPnQ&feature=youtu.be[/video] Tried updating the server, restarting twice and still nothing.[/QUOTE] Can you try setting sv_parallel_sendsnapshot to 1? It was changed in the last update as it was a common cause of servers crashing (and TF2 has that same change).
[QUOTE=Willox;49798097]Any issues related to SetParent and entities being caught by the crazy physics crasher should be resolved in the dev branch. The physics object follows the entity around now rather than just falling out of the map. If you don't want to update, just don't call Spawn() (or any other function that create physics objects) after SetParent(). Can you try setting sv_parallel_sendsnapshot to 1? It was changed in the last update as it was a common cause of servers crashing (and TF2 has that same change).[/QUOTE] Does this mean that parented entities will now be solid if you call spawn on them or just make the physics object follow with no collisions?
[QUOTE=highvoltage;49798113]Does this mean that parented entities will now be solid if you call spawn on them or just make the physics object follow with no collisions?[/QUOTE] No, the collision is disabled until they are unparented. It does mean that the entities won't fly off when you unparent them though.
[QUOTE=Willox;49798097] Can you try setting sv_parallel_sendsnapshot to 1? It was changed in the last update as it was a common cause of servers crashing (and TF2 has that same change).[/QUOTE] I tried putting it in the server console - nothing changed.
[QUOTE=Rustic77;49798126]I tried putting it in the server console - nothing changed.[/QUOTE] Can you send me your config? Remove the secret stuff of course.
[QUOTE=syl0r;49796935]I don't see how that point is even valid in most cases. I mean sure, some bugs are unfortunately inevitable, but let's face it, many (if not most) of the bugs in the updates occur because the developers didn't think about the implications of what their changes are actually going to affect. As an example we have the changed behaviour of TEXT_ALIGN_BOTTOM and TEXT_ALIGN_TOP: Not only is this change not mentioned in the [URL="http://www.garrysmod.com/2016/02/22/february-2016-update-2/"]changelog[/URL], it also completely breaks the behaviour of scripts that relied on the (admittedly wrong) previous behaviour. When making this change it must've been quite obvious that, even though the enum was wrong, people were definitely relying on exactly that faulty behaviour, so why would you just change it without even giving the slightest hint? Why wasn't there at least a notice to developers that the this is gonna be changed [U][B][U]before[/U][/B][/U] the update happened, so they can adapt their code. (A better alternative would've been to create a new enum like ALIGN_ and deprecate the old one) I just think that especially in a game such as Garry's Mod, with many relatively old, yet really impressive gamemodes, backwards compatibility should be one of the top priorities, but unfortunately it seems like my view is not shared by the devs. And to counter your argument, we actually did test on the devbranch but we only tested things that are likely to break in the update, which means mostly things that were mentioned in the changelog as well as things that usually tend to break, oh and this is also not the first time something like that has happened.[/QUOTE] The TEXT_ALIGN thing was an issue that should of been brought up and fixed long ago the first time someone noticed that they had to use BOTTOM in place of TOP. Now I will agree some more notice on it would be nice but I'm sure whoever changed it just presumed no-one was using the ENUMs for BOTTOM in place of TOP instead of just using the numbers. As for the backwards compatibility issue I'd say its still doing very well considering we haven't had a major API update since ... gmod 11? I forgot how garry was numbering the releases past gmod 10 when it moved to steam but whatever update came with the big 'why your shit is broken' checklist. The dev branch is there for you to test on, the fp devs obviously can't check your gamemode for you. Doing light testing and then complaining about issues isn't the devs fault. Sandbox games with an external API will always have these issues, there's just way too much to support. Every time Minecraft updates I'm willing to bet the Forge Mod Loader devs moan and groan but they still fix it. And the people that use FML moan and groan because the FML API changed in a few ways usually. Bitching doesn't solve the issues, if you maintain a server or gamemode FUCKING CHECK YOUR CODE ON THE DEV BRANCH EVERY DAY AHHHHHHHHH. I've had no issues with the past 3 updates because I dev on the dev branch every day and playtest it. If I find a issue I report it, all regression issues I've pointed out get fixed quickly. (Feature requests on the other hand :V). But I do think a proper timed release system would benefit. Something like once a week updates where the last 3 days before update day can't have any new changes implemented. Only bugfixes for existing changes. Maybe create a mailing list that sends out changelogs and lets people know of known issues and fixes. I'm not going to disagree that there are some problems with the current way fp devs do updates but the OH GOD ITS BROKE problems aren't entirely RBB/Kilburn/Willox's faults. The Lua developers need to maintain and check their code.
[QUOTE=Willox;49798140]Can you send me your config? Remove the secret stuff of course.[/QUOTE] Done.
Let's get updates every 2-3 months instead, so enough time is given to hammer out issues.
[QUOTE=mcd1992;49798142]The TEXT_ALIGN thing was an issue that should of been brought up and fixed long ago the first time someone noticed that they had to use BOTTOM in place of TOP.[/QUOTE] And I completely agree with you. It shouldn't even have been the wrong value in the first place. Unfortunately it is the case that it was wrong though and changing it now, like five or so years later, shouldn't be something you just do that lightly without mentioning it in the changelog. [QUOTE=mcd1992;49798142][...]whoever changed it just presumed no-one was using BOTTOM in place of TOP[/QUOTE] Now that is exactly the point I tried to bring up. Someone thought it wasn't going to affect anyone. And I really just want to understand how you can make that presumption. I mean it's so obvious that switching these two around is going screw up some scripts. And don't get me wrong here, it's obviously really simple to fix (3 times replace across all files) but why even break it in the first place? Why not preserve backwards compatibility? Furthermore this wasn't the only time something like this happened, it'll probably also happen again. I just want to try and make sure it happens less frequently, because problems like this are so unnecessary and preventable. [QUOTE=mcd1992;49798142]The dev branch is there for you to test on, the fp devs obviously can't check your gamemode for you[...]FUCKING CHECK YOUR CODE ON THE DEV BRANCH EVERY DAY AHHHHHHHHH.[...]The Lua developers need to maintain and check their code. [/QUOTE] Why did you just bring up the exact same argument that I responded to. Did I not explain how it is really hard to test things that aren't mentioned? Also additionally, some changes are only going to be apparent if there's many players on the server, do you expect me to get 40 players on a dev branch server every day and see if something went wrong as well as cover almost all of my code? Really? [QUOTE=mcd1992;49798142] Maybe create a mailing list that sends out changelogs and lets people know of known issues and fixes. [/QUOTE] There is a changelog, it didn't (and to this date doesn't) include the TEXT_ALIGN change, that's exactly what the problem is. [QUOTE=mcd1992;49798142] [...]Bitching doesn't solve the issues[...] [/QUOTE] I don't think I am bitching, and I hope you don't perceive my posts as such. I am merely pointing out that there are problems with the updates and I don't see any reason to just pretend as if they were always the best thing to happen. Yes the updates are good and necessary, but they could be made better if the developers thought about the implications of their changes. Especially in cases like this, if the developers just asked themselves "Is this change going to break thing?", they'd hopefully find out and not do the change.
[QUOTE=dezamb;49798225]Let's get updates every 2-3 months instead, so enough time is given to hammer out issues.[/QUOTE] How about updates go on as they have been and people follow this thread/check the dev change list to see what's gonna change [editline]23rd February 2016[/editline] [QUOTE=syl0r;49798287] Also additionally, some changes are only going to be apparent if there's many players on the server, do you expect me to get 40 players on a dev branch server every day and see if something went wrong as well as cover almost all of my code? Really?[/QUOTE] I really don't understand how people can say this and then have face to bitch at the devs for not doing this. How about we just stop updating all together and let the game rot into the ground that way nothing can ever break ever again. Now everyone can be happy.
[QUOTE=highvoltage;49798339]How about updates go on as they have been and people follow this thread/check the dev change list to see what's gonna change [editline]23rd February 2016[/editline] I really don't understand how people can say this and then have face to bitch at the devs for not doin this. How about we just stop updating all together and let the game rot into the ground that way nothing can ever break ever again. Now everyone can be happy.[/QUOTE] It would be nice to have it pop up on launch, or have the menu background be a change log on the dev branch. Pretty hassle free way to make sure everyone who uses it is up to date. I'm sure everyone here knows that following this thread can get pretty crazy at times.
I always chuckle a little bit whenever addon developers freak the fuck out when an update comes out It's your job to update your addons when new features are released If you're not comfortable with that then you have no place being an addon developer in a sandbox game with frequent updates
[QUOTE=Revenge282;49798370]It would be nice to have it pop up on launch, or have the menu background be a change log on the dev branch. Pretty hassle free way to make sure everyone who uses it is up to date. I'm sure everyone here knows that following this thread can get pretty crazy at times.[/QUOTE] A button on the main menu that shows the dev change log would be neat. And I don't necessarily mean following it word for word but skim through for when one of the devs post really, just to see what's up
[QUOTE=syl0r;49798287] I mean it's so obvious that switching these two around is going screw up some scripts. And don't get me wrong here, it's obviously really simple to fix (3 times replace across all files) but why even break it in the first place? Why not preserve backwards compatibility?[/QUOTE] They weren't switched around, they were offset by 1. Would you rather people continue to make scripts the use one of those enums as the BOTTOM one doesn't even work? [QUOTE=syl0r;49798287] Why did you just bring up the exact same argument that I responded to. Did I not explain how it is really hard to test things that aren't mentioned? [/QUOTE] I believe most of the changes were mentioned in the pre update change-log. Also they were mentioned through-out this thread as they were made. [QUOTE=syl0r;49798287] There is a changelog, it didn't (and to this date doesn't) include the TEXT_ALIGN change, that's exactly what the problem is. [/QUOTE] It probably didn't include it because the issue came about a day before the update, still should've been included, though probably easily overlooked. [QUOTE=syl0r;49798287] Yes the updates are good and necessary, but they could be made better if the developers thought about the implications of their changes. Especially in cases like this, if the developers just asked themselves "Is this change going to break thing?", they'd hopefully find out and not do the change.[/QUOTE] So we shouldn't change something to make it better if it breaks existing stuff?
FYI I just added the missing pages on the wiki for new functions since last two updates. Some of them are not documented at all because I have no idea what they do ( Like the closed/open list functions for CNavAreas )
[QUOTE=Robotboy655;49794099]Let me just whip out my telepathic hacker powers again and get that dump file from your PC to diagnose the case.[/QUOTE] ur "telepathic hacker powers" are shit if you don't know that you can log in to [url]https://partner.steamgames.com/errors/viewbuild/4000/0/[/url] and grab minidumps for the most common crashes
game.mountgma doesn't really handle item updates, does it? how would that work, having to check updated date every time, and even then, does it replace the file downloaded?
Is TEXT_ALIGN_TOP broke for anybody else?
[QUOTE=Jordanlol;49801480]Is TEXT_ALIGN_TOP broke for anybody else?[/QUOTE] use TEXT_ALIGN_BOTTOM also read the last two pages of the thread
If you're still bitching about TEXT_ALIGN_TOP, here's your backwards-compatible fix: [lua] TEXT_ALIGN_TOP = 5 TEXT_ALIGN_BOTTOM = 6 [/lua] Put it in at the top of a clientside file and enjoy your backwards compatibility. On a side note: You'll lose forward compatibility. But that's not important right? New content for GMod isn't made daily right?
[QUOTE=highvoltage;49798339] I really don't understand how people can say this and then have face to bitch at the devs for not doing this. How about we just stop updating all together and let the game rot into the ground that way nothing can ever break ever again. Now everyone can be happy.[/QUOTE] I never implied we should stop updating, I even mentioned in my post that updates are important and great, so please don't put these words in my mouth. Furthermore you clearly don't get the problem here. I am not talking about bugs that the developers really couldn't have known about, yeah that happens and is to some extent unavoidable I guess. I am talking about bugs that [I][U][B]must[/B][/U][/I] already be apparent to the developers in the concept phase of the new update [U][B]and[/B][/U] are easy to [U][B]prevent[/B][/U]. [QUOTE=bobbleheadbob;49802896]If you're still bitching about TEXT_ALIGN_TOP, here's your backwards-compatible fix: [...] Put it in at the top of a clientside file and enjoy your backwards compatibility. On a side note: You'll lose forward compatibility. But that's not important right? New content for GMod isn't made daily right?[/QUOTE] As you have admitted yourself your fix is completely useless, so why even post it? The backwards compatible (and forwards compatible) fix would've been for the developers to deprecate the old enum (while keeping its wrong behaviour) and creating a new one Why are you even defending this change when there would've been a perfectly fine way to fix it? But of course everyone's just insisting that this change was great and that I (and everyone else) should just deal with it. Let's all delude ourselves into believing all updates are always perfect and they can't be improved at all. And if developers make changes that break existing code, it was obviously my fault to rely on the wrong behaviour in the first place.
I think it should have been documented better, but I don't really see a whole lot of work going behind fixing it; just a simple Replace All function, really. Things break between updates -- if backwards compatibility is constantly maintained, then there would be a ton of bloat and useless copies. You have to break a few eggshells to make an omelet
[QUOTE=syl0r;49803293]I never implied we should stop updating, I even mentioned in my post that updates are important and great, so please don't put these words in my mouth.[/QUOTE] That was sarcasm, and meant to be a general comment to people that just say that updates break everything. I didn't mean to accuse you of hating updates, sorry. [QUOTE=syl0r;49803293]Furthermore you clearly don't get the problem here. I am not talking about bugs that the developers really couldn't have known about, yeah that happens and is to some extent unavoidable I guess. I am talking about bugs that [I][U][B]must[/B][/U][/I] already be apparent to the developers in the concept phase of the new update [U][B]and[/B][/U] are easy to [U][B]prevent[/B][/U].[/QUOTE] But how far should the developers test? How was willox supposed to know that parenting objects makes the physics fall through the earth? Or that the airboat spawns at a messed up z position? How could he test every different combination of game, workshop, gamemode, legacy addon, and other game mounting setups people have?
[QUOTE=highvoltage;49803386] But how far should the developers test? How was willox supposed to know that parenting objects makes the physics fall through the earth? Or that the airboat spawns at a messed up z position? How could he test every different combination of game, workshop, gamemode, legacy addon, and other game mounting setups people have?[/QUOTE] Sadly it seems that either people here can't (or are unwilling to) read or I unable to express myself properly. [QUOTE=syl0r;49798287] I am not talking about bugs that the developers really couldn't have known about, yeah that happens and is to some extent unavoidable I guess.[...] I am talking about bugs that must [U][B]ALREADY [/B][/U]be [U][B]APPARENT [/B][/U] to the developers in the [U][B]CONCEPT PHASE[/B][/U] of the new update and are easy to prevent. [/QUOTE] [QUOTE=code_gs;49803378][...]just a simple Replace All function, really. [/QUOTE] [QUOTE=syl0r;49798287] And don't get me wrong here, it's obviously really simple to fix (3 times replace across all files) but why even break it in the first place? Why not preserve backwards compatibility? [/QUOTE] My point is, there is no reason not to preserve backwards compatibility. Why break scripts (most of which won't ever get fixed) for no good reason? Sure of course this is going to marginally "blow" up the codebase (5 loc) but even then there's ways to deal with issues such as maintainability of those 5 lines. Unfortunately it seems like my arguments are just being ignored so I don't see much point to continue spamming this thread.
[QUOTE=syl0r;49803293] As you have admitted yourself your fix is completely useless, so why even post it? The backwards compatible (and forwards compatible) fix would've been for the developers to deprecate the old enum (while keeping its wrong behaviour) and creating a new one Why are you even defending this change when there would've been a perfectly fine way to fix it? [/QUOTE] Looking back, the perfect fix would have been to change the draw and markup enums to match the global ones, not the other way around. But what's done is done. Make your point and move on. At this point you're just complaining.
[QUOTE=Noi;49803572]This is what I did: 1) Spawned a vehicle TDMCars BMW without any content mounted. 2) Mounted TDMCars BMW. Some textures were missing, because I didn't mount base pack, but vehicle model appeared. 3) Mounted TDMCars Base Pack. Missing textures remained in place. I ran mat_reloadallmaterials and it sorta worked: bump textures on vehicle glass were missing.[/QUOTE] Yeah it's looking like some specific complicated types of models are having problems too, it's only supposed to reload models (and the materials those loaded models have at the time) - not materials. Maybe I didn't make it clear enough on the Wiki article. You'll notice from mat_reloadallmaterials how slow it can be, and it can be just as slow for single materials depending on what has changed.
Sorry, you need to Log In to post a reply to this thread.