In response to a PM, since this seems to have general relevance:
Lord Misfit wrote:but the problem is how elaborate and interconnected a lot of background elements of the mod
as the author of Hideous Destructor I can definitely relate to that!
The problem is, this means the GZDoom dev folks aren't going to have a clue about how your stuff is organized without dedicating a lot of time to studying your mod that they won't have. If they tried to debug using Aetherius (or HD) as-is, they could easily spend dozens of man-hours looking at a part of the code that has nothing to do with what's actually causing the bug, in a situation where you (or I) would have known within the first 5 seconds that the problem would also be affected by this other piece of code in another file.
So it's not only a courtesy but a practical necessity that we, the modders, have to pull out the minimum part of our own mods that cause the bug to happen and put together a demonstration.
See also the sticky note.
The times I
won't do this are:
1. I'm pretty certain I know what's causing it and I'm just using HD as the most obvious example - and the example in question is one of the simpler parts of HD. (e.g. "Portals don't work in software, I noticed this with the back corridor in the HD range")
2. I haven't the
slightest clue what the problem is and it's super obvious I lack the technical knowledge or sufficient feedback from GZDoom (e.g., ability to understand crashlogs) to even begin to figure it out. ("HD crashes to desktop on startup with GZ commit no. 12345 but works fine in commit no. 12344, crash log attached")
3. A demo already exists. ("Cameratextures on HUD broke again, here's a link to _mental_'s test pk3")
Any suggestions you can give me for how to approach this? Should I try to use the original weapon as a basis to condense, or do you honestly think I should try to recreate it from scratch?
What I normally do in a situation like this is:
1. find out exactly which actors cause the bug (is it all the HD weapons, or even the vanilla weapons while running HD)?
2. create backups of your work (copy another folder, commit to git, etc.)
3. see if disabling ACS helps
4. keep commenting-out and breaking things, running the mod and checking for the bug
and nothing else each time until the bug no longer appears
5. find the one line of code that can stop the bug if you comment it out
6. create a new weapon from scratch with only that one thing
7. see if that new weapon can be used to trigger the bug, if it does then post, if it does not then make a note that this is not the culprit and go back to step 3
Sometimes I'll shortcut around step 6 by inheriting from a stock Doom weapon (but only after checking to make sure that the bug isn't happening with the stock Doom weapon as well).
Only in the most extremely specific of cases would I try to take an existing HD weapon and pare it down until it works as a standalone, because otherwise it would be a lot
more work for me to cut out all those elaborate background interconnections so that GZDoom would even start (and then figure out what I'd deleted by mistake such that I could no longer replicate the bug), than for me to take the offending code and shoehorn it into something like this:
Code: Select all
class testwep:weapon{
states{
select:
TNT1 A 0 A_Raise();
wait;
deselect:
TNT1 A 0 A_Lower();
wait;
ready:
TNT1 A 1 A_WeaponReady();
wait;
fire:
altfire:
TNT1 A 1;
TNT1 A 0 A_Refire();
goto ready;
}
}
In response to a PM, since this seems to have general relevance:[quote="Lord Misfit"]but the problem is how elaborate and interconnected a lot of background elements of the mod[/quote]as the author of Hideous Destructor I can definitely relate to that!
The problem is, this means the GZDoom dev folks aren't going to have a clue about how your stuff is organized without dedicating a lot of time to studying your mod that they won't have. If they tried to debug using Aetherius (or HD) as-is, they could easily spend dozens of man-hours looking at a part of the code that has nothing to do with what's actually causing the bug, in a situation where you (or I) would have known within the first 5 seconds that the problem would also be affected by this other piece of code in another file.
So it's not only a courtesy but a practical necessity that we, the modders, have to pull out the minimum part of our own mods that cause the bug to happen and put together a demonstration. [url=https://forum.zdoom.org/viewtopic.php?f=2&t=56209]See also the sticky note.[/url]
The times I [i]won't[/i] do this are:
1. I'm pretty certain I know what's causing it and I'm just using HD as the most obvious example - and the example in question is one of the simpler parts of HD. (e.g. "Portals don't work in software, I noticed this with the back corridor in the HD range")
2. I haven't the [i]slightest clue[/i] what the problem is and it's super obvious I lack the technical knowledge or sufficient feedback from GZDoom (e.g., ability to understand crashlogs) to even begin to figure it out. ("HD crashes to desktop on startup with GZ commit no. 12345 but works fine in commit no. 12344, crash log attached")
3. A demo already exists. ("Cameratextures on HUD broke again, here's a link to _mental_'s test pk3")
[quote]Any suggestions you can give me for how to approach this? Should I try to use the original weapon as a basis to condense, or do you honestly think I should try to recreate it from scratch?[/quote]
What I normally do in a situation like this is:
1. find out exactly which actors cause the bug (is it all the HD weapons, or even the vanilla weapons while running HD)?
2. create backups of your work (copy another folder, commit to git, etc.)
3. see if disabling ACS helps
4. keep commenting-out and breaking things, running the mod and checking for the bug [b]and [i]nothing[/i] else[/b] each time until the bug no longer appears
5. find the one line of code that can stop the bug if you comment it out
6. create a new weapon from scratch with only that one thing
7. see if that new weapon can be used to trigger the bug, if it does then post, if it does not then make a note that this is not the culprit and go back to step 3
Sometimes I'll shortcut around step 6 by inheriting from a stock Doom weapon (but only after checking to make sure that the bug isn't happening with the stock Doom weapon as well).
Only in the most extremely specific of cases would I try to take an existing HD weapon and pare it down until it works as a standalone, because otherwise it would be a lot [i]more[/i] work for me to cut out all those elaborate background interconnections so that GZDoom would even start (and then figure out what I'd deleted by mistake such that I could no longer replicate the bug), than for me to take the offending code and shoehorn it into something like this:[code=php]class testwep:weapon{
states{
select:
TNT1 A 0 A_Raise();
wait;
deselect:
TNT1 A 0 A_Lower();
wait;
ready:
TNT1 A 1 A_WeaponReady();
wait;
fire:
altfire:
TNT1 A 1;
TNT1 A 0 A_Refire();
goto ready;
}
} [/code]