Closed mode777 closed 8 months ago
Entity Base classes are built correctly in the current version without this PR. I just tested with the latest version of Qodot. Were you experiencing issues where your Base Classes didn't get added to the FGD?
I used qodot_fgd.tres
though I had to add the built in base classes since they weren't added to the FGD for some reason.
This was the output after exporting. You'll notice it includes the 3 base classes at the top.
@BaseClass = Target : "Performs actions (signal callbacks, methods) on entities with a matching 'targetname'." [
target(string) : "Name of entity (targetname) to target." : ""
]
@BaseClass = Targetname : "Subscribes to actions (signal callbacks, reciever methods) performed by other entities with a matching 'target'." [
targetname(string) : "Name of target to subscribe to." : ""
]
@BaseClass color(255 255 40) = Light[
_color(color255) : "Light color" : "255 255 255"
delay(choices) : "Attenuation" = [
1 : "Inverse distance falloff"
2 : "Inverse distance squared"
5 : "Inverse distance squared B"
0 : "Linear falloff (Default)"
4 : "Local minlight"
3 : "No falloff"
]
light(integer) : "Brightness" : 300
mangle(string) : "Spotlight angle" : "0.00499999988824 0 0"
wait(integer) : "Fade distance multiplier" : 1
]
@SolidClass = worldspawn : "World Entity" [
]
@SolidClass = group : "Brush Group" [
]
@SolidClass = illusionary : "Non-colliding Brush" [
]
@SolidClass = physics : "Physics Brush" [
mass(float) : : "1"
velocity(string) : : "0 0 0"
]
@PointClass size(-8 -8 -8, 8 8 8) base(Targetname, Target) = signal : "Name of signal to call target." [
signal_name(string) : "Name of signal to call on target." : ""
]
@PointClass size(-8 -8 -8, 8 8 8) base(Targetname, Target) = receiver : "Calls methods on target." [
receiver_name(string) : : ""
]
@PointClass size(-8 -8 -8, 8 8 8) base(Light) = light : "Invisible light source" [
angle(float) : "Rotation Angle" : "0"
]
@SolidClass = button : "Interactive button brush." [
axis(string) : "Direction of movement when pressed." : "0 -1 0"
depth(float) : "How far to move along the axis when pressed." : "0.8"
press_signal_delay(float) : "Seconds after press() is called, before emitting is own pressed signal." : "0"
release_delay(float) : "Seconds after a physics body exits, before calling release()" : "0"
release_signal_delay(float) : "Seconds after release() is called, before emitting is own released signal." : "0"
speed(float) : "Delta multiplier for a lerp weight to move the button to its desired position." : "8"
target(string) : : ""
trigger_signal_delay(float) : "Seconds after press() is called, before emitting the trigger signal." : "0"
]
@SolidClass = func_detail : "Detail Brush" [
]
@SolidClass = mover : "Moving brush." [
rotation(string) : : "0 0 0"
scale(string) : : "1 1 1"
speed(float) : : "1"
translation(string) : : "0 0 0"
targetname(string) : : ""
]
@SolidClass = rotate : "Rotating Brush" [
axis(string) : "Rotation Axis" : "0 1 0"
speed(float) : "Rotation Speed" : "360"
]
@SolidClass = trigger : "Trigger Volume" [
target(string) : : ""
]
@SolidClass = wall : "Basic entity brush." [
]
Yes it works if you manually add the base classes to the FgdFile (makes me wonder why Qodot does not include them by default). With my PR they are always added as long as a FgdClass references them. I agree that it all boils down to what the expected behaviour is. If my changes do not represent the intended behaviour I suggest that the default config that comes with Qodot should at least add them.
makes me wonder why Qodot does not include them by default
Qodot's always had problems regarding its built in FGDs, largely from a lack of understanding by everyone who uses (and maintains Qodot lol) on how the whole system works. The example FGD resources themselves went through several overhauls relatively recently, to try to reduce confusion and resolve issues with previous setups. Basically, in short, them not being included in the example qodot_fgd.tres
is an oversight.
Also of note is that the FGD resources included with Qodot are meant to serve as examples, not an actual default set. The way everything is set up is a bit of a mess that doesn't really help teach that intent, but the general recommendation is "Don't use the example FGD resources for your game; make your own", as the premade resources and entities are pretty poor honestly (no shade to Shifty).
Depending upon your map editor of choice (Qodot doesn't just work with TrenchBroom, it's just intended for it but you can make it work with JACK maps) the order of classes in your FGD can matter, so the best practice would be to not automate it based upon inclusions from other entities but rather force users to manually add their base classes to their FGDs. The real fix in this case would be to add those example base classes to the qodot_fgd.tres.
We're close to releasing a new plugin that fixes a lot of these issues, provides a true set of default FGD resources, and is near-thoroughly documented. We're also winding down on updates for this plugin, as it has accrued a lot of tech debt with some pretty big core design problems (along with other non-tech related concerns about its future). A lot of what we were trying to add or update on Qodot has been limited by a need to not break compatibility with people's projects. The last official Qodot release for it is intended to be released when TrenchBroom 2024.1 gets out of pre-release, and then we'll be moving on fully to the successor plugin.
We discussed this almost entirely on the Qodot Discord, which I admit is a failing on the Qodot Team's part not to discuss it here as well. We'll be doing some sort of announcement on here soon about it.
Thanks for the detailed report and good to see that there is some progress happening!
What does this PR change?
I noticed that BaseClasses are not created in the current FGD file creation. I don't know if this is broken or never worked before, but I decided to fix it.
Does this pull request address an existing issue?
See above. Maybe it would be more correct to create an issue first but it was easily fix.