Next Update v6.0 - October 2016

[Rubat]

[QUOTE=MaxShadow;51977222]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.[/QUOTE]

What exactly is this "fix" of yours?

[t]http://i.imgur.com/Iy4XGax.png[/t]

[QUOTE=bobbleheadbob;51977165]Is anyone else having problems with ent:SetMaterial()? It's simply not working for me.

Even the material STool isn't working.[/QUOTE]

It is broken in DirectX 8 or lower.

[MaxShadow]

[QUOTE=Robotboy655;51977429]What exactly is this "fix" of yours?[/QUOTE]

Well, exactly that one. That little "for" block that prevents the game from creating duplicated ammo types. Without that, some SWEPs stop working when you have too many, because the list has a hardcoded limit of 152 ammo types I think, and it quickly fills up with unused duplicates.

Right now the game only does "table.insert( AmmoTypes, tbl )", without any kind of check, or at least that's what I have in my gmod installation.

[c👌de_g🎷]

[QUOTE=MaxShadow;51977509]Well, exactly that one. That little "for" block that prevents the game from creating duplicated ammo types. Without that, some SWEPs stop working when you have too many, because the list has a hardcoded limit of 152 ammo types I think, and it quickly fills up with unused duplicates.

Right now the game only does "table.insert( AmmoTypes, tbl )", without any kind of check, or at least that's what I have in my gmod installation.[/QUOTE]

I made a PR to fix that

[Rubat]

It's already in Dev for 4 months and will be released with update.

[MaxShadow]

[QUOTE=code_gs;51977551]I made a PR to fix that[/QUOTE]

Yeah, thats the one I uploaded to the workshop (with a tweak from UselessGhost) to fix the problems ppl was having with one of my addons. Actually, I suggested the same thing a year ago.
[url]https://facepunch.com/showthread.php?t=1507949[/url]

[c👌de_g🎷]

[QUOTE=MaxShadow;51977589]Yeah, thats the one I uploaded to the workshop (with a tweak from UselessGhost) to fix the problems ppl was having with one of my addons. Actually, I suggested the same thing a year ago.
[url]https://facepunch.com/showthread.php?t=1507949[/url][/QUOTE]

The PR wasn't merged a year ago, but 4 months ago.

[NeatNit]

[QUOTE=NeatNit;51976259]what about [url]https://github.com/Facepunch/garrysmod-requests/issues/738[/url][/QUOTE]
Why the disagrees?

[mcNuggets]

Walking on props is still fucked up and pretty poorly optimized.

Is there any way to make walking on props "playable"?

[FPtje]

Also, don't touch anything that has even a remote potential of affecting prop surf performance. Stay away from it!! Shoo!

:v:

[MeepDarknessM]

[QUOTE=Rocket;51979882]As long as the game still uses VPhysics, pretty much no.[/QUOTE]

willox made (a long time ago) a walkable props addon. it wouldn't spaz out and you can actually stand on the prop as it is moved, but it's very buggy. It's possible.

[MaxShadow]

[QUOTE=mcNuggets1;51979624]Walking on props is still fucked up and pretty poorly optimized.

Is there any way to make walking on props "playable"?[/QUOTE]

This addon makes props walkable with a very hacky method. It even allows you to walk on walls and ceilings.
[url]http://steamcommunity.com/sharedfiles/filedetails/?id=531849338&searchtext=Localized[/url]

What I would like to see is better support for polywelding. That thing is much better than the default weld, but it's quite buggy at the moment.

[Mr. Bix]

i don't know if anyone has posted about this, but as of a few updates ago, having an entity remove itself in a collision hook (such as a rocket exploding on impact) now causes the following error

[lua]Changing collision rules within a callback is likely to cause crashes![/lua]

and as far as i can tell there's no way to get rid of it

is there any possibility of this being dealt with without me having to go back and change literally every single projectile i've ever made

[ForrestMarkX]

[QUOTE=noobcake;51981743]i don't know if anyone has posted about this, but as of a few updates ago, having an entity remove itself in a collision hook (such as a rocket exploding on impact) now causes the following error

[lua]Changing collision rules within a callback is likely to cause crashes![/lua]

and as far as i can tell there's no way to get rid of it

is there any possibility of this being dealt with without me having to go back and change literally every single projectile i've ever made[/QUOTE]

Don't call ENT:Remove() inside of ENT:PhysicsCollide()

[Bobblehead]

[QUOTE=ForrestMarkX;51981752]Don't call ENT:Remove() inside of ENT:PhysicsCollide()[/QUOTE]

If you have to do it, make a timer for 0 seconds.

[c👌de_g🎷]

I still don't understand the message; Entity:Remove () just flags it for deletion, it doesn't actually invalidate the entity immediately. Why would that cause crashes?

[Bobblehead]

[QUOTE=code_gs;51981810]I still don't understand the message; Entity:Remove () just flags it for deletion, it doesn't actually invalidate the entity immediately. Why would that cause crashes?[/QUOTE]

Maybe it's a timing issue.

[NeatNit]

[QUOTE=code_gs;51981810]I still don't understand the message; Entity:Remove () just flags it for deletion, it doesn't actually invalidate the entity immediately. Why would that cause crashes?[/QUOTE]
I've seen this started before but never with a source. If true though, then there really is no reason to warn.

