[QUOTE=garry;24104945]Ok, post your niggles and I will try to fix them in the next update.
By niggles I mean tiny things that I can fix easily - not entire system overhauls that will take longer than an hour.[/QUOTE]
[release][b]Thread Archives[/b]
[url=http://www.facepunch.com/threads/986675]Niggles V1 by [/url] [url=http://www.facepunch.com/members/1-garry]garry[/url]
[url=http://www.facepunch.com/threads/1089190]Niggles V2 by [/url] [url=http://www.facepunch.com/members/412405-Nick-Clegg]Nick Clegg[/url][/release]
So yeah, that's pretty much it for the niggles thread I suppose. I'd say my first niggle is to contact Valve and [b]get Linux vehicles fixed[/b]
Oh my god, Linux vehicles are the biggest fucking annoyance in gmod
[QUOTE=Deadman123;34504434]Oh my god, Linux vehicles are the biggest fucking annoyance in gmod[/QUOTE]
Yeah, we're heading towards 2 years of breakage now :(
Pretty sure someone has an experimental fix for it, its just buggy
[QUOTE=Deadman123;34504490]Pretty sure someone has an experimental fix for it, its just buggy[/QUOTE]
It's not safe to run a community using outdated/modified binaries that could break any day of the week though.
[QUOTE=Banana Lord.;34504513]It's not safe to run a community using outdated/modified binaries that could break any day of the week though.[/QUOTE]
true enough
Oh my next niggle (probably easier), actually verify information from the client with stools (ie. materials) to help stop them from exploiting them. It's fairly simple to fix but should really be included by default.
Half the things in linux have problems.
Yep, just bought a server.
found out linux was bad for garry's mod
fix dat shit
It's bad if you want to run sandbox. Running anything else is fine. :v:
[QUOTE=BlackAwps;34505583]It's bad if you want to run sandbox. Running anything else is fine. :v:[/QUOTE]
Anything which requires vehicles or certain NPCs generally doesn't work
Not to mention that outdated binary can cause INSANE constraint lag somehow. Making sandbox usually useless.
AzuiSleet released one in October that doesn't cause constraint lag and doesn't crash with vehicles.
[QUOTE=GranPC;34510481]AzuiSleet released one in October that doesn't cause constraint lag and doesn't crash with vehicles.[/QUOTE]
As Banana said, it's not safe to run on stuff that can break with a update. And Azui said npc_seagull still crashes
[QUOTE=GranPC;34510481]AzuiSleet released one in October that doesn't cause constraint lag and doesn't crash with vehicles.[/QUOTE]
You're telling me that Azu released a fix and explained how to fix it, yet ValVe has not yet bothered? Wow.
[QUOTE=JustSoFaded;34518140]You're telling me that Azu released a fix and explained how to fix it, yet ValVe has not yet bothered? Wow.[/QUOTE]
It was fixed, but broke again soon after.
[QUOTE=raBBish;34518335]It was fixed, but broke again soon after.[/QUOTE]
I'm not quite sure about that, with my linux server I downloaded the fixed vphysics.so and put it the the bin folder and vehicles work perfectly now.
The October one was never put on hldsupdatetool
A way to change the color and direction of light_environment via Lua without light_environment needing to be given a name in Hammer. So we can adjust the global lighting of every map with a light_environment. Maybe also functions for env_sun too.
Would be nice to tell Valve to fix things they broke with recent updates.
Taken from another thread.
[QUOTE=LemONPLaNE;34288873]There's something with this map that makes hosting a server quite frustrating.
Namely, this:
[img]http://i.imgur.com/n3g0i.png[/img][/QUOTE]
Explaination:
[QUOTE=krassell;34303844]So, this is the bug that appeared with new update from Valve. I can confirm this happens in HL2DM at very least, prolly CSS too. What it does is when the message of that sort appears, it means that func_rotating broke. It just stops rotating, no matter what you're doing. Also, this does not depend on the map, every func_rotating will eventually break(even the ones, which were made dynamically) Momentary_rot_buttons are also fucked up and work half of the time, then break beyond any repairment. Basically everything that used standard Valve rotation system is broken. Rotating doors sort of work, but more you use them, more they have chances to break just like func_rotating.[/QUOTE]
I hope this annoying thing can be fixed, as it breaks hell lot of maps.
This makes me think that Valve break some things on purpose sometimes...
[QUOTE=somescripter;34523579]A way to change the color and direction of light_environment via Lua without light_environment needing to be given a name in Hammer. So we can adjust the global lighting of every map with a light_environment. Maybe also functions for env_sun too.[/QUOTE]
Wouldn't you need to recompile the lightmap if you changed the light_environment settings? How would controlling it with lua help??
[QUOTE=DrogenViech;34524699]Wouldn't you need to recompile the lightmap if you changed the light_environment settings? How would controlling it with lua help??[/QUOTE]
As far as I know it doesn't really do anything to the baked lighting itself, it just won't get an entity index, so it's invisible from the entity system.
You can fetch the light_env entity in the hook EntityKeyValue and use it later, but for some reason it won't update the light on the map until you refresh the maps lighting. I'm guessing it behaves like this because it doesn't get told on client to update because it doesn't exist there?
[lua]
hidden_entities = {}
hook.Add("EntityKeyValue", "hidden_entities", function(ent, key, val)
ent:SetKeyValue("targetname", ent:GetClass())
ent:SetKeyValue("classname", ent:GetClass()) -- dunno if this is needed
hidden_entities[ent:GetClass()] = ent
end)
[/lua]
You could try using entspy instead, cause maybe it will update on client then. Assuming it does Garry should make it so the light_environment doesn't disappear from the entity system.
[lua]
hidden_entities.light_environment:Fire("SetPattern", "\1") -- did you also know it can go from from 1 to 128 and not just a to z (97-122)?
[/lua]
Then retry and you'll see the changes. (not sure how this behaves in sp or a listen server)
You can also spawn dynamic lights around the map to see partial changes. I remember when I was really new to lua, I used the eventscripts plugin to change the lightstyle of the map, but it had the same behavior, so I made something which spammed dynamic lights all over the map right after I changed it. It was really bad and lagged every time it changed and it didn't really work on non flatgrass ish maps
[QUOTE=CapsAdmin;34526664]As far as I know it doesn't really do anything to the baked lighting itself, it just won't get an entity index, so it's invisible from the entity system.
You can fetch the light_env entity in the hook EntityKeyValue and use it later, but for some reason it won't update the light on the map until you refresh the maps lighting. I'm guessing it behaves like this because it doesn't get told on client to update because it doesn't exist there?
[lua]
hidden_entities = {}
hook.Add("EntityKeyValue", "hidden_entities", function(ent, key, val)
ent:SetKeyValue("targetname", ent:GetClass())
ent:SetKeyValue("classname", ent:GetClass()) -- dunno if this is needed
hidden_entities[ent:GetClass()] = ent
end)
[/lua]
You could try using entspy instead, cause maybe it will update on client then. Assuming it does Garry should make it so the light_environment doesn't disappear from the entity system.
[lua]
hidden_entities.light_environment:Fire("SetPattern", "\1") -- did you also know it can go from from 1 to 128 and not just a to z (97-122)?
[/lua]
Then retry and you'll see the changes. (not sure how this behaves in sp or a listen server)
You can also spawn dynamic lights around the map to see partial changes. I remember when I was really new to lua, I used the eventscripts plugin to change the lightstyle of the map, but it had the same behavior, so I made something which spammed dynamic lights all over the map right after I changed it. It was really bad and lagged every time it changed and it didn't really work on non flatgrass ish maps[/QUOTE]
That's very useful, can it also pick up prop_static entities which seem to be "hidden" in lua too?
[QUOTE=krassell;34524127]Would be nice to tell Valve to fix things they broke with recent updates.
Taken from another thread.
Explaination:
I hope this annoying thing can be fixed, as it breaks hell lot of maps.
This makes me think that Valve break some things on purpose sometimes...[/QUOTE]
This doesn't apply as much to Garry as it does to non-licensee developers, but sometimes reverting to old code helps more than using whatever new code they've pushed into the SDK. It's very bothersome, and makes me feel like Valve now neglects their code's behavior to a much larger degree than they ever have. I've fixed every last large bug with my mod by merging bits of the older engine build into the newer one in the public SDK.
As for Garry, I would assume he has to contact Valve or fix them himself.
[QUOTE=CapsAdmin;34526664]As far as I know it doesn't really do anything to the baked lighting itself, it just won't get an entity index, so it's invisible from the entity system.
You can fetch the light_env entity in the hook EntityKeyValue and use it later, but for some reason it won't update the light on the map until you refresh the maps lighting. I'm guessing it behaves like this because it doesn't get told on client to update because it doesn't exist there?
[lua]
hidden_entities = {}
hook.Add("EntityKeyValue", "hidden_entities", function(ent, key, val)
ent:SetKeyValue("targetname", ent:GetClass())
ent:SetKeyValue("classname", ent:GetClass()) -- dunno if this is needed
hidden_entities[ent:GetClass()] = ent
end)
[/lua]
You could try using entspy instead, cause maybe it will update on client then. Assuming it does Garry should make it so the light_environment doesn't disappear from the entity system.
[lua]
hidden_entities.light_environment:Fire("SetPattern", "\1") -- did you also know it can go from from 1 to 128 and not just a to z (97-122)?
[/lua]
Then retry and you'll see the changes. (not sure how this behaves in sp or a listen server)
You can also spawn dynamic lights around the map to see partial changes. I remember when I was really new to lua, I used the eventscripts plugin to change the lightstyle of the map, but it had the same behavior, so I made something which spammed dynamic lights all over the map right after I changed it. It was really bad and lagged every time it changed and it didn't really work on non flatgrass ish maps[/QUOTE]
From my experience if the light_environment in the map is given a name in Hammer, it actually does update the lightmaps :)
[QUOTE=somescripter;34535078]From my experience if the light_environment in the map is given a name in Hammer, it actually does update the lightmaps :)[/QUOTE]
I just compared two bsps where one of them was compiled with just an added targetname to the light_environment and you're right, it bumps the size up a little over 100kb
But what can garry do about this then?
It's been pointed out before that it would be neat with pre and post world draw hooks where we could use the render functions to change how world should draw. I'd rather want something like that.
[QUOTE=amcfaggot;34527137]This doesn't apply as much to Garry as it does to non-licensee developers, but sometimes reverting to old code helps more than using whatever new code they've pushed into the SDK. It's very bothersome, and makes me feel like Valve now neglects their code's behavior to a much larger degree than they ever have. I've fixed every last large bug with my mod by merging bits of the older engine build into the newer one in the public SDK.
As for Garry, I would assume he has to contact Valve or fix them himself.[/QUOTE]
Well, talking about old and new code, it looks like that they're breaking old games on purpose. I can list things that Valve 'accidently' broke within HL2DM since it's release.
I have a friend whos' hobby is pimping the shit out of HL2DM, and he spends most of his time submerged in Valve's old and new code. He recently found out that Valve made Source's limits even tighter with recent updates by reducing MAX_DISP_LIGHTMAP_DIM_WITHOUT_BORDER (125 in OB vs 128 in Beta/old HL2), MAX_DISP_LIGHTMAP_DIM_INCLUDING_BORDER(128 in OB vs 131 in Beta/old HL2), and something related to the VPHYSICS(Trace ends in vphysics.dll IIRC). This makes most old(Pre-OB) maps crash, however first two errors can be dealt with by simply recompiling the maps. Error related to VPHYSICS persists no matter what. The new code also lacks many important checks that prevented crashes in the past. Valve don't seem to care about that, as this doesn't affect TF2 so far.
Why did they even care about these variables? Why did they change them so slightly that it does not affect memory useage but crashes the shit out of dedicated server? This is a motherfucking conspiracy. :tinfoil:
Well I'm personally more annoyed at how their engine is broken for current games on this engine, not old ones...and they don't fix it...
[QUOTE=krassell;34524127]Would be nice to tell Valve to fix things they broke with recent updates.
Taken from another thread.
Explaination:
I hope this annoying thing can be fixed, as it breaks hell lot of maps.
This makes me think that Valve break some things on purpose sometimes...[/QUOTE]
For the moment, you can fix it with
[lua]hook.Add( "Think", "func_rotating_fix", function()
for _, ent in ipairs( ents.FindByClass( "func_rotating" ) ) do
local a = ent:GetAngles()
a.p = math.NormalizeAngle( a.p )
a.y = math.NormalizeAngle( a.y )
a.r = math.NormalizeAngle( a.r )
ent:SetAngles( a )
end
end )[/lua]
in something like "lua/autorun/server/func_rotating_fix.lua"
Has anyone else noticed that when you play back a demo, your player metatable functions don't seem to work? For example, my _R.Player.IsMod function doesn't exist unless I put it in myself after the demo loaded/put it in an autorun file.
Sorry, you need to Log In to post a reply to this thread.
