TeamSpen210 / HammerAddons

Useful tweaks and content for Source Engine Games
124 stars 36 forks source link

Gmod FGD `origin` kv causing certain effect entities having strange behaviour #258

Open Vinzuerio opened 9 months ago

Vinzuerio commented 9 months ago

Hello! I'd like inform there was an issue when using HammerAddons' Garry's Mod FGD.

Recently I was having issues when using from this FGD and figured out this afternoon, some entities such as func_dustmotes and func_dustcloud (or any BModelParticleSpawner base entity) with origin key value present will cause strange effect. The entity itself still stays in exact position, however when map was compiled and loaded map in Garry's Mod, those effects will spawn on the worldspawn origin but not from entities's position.

Upon inspection, this causes internal entities' SaveValue m_AbsOrigin (along with other positions related) are changed from origin kvs thus causing the effect to be broken. it seems working in cs_militia (Apparently the position must stay 0,0,0 so it should be default for these kind of entities?)

Workaround

My current workaround as follows:

I'm not sure with other entities but I noticed this mostly affecting to func_dustcloud and func_dustmotes on my compiled maps

What I'm using & tested:

Screenshots

Improper func_dustmotes in my compiled map Coordinate of entities are changed from origin keyvalue, however it must be 0,0,0 and effects are spawned on world origin instead dustsmoke_worldspawn2 Close view of the effect near worldspawn origin dustsmoke_worldspawn1

Testing on cs_militia (what it should be) 20240207155937_1

Comparison dustsmoke3

I may have to test all effect/any brush entities just in case if this actually having similar effect to this one. I'll may have to update this issue on which entities are effected.

TeamSpen210 commented 9 months ago

It's those two entities specifically that have the problem in all engine branches. Valve didn't implement them properly, using the local position of the brush but not applying the origin transform. But this should have been fixed via an override in BModelParticleSpawner...

Vinzuerio commented 9 months ago

Alright thanks for the info!

Unfortunately when removing origin in BModelParticleSpawner it appears they still coming back in hammer and I think it still using from BaseEntityBrush base since it has origin key. I realised on my first workaround seems don't help since they will come back after reloading the vmf file, so the second workaround will fix it.

image

I might have to use my second workaround since it's convinient way to use these entities. (and because they're intended to be static and cant be parented anyway)

Also sorry for unrelated question but is there a way to exclude file(s) when automatic packing is enabled? Would appreciate with the help since I'm not sure how to exclude detail.vbsp to be included inside my map (it always included even though --no-pack is specified)

TeamSpen210 commented 9 months ago

Try adding back origin to BModelParticleSpawner, but defining it like so:

origin(string) readonly: "Origin": "0 0 0" : "Broken origin"

For excluding files, you should be able to use the pack_blocklist setting.

Vinzuerio commented 9 months ago

Try adding back origin to BModelParticleSpawner, but defining it like so:

origin(string) readonly: "Origin": "0 0 0" : "Broken origin"

For excluding files, you should be able to use the pack_blocklist setting.

image

image

Confirmed the override works!

Also pack_blocklist works too after testing it. I honestly have no idea why these random models, detail.vbsp and some textures always included when auto-packing is enabled and when there is no entities with model or textures associated with it. (the map is completely blank with dev textures, func_dustmote & func_dustcloud, sky texture and that's it). These (except detail.vbsp that stored in <mod> folder) are from recompiled hl2 beta contents using crowbar with newer model format, the contents are loaded using searchpaths in gameinfo.txt image

Anyway I'll close this issue as it's fixed for now. Thanks for the help once again!