• Next Update v2
    3,675 replies, posted
Was there a reason to give a type specific NWvar a type that is different to what it expects pre-update?
The last 2 times my server has crashed, the usual "[B]Steam_: Saved dump file to 'garrysmod\srcds_blah.mdmp[/B]'" message is printed but SRCDS never actually closes like it did pre-update. It just sits there and doesn't get restarted by serverdoc unless I manually close it. I don't recall this ever occurring while my server was on the dev branch over the last half a year. Is this occurring for anyone else? I've kept up with all of the thread replies and don't think I've seen anyone else say anything about it, but I may have missed them.
[QUOTE=NiandraLades;47286959]Is anyone else having this, or could indicate what it means? [img]http://i.imgur.com/Oq2oOSn.png[/img][/QUOTE] update: i was trying to update my server while it was still running and turning it off fixed it
So many random crashes now. Did the GMod devs even test this update on anything other than Sandbox?
I'm running an ancient DarkRP version, with modified wire that must be 6months + old, tons of random addons hacked together from pre-gmod13 and yet somehow everything works perfectly with no server crashes, on linux Debian. Shockingly surprised considering I didn't test the dev branch at all, been way to busy recently. However... Few folks on Mac OS X are crashing on join, but no info on that.
hi everyone, I run a custom gamemode and since the update I get random server crashes and it decides to reboot itself, some errors are: [ERROR] lua/includes/modules/gamemode.lua:86: attempt to index upvalue 'hook' (a nil value) (not sure how to fix this since I have not even touched anything in here? probably a reference?) [ERROR] gamemodes/ourgamemode/gamemode/modules/pocket/cl_inventory.lua:123: bad argument #1 to 'pairs' (table expected, got nil) [ERROR] gamemodes/ourgamemode/gamemode/modules/base/sv_cdealer.lua:282: bad argument #2 to 'SetNWString' (string expected, got nil) [ERROR] gamemodes/ourgamemode/gamemode/modules/f4/cl_menu.lua:1659: bad argument #1 to 'GetBonePosition' (number expected, got no value) [ERROR] gamemodes/ourgamemode/gamemode/modules/base/sv_cdealer.lua:240: Tried to use a NULL entity! [ERROR] gamemodes/ourgamemode/gamemode/modules/base/sv_profilename.lua:126: bad argument #2 to 'SetNWString' (string expected, got nil) [ERROR] gamemodes/ourgamemode/entities/weapons/arrest_stick.lua:133: attempt to call method 'Team' (a nil value) [ERROR] addons/dlogs/luadeaglelogs/hooks/playerdeath.lua:29: attempt to call method 'Team' (a nil value) I think the main thing that's breaking it all is: bad argument #2 to 'SetNWString' (string expected, got nil) - but all this was working before the updates, could someone explain why on earth I am getting nil values yet before the update it was working. I am using basic things like ply:SetNWString is there anything wrong with using that? Has it been removed or something?
SetNWString now has to actually take a string. If you try and pass nil to it not an actual string it just errors. Also that "custom gamemode" oddly looks like DarkRP with a copy a deaglelogs installed. [editline]10th March 2015[/editline] Also for the hook thing update your anticheat.
ok Thanks meharryp :downs: yes its not fully custom since we love deaglelogs but even that has broken, thanks for the help though
Renamed DarkRP with scripts != Custom gamemode.
[QUOTE=Author.;47293379]Renamed DarkRP with scripts != Custom gamemode.[/QUOTE] The best renamed DarkRP servers are the deathmatch ones. They always forget to turn sv_allowcslua to 0, so wallhacks for all!
[QUOTE=sixteen.io;47293251]So many random crashes now. Did the GMod devs even test this update on anything other than Sandbox?[/QUOTE] Uh, perhaps it isn't their job to test on anything other than Sandbox and TTT? If it doesn't work on anything other than Sandbox or TTT, then it's the fault of the gamemode's developer. And developers had plenty of time to fix their shit for the update because the dev branch was updated frequently.
[QUOTE=StonedPenguin;47291075]I set 3 different NWVars per player, I've had an average of 70 players through out the day and not a crash one.[/QUOTE] Unfortunately I cannot say the same. I run a gamemode that is not mine on one of my server (melonbomber). The setup of the nwbools is terrible The amount of nwbools,terrible. the execution of the nwbools, also terrible. The internals of it are terrible all around, however the gameplay is fun. It is specifically SetNWBool that is crashing servers. It's not an all the time thing though, it seems completely random. I had to re-write the NWBool function on both server and client to get my servers to stop crashing.
Clients however do seem to be crashing a lot, with no helpful error messages to give me :(
GetMaterial[B]s[/B]() seems to return the original set of materials and is unaffected by changes made using SetSubMaterial(), I'm not sure if its bug or intended behaviour? I didn't get a chance to test it before it went live.
[QUOTE=Mista Tea;47291979]I realize this is a small problem in comparison to others, but is this going to be a long-term issue? There is no corresponding label:GetFGColor() function, so now we have to either call label:SetTextColor() along with label:SetFGColor() to be able to use label:GetTextColor(), or we use label:GetColor() which doesn't even return a new Color object (it returns the old table method {r=,g=,b=,a=}). Also, does this only affect DLabels? Things like DTextEntrys still seem to have a functioning SetTextColor() function. If it's only DLabels, why not define label:SetTextColor() to internally call label:SetFGColor() and set m_colText to the passed param, that way label:GetTextColor() also works and we don't have a bunch of malfunctioning labels everywhere. [URL]https://github.com/garrynewman/garrysmod/blob/master/garrysmod/lua/vgui/dlabel.lua[/URL] [code] AccessorFunc( PANEL, "m_colText", "TextColor" ) -- no change here -- ... function PANEL:SetTextColor( color ) self.m_colText = color self:SetFGColor( color ) end[/code] It's slightly hacky but it's better than just dropping label:SetTextColor()'s original functionality. The only other thing we can really do is add a call to label:ApplySchemeSettings() every time we change the text color.[/QUOTE] The reason I didn't do something like this is because there are TextStyleColor and TextColor. What's the difference? Why TextStyleColor exists? At the time I made those changes I didn't bother looking into it.
[QUOTE=NightmareX91;47293532] [QUOTE=sixteen.io;47293251]So many random [U]crashes[/U] now. Did the GMod devs even test this update on anything other than Sandbox?[/QUOTE] Uh, perhaps it [U]isn't their job[/U] to test on anything other than Sandbox and TTT? If it doesn't work on anything other than Sandbox or TTT, then it's the fault of the gamemode's developer. And developers had plenty of time to fix their shit for the update because the dev branch was updated frequently.[/QUOTE] Incompatibilities are developers' responsibility. Crashes are not. Bad use of functions should lead to properly descriptive errors, not game crashes. That is assuming these functions are misused. For all I know there might be a bug in some functions where they crash the game on some input that would otherwise be valid. The GMod devs are responsible for a stable API. The API isn't stable if it crashes the game, regardless of whether it's misused.
[QUOTE=Ott;47292389][URL="http://facepunch.com/showthread.php?t=1455059"]They're evolving[/URL][/QUOTE] Okay new format: 'last update, [B]this isn't GMod YYYY [/B][B]you dickheads[/B]: YYYY.MM.DD'
[QUOTE=MattJeanes;47294101]YYYY.MM.DD[/QUOTE] You [URL="https://xkcd.com/1179/"]almost got it right[/URL]. :eng101: [editline]10th March 2015[/editline] But I agree YYYY.MM.DD would be best for a version number.
[QUOTE=NightmareX91;47293532]Uh, perhaps it isn't their job to test on anything other than Sandbox and TTT? If it doesn't work on anything other than Sandbox or TTT, then it's the fault of the gamemode's developer. And developers had plenty of time to fix their shit for the update because the dev branch was updated frequently.[/QUOTE] No because there are crashes and so on that are occurring when using non-obsolete methods, which is not the fault of the addon developers. There are many gamemodes that bring new players to GMod, such as Dark RP and HL2 RP. If the developers care about content creation that drives players to their product, then they should make sure their updates don't cause arbitrary crashes.
Every SetNW* should be able to accept nil, how else are you going to remove a var?
[QUOTE=sixteen.io;47294343]No because there are crashes and so on that are occurring when using non-obsolete methods, which is not the fault of the addon developers. There are many gamemodes that bring new players to GMod, such as Dark RP and HL2 RP. If the developers care about content creation that drives players to their product, then they should make sure their updates don't cause arbitrary crashes.[/QUOTE] Which, for the 200th time, is why this update was in testing for so long. If developers can't be bothered to update their stuff as well then GMod will never move forwards and we'll always be stuck with using laggy, unoptimized functions because whenever an update is pushed some developers can't be bothered to change to the new functions, making people complain about lag, causing reports get get posted here, and the blame being placed on the current devs. It's an endless cycle and until people realize that addon creators need to fix their stuff and stop blaming the devs for everything.
[QUOTE=meharryp;47294380]Which, for the 200th time, is why this update was in testing for so long. If developers can't be bothered to update their stuff as well then GMod will never move forwards and we'll always be stuck with using laggy, unoptimized functions because whenever an update is pushed some developers can't be bothered to change to the new functions, making people complain about lag, causing reports get get posted here, and the blame being placed on the current devs. It's an endless cycle and until people realize that addon creators need to fix their stuff and stop blaming the devs for everything.[/QUOTE] That's not the issue, learn to read or comprehend. While the people drama bitching can go screw themselves, the end result is functions used incorrectly should error not crash without logs etc.
[QUOTE=Ott;47294374]Every SetNW* should be able to accept nil, how else are you going to remove a var?[/QUOTE] "", 0, NULL, vector_origin, angle_zero, the list goes on. Make your own "nil" var. [editline]10th March 2015[/editline] I think Kilburn is implementing this into the next version though.
[QUOTE=Joeyl10;47294709]"", 0, NULL, vector_origin, angle_zero, the list goes on. Make your own "nil" var. [editline]10th March 2015[/editline] I think Kilburn is implementing this into the next version though.[/QUOTE] How do you distinguish between it actually being that value, and it being "null". There is no defending this, it's bad practice, you should be able to nullify the var.
Yeah now I have to change my checks from the value being nil to a nil replacement. Its kinda silly
[QUOTE=Joeyl10;47294709]"", 0, NULL, vector_origin, angle_zero, the list goes on. Make your own "nil" var.[/QUOTE] The Get functions have an explicit fallback argument. In some situations you may need to rely on it, for example, with [url=http://wiki.garrysmod.com/page/Entity/GetNWAngle]GetNWAngle[/url] I might want to do:[lua]ent:GetNWAngle( "my_key", Angle(90, 0, 0) )[/lua]In this case, having no value (nil) and having angle_zero has very different meanings.
My DarkRP server is still crashing, I have updated ULX, DLOGS, DarkRP and !cake anti cheat. There are no errors on console and the only thing I have is a dump file with error EXCEPTION_ACCESS_VIOLATION_READ [url]http://dumps.metastruct.uk.to/dumper.py?dump=srcds_1678491_crash_2015_3_10T15_35_17C0.mdmp&key=pGM_AlKNmBVZZv3uDzdz7YMjyDdNE-LEHY2YnwxUFc-hUSW_Bhy2VdiiGslnlAv3U-OW4hKtbRjhrF_a0Cd-ihOhy0Q1CwVjn38itsy_hB67mAmorthj1SPtXmCebWtQwbne3_j3KOCsB_j1Aa6eBUQ2Dnx3TW3dQZDk497OHcg=[/url] If someone could help, that would be great.
For some reason, ever since the latest gmod update, people who connect to my server, including myself, are not able to see the weapons that they are holding. Is there any reasoning behind this? Any Fix? Players are able to see the world models of the weapons perfectly fine though. This is EVERY weapon, including the gravity gun and physics gun. Gamemode = DarkRP.
[QUOTE=meharryp;47293040]Was there a reason to give a type specific NWvar a type that is different to what it expects pre-update?[/QUOTE] Because it's bad programming practice to be doing something like this Entity:SetNWEntity("test","obviously not an entity, so why should this work") [editline]10th March 2015[/editline] [QUOTE=Joeyl10;47294709]"", 0, NULL, vector_origin, angle_zero, the list goes on. Make your own "nil" var. [editline]10th March 2015[/editline] I think Kilburn is implementing this into the next version though.[/QUOTE] None of those will flag the garbage collector for cleaning next gc cycle though, only variables that have been changed to nil will be flagged for cleaning.
[QUOTE=ImDesire;47295289]For some reason, ever since the latest gmod update, people who connect to my server, including myself, are not able to see the weapons that they are holding. Is there any reasoning behind this? Any Fix? Players are able to see the world models of the weapons perfectly fine though. This is EVERY weapon, including the gravity gun and physics gun. Gamemode = DarkRP.[/QUOTE] I can confirm this happening on our server as well. Other problems are bodygroups and skins of models not working correctly (showing the wrong skin/bodygroups)
Sorry, you need to Log In to post a reply to this thread.