By: Grocel

Originally posted by Grocel:

@Grande1900:

The structure @ExtendClass is not supported by Hammer so far as I know and we have built the file for Hammer first. If we tried to add @ExtendClass it would not load in Hammer. If H++ also does not work with it properly neither, it is sadly no use for us.

The tracker seems kinda active, at least issue are added to it quite frequently. What's the current tracker for it?

By: Grande1900

Originally posted by Grocel:

@Grande1900: You might want to forward your issue to:
https://github.com/ficool2/HammerPlusPlus-Issue-Tracker/issues

Originally posted by Grande1900:

Originally posted by Grocel:

@Grande1900: You might want to forward your issue to:
https://github.com/ficool2/HammerPlusPlus-Issue-Tracker/issues

1. This issue tracker has been deprecated for two years
2. HPP has an @ExtendClass that allows you to append keyvalues and helpers to existing classes
3. Currently, and unfortunately, keyvalues don't get appended for some reason (someone has already made an issue on the (deprecated) issue tracker that I mentioned before).

By: Grocel

Originally posted by Grocel:

@Grande1900: You might want to forward your issue to:
https://github.com/ficool2/HammerPlusPlus-Issue-Tracker/issues

By: SligWolf

Originally posted by SligWolf:

Hiho!

Our fgd file works fine with GMod's official Hammer Editor.
It seems that Hammer++ might have an issue with this particular edge case, maybe it should be reported to its developer. I'm afraid there is nothing I can do about this.

The redefinitions are needed to add a custom field to the vehicle entity classes.
Removing them will make the fgd file effectively useless.

The custom field looks like this below:
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3293943285

By: Grande1900

Originally posted by Grande1900:

If I try using the FGD in Hammer++ and spawn one of the vehicle classes, it hangs. If I remove the @PointClass definitions for the vehicles, then it works fine.

Edit:
*By removing the @PointClass definitions, I mean commenting out the redefinitions for prop_vehicle_prisoner_pod, prop_vehicle_airboat, and prop_vehicle_jeep at the end of the file.

Additional note by SligWolf:
Grocel and I desided to not change the FGD file shipped with the addon. However you can use the patched file that I uploaded in the PR for your H++ setup if you like.
Please consider this as an unofficial patch.

https://github.com/SligWolf/sligwolf_addon_base/pull/1#issuecomment-2243009669

Be sure that one or more of these addons are NOT installed in your gmod:
These addons (not limited to) are known to cause an issue:

• None known at the moment.

Statements:

• All our addons are carefully tested.
  
• Your problem is very likely caused by wrong usage or by bad reading
  UNTIL proven otherwise!
  
• Resolve addon conflicts or other issues yourself.
  Use this troubleshooting guide.

Statement:
There is a GMod bug that causes the in game physics interaction to glitch around.
It only happens if the server or singleplayer run on the x86-64 branch.

Important note!
If your game is the normal main branch and you join a server that is running on x86-64, then you will have the same issue.

If the server or singleplayer does not run on the x86-64 branch, everything should be fine.
Keep that in mind.

There is nothing I can do. I'm simply not the developer of Garry's Mod.
Here you can get details about the problem:

• Facepunch/garrysmod-issues#5968
  Unstable collision detection in physics on x86-64 branch[github.com]
  
  
• SW Addons - Bug Reports
  Problem with the trains on x64 Chromium Beta

You do have the permission:
To rework our Models*, Textures*, Maps* and Scripts* for everything you want.

You do have not the permission:
To sell our work in any way!
Reworking our work without knowing what you are doing!

---

*Models:
Make sure your new separate model does not overwrite models of our addons.
Means: Decompile the model and compile it with a different name for your addon.

*Textures:
Make sure your new separate texture does not overwrite textures of our addons.
Means: Rename and edit the texture files for your addon. (Except it is a reskin.)

*Maps:
Make sure your new separate map does not overwrite the map of our addon.
Means: Decompile the map and compile it with a different name for your addon.

*Scripts:
Make sure your new separate script does not overwrite scripts of our addons.
Copy and paste a script and change some names inside it, is wrong.
If you don't have the knowledge to do it right, don't do it.

Put your stuff not in our folders, please use your own paths like:
"lua/username/..." "models/username/..." and so on.

---

And last thing, give credits somewhere if you upload some of our reworked content.
With downloading our content you agree with these rules.
Thank you for your understanding.

By: Grocel

Originally posted by Grocel:

I have contacted other well known server/addon developers about it yesterday. I think there is some interesting investigation going on right now. They can reproduce the issue too.

Edit:
Issue has officially has been reported to the GMod developer:
https://github.com/Facepunch/garrysmod-issues/issues/5968

Let's see what comes from this.

By: SligWolf

Originally posted by SligWolf:

Hey!

So after the update for the sliders I tested them again on x64.
Bad news, it doesn't changed anything.
Unfortunately, there is indeed nothing I can do about it.

Edit:
Well, it seems they will someday make the x64 to the main release and all SW Trains will break if the error is still present.

We can just hope and wait.
But I think the real problem is that the Source Engine is just too old, that odd behovior can happens with newer hardware. And if there is really nothing we can do to save the SW Trains, then we have to say goodbye or need to recreate all from scratch.

These are my thoughts about the situation.