[editline]19th March 2017[/editline]

[QUOTE=bobbleheadbob;51981842]Maybe it's a timing issue.[/QUOTE]
That's the thing - since Entity:Remove only flags for deleting, there's no timing involved - the engine deletes the entity at the appropriate time in the current/next tick.

This is all assuming that it really works as code_gs described.

[Derek_SM]

[QUOTE=NeatNit;51981843]I've seen this started before but never with a source. If true though, then there really is no reason to warn.

[editline]19th March 2017[/editline]

That's the thing - since Entity:Remove only flags for deleting, there's no timing involved - the engine deletes the entity at the appropriate time in the current/next tick.

This is all assuming that it really works as code_gs described.[/QUOTE]

If the entity got immediately removed then we wouldn't be able to grab it in the EntityRemoved hook, no?

[Mr. Bix]

see that's the thing, i would totally understand if doing that actually [I]caused[/I] crashes, but it doesn't and never has

so that warning is nothing but an inconvenience to people like me, who don't like having their server consoles spammed for no reason

[NeatNit]

[QUOTE=Derek_SM;51981863]If the entity got immediately removed then we wouldn't be able to grab it in the EntityRemoved hook, no?[/QUOTE]
No, it would be a trivial matter of calling this hook before Entity:Remove returns.

Edit: to clarify, this is [del](presumably)[/del] not what happens. I'm just saying that it [i]would be[/i] what happens [i]if[/i] the entity was removed immediately when Entity:Remove() was called. Which it's not.
[del]I still don't have proof that Entity:Remove() is delayed though. Just going by everyone's assertions, no reason to doubt them.[/del] Edit: Proof (or rather, evidence) 2 posts below.

[Grocel]

[QUOTE=NeatNit;51981952]No, it would be a trivial matter of calling this hook before Entity:Remove returns.[/QUOTE]

EntityRemoved is also called when the engine itself removes the entity which makes sense.

[Derek_SM]

[QUOTE=NeatNit;51981952]No, it would be a trivial matter of calling this hook before Entity:Remove returns.[/QUOTE]

But wouldn't that have to be at the next frame anyway?

Regardless of that:

[lua]
hook.Add( "EntityRemoved", "test", function( ent )
print( ent:IsFlagSet( FL_KILLME ), ent:IsEFlagSet( EFL_KILLME ) )
end )
[/lua]

First returns false in my tests, second returns true, and uh
here:
[url]https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/shared/shareddefs.h#L580[/url]

[NeatNit]

Edited my last post to clarify, it's [i]not[/i] actually what happens.

[editline]19th March 2017[/editline]

[QUOTE=Derek_SM;51982136]and uh
here:
[url]https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/shared/shareddefs.h#L580[/url][/QUOTE]
Oh, cool

[editline]19th March 2017[/editline]

On the same topic, I guess this is the better place to ask. Just a curiosity I have:

[img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Global/SafeRemoveEntity]SafeRemoveEntity[/url] will remove the entity unless it's a player or the world. Why does [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Entity/Remove]Entity:Remove[/url] even work on players or the world? Is there ever a scenario where you'd actually want to do that?

[Rubat]

It doesn't work on players.

[NeatNit]

News to me. Last time I checked it caused a whole bunch of junk to happen.

[Rubat]

It used to. Maybe I should make it not work on the world too.

[Bo98]

[QUOTE=noobcake;51981743]i don't know if anyone has posted about this, but as of a few updates ago, having an entity remove itself in a collision hook (such as a rocket exploding on impact) now causes the following error

[lua]Changing collision rules within a callback is likely to cause crashes![/lua]

and as far as i can tell there's no way to get rid of it

is there any possibility of this being dealt with without me having to go back and change literally every single projectile i've ever made[/QUOTE]

Relevant request: [url]https://github.com/Facepunch/garrysmod-requests/issues/894[/url]

[mcNuggets]

[QUOTE=Rocket;51979882]As long as the game still uses VPhysics, pretty much no.[/QUOTE]
That is quite a shame.

A lot of gamemodes are based on walking on physics controlled entities.

Like Smash, Neo-Smash in some cases Deathrun, etc.

Even walking on freezed props is nearly impossible even as listen host of a server or as a player on a dedicated server.

It is just so much potential for new gamemodes which fades away...

[HighVoltage]

[QUOTE=mcNuggets1;51982728]That is quite a shame.

A lot of gamemodes are based on walking on physics controlled entities.

Like Smash, Neo-Smash in some cases Deathrun, etc.

Even walking on freezed props is nearly impossible even as listen host of a server or as a player on a dedicated server.

It is just so much potential for new gamemodes which fades away...[/QUOTE]

You got to remember that source wasn't made for this at the time, we are pushing at the limits of a old engine that is literally just a tower of duct tape.

[mcNuggets]

[QUOTE=highvoltage;51982897]You got to remember that source wasn't made for this at the time, we are pushing at the limits of a old engine that is literally just a tower of duct tape.[/QUOTE]
It is still possible to change things and update things for the good.
Just because it's old it doesn't mean it has to "die".

It is still a relevant engine and is used in quite alot of games.

It has a lot of positive aspects, aswell as negative.
Redoing specific aspects wouldn't hurt anyone.