Yes, but you'll still need to write a custom FireBullets function without this. (I'm Kefta btw)
To explain the suggestion, adding the suggested key to the trace struct will poll the ShouldCollide hook as a filter for entities to hit - whether you use that for bullets or player movement is up to you.
Oh, got it, thanks for explaining. I remember talking with you about the custom FireBullets function. I guess there's no way around that then (will it also be able to support other player-prop interactions such as Physgunning a prop btw?)
Correct me if I'm wrong but if I understood you correctly; custom FireBullets or not, there isn't much we can do until the devs implement your suggestion?
FireBullets is not necessary for that, nor is there a way to change the filter of what the default physgun beam hits.
You can technically utilise the trace structure's filter feature to call the ShouldCollide hook for every entity hit, but it will be extremely slow. Example:
-- pPlayer = player being used in the trace
util.TraceLine({
start = StartPos,
endpos = EndPos,
mask = MASK_PLAYERSOLID,
collisiongroup = pPlayer:GetCollisionGroup(),
filter = function(pEntity)
-- Don't hit the player
if (pEntity == pPlayer) then
return false
end
return hook.Run("ShouldCollide", pPlayer, pEntity) ~= false
end
})
Can we get an answer on this: Make render.RedownloadAllLightmaps asynchronous?
I get a lot of messages from server-owners running my mod on large maps, causing clients to lag when calling render.RedownloadAllLightmaps.
It also breaks on larger maps, as there is a file-transfer-limit.
I tried to use light_environment to control the light-level, but sadly this ignores entities along with other things.
Could be somewhat solved in Lua, as well if there were a binding R_BuildLightMap and additional functions to identify lightmap by ID.
Would be awesome to have render.RegenerateAllLightmaps( String lightlevel , boolean DoStaticProps ) along with light_environment and engine.LightStyle. Dark PhysObj problems ·.. being fixed.
https://i.imgur.com/6M6Ubyo.png
I assume these commits mean something different than what I think they do, right? I noticed this comment from @code_gs in a 2 year old GitHub request too.
https://files.facepunch.com/forum/upload/107145/b35f3e6f-5364-48a8-be18-87c401a5459b/image.png
An OGL Windows client would be cool as hell if that is the case.
Doesnt limux and mac runs in opengl? although i would like to agree, csgo runs awful in linux (also speaking graphically)
Isn't MacOS dropping OpenGL support, though?
They're deprecating it, but I doubt they'll fully drop it for the foreseeable future, especially with the current controversy.
I've been using it to test the SDL and OpenGL code paths on Windows, rather than having to pop over to Linux/macOS all the time.
It wouldn't be difficult to ship an OpenGL Windows build as well as the 32/64 bit builds. I don't think there's exactly any reason to use it over DirectX though.
I can think of at least one good reason. You can't push DX9 textures to a Vive, but you can push OGL textures to it.
I'm not asking for official support but it would make a community-made addon a much bigger possibility. I've personally tried to get SteamVR to work in Garry's Mod by sharing a texture handle with a dummy DX11 program and trying to send textures between the devices but either I don't know enough about DX or some kind of technical hurdle makes it more challenging than it should be. Nevermind all the additional latency that would be added by a solution like that.
You can share textures between D3D9Ex and DX11. It's a little finicky, but I've in fact done it with GMod before to play about with my Oculus Rift (it's unplayable, so I have nothing to show you.)
It'd probably be easier to do that with OpenGL though, hah.
Yep, that's the wall I've hit. I know it's possible because I can pull an IDirectXTexture9 out of GMod and save it to disk, but all of my attempts to then share that texture to DX11 have failed for one reason or another.
This isn't really related to the thread so I won't pester you about it here, but if you do have some sort of proof of concept code to share a DX9 texture from Garry's Mod to a DX11 device I'd love to see it.
It's probably been said plenty of times before but official VR support would be the bomb. I don't have any idea on how possible that is, in terms of performance and just general functionality, but it's an idea nonetheless.
I just think it'd be pretty cool to make shit in sandbox and fight NPC armies n shit. But on the other hand, if the only use would be for singleplayer (assuming that would be the limitation) then I can see why it wouldn't be worth the time spent trying to get it to work.
It's probably been asked, but how feasible are colored prop_static like in the CSGO and Portal 2 branches?
Another question; $treeSway will work retroactively on all maps and models, right? I think it's obvious but I'm asking just in case. As long as the model has that property, it should work? It'll be great to see my ports from CSGO suddenly start having moving trees overnight.
As long as the map has env_wind and the models have $treesway with all of the appropriate properties, then yeah it'll work. Go ham my man!
$treeSway isn't available yet? I'm on the Beta branch and it doesn't seem to work yet. There is wind in the map, as evidenced by ropes.
Also will all these variables be functional as well?
$treeswayfalloffexp
$treeswayheight
$treeswayradius
$treeswayscrumblefalloffexp
$treeswayscrumblefrequency
$treeswayscrumblespeed
$treeswayscrumblestrength
$treeswayspeed
$treeswayspeedhighwindmultiplier
$treeswayspeedlerpend
$treeswayspeedlerpstart
$treeswaystartheight
$treeswaystartradius
$treeswaystrength
Be sure you're on dev. (The function cl_tree_sway_dir should exist)
Be sure the shader is VertexLitGeneric.
Be sure there is no bumpmap on the texture.
cl_tree_sway_dir takes two arguments; x and y
I don't understand the last one but the other three are done.
It should probably be implemented as a graphics setting. I remember way back when L4D2 released and had tree sway, my ole shitter computer then couldn't take it. Probably a non-issue for the vast majority of people nowadays but for the people that play on laptops it'll likely be worth being able to turn off.
It will next update - it requires updating the net table for env_wind which will not allow dev branch clients to join main branch servers.
Just being curious, is there a reason (Lua limitation maybe) why CreateMaterial does not support the Subrect shader?
The PlayerDisconnect mystery is over (I really hope this isn't the issue everyone has been referring to lol)
Here's a question, is there a reason, beyond just not having implemented support for it yet, that system.FlashWindow is only supported on Windows?
And why system.HasFocus has broken support on platforms other than Windows?
Could the Chromium branch be updated to the latest main branch version? It's causing compatibility issues evidenced here.
Could we get official multicore/chromium support yet? :P
We've been wanting it for years.
I would settle for a mountable model that players inherit that refreshes on client connection, so you can just add new animations to it and have it refresh.
Current usage of m_/f_anm integration is cached only once, meaning any new ACTs or etc can never be loaded in or synced directly by the server.
Additionally, the blank skeleton approach that relies on bone merge is limited by the assumption of all the bones being shared
I'd be happy with an easy way to add new hold types for now though! Store the holdtype lists and ACTs globally so people can add to it without relying on translations within the SWEP exclusively
Sorry, you need to Log In to post a reply to this thread.
Next Update v8 - February 2018 Update is out!
