View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3596 [The Dark Mod] GUI normal always 03.11.2013 12:57 03.12.2020 19:07
Reporter: sulfur Platform: x86_64  
Assigned To: cabalistic OS: Linux  
Priority: normal OS Version: Arch Linux  
Status: resolved Product Version: TDM 2.00  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.08  
    Target Version: TDM 2.08  
Summary: Issues with key bindings
Description: There are some issues with key bindings.

keypad / binds as INS,
keypad Enter binds as DOWNARROW,
right Control binds as PGDN,
right Alt binds as ENTER (this can be result of keyboard layout)

As the result:

keypad 0 has the same code as keypad /
keypad Enter has the same code as keypad 2
keypad 3 has the same code as right Control

which makes some of keypad keys unusable.

I haven't seen this problem in TDM 1.x
Tags:
Steps To Reproduce: Enter key bindings menu, try to bind keypad keys.
Additional Information: Keyboard layout: pl, keyboard: pc104
Should be possible to reproduce on US keyboard layout.
Attached Files:
Notes
(0010250)
user81   
28.03.2018 10:47   
@nbohr1more, is this still an issue anymore..?
(0012210)
cabalistic   
16.02.2020 15:04   
I made some improvements to the key mapping, should hopefully fix the most glaring issues.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5268 [The Dark Mod] AI major always 29.05.2020 10:36 03.12.2020 19:06
Reporter: grayman Platform:  
Assigned To: grayman OS:  
Priority: high OS Version:  
Status: resolved Product Version: TDM 2.07  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.08  
    Target Version: TDM 2.08  
Summary: AI in King of Diamonds gets stuck on a chair, mission fails
Description: Parkins, a main character in King of Diamonds, sits down in a chair in his attic.

When he goes to leave, he gets stuck treadmilling, and can't leave the attic.

This fails the mission, because Parkins is carrying the only key to the attic door, and it's important that the player be able to get into the room.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: KODR1.save (2,615,171 bytes) 04.06.2020 04:10
https://bugs.thedarkmod.com/file_download.php?file_id=873&type=bug
KODR2.save (2,616,894 bytes) 04.06.2020 04:11
https://bugs.thedarkmod.com/file_download.php?file_id=874&type=bug
KODR3.save (2,614,253 bytes) 04.06.2020 04:11
https://bugs.thedarkmod.com/file_download.php?file_id=875&type=bug
KODWOW.save (2,616,698 bytes) 08.06.2020 01:52
https://bugs.thedarkmod.com/file_download.php?file_id=878&type=bug
KODWOW2.save (2,616,649 bytes) 08.06.2020 01:52
https://bugs.thedarkmod.com/file_download.php?file_id=879&type=bug
Notes
(0012577)
grayman   
29.05.2020 11:34   
When an AI gets stuck on an object that’s behind him, there’s no reason he shouldn’t be able to move forward. Temporarily make the object non-solid so it loses its grip on the AI, until the AI leaves. Then make the object solid again.

Fixed in rev. 8743:

State.cpp
Entity.cpp
Entity.h
(0012582)
grayman   
01.06.2020 12:43   
Additional in rev. 8745:

Actor.cpp
Actor.h
AI.h
State.cpp
Entity.cpp
Entity.h

Rev. 15943:

tdm_ai_base.script
(0012584)
grayman   
02.06.2020 14:55   
Additional in rev 8749:

Entity.cpp
(0012585)
nbohr1more   
04.06.2020 04:10   
(Last edited: 04.06.2020 15:19)
Rev 8750 before the door
(0012586)
nbohr1more   
04.06.2020 04:10   
After noclipping
(0012587)
nbohr1more   
04.06.2020 04:11   
(0012588)
nbohr1more   
04.06.2020 04:11   
After alerting the AI
(0012589)
nbohr1more   
04.06.2020 04:12   
Parkins is treadmilling but alerting him will release him from the situation.
(0012590)
nbohr1more   
04.06.2020 04:55   
Hmm. This was replicated with capped FPS ( com_fixedTix 0 ).

Uncapping FPS restored the fix...
(0012591)
grayman   
04.06.2020 15:19   
I can't use KODR2 or KODR3.

I need a failure savegame prior to Parkins reaching the chair.
(0012592)
nbohr1more   
04.06.2020 16:34   
Hmm...

I again played with TDM on all "safe" settings (capped FPS, no multi-core) and noclipped right to the attic
then waited for Parkins. On attempting to save as he was approaching the desk, the game crashed to desktop.
(0012593)
nbohr1more   
05.06.2020 03:07   
SVN Rev 8752

The above "noclip" replication now saves with no error or crash.
After saving, Parkins had no trouble leaving his seat and exiting the room.

I will try a full replication to verify further.
(0012594)
nbohr1more   
05.06.2020 04:06   
I cannot replicate the problem on rev 8752 with either safe or experimental settings.
(0012595)
grayman   
05.06.2020 04:07   
Note to self:

Rather than checking sit/sleep completion flag once, try checking it until the AI is free of the chair/bed. Then clear it. There could be a timing issue between the setting and checking of the flag, and multiple checks should be able to deal with it.
(0012599)
nbohr1more   
06.06.2020 22:19   
(Last edited: 07.06.2020 02:23)
A thought:

This seems to only happen when the AI is far out of sight.... "Interleaved Thinking" at play here?

Edit:

tdm_ai_opt_disable 0

seems to cure this issue in 2.08 Beta 7...

Edit 2:

More testing.
I was able to reproduce it with this setting. Sorry
(0012602)
grayman   
07.06.2020 18:49   
Revs 8758, 8768, and 15950 round out the addition of checking AI who don't run into an obstacle after sitting/sleeping.
(0012603)
grayman   
07.06.2020 19:02   
Interleaved thinking won't be in play.

The sitting/standing/sleeping anims need to stay in sync, so the AI gets to think every frame.
(0012604)
nbohr1more   
08.06.2020 01:52   
Rev 8768 before door
(0012605)
nbohr1more   
08.06.2020 01:52   
Noclip past door
(0012606)
nbohr1more   
08.06.2020 01:52   
(0012607)
grayman   
08.06.2020 05:37   
At this point, since we have an OK from Spooks to correct the map, I'm going to stop working on the problem. Apparently it's way more complex (as is usually the case with pathfinding) than I originally imagined, and spending more and more time on it seems pointless.
(0012608)
stgatilov   
08.06.2020 07:53   
Do you think the code you implemented should be removed/commented/disabled/frozen or left in working state?
(0012609)
grayman   
08.06.2020 08:28   
Removed.

My ability to solve the continuous "one more example of failure" for this problem has been exhausted.

I just wish I was able to reproduce the problem; that would have prevented the "spec" nature of the solution.
(0012614)
Dragofer   
13.06.2020 17:58   
I can't start TDM SVN anymore, getting a crash with a blue window containing the following message:

Error: file script\tdm_ai_base.script, line 1666: Unknown value "setGetUpTime"
(0012615)
AluminumHaste   
13.06.2020 18:34   
(Last edited: 13.06.2020 19:44)
Yeah, same here, looks like it was left in by accident when the other fixes were removed.

Commenting out those 2 lines in the script file gets the game to load. Seeing as they are tagged with this bug report, fairly confident they can go.
(0012617)
nbohr1more   
17.06.2020 03:05   
A repaired version of this mission is up on the repo.

The state of SVN can be discussed in internal forums or (if we really need to) in another bug tracker.

Closing.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2993 [The Dark Mod] Design/Coding normal have not tried 24.01.2012 16:24 03.12.2020 19:05
Reporter: angua Platform:  
Assigned To: STiFU OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 1.07  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.08  
    Target Version: TDM 2.08  
Summary: Removing an inventory item can invalidate cursor, resulting in crash
Description: In Inventory.cpp, the CInventory::RemoveItem() function advances the cursor to the next before removing the item. If the removed item is the second last one, the cursor moves to the last one, and then the numbers of elements in the category is reduced by one, leaving the cursor at an invalid position.
Tags:
Steps To Reproduce: Make a custom category with at least 2 items, remove the second last item
(use on object in world, with script function
$player1.replaceInvItem(item, $null_entity);)
Try removing the other item -> crash
Additional Information:
Attached Files:
Notes
(0004539)
grayman   
05.05.2012 15:29   
As we attempt to wrap up 1.08, is this fix required, or can it wait?
(0004543)
tels   
05.05.2012 17:03   
It is not fixed, and since its a crash, it should probably be fixed. A cursory look didn't show me an easy way to fix it, tho. Once the cursor runs over, it somehow needs to be set back to a valid item.
(0004544)
tels   
05.05.2012 18:06   
And I forgot to mention that the crash can occur because the player drops an item from the inventory to the hands or ground, too.
(0004546)
grayman   
05.05.2012 18:18   
I picked up two flashmines, then dropped one after the other on the ground, with no crash.

Guess I have to find out what's going on.
(0004547)
grayman   
05.05.2012 18:19   
And how do I "make a custom category"?
(0004548)
grayman   
05.05.2012 21:46   
This note is for angua, because she filed the issue.

I'm unable to reproduce a crash, and want to know if I'm creating a reasonable test case.

I have a flashmine (Mine1) and a mine (Mine2), both of which belong to the Tools category.

I have two buttons. Button 1 calls a script that does this:

$player1.replaceInvItem($Mine1, $null_entity);
$player1.replaceInvItem($Mine2, $null_entity);

Button 2 calls a script that does this:

$player1.replaceInvItem($Mine2, $null_entity);
$player1.replaceInvItem($Mine1, $null_entity);

In the game, I pick up Mine1, then Mine2.

In the inventory cursor list, Mine2 becomes the first entry, and Mine1 is the second entry.

Regardless of which button I press, I can't get a crash. I assume Button 2 is the one that creates the problem you describe, since Mine2--the second item from the end--is removed first, followed by Mine1.

Have I set this up correctly?

(There is a display problem where the screen isn't being updated properly depending on what's being displayed, but that's a separate issue.)
(0004563)
angua   
10.05.2012 18:19   
Can't reproduce the crash either, looks like this is not an issue any more.
(0004566)
grayman   
10.05.2012 18:57   
May I close it,then?

Thanks.
(0004573)
tels   
11.05.2012 17:40   
I am still not convinced that this bug is really fixed.


Consider what this code does:

void CInventory::RemoveItem(const CInventoryItemPtr& item)
{
        if (item == NULL) return;

        // Update the cursors first
        for (int i = 0; i < m_Cursor.Num(); i++)
        {
                if (m_Cursor[i]->GetCurrentItem() == item)
                {
                        // Advance the cursor, this should be enough
                        m_Cursor[i]->GetNextItem();
                }
        }

        // Now remove the item, the cursors are updated.
        item->Category()->RemoveItem(item);
}


If you have three items in a category, 0, 1, and 2, and the cursor is at item 1 (the second-to-last-one), then

m_Cursor[i]->GetNextItem();

will fetch the ptr to the last item (2) and set the item index for the cursor to "2".

However, when you then remove the second-to-last-item, the ptr to the item inside the cursor is still valid (points to 2), but the itemIndex is invalid, it is still "2", but there are only two items now (0 and 1).

The code item->Category()->RemoveItem(item); does not seem to update the cursor anymore.

E.g. the code seems to be backwards, it first updates the cursor, then removes the item, leaving and invalid cursor.

That it no more crashes is probably pure luck.
(0004869)
CodeMonkey   
07.10.2012 13:07   
Wouldn't it be better to select the previous item?

This 'could' lead to a case where it tries to select an invalid index, ie, -1, but, that shouldn't be hard to account for.
(0011561)
VanishedOne   
09.02.2019 20:11   
Possibly relevant: when I made the this-message-will-self-destruct-after-you-read-it note in ITB I started out just dropping it in the map with "inv_map_start" "1", and removing it with $player1.replaceInvItem($inv_item_to_remove, $null_entity) caused the item cursor to change to empty. However, after I made a corresponding shop item and added it to the starting inventory via the shop, the inventory cursor would stick around until I cycled to another item. I ended up adding $player1.getPrevInvItem(); to the script.
(0011593)
STiFU   
14.02.2019 10:37   
The GetCurrentItem()-method family do a validity check of the index and return NULL-ptr for invalid indices. The callers do not consistently check for nullptr and I didn't want to mess with the whole codebase, so I have ensured the index is always valid. As a fallback, the TDM_DUMMY_ITEM is selected in error cases, which always exists. This is the same as clearing the inventory ingame.

Rev. 7957


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4004 [The Dark Mod] Models normal have not tried 03.01.2015 02:28 03.12.2020 19:05
Reporter: Springheel Platform:  
Assigned To: Dragofer OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.03  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.08  
    Target Version: TDM 2.08  
Summary: Covered models
Description: The covered furniture models need some attention before they are ready for release.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0009510)
nbohr1more   
17.10.2017 15:14   
2.07?
(0012292)
Dragofer   
22.03.2020 12:26   
Fixed in Rev 15867. Forum thread: https://forums.thedarkmod.com/index.php?/topic/20306-covered-furniture-refurbished/&tab=comments#comment-445105


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4523 [The Dark Mod] Tweaking tweak always 06.05.2017 19:11 03.12.2020 19:04
Reporter: Anderson Platform:  
Assigned To: nbohr1more OS: Windows  
Priority: low OS Version: 10  
Status: resolved Product Version: TDM 2.05  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.06  
    Target Version: TDM 2.06  
Summary: Romanian Translation fix slated for 2.06
Description: I've PM'ed Bikerdude about this and created a thread in the forum related to this matter: http://forums.thedarkmod.com/topic/18828-romanian-gui-issue-request-for-bugtracker/#entry405642

If possible I'd like this planned for 2.06 to deal with it quickly because this translation is only bare bones. It doesn't even contain the proper characters unfortunately as I'm a layman in code and Strawberry.
Tags: Bug, Fix, Glitch, Hotfix, Patch, Romanian, Translation, Tweak
Steps To Reproduce: Check the GUI and menu in Romanian.
Additional Information:
Attached Files: all.lang (630,798 bytes) 23.01.2018 15:48
https://bugs.thedarkmod.com/file_download.php?file_id=578&type=bug
all_Romanian.lang (631,248 bytes) 24.01.2018 07:46
https://bugs.thedarkmod.com/file_download.php?file_id=581&type=bug
Notes
(0009787)
nbohr1more   
14.12.2017 15:32   
Slovak targeted for 2.06 too:

http://forums.thedarkmod.com/topic/17374-slovak-translation-progress-screenshots-etc/#entry415909
(0009795)
user81   
14.12.2017 19:14   
Also replied in the above thread asking in Petike had manage to fix the broken fonts.
(0009991)
grayman   
10.01.2018 12:50   
I know Petike is working on Slovak.

If he's not also working on Romanian, who is?
(0009992)
Anderson   
10.01.2018 13:02   
(Last edited: 10.01.2018 13:02)
I was on Romanian with help from Tels.

(0009995)
grayman   
11.01.2018 14:20   
@Anderson, @NB:

Is there more work to be done on Romanian?
(0009996)
Anderson   
11.01.2018 14:50   
(Last edited: 11.01.2018 14:50)
At the moment I have done everything within my abilities. The Romanian translation should be fully functional as is.

(0009997)
grayman   
11.01.2018 15:48   
@NB, if you agree, can we close this issue?
(0009999)
Anderson   
11.01.2018 16:18   
If the latest tdm_base01.pk4 is implemented then yes, it can be closed as far as Romanian is concerned.
(0010000)
nbohr1more   
11.01.2018 18:31   
We need to compare your work to the Slovak translation.

Somehow it wasn't fully compliant before.
(0010001)
Anderson   
11.01.2018 20:07   
What are the standards to comply with, if I may ask?

I coordinated all translation of the GUI, menu, loading tips, inventory description with Tels at the time, as he was the one who started the Internationalisation (I18N) project.
(0010002)
nbohr1more   
11.01.2018 20:48   
Just needs to match the strings in all.lang for 2.06

Every time someone adds new words to the GUI, we need matching string values.
(0010003)
Anderson   
11.01.2018 20:56   
I think it's set properly in the tdm_base01.pk4 linked in the description to Google Drive.

Did the strings in all.lang for 2.06 change?
(0010009)
nbohr1more   
13.01.2018 14:20   
"Did the strings in all.lang for 2.06 change?"

2.06 has new Graphic menu options for uncapped FPS, multi-core, and soft shadows.
They will need corresponding translation updates.
(0010010)
grayman   
13.01.2018 15:03   
@NB,

Do we have translators on record for the other languages?

They should be contacted to see if they can translate the new strings.

Is that something you can take care of?
(0010011)
nbohr1more   
13.01.2018 17:38   
I will take a look.
I was thinking that Petike was making is Slovak "2.06 ready" so I could just compare that to Anderson's work.
(0010013)
Anderson   
15.01.2018 13:05   
(Last edited: 15.01.2018 13:08)
How do I get the all.lang file for 2.06? Beta forums are closed to me.

Or you can PM me the words that need translating and I will answer.

Atm busy with real life so doing it myself would take longer. At least for the duration of this winter.

(0010014)
grayman   
15.01.2018 13:10   
I attached the current 2.06 all.lang file.
(0010015)
nbohr1more   
15.01.2018 14:09   
2.06 Beta is public:

http://forums.thedarkmod.com/topic/19162-beta-testing-206/
(0010019)
Anderson   
15.01.2018 15:11   
Thanks!

I will do my best, but I can't guarantee anything at least until February.
(0010020)
Anderson   
19.01.2018 15:46   
Sorry, messed up the file name on upload but I revised the characters to exclude all broken cedillas and umlauts.

Could you tell me the string numbers for the graphics options you've mentioned?
(0010027)
grayman   
23.01.2018 14:45   
These are the new strings I added for the new graphics features.

They're available starting with yesterday's 2.06 package build.

    // Strings required for new 2.06 features (grayman 0004736)
    "#str_02930" "Player Field of View"
    "#str_02931" "Soft Shadow Quality"
    "#str_02932" "Multi Core Enhancement"
    "#str_02933" "Uncap FPS"
    "#str_02934" "HUD Size/Opacity"

    // Strings for inventory grid
    "#str_02935" "Inventory Grid"

    "#str_02940" "Total:"
    "#str_02941" "Jewels:"
    "#str_02942" "Goods:"
(0010031)
Anderson   
23.01.2018 15:46   
Can you upload the new file here with these strings here?
Thank you in advance.
(0010032)
grayman   
23.01.2018 15:48   
Done
(0010037)
Anderson   
24.01.2018 07:46   
Also done.
(0010040)
nbohr1more   
25.01.2018 04:37   
Rev 15153 Skina's Russian fixes
Rev 15154 Anderson's Romanian fixes
(0010041)
nbohr1more   
25.01.2018 07:19   
Rev 15155 more language fixes and Petike the Taffer's Slovak
(0010042)
nbohr1more   
25.01.2018 07:50   
15156 Russian Unicode to CP1251 fix
(0010054)
grayman   
14.03.2018 19:12   
(Last edited: 14.03.2018 19:12)
@NB:

I'm trying to get my head around these language changes.

When you submitted Russian, Romanian, and Slovak *.lang files, had you added their strings into all.lang, and then used Tels' program to automatically create the 3 *.lang files?

Or did these guys create free-standing *.lang files and you submitted them as is, w/o transferring their contents to all.lang first, and then using the process?

(0010056)
nbohr1more   
15.03.2018 00:44   
(Last edited: 15.03.2018 00:45)
I copied the (specific, eg. just russian, etc) lang data from the all.lang to it's own document then used compare in Notepad++ to see where the all.lang differed from russian.lang (etc) and updated the child lang files to include additional translation strings.

Where there was no translation for some of the new strings, I used google translate then copied the result into an Cyrillic converter and then finally into the child lang file.

All tedious manual work.

The script would be great if it worked instead of creating a sheet of question marks (due to unrecognized characters).

(0010057)
grayman   
15.03.2018 01:03   
(Last edited: 15.03.2018 01:05)
So it looks like we have to remove those three languages from the perl script and instead of creating the individual files automatically, we have to maintain them manually.

Right?

I'll need to do this, revert the 3 individual files I submitted as part of 15157, and add the single missing line (#str_07221) in each of the 3 files that 15157 is adding. It won't be translated, but at least it'll be present.

(0010058)
nbohr1more   
15.03.2018 01:06   
Sounds like it. Unless Obsttorte has any better idea.

Thanks.
(0010059)
grayman   
15.03.2018 01:07   
Is it just Russian I need to handle this way?

I don't see the question marks in Romanian or Slovak.
(0010060)
grayman   
15.03.2018 01:09   
You mean if Obs has a better idea along the lines of fixing the perl script?
(0010061)
nbohr1more   
15.03.2018 01:15   
I think russian is the biggest problem. Romanian we just need to watch out for those strange "a" characters that keep coming back somehow. (Probably because I just took Anderson's romanian.lang and didn't backport the changes to all.lang.)

Obs seems to know language stuff pretty well. He always gets into the threads.
(0010064)
grayman   
15.03.2018 16:12   
@NB:

I just submitted russian.

Rev 15164.

Can you see if what I did was correct?

I commented the russian section in gen_lang.pl and all.lang, and changed russian.lang by hand.
(0010065)
nbohr1more   
16.03.2018 00:27   
(Last edited: 16.03.2018 01:53)
Looks good to me.

At least as good as what I had, except I'm gonna fix a few character issues in Romanian...

Revision 15165

Russian resolution settings fix

Revision 15166

(0010066)
grayman   
16.03.2018 12:49   
Two bad things:

1 - I can't simply comment out the Russian section in all.lang. The syntax inside the section doesn't allow for block comments (/* -> */). I had to delete the entire section to get gen_lang.pl to run.

2 - gen_lang.pl corrupts the romanian.lang and slovak.lang output files.

So we have three languages that can't be handled by the gen_lang.pl program.
(0010067)
grayman   
16.03.2018 12:56   
I started a PM with Obs to see if he can help with the script.
(0010405)
nbohr1more   
27.04.2018 18:18   
Rev 15193 should complete the 2.06 work.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4350 [The Dark Mod] Distribution feature N/A 10.07.2016 13:30 03.12.2020 19:04
Reporter: grayman Platform:  
Assigned To: taaaki OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.04  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Simplify Release Mechanics
Description: The TDM Release Mechanics wiki page at

http://wiki.thedarkmod.com/index.php?title=TDM_Release_Mechanics

has a list of instructions for preparing a release for publication.

Atm, it requires a lot of typing of individual commands, and making a mistake can mess things up and require starting over.

It would be much nicer if these instructions were converted to a shell script that could be fed either the release number ("2.05") or the major and minor release numbers ("2" "5").

This script should not handle pushing to the mirrors, because some time is needed after running the script to update the mirror destinations, do any final testing, and coordinate with the update to the TDM main web site announcing the release.

Then the release process could be reduced to:

1 - building the final release

2 - running the script

3 - pushing to the mirrors
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0009790)
grayman   
14.12.2017 16:58   
Any progress on this?

Shall I move it to 2.07?
(0009960)
stgatilov   
02.01.2018 17:24   
The aforementioned wiki page should be updated a bit after 2.06, related to 0004721
(0009962)
grayman   
02.01.2018 17:42   
Perhaps the way to handle this one is to do the normal release handoff to taaaki once we're done testing, and let him update the writeup based on how he releases 2.06. Then he can close this when 2.06 is released.

He made a lot of changes in the writeup when he released 2.05.
(0012348)
stgatilov   
09.04.2020 04:45   
I assume this issue was about automating creation of a package and some release-related stuff.
According to what I saw during 2.07 and what I see on the wiki page, it is already done, and the scripts were run through "release webpage" before server issues happened.
This page is not working now, and I hope taaaki will restore it.

I suggest closing this, because it is not clear what to do here, the main job seems to be done long time ago.
Anyway, I'll move it off the 2.08 roadmap.
(0012349)
grayman   
09.04.2020 04:51   
Agreed


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4488 [The Dark Mod] GUI normal always 05.03.2017 14:20 03.12.2020 19:03
Reporter: AluminumHaste Platform: x86-64  
Assigned To: stgatilov OS: Windows  
Priority: normal OS Version: 7  
Status: resolved Product Version: TDM 2.05  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version:  
Summary: Image previews are sometimes black
Description: Some missions shots are completely black.
Checking the console shows that it can't load previewshot_gatehouse_2014-01-29_19.24

Checked the _missionshots folder and the name is:
previewshot_gatehouse_2014-01-29_19.24.32859.jpg

The filename parsing is completing on the first period.


Tags:
Steps To Reproduce: Open TDM
Download Missions
Select Gatehouse
Click "More..." button

Screenshots show black.

Check console shows

WARNING: Couldn't load image: fms/_missionshots/previewshot_gatehouse_2014-01-29_19.24

Additional Information: The ideal fix would be a code change in filename parser, as this might affect other parts of the engine elsewhere.

Otherwise, all screenshots that were uploaded to mission database would have to be downloaded, renamed, re-uploaded.
Attached Files: screenshot.png (1,423,133 bytes) 30.07.2017 16:54
https://bugs.thedarkmod.com/file_download.php?file_id=466&type=bug
screenshot2.png (1,158,436 bytes) 02.08.2017 17:09
https://bugs.thedarkmod.com/file_download.php?file_id=467&type=bug
screenshot3.png (420,665 bytes) 02.08.2017 17:10
https://bugs.thedarkmod.com/file_download.php?file_id=468&type=bug
screenshot4.png (76,416 bytes) 02.08.2017 17:17
https://bugs.thedarkmod.com/file_download.php?file_id=469&type=bug
screenshot5.png (31,838 bytes) 02.08.2017 17:17
https://bugs.thedarkmod.com/file_download.php?file_id=470&type=bug
FIXED.png (2,081,048 bytes) 02.08.2017 19:28
https://bugs.thedarkmod.com/file_download.php?file_id=471&type=bug
Notes
(0009039)
AlexDiru   
30.07.2017 16:55   
(Last edited: 30.07.2017 16:58)
See screenshot.png for some idea of what is happening. The images are downloading from the server correctly, but not being rendered properly. Going to check some other missions where the images load correctly and see if there is any difference with what is downloaded.

Full Moon Fever works correctly, and it saves the image to same location (__missionscreenshot.temp). So it is something happening between downloading the temp page and displaying it on the GUI

Also I have a really bad keyboard which doesn't let me open the console (even with rebound keys in the config file... New one should arrive on Monday and will help debugging)

(0009040)
AlexDiru   
02.08.2017 10:21   
Got the console working with this new keyboard, wish the warning message would tell me which file it was from. But I will look at this again today
(0009041)
AlexDiru   
02.08.2017 11:54   
More progress:
https://pastebin.com/icncMgbf
Starts off with the stack of where FAILED TO LOAD IMAGE is called from

Currently debugging the Script_Set function, but not easy
(0009042)
AlexDiru   
02.08.2017 17:09   
Screenshot 2 shows the image failing to load when the extension is forced on it
Screenshot 3 shows the image failing to load when the absolute path and extension are forced on it.

Maybe it's something inside R_LoadImageProgram not liking all the periods in the filename
(0009043)
AlexDiru   
02.08.2017 17:16   
Screenshot 4 shows where the lexer is reading the filename incorrectly! We are getting there!

Screenshot 5 shows it reading correctly (from Exhumed FM)
(0009044)
AlexDiru   
02.08.2017 18:20   
R_ParseImageProgram_r calls idLexer::ReadToken twice when 'More' is pressed for The Gatehouse

Works correctly the first pass
Works incorrectly the second pass

src.buffer (\n replaced by actual newlines to increase readability)

material fms/_missionshots/previewshot_gatehouse_2014-01-29_19.24.32859 // IMPLICITLY GENERATED
{
\t{
\tblend blend
\tcolored
\tmap \"fms/_missionshots/previewshot_gatehouse_2014-01-29_19.24.32859\"
\tclamp
...

The difference is the quotes around the filename in the one that fails
ReadName is being called for the first one
ReadString is being called for the one wrapped in quotes
(0009045)
AlexDiru   
02.08.2017 19:13   
May have gotten ReadName and ReadString the wrong way around.

I have added LEXFL_ONLYSTRINGS to R_LoadImageProgram as the filename has hyphens in. This nearly solves the problem, but it's still having trouble with the extension
(0009046)
AlexDiru   
02.08.2017 19:18   
The think the next problem is DefaultFileExtension in R_LoadImage due to the periods in the files
(0009047)
AlexDiru   
02.08.2017 19:27   
I DID IT!!!

Going to clean up code and send patch

This took way longer than expected

Fix is slightly hacky though
(0009397)
nbohr1more   
05.10.2017 13:33   
Patch?
(0009509)
nbohr1more   
17.10.2017 15:14   
Ping
(0009515)
AluminumHaste   
17.10.2017 15:32   
I sent him a PM on the forums, hopefully he sees it.
(0009775)
grayman   
13.12.2017 15:10   
So we're waiting for AlexDiru to provide us his 4-month-old 'slightly hacky' patch to fix this problem?
(0009776)
AluminumHaste   
13.12.2017 15:17   
Looks like.
(0009777)
grayman   
13.12.2017 15:38   
I will look at this problem.
(0009781)
grayman   
14.12.2017 08:24   
(Last edited: 14.12.2017 08:24)
Gatehouse's preview picture filenames have a different format than those for other missions.

I.e. here's a Gatehouse picture:

previewshot_gatehouse_2014-01-29_19.23.20420.jpg

And here's one from NHAT:

previewshot_anoott_4143.jpg

If there's any number of dots before the file extension, it screws up loading the picture.

It looks like the correct fix is to fix the filenames.

(0009782)
grayman   
14.12.2017 14:47   
This problem will be fixed by changing the names of the preview pictures to remove the extraneous dots.

No point in futzing with low-level TDM code, trying to accommodate the dots.
(0012680)
stgatilov   
26.07.2020 13:45   
Indeed, we should not change the common image loading code in the engine.
Too much depends on it, and too many obstacles to make it work with bad names.

Instead, I simply added some code to sanitize screenshot filenames in svn rev 8892.
For example, here is a name of screenshot file saved for Gatehouse:
  previewshot_gatehouse_2014_01_29_19_24_32859.jpg
As you see, all dots and hyphens (and other bad chars) are replaced with underscores.

Followed by minor refactoring in svn rev 8893.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5241 [The Dark Mod] Coding normal have not tried 04.05.2020 13:38 03.12.2020 18:51
Reporter: Bikerdude Platform: PC  
Assigned To: stgatilov OS: Windows  
Priority: normal OS Version: 10  
Status: assigned Product Version: TDM 2.07  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stencil shadows not compataible with see-through textures:
Description: The two example textures I tried were -

- textures/darkmod/metal/grate/grate_mesh_seethru
- textures/darkmod/metal/grate/trans_grating01

With stencil shadows enabled, light doesn't pass through, you just get full shadows as if a non transparent surface was there.

To get them to cast shadows correctly as per the texture shape (as in through a grate with holes in it), you have to enable maps shadows.
Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files: shadowhide_2020-05-04_14.35.03.jpg (739,954 bytes) 04.05.2020 13:38
https://bugs.thedarkmod.com/file_download.php?file_id=850&type=bug
shadowhide_2020-05-04_14.35.08.jpg (491,667 bytes) 04.05.2020 13:38
https://bugs.thedarkmod.com/file_download.php?file_id=851&type=bug
Notes
(0013075)
Bikerdude   
02.12.2020 16:42   
Any ideas on what this could be? so I can try and provide some trouble shooting.
(0013086)
nbohr1more   
03.12.2020 17:08   
Stencil Shadows cannot do transparent shadows.

We could make it so that shadow maps render just for transparent objects so we would have a hybrid scenario.

We already do have a hybrid thing happening when using shadow maps because lights that are too large
for shadow maps become stencil shadows.
(0013087)
stgatilov   
03.12.2020 17:22   
Hey, guys... why me? =)
(0013088)
nbohr1more   
03.12.2020 18:10   
(Last edited: 03.12.2020 18:12)
Well... I can look at what Duzenko did for the hybrid behavior for shadow maps but I recall that you were pretty
vocal about this topic so I didn't want to do something that isn't kosher.

A while back, I speculated about using an inverted stencil mask and arranging the transparent occluders as
a light texture for a re-projection of the same lights but I think the idea was deemed too expensive (and I don't have the chops
to do it anyway).
(0013089)
Bikerdude   
03.12.2020 18:51   
Well what ever you guys come up with, I am happy to user-test it from my end.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5309 [DarkRadiant] Renderer minor have not tried 26.07.2020 20:28 03.12.2020 16:19
Reporter: orbweaver Platform:  
Assigned To: orbweaver OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.2  
    Target Version: 2.9.2  
Summary: Creating a model entity creates a "phantom light" near the world origin
Description: 1. Create a textured floor brush at the world origin (with upper surface at Z=0, and X and Y dimensions extending a reasonable distance).
2. Choose Create Entity and add a simple entity (e.g. atdm:moveable_barrel_01). The location of the entity does not matter.
3. Enter lighting preview mode.

Observe that the floor brush is now lit with a light which does not exist in the map and cannot be selected or edited. The light persists for the session, but is gone if the map is reloaded in a new session.

Hypothesis: this is something to do with the entity preview widget, maybe? A light is needed to show the preview and perhaps this light is remaining in the internal scene after the widget has closed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012727)
orbweaver   
11.08.2020 20:14   
Confirmed that the phantom light is caused by the model preview.

In ModelPreview::setupSceneGraph() we create a local scene graph with a light node, but LightNode::onInsertIntoScene() always inserts the new node into the GlobalRenderSystem (since there is no other render system to insert it into).

Since the ModelPreview is persistent (for performance reasons we don't create a new dialog for each EntityClassChooser operation, but maintain a single dialog which is hidden and shown on demand), the LightNode is never destroyed and the singleton GlobalRenderSystem maintains the light for the rest of the session.

This could be worked around by adding extra function calls to create and destroy this light node (or manually attach/detach it from the render system) each time the model preview is shown, but it really highlights the limitations of this global light list. A better long term solution is to remove the global light list and have lights submitted from the active scenegraph using RenderableCollector.
(0012744)
orbweaver   
18.08.2020 20:02   
Another manifestation of the same bug: toggling any filter, even without the model preview visible (or ever having been shown), also creates the phantom light! The call trace is as follows:

    frame #0: 0x00005555559f0c3d darkradiant`render::OpenGLRenderSystem::attachLight(this=0x000055555655f630, light=0x000055555791c1c0) at OpenGLRenderSystem.cpp:405
    frame 0000001: 0x000055555582f160 darkradiant`entity::LightNode::onInsertIntoScene(this=0x000055555791c1c0, root=0x000055555780d180) at LightNode.cpp:92
    frame 0000002: 0x0000555555a04945 darkradiant`scene::SceneGraph::insert(this=0x0000555557890560, node=std::__shared_ptr<scene::INode, 4>::element_type @ 0x000055555791d7a8) at SceneGraph.cpp:126
    frame 0000003: 0x00007ffff51dde95 libscenegraph-2.8.1.so`scene::InstanceSubgraphWalker::pre(this=0x00007fffffffc9a0, node=std::__shared_ptr<scene::INode, 4>::element_type @ 0x000055555791d7a8) at InstanceWalkers.cpp:17
    frame 0000004: 0x00007ffff51efb6a libscenegraph-2.8.1.so`scene::Node::traverse(this=0x000055555791c1c0, visitor=0x00007fffffffc9a0) at Node.cpp:234
    frame 0000005: 0x00007ffff51efe8f libscenegraph-2.8.1.so`scene::Node::onChildAdded(this=0x000055555780d180, child=std::__shared_ptr<scene::INode, 4>::element_type @ 0x000055555791d7a8) at Node.cpp:276
    frame 0000006: 0x00007ffff51e082f libscenegraph-2.8.1.so`scene::TraversableNodeSet::append(this=0x000055555780d1b0, node=std::__shared_ptr<scene::INode, 4>::element_type @ 0x000055555791d7a8) at TraversableNodeSet.cpp:116
    frame 0000007: 0x00007ffff51ef743 libscenegraph-2.8.1.so`scene::Node::addChildNode(this=0x000055555780d180, node=std::__shared_ptr<scene::INode, 4>::element_type @ 0x000055555791d7a8) at Node.cpp:175
    frame #8: 0x00007ffff4ecaca1 libwxutil-2.8.1.so`wxutil::ModelPreview::setupSceneGraph(this=0x00005555574a63e0) at ModelPreview.cpp:110
    frame 0000009: 0x00007ffff4ef2425 libwxutil-2.8.1.so`wxutil::RenderPreview::getScene(this=0x00005555574a63e0) at RenderPreview.cpp:263
  * frame 0000010: 0x00007ffff4ef1e8e libwxutil-2.8.1.so`wxutil::RenderPreview::filtersChanged(this=0x00005555574a63e0) at RenderPreview.cpp:171

The simple act of calling filtersChanged(), which happens in response to any filter being activated or deactivated, re-initialises the lighting in the preview scene and attaches the preview light to the shader system. The end result is that lighting can visibly change in response to toggling a filter.
(0013080)
orbweaver   
02.12.2020 21:15   
As of commit 4309d9e9f421c84361d3968f583b1936dffb61f5 the lighting system has been refactored so that lights are not inserted straight into the render backend, but instead collected by traversing the scene with the frontend. This fixes the phantom light problem.
(0013085)
greebo   
03.12.2020 15:31   
Just merged your master branch into mine


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5108 [DarkRadiant] Saving and loading feature N/A 05.01.2020 13:54 03.12.2020 15:32
Reporter: Dragofer Platform:  
Assigned To: greebo OS: Windows  
Priority: low OS Version: 10  
Status: resolved Product Version: 2.6.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.2  
    Target Version: 2.9.2  
Summary: Allow DR to open .maps that are inside .pk4s
Description: I often want to look at other people's maps to see how they did something, or what's causing a bug while I'm betatesting.

However, I'm not aware of any way to open a .map in DR while it's still in its .pk4 archive, so I need to extract the archive or just the maps folder first.

I think it'd be a neat little feature if, after clicking on 'Open', I could double-click on the .pk4s to see & open the maps that are inside.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012085)
greebo   
06.01.2020 04:30   
Tough one, because the file picker is used as delivered by Windows/Linux/macOS which don't support opening the PK4 files.
I already wanted to have such a feature myself, so unless I have some enlightening idea it's going to be a separate "Open Map from PK4" dialog.

I also wanted to have a "Repo Browser" feature some time in the past, where I can browse the file structure as the game is perceiving it, where one can see the folders and select files to see which PK4 or folder they are defined in.
(0012098)
Dragofer   
06.01.2020 22:48   
'Open map from .pk4' would already be perfect. It's just a small thing, so it shouldn't become a complicated project just to get this.

A repro browser sounds interesting, but so far it's already helped to see where materials are defined.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5436 [DarkRadiant] GUI feature always 29.11.2020 22:36 03.12.2020 15:32
Reporter: grayman Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.2  
    Target Version: 2.9.2  
Summary: Feature request: User control of font size of "size" numbers on ortho screen
Description: See this thread.

https://forums.thedarkmod.com/index.php?/topic/20670-size-of-size-text-in-dr/&tab=comments#elControls_453827_menu
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: texts.png (40,692 bytes) 02.12.2020 15:39
https://bugs.thedarkmod.com/file_download.php?file_id=958&type=bug
2020-12-03 15_50_01-unnamed.map.png (34,087 bytes) 03.12.2020 14:51
https://bugs.thedarkmod.com/file_download.php?file_id=959&type=bug
Notes
(0013068)
greebo   
02.12.2020 14:41   
Do you need separate control over the font sizes used for the grid text and the size info text? Or should both use the same size?
(0013070)
grayman   
02.12.2020 15:16   
If, by "grid text", you mean the x/y/z coordinates at the upper-left-hand corner of the selected objects, then yes, because they don't scale either.

The same user-controlled setting could be used for both.

Thanks.
(0013071)
greebo   
02.12.2020 15:39   
By grid text I meant the grid coordinates at the left/upper boundary of the orthos, by "size info text" I meant the extents of the selected objects, see the attached image:
(0013079)
grayman   
02.12.2020 18:11   
The numbers in red are what I'd like to adjust.

The grid text could use it too
(0013082)
greebo   
03.12.2020 13:45   
Ok, gotcha
(0013083)
greebo   
03.12.2020 14:51   
The preference setting can be found here:
(0013084)
grayman   
03.12.2020 15:00   
Thanks!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5216 [The Dark Mod] Script/Def normal always 14.04.2020 14:19 03.12.2020 04:35
Reporter: Bikerdude Platform: PC  
Assigned To: nbohr1more OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: SVN  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version: TDM 2.09  
Summary: atdm:lamp_wall_gasflame03_lit - playing lit sound when extinguished/unlit
Description: I did a search in an export of all the bug trackers and didnt find anything with 'gasflame'. As I could have sworn this got fixed ages ago..?
Tags:
Steps To Reproduce: 1. load up any map with this entity in
2. douse it with a water arrow or set as 'extinguished' '1'
3. player cant still hear the gas sound
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files:
Notes
(0012366)
Bikerdude   
16.04.2020 16:10   
This has been broken since 2.0.
(0012473)
Bikerdude   
07.05.2020 12:25   
I have tried finding a work around for this, but got nowhere.
(0012806)
Bikerdude   
09.10.2020 21:15   
Can someone point me where I need to look to try and resolve this..?
(0012813)
Dragofer   
10.10.2020 09:20   
The entity is set up in tdm_lights_static_gas.def. Probably a problem with the snd spawnargs not being correctly set.
(0012814)
Bikerdude   
10.10.2020 09:43   
Thanks, I will have a look and post back.
(0013069)
Bikerdude   
02.12.2020 14:57   
I found and fixed the issue -

1. the entity 'atdm:lamp_wall_gasflame03_unlit' had sound args incorrectly added, that should have been added to the attached flame entity.
2. I added the missing sound args and lowered the volume of the 'light_gasflame' entity.

-----------------------------------------

// Fixed gasflame03 entity - this need to replace the exiting section 'tdm_lights_static_gas.def' starting on line 109 //

entityDef atdm:lamp_wall_gasflame03_unlit
{
    "inherit" "atdm:torch_wall"
    "model" "models/darkmod/lights/extinguishable/wall_gaslight03.lwo"
     "editor_displayFolder" "Lights/Model Lights, Static/Switchable/Gas/"
    "editor_usage" "An unlit wall-mounted gas lamp with an open top. "

    "extinguished" "1"
    "noshadows_lit" "1" // turn off shadow when lit
    "noshadows" "1" // lit, so has no shadows

    "light_center" "-1 0 7"
    "editor_setKeyValue light_center" "-1 0 7"

    "def_attach" "light_gasflame_unlit"
    "pos_attach" "flame" // At the attach point called "flame"...
    "attach_pos_name_1" "flame" // ... which is defined here.
    "name_attach" "flame" // Give it a name to pass along spawnargs
    "attach_pos_origin_1" "-1 0 7.5" // Offset the flame

    "skin" "lights/gaslight_brass_unlit"
    "skin_lit" "lights/gaslight_brass"
    "skin_unlit" "lights/gaslight_brass_unlit"
    "texture" "lights/biground1"
}


entityDef atdm:lamp_wall_gasflame03_lit
{
    "inherit" "atdm:lamp_wall_gasflame03_unlit"
    "editor_displayFolder" "Lights/Model Lights, Static/Gas"
    "editor_usage" "A lit wall-mounted gas lamp with an open top. Can be put out with water arrows."
    
    "def_attach" "light_gasflame"
    "pos_attach" "flame" // At the attach point called "flame"...
    "attach_pos_name_1" "flame" // ... which is defined here.
    "name_attach" "flame" // Give it a name to pass along spawnargs
    "attach_pos_origin_1" "-1 0 7.5" // Offset the flame
    "extinguished" "0"
    "skin" "lights/gaslight_brass"

}

// Fixed light_gasflame entity - this need to replace the exiting section in 'tdm_lights.def" starting on line 866 //

entitydef light_gasflame
{
    "inherit" "light_extinguishable"

    "editor_usage" "Static extinguishable candle flame with attached glow. (Light origin does not move to simulate flickering)"
    "editor_displayFolder" "Lights/Light Sources/Candle Flames"

    "mins" "-1 -1 -2"
    "maxs" "1 1 2"

    "model_lit" "tdm_fire_candle.prt"
    "model_extinguished" "tdm_smoke_candleout.prt"
    
    "falloff" "0"
    "texture" "lights/biground_candleflicker_shadow"
    "_color" "0.80 0.6 0.23"
    "light_radius" "230 230 210"

    "snd_lit" "gaslight"
    "snd_extinguished" "tdm_candle_extinguish"
    
    "s_volume" "-15"

    "sr_radius_4" "5"
    "sr_magnitude_4" "0.1"
    
    "should_be_vert" "1"
    
    "canBeBlownOut" "1"
    "editor_setKeyValue canBeBlownOut" "1"
}

--------------------------------------------------------

Can someone on the team please confirm and commit please.
(0013072)
nbohr1more   
02.12.2020 15:56   
Ill try to review this tonight
(0013073)
Bikerdude   
02.12.2020 16:40   
Grand.
(0013081)
nbohr1more   
03.12.2020 04:34   
Rev 16028

I decreased the audio -10

-15 made it so you had to be right up against the lamp to hear it.

My understanding is that the audio should clue the player about how the light works from a distance.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5239 [The Dark Mod] Graphics normal have not tried 03.05.2020 11:12 02.12.2020 17:31
Reporter: cabalistic Platform:  
Assigned To: cabalistic OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.10  
Summary: Reflection probes support in the engine
Description: Currently, setting up cubemap reflections in materials is a rather tedious and manual process for mappers. To support this feature better and make it more convenient to use, I propose to borrow the concept of reflection probes as utilized by e.g. Unity or Godot: mappers can reflection probe entities in their map, which the engine can then use to automatically capture cubemaps from those positions on command. Materials can be defined to use reflection probes, in which case the engine will auto-assign them cubemaps from reflection probes in their vicinity (either the nearest or possibly a blend of any relevant probe).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012638)
stgatilov   
28.06.2020 07:06   
It is supposed to add one more stage of dmap process?
Like what runParticle does for particle collisions (although I did not integrate it into dmap yet).
(0012639)
cabalistic   
28.06.2020 07:15   
It will definitely need an in-engine command to generate reflection maps at all "probe" positions. I guess it would make sense to make that part of dmap eventually?
(0012640)
stgatilov   
28.06.2020 08:19   
Yes, dmap looks like the best place, otherwise mappers will have to do some manual steps.

You can do it like it works with runAAS and runParticle: create a new compiler tool, and after some time integrate it into dmap (like AAS).
(0013078)
nbohr1more   
02.12.2020 17:30   
(Last edited: 02.12.2020 17:31)
RBDOOM-3-BFG has made some new progress on the Probes branch:

https://github.com/id-Software/DOOM-3-BFG/compare/master...RobertBeckebans:497-light-probe-interpolation

Autospawn env probes in the center of BSP areas:

https://github.com/RobertBeckebans/RBDOOM-3-BFG/commit/2498a171494404e01f049c334e61e5ecdfb8f0c3


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2642 [The Dark Mod] Coding feature N/A 20.02.2011 18:04 02.12.2020 16:52
Reporter: tels Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 1.04  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add multiple particles to func_emitter
Description: We have StaticMulti to present multiple func statics as one model to the rendered, but we lack a way to do the same for particles.

Particle emitters cannot be "combined" into a rendermodel, but we should at least be able to store all models and their offset in one entity, then present them all to the renderer, instead of having to have multiple entities with one particle for each.

This would help in cases like fog (multiple floating fog particles), leaves or foliage (hundreds of trees with particle leaves, or flower patches), or f.i. a grand city view with dozend of chimney smoke stacks.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0003618)
tels   
20.02.2011 18:36   
A first stab of this has been implemented with revision 0004618. Multiple particle models can be set with "modelSUFFIX" like "model_2" and positioned with the corrosponding offset spawnarg (relative to entity origin).

LOD changes only happen for the first model, and there are some issues with Save()/Restore() which need sorting out. But otherwise it works.
(0003646)
tels   
23.02.2011 17:16   
The code has been restructured to not use so much memory if there are no additional models (keep only 1 instead of 3 lists, only put additional models into it, not the base model etc.). Also each model has a flags field (so we later can selectively hide them), and the Save/Restore code is much more complete now.

The code can now also distinguish between "is the same as the original model" (which should get full LOD treatment) and "is not the same", which should only pay attention to the hide_distance.

Also two script events have been added:

* emitterGetNumModels()
* emitterAddModels(modelName, modeloffset)

Things to do:

* removeModel()
* script events for removeModel() and getModelOffset(), getModelAtOffset()?
* LOD thinking for the individual involved models
(0013057)
stgatilov   
30.11.2020 12:33   
I would say most of the cases listed in issue description can be implemented using "particle deform" system:
  fog (multiple floating fog particles)
  leaves or foliage (hundreds of trees with particle leaves, or flower patches)

Things like this cannot, since exact emit positions are important:
  a grand city view with dozens of chimney smoke stacks
Although it is dangerous to combine particle systems across large distance into one entity, since they will loose individual bounding box checks and will always be rendered.

One way to achieve it is using smoke particles + script, but:
  1) There is only one global smoke particle system in game (no idea why).
  2) The limit: <= 10000 particle at any time.
  3) Is stateful, so not very good for performance. Plus same problem about one bounding box for all.

In principle, it is possible to add something like idSmokeParticles, but with following differences:
1) can exist in many instances
2) particles are stateless like in particle models, emission is tied to some fixed array of locations/orientations (aka static entities).
3) each emission location should have many particles, not just one.

I think the best idea would be taking idRenderModelPrt.
It can be extended to store array of origin+axis locations.
Then in idRenderModelPrt::InstantiateDynamicModel: if this array exists, then treat each of its elements as individual particle system.
If the array does not exist, assume that it has one element with identity location (which would work as usual).

No idea how to fill the array though.
I guess it should be some code in SEED.cpp or near that.
(0013058)
stgatilov   
30.11.2020 12:34   
Anyway, it is not part of refactoring, so removing child-parent relation.
The refactoring should have made it easy to write yet-another particle system use case if needed (adding to the three that we already have).
(0013076)
Bikerdude   
02.12.2020 16:48   
@stgatilov, on this subject, is there a way to show how particles are being rendered on-screen (so we can see how close to the 10000 limit we are etc)
(0013077)
stgatilov   
02.12.2020 16:52   
I don't think there is.
Anyway, the limit only applies to smoke particles, which are used very rarely.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4287 [The Dark Mod] Mapping minor always 13.02.2016 19:34 02.12.2020 16:43
Reporter: Spooks Platform:  
Assigned To: Dragofer OS:  
Priority: low OS Version:  
Status: assigned Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: metal_safe prefab has a broken door
Description: The metal_safe.pfb prefab door can't seem to activate its set_target_frobable target consistently, resulting in an odd pattern where items in the safe will be frobable on odd opens but not on even ones.
Tags:
Steps To Reproduce: Import furniture/misc/metal_safe.pfb
Open door in-game, note how crown, key and note are frobable.
Close door, then re-open. Note how crown, key and note are not frobable.
Additional Information: When the door closes it does not seem to trigger the target_set_frobable entity - you can frob items through the safe walls at that point.
Attached Files: safe01.pfbx (115,832 bytes) 01.12.2020 13:33
https://bugs.thedarkmod.com/file_download.php?file_id=957&type=bug
Notes
(0008042)
Spooks   
14.02.2016 11:35   
Looking over it today and the prefab's door doesn't have trigger_on_close set to 1. Trivial severity.
(0010198)
user81   
28.03.2018 09:36   
I think is the safe I created, so will fix and add download link.
(0011042)
user81   
22.12.2018 10:06   
@nbohr, does this still need looking at..? if so assign back.
(0013052)
Bikerdude   
30.11.2020 10:12   
I assume this still needs fixing..?
(0013060)
nbohr1more   
30.11.2020 13:53   
Yes please Biker :)
(0013062)
Bikerdude   
01.12.2020 13:33   
Here you go.
(0013063)
nbohr1more   
01.12.2020 15:57   
Thank you!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5384 [The Dark Mod] Sound normal always 08.11.2020 18:52 02.12.2020 16:41
Reporter: Bikerdude Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Broken sound shader: water_medium_running
Description: I have a number of looping speakers setup in TPW and all the ones with "water_medium_running" are playing for a few minutes and then cutting out.

I have attached a screenshot of an example speaker.
Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files: Capture.JPG (29,301 bytes) 08.11.2020 18:52
https://bugs.thedarkmod.com/file_download.php?file_id=919&type=bug
Notes
(0013065)
Bikerdude   
01.12.2020 17:41   
Any ideas on what this could be? so I can try and provide some trouble shooting.
(0013074)
Bikerdude   
02.12.2020 16:41   
Bump


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5437 [The Dark Mod] Graphics feature N/A 30.11.2020 10:07 02.12.2020 05:51
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Particles: static collision with "linear" mapLayout
Description: Right now only "texture" mapLayout is supported for collisionStatic feature.
It is severely limited: it can only process particles which have non-random path, i.e. their movement is fully defined by their emit location.

The "linear" mapLayout should model all particles across several consecutive cycles, and precompute their collisions.
It exploits determinism of PRNG and is suitable for all particles, including randomly moving ones (snow, flame, etc).
It can also be used for particle models ("texture" layout is only usable with particle deform).
Tags:
Steps To Reproduce:
Additional Information: Original proposal:
  https://forums.thedarkmod.com/index.php?/topic/20235-proposal-for-particle-collision/
Attached Files:
Notes
(0013067)
stgatilov   
02.12.2020 05:50   
(Last edited: 02.12.2020 05:51)
This is partly done in:
  r9020. Implemented "mapLayout linear" for particle collisions.
  r9019. Added "diversityPeriod" property to particle stage declarations.
However, right now it only works for "particle deform" systems.
For more popular "particle models" it is not implemented yet.

In order to use it, several properties must be defined in particle stage:
  collisionStatic 1
    Needed to trigger any collisions --- obviously =)
  mapLayour linear
    Specifies that collisions are precomputed for every possible particle trajectory.
  diversityPeriod K
    Says that every K-th cycle of the system looks exactly the same.
    This limits number of possible particle trajectories, making it possible to inspect them all beforehand.
  collisionStaticTimeSteps T
    In order to find first collision, the particle trajectory is approximated with a polyline having N segments in it.
    This is not needed/ignored if particle stage is such that every particle travels along straight line (without any randomness or curving).

Suppose that particle system has N particles in total (recall that "count" is multiplied by surface area or number of triangles for particle deform systems).
Then the cost of static collisions is:
  N * K texels in precomputed map
  O(N * K * T) rays to trace against world for runParticle
So numbers K and T should be kept reasonably low since performance strongly depends on it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5369 [The Dark Mod] Script/Def normal always 26.10.2020 23:01 02.12.2020 05:22
Reporter: grayman Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.08  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version: TDM 2.09  
Summary: Scripting: how to save condump
Description: I'm trying to use a script to dump the console to a file (rather than asking the player to run a condump command on the console).

I'm using the following syntax to do this:

    sys.sessionCommand("condump ws6_stats.txt"); // print statistics to file

The problem is that I see no evidence that the file gets written. I look in my mod folder (where condump files are usually written) and there's nothing there.

Does anyone know if I'm using the correct syntax?

I've used sessionCommand before with other console commands, w/o any problems.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: stats.pk4 (9,113 bytes) 26.11.2020 18:24
https://bugs.thedarkmod.com/file_download.php?file_id=951&type=bug
Notes
(0012847)
grayman   
28.10.2020 05:32   
As the fix for issue 3139, I added this line in idGameLocal::RunFrame()

ret.sessionCommand[0] = 0; // grayman 0003139 - must be cleared here, to handle the "player waiting" time

The condump sessionCommand is processed and set up to run in the background, which uses "ret" to hold the request. While the change above is needed to fix 3139, it's possible that the background request is being cleared out before it has a chance to run.

But ... commenting out the 'clear' line does NOT cause the background request to be processed. The request just disappears at some point that I was unable to track down.

Perhaps a different solution that doesn't clear the request is needed to fix 3139.

Something to look at.
(0012848)
stgatilov   
28.10.2020 06:18   
Starting from 2017, MSVC has "break when value changes" in context menu in watch.
You can set breakpoint at when the command is put into the variable (where it is lost later), then expand the watch entry to show individual characters, add such a memory breakpoint on the first character, and continue. It should break when the string is changed. Alternative approach is to do "break when value changes" on string length.
(0013017)
stgatilov   
26.11.2020 01:00   
Do you have anything like a test map?
(0013018)
grayman   
26.11.2020 01:03   
No.

I'll create one, but it will take a while.
(0013026)
grayman   
26.11.2020 18:24   
Test map attached.

The guards are friendly.

If you look at the script file, you can see the categories statistics keeps track of. You can perform actions in the map to raise the counts of many of those categories.

When you're done performing actions, press the button on the wall. The stats will be dumped to the console, and an attempt is made by the script to create a file listing the stats.

The file isn't created.

Let me know if you need more.

Thanks for looking at this.
(0013027)
stgatilov   
27.11.2020 06:59   
The reason it does not work is that sessionCommand is not an arbitrary console command.
sessionCommand only allows commands: map, devmap, died, disconnect.
Basically, this are the commands for switching map or ending game --- something you cannot do from withing game code.
(0013028)
stgatilov   
27.11.2020 07:24   
I think there is no way to execute arbitrary console commands from game script, and I bet there is a reason behind it.
The only option is to add some event like saveConDump(filename, unwrap), which would save into fms/{currentfm}/condump_{filename}.txt.
(0013030)
grayman   
27.11.2020 10:17   
Thanks for looking into this.

Is it a lot of work to provide "saveConDump(filename, unwrap)"?

Worst case is there's no support for what I'd like to do. I can point the player at this solution (which I have not yet tried):

https://forums.thedarkmod.com/index.php?/topic/20596-beta-testing-ws6-baleford-museum/page/3/#elControls_453529_menu
(0013031)
grayman   
27.11.2020 10:24   
"The reason it does not work is that sessionCommand is not an arbitrary console command.
sessionCommand only allows commands: map, devmap, died, disconnect. Basically, this are the commands for switching map or ending game --- something you cannot do from withing game code."

Is this note:

https://wiki.thedarkmod.com/index.php?title=Calling_Console_Commands_From_SDK

an appropriate place to comment about these limitations, so that someone in the future doesn't fall into the same hole I did? I incorrectly inferred that all console commands were supported.

Thanks.
(0013034)
stgatilov   
27.11.2020 11:52   
Yes, the wiki article says any console command should work.
But it is definitely not so. Better fix it.

I think it wouldn't be hard to implement the new script event.
Although I'd probably add some some basic limitations on filename string and number of times executed during single TDM run.
(0013036)
grayman   
27.11.2020 12:27   
Why a limitation? Performance impact when run?

The script would take a single snapshot automatically at mission end, and the player can then read the results at his convenience. There's no requirement or interest in multiple invocations.

Unless you're imagining a broader scope for what your changes would provide.
(0013037)
stgatilov   
27.11.2020 13:52   
Done svn rev 8991.

The new event is called "saveConDump", called like this:
  sys.saveConDump("missionstats");
Unlike the normal condump, it saves the dump file into the current FM directory.
Dump is always in "unwrap" mode, since I don't see why the other mode could be better.

The filename is truncated to 20 characters.
Allowed characters are Latin letters, digits, and underscore (all the others are replaced with underscores).
If filename is empty, it is replaced with "default".
The file is saved at path: fms/{currentfm}/condump_{filename}.txt
The condump_ is force-prepended, because otherwise script could potentially overwrite e.g. darkmod.txt, which is too bad.

Only 100 condumps are allowed while TDM executable is running.
101-th and later calls will issue warning and do nothing.
(0013038)
grayman   
27.11.2020 14:42   
Works beautifully!

One request, though. There's a "clear" console command that clears out everything currently dumped to the console. It would be nice if all the (meaningless) lines prior to the stats dump could be erased before dumping stats to the file.

Note my use of this line just prior to dumping, in stats.script:

    sys.sessionCommand("clear"); // clear the console to make way for the stat report

That was when I thought sessionCommand() was a general feature.

Thanks!
(0013039)
grayman   
27.11.2020 14:46   
Does the 20-char limit apply to this string:

"filename"

or this string:

"condump_{filename}"
(0013040)
stgatilov   
27.11.2020 15:29   
The 20-char limit is for the argument you pass, condump_ is prepended later.

Won't clearing the game console at arbitrary moments lose potentially helpful debug information?
Everything starting from the version and machine characteristics and ending with all the warnings/errors gets lost just because mapper decided to call clear at wrong moment?...
(0013041)
stgatilov   
27.11.2020 15:31   
On the other hand, there is qconsole.log, which includes warnings/errors but does not include version/hardware info.
And players rarely enable it.
(0013042)
grayman   
27.11.2020 16:43   
"Won't clearing the game console at arbitrary moments lose potentially helpful debug information?
Everything starting from the version and machine characteristics and ending with all the warnings/errors gets lost just because mapper decided to call clear at wrong moment?..."

This happens once, at the end of the mission. The only danger is that something bad is happening at the end of the mission, and the log gets wiped out, taking with it important information.

I'm not so worried about this. Players like to know their stats, and this is the only way I can provide that information. I was just trying to provide it in a neat and succinct way, w/o the clutter of X minutes of logging prior to the mission end.

When we get to 2.09 beta testing, and WS{6/7/8} beta testing restarts, we can start with the version w/o clearing, and see if people are fine with the extra verbage. If so, we skip the clear request.
(0013044)
grayman   
27.11.2020 21:01   
Rather than building the "clear" request into the sys.saveConDump() function, can it be created as a separate request?

That way we give the player the ability to comment out a separate "clear" request line in the script, in case we need to get from him a dump of lines prior to the sys.saveConDump() line.
(0013045)
stgatilov   
28.11.2020 03:47   
Maybe I should add one more logfile specifically for script?
And some function like xprintln?
(0013051)
stgatilov   
30.11.2020 08:05   
I added second argument in svn rev 9007.
If it is not empty, then it is the "marker line", before which everything is removed.

Here is the sample usage:
    sys.println("(WS6 Mission Stats)");
    ...
    sys.saveConDump("missionstats", "(WS6 Mission Stats)");

P.S. I'm sorry for delay.
But I really don't like this "feature". To me it looks like a hack which better be avoided =(
(0013054)
grayman   
30.11.2020 11:08   
What do you object to?

1. The creation of the file that the player can read afterward?

2. The overloading of the console mechanism to provide the file?

3. The "break" line prior to which console information is flushed from the file?
(0013059)
stgatilov   
30.11.2020 12:46   
I think to p.1.
The rest are just the issues following from it.

Also it is clear that this particular case surfaced because you do NOT want to display statistics but DO want to display them at the same time.
(0013061)
grayman   
30.11.2020 16:55   
Well, I see no difference between TDM dumping info useful to devs and TDM dumping info useful to players. Of course, I'd prefer a more elegant solution along the lines of what greebo did for campaigns, where the author can create a readable document in the following mission that gives stats produced during the previous mission. But that option doesn't present itself here.

So let's leave your work in place and see how the beta testers react to what we're offering. Stat-readers seem to be adamant that they want their stats. Perhaps they'll be placated with even a "hacky" offering. If I can talk them out of requiring the stats in any form, then I'd be glad to dump the option. (I didn't plan to give them _anything_ until one of my current testers mentioned that some players would be pissed.) And the presentation of the story--in my mind--overrides the need to present fancy screens of info and sounds, etc. .


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5349 [The Dark Mod] Coding tweak N/A 01.10.2020 05:03 01.12.2020 17:44
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.08  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version: TDM 2.09  
Summary: Implement priorities and checksums for FM download mirrors.
Description: Some mirror owners can't handle too much traffic.
It's better to choose random mirror according to weights specified in downloaded XML.

Another thing is that downloader should verify checksum if XML file contains it.

BTW, probably makes sense implement weighting in tdm_installer too.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012866)
stgatilov   
08.11.2020 04:12   
Here is how the XML looks now:

<tdm>
<availableMissions>
<mission id="146" title="A Good Neighbor" releaseDate="2020-03-08" size="81.3" version="2" internalName="good" type="single" author="Amadeus">
<downloadLocation language="English" url="http://www.southquarter.com/tdm/fms/good.pk4" />
<downloadLocation language="English" url="http://bloodgate.com/mirrors/tdm/fms/good.pk4" />
<downloadLocation language="English" url="http://darkmod.taaaki.za.net/fms/good.pk4" />
<downloadLocation language="English" url="http://www.fidcal.com/darkuser/missions/good.pk4" />
</mission>
<mission id="101" title="A House of Locked Secrets" releaseDate="2015-05-29" size="195.6" version="1" internalName="ahouseoflockedsecrets" type="multi" author="Moonbo">
<downloadLocation language="English" url="http://www.southquarter.com/tdm/fms/ahouseoflockedsecrets.pk4" />
<downloadLocation language="English" url="http://darkmod.taaaki.za.net/fms/ahouseoflockedsecrets.pk4" />
<downloadLocation language="English" url="http://www.fidcal.com/darkuser/missions/ahouseoflockedsecrets.pk4" />
<downloadLocation language="English" url="http://bloodgate.com/mirrors/tdm/fms/ahouseoflockedsecrets.pk4" />
</mission>
<mission id="117" title="A Matter of Hours" releaseDate="2017-04-28" size="1.3" version="1" internalName="matterofhours" type="single" author="Springheel">
<downloadLocation language="English" url="http://www.fidcal.com/darkuser/missions/matterofhours.pk4" />
<downloadLocation language="English" url="http://darkmod.taaaki.za.net/fms/matterofhours.pk4" />
<downloadLocation language="English" url="http://www.southquarter.com/tdm/fms/matterofhours.pk4" />
<downloadLocation language="English" url="http://www.mindplaces.com/save/matterofhours.pk4" />
<downloadLocation language="English" url="http://bloodgate.com/mirrors/tdm/fms/matterofhours.pk4" />
</mission>
<mission id="147" title="A Night Of Loot: One Man's Treasure" releaseDate="2020-06-13" size="3.9" version="1" internalName="anol" type="single" author="OGDA">
<downloadLocation language="English" url="http://darkmod.taaaki.za.net/fms/anol.pk4" />
<downloadLocation language="English" url="http://www.fidcal.com/darkuser/missions/anol.pk4" />
<downloadLocation language="English" url="http://www.southquarter.com/tdm/fms/anol.pk4" />
<downloadLocation language="English" url="http://bloodgate.com/mirrors/tdm/pub/pk4/fms/anol.pk4" />
</mission>
<mission id="52" title="A Night to Remember" releaseDate="2011-10-31" size="33" version="2" internalName="antr" type="single" author="Fieldmedic">
<downloadLocation language="English" url="http://darkmod.taaaki.za.net/fms/antr.pk4" />
<downloadLocation language="English" url="http://www.fidcal.com/darkuser/missions/antr.pk4" />
<downloadLocation language="English" url="http://www.southquarter.com/tdm/fms/antr.pk4" />
<downloadLocation language="English" url="http://bloodgate.com/mirrors/tdm/fms/antr.pk4" />
<localisationPack url="http://www.fidcal.com/darkuser/missions/antr_l10n.pk4" />
<localisationPack url="http://bloodgate.com/mirrors/tdm/fms/antr_l10n.pk4" />
<localisationPack url="http://darkmod.taaaki.za.net/fms/antr_l10n.pk4" />
</mission>
...
(0012867)
stgatilov   
08.11.2020 04:13   
The most appropriate fix would be to add "weight" attribute to "downloadLocation: and "localizationPack". Then:
1) The old TDM versions would ignore it if it is present.
2) The new TDM versions can have a default weight of "1.0" if it is not set.
So the change would be fully compatible both ways.

(0012919)
stgatilov   
14.11.2020 04:12   
Committed in svn rev 8977.

Among several provided URLs, the probability to choose a particular one is proportional to its weight.
The syntax for adding weights is like this:
  <downloadLocation language="English" weight="0.1" url="http://bloodgate.com/mirrors/tdm/fms/good.pk4" />
If weight is not specified, then it gets default unit value (i.e. 1.0).

Note that it won't have effect until someone updates missionlist.xml on server.
See also this discussion:
  https://forums.thedarkmod.com/index.php?/topic/20624-store-missions-archive-in-svn/
(0013066)
stgatilov   
01.12.2020 17:44   
Implemented reading and verifying "sha256" attribute of download links (if it is present).
In svn commits 9022 & 16023.

If checksum does not match, then custom error message is shown (downloaded file is deleted immediately).
If attribute is not set, then it is not checked.
Normally the whole process is silent.

I use unoptimized implementation of SHA256 and compute it on-the-fly.
I believe that since download speed is anyway much slower than sha256 computation, computing hash in curl write callback should not increase wall time of download.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5398 [The Dark Mod] Textures normal always 11.11.2020 14:28 01.12.2020 17:40
Reporter: Bikerdude Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Broken texture: utility_grate_001
Description: A few of Epifire's models use this texture and it both is broken in DR and in-game
Tags:
Steps To Reproduce: The following textures appear to be missing -

- diffusemap textures/goldwell_custom/mesh
- bumpmap textures/goldwell_custom/mesh_local
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files: Capture.JPG (143,798 bytes) 11.11.2020 14:28
https://bugs.thedarkmod.com/file_download.php?file_id=932&type=bug
Notes
(0012896)
Bikerdude   
11.11.2020 14:30   
replacing the whole mater def to the following fixed for me in TPW -

utility_grate_001
{
    metal
    
    {blend diffusemap
    map textures/darkmod/metal/grate/grate_rusted_mesh
    alphatest .5
    red .6
    green .8
    blue 1
    }

    bumpmap textures/darkmod/metal/grate/grate_rusted_mesh_local

    {
        if ( parm11 > 0 )
        blend gl_dst_color, gl_one
        map _white
        rgb 0.40 * parm11
    }
    {
        if ( parm11 > 0 )
        blend add
        map textures/darkmod/metal/grate/grate_rusted_mesh
        rgb 0.15 * parm11
    }

    // TDM Ambient Method Related
    {
        if (global5 == 1)
        blend add
        map textures/darkmod/metal/grate/grate_rusted_mesh
        scale 1, 1
        red global2
        green global3
        blue global4
    }
}
(0013064)
Bikerdude   
01.12.2020 17:40   
@nbohr1more, as you seem to be monitoring the trackers atm, this is an easy fix if you guys want to use my above workaround.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5138 [The Dark Mod] Coding normal N/A 01.02.2020 05:35 30.11.2020 12:34
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version: TDM 2.09  
Summary: Refactor particle systems code
Description: Currently particle systems code is split across files:
  ParticleDecl.cpp --- some common code
  tr_deform.cpp --- emitting surfaces only
  Model_prt.cpp --- particle models only
  ParticleCollisionStatic.cpp --- offline tool for computing collisions (new)
Now the problem is: I have to duplicate some code in ParticleCollisionStatic.cpp.
To support "mapLayout linear" I will have to duplicate much more unless some refactoring happens.

The idea is to factor all the common code into a new file.
ParticleDecl.cpp will be only for reading/parsing decl files, all the particle-modelling code will be called from the new file.
The code for emitting particles from tr_deform.cpp and Model_prt.cpp will be moved to new file too. That's the main thing: allow to reuse emitting logic of both cases.

Things to keep in mind during refactoring:
1) Split particle origin computation into several pieces, in order to fix bounds computation (0005136).
2) Use structs and functions instead of classes and methods. This way it would be possible to compile the same code with GLSL in future.
Tags: particle
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013011)
nbohr1more   
22.11.2020 17:06   
I added 0002642 to this issue as it relates to the particle system design.

That said, I also did this to highlight the fact that the "SEED system" is basically like a large scale particle emitter and would
benefit from the same things that a particle system would ( geometry instancing, transform feedback, etc).

There is probably a decent amount of code duplication between SEED and the particle system and the render backend
with the whole "ModelGenerator.cpp code in the Game section of the project.
(0013053)
stgatilov   
30.11.2020 10:47   
Forum post:
  https://forums.thedarkmod.com/index.php?/topic/20656-particle-systems-refactoring-and-running-on-gpu/
(0013056)
stgatilov   
30.11.2020 12:18   
Well, the refactoring is finished.
It started with preliminary commits 9008-9010, followed by main changes in 9011-9018.

Now almost everything is moved to ParticleSystem.[h/cpp].
Note that ParticleSystem_[def/decl].h are considered to be parts of these files.
These parts has some basic GLSL compatibility, making it possible to run this code on GPU (not sure if it is worth it though).

The code in C-style, passing structs with raw around.
All the functions are named idParticle_XxxYyyZzz and never access any global state: all inputs and outputs are explicitly marked.
As the result of refactoring, the duplicate code is deduplicated =)
Also, some parts of the computation are split into subparts for better resuse.

Here are some notable changes:
1) Random seed for each particle is now computed by hash function of its index and other quantitites, instead of "stepping random" paradigm (see 0003161).
2) Randomizer for particle deform system is now computed from model name/surface index instead of its coordinates (see 0004132).
3) Bounding boxes are fixed (see 0005136).
4) Added check for image size mismatch.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5136 [The Dark Mod] Graphics major sometimes 01.02.2020 05:11 30.11.2020 12:10
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version: TDM 2.09  
Summary: Wrong bounds of particle system
Description: The code for computing bounds of particle systems is wrong.
This can lead to culling out the whole system randomly.
Tags: particle
Steps To Reproduce: Start test_raincollision dev FM and look at the section with curved rain patch.
If you look down, it will disappear
Additional Information: There are two ways to use particle system in our engine:
1) particle model: set "model" with .prt extension on entity
2) particle-emitting surface: set "particle deform" on a material and put it on some surface
Some of the code is reused.

In the first case, bounds are computed for every particle stage but setting particle system to standard orientation and sampling 1000 random particles. Note that this is done once per every particle stage, so it does not take much time.
In the second case bounds depend on surface geometry. This is the stupid piece of code which is doing this now:
  tri->bounds.AddBounds(particleSystem->bounds);
Where particleSystem->bounds is the bounds of particle stage.

I think even code for particle model is not correct in presence of gravity and worldAxis.
For the code for surfaces is something which bears no relation to reality =)
Attached Files:
Notes
(0012162)
stgatilov   
01.02.2020 05:13   
In rev 8547, I committed a small fix.
It is intended to simplify rain testing, since it does not take gravity and worldAxis into account.
Enabled by r_tempFixBoundsOfParticleDeformedSurfs cvar.

The same idea with interval math can be extended to all cases, but for that to happen it is necessary to compute several different bounds for particle stage, not just one.
Most importantly, I mean: bounds with gravity, and bounds without gravity.
I hope to do this during particle code refactoring.
(0013055)
stgatilov   
30.11.2020 12:09   
Done in svn rev 9012, as a part of major particle refactoring (0005138).

The previous code was wrong by trying to precompute the bounds of the final particle locations, with all the world-space effects applied (like worldGravity and worldAxis).
As the result, such precomputed bounds were not usable with any other entity orientation, not to say they were not applicable to particle deforms.

Now only "standard bounds" are precomputed by particle sampling (saved in particle stage), which exclude gravity and worldAxis postprocessing (EstimateBoundsStdSys).
They are computed in "particle emission coordinate system", which should be multiplied by origin/axis from idParticleData and by entity axis to transform into world space.

From these standard bounds, some provably correct bounds can be computed for entity in any orientation pretty fast (GetStageBoundsModel).
Even bounds of particle deform systems is now computed correctly, by combining bounds on emit location/orientation (AnalyzeSurfaceEmitter) and standard bounds (GetStageBoundsDeform).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4957 [The Dark Mod] Feature proposal feature N/A 12.01.2019 09:39 30.11.2020 10:07
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.07  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.08  
    Target Version: TDM 2.08  
Summary: Snow and rain particles stopping on brushes
Description: Original post by Goldwell:
  http://forums.thedarkmod.com/topic/19793-208-major-changes/#entry432359

Currently rain and snow particles fail through everything on their way. It is possible to make them stop/hit at desired place, but it is tedious.

This issue is to investigate the possibility of better rain/snow system which would automatically stop its particles on hitting brushes (and maybe even models).
Tags: particle
Steps To Reproduce:
Additional Information: More recent discussion on dev forums:
  https://forums.thedarkmod.com/index.php?/topic/20235-proposal-for-particle-collision/
Basically, there is a lengthy design document about intended way of dealing with the problem.
Attached Files:
Notes
(0011325)
stgatilov   
12.01.2019 09:42   
I have no idea yet how particle system works in the code.
But I'm pretty sure that all particles are modeled completely on CPU. Then it should be straightforward to add collision detection under some new spawnarg.

One issue to keep in mind is performance.
Collision detection is not free, and doing it for every particle every frame may be costly (and may be not --- to be found). That's why there are ideas like 1) using only brushes for collision, and 2) computing hit location once or once per 10 frames.
(0011327)
STiFU   
12.01.2019 14:52   
Theoretically, it should be possible to calculate particle lifetimes offline such that no collisions with brushes occur. I imagine something like a lookup table that maps particle spawn position to particle lifetime, which could be calculated during dmap.
(0011328)
stgatilov   
12.01.2019 15:25   
Yes, this is third optimization (even more serious one): precompute particle path depending on point in emitter area.
One graphical way to do that is to render all solid objects from above into one bitmap with depth info, then depth at each pixels says how long the particle will go.

Note that the generic solution with always checking collision produces less artefacts. It always works good, even in presence of moving objects. Every optimization applied adds artefacts in some case: rain goes through crates if only brushes are taken into account, or rain going through AI when they are moving, etc.
That's why I suggest starting with slow but correct solution, profile, and then apply optimization in order of increasing severity.
(0011331)
STiFU   
12.01.2019 16:26   
Right, good idea. There is also the option to do an offline-online hybrid, use offline data only for distant particles and accurate online calculations for close ones.
(0011339)
VanishedOne   
12.01.2019 20:52   
From what I remember of SteveL's posts on particles, 'smoke' particles in the 'world particle system' have their positions stored so that e.g. smoke trails don't follow their emitters around, but particles spawned by func_emitters don't have individual state (though the emitter does get a bounds check on map load).

http://forums.thedarkmod.com/topic/17034-trailing-particles/
http://forums.thedarkmod.com/topic/16710-particle-request-candle-smoke/page-5#entry360281

I'm not sure where particles emitted from patches come into this (http://wiki.thedarkmod.com/index.php?title=World_Particle_System indicates they're another subsystem again), though visportalling has a known effect: http://forums.thedarkmod.com/topic/11314-keeping-your-house-dry/
(0012161)
stgatilov   
01.02.2020 04:57   
Here is the chronology of events.

Duzenko did the following commits while working on the feature:
  8420, 8423, 8433, 8436
They include:
  test code to call idRenderWorld::Trace for every particle every frame --- purely experimental
  command to generate heightmap by material name (why was it implemented as a cvar?) --- now runParticle tool does the job
  new deform DFRM_RAIN and copy/pasted code --- not a good idea to leave such stuff lying around
I have reverted all of these changes in rev 8549.

Then there was a proposal in dev forums:
  https://forums.thedarkmod.com/index.php?/topic/20235-proposal-for-particle-collision/
I made a bunch of preparational commits. I guess it includes all my commits from rev 8534 to 8548.
Here are the most important ones:
  rev 8537:
    Now idImage can store image data on CPU side. This depends on "residency", which can be "graphics", "cpu" or "both".
    Also discussed on dev forums: https://forums.thedarkmod.com/index.php?/topic/20237-idimage-store-cpu-side-data/
    Rev 8546 is worth mentioning: don't reload missing texture if it is queried with nondefault filtering/clamping settings.
  rev 8540:
    Implemented idRenderWorld::TraceAll as a faster and more flexible substitute for preexisting idRenderWorld::Trace.
    I could not live without flexibility, and performance boost is also very welcome given the number of traces done.
    In rev 8541, I removed idRenderWorld::Trace code and made it call the new idRenderWorld::TraceAll instead.
    Commit 8543 adds SIMD optimization to ray-surface intersection code (it was present in Doom 3, but we did not reimplement that for x64 until now)

All the main changes come in commit 8547.
They implement enough stuff to make working rain.
(0012163)
stgatilov   
01.02.2020 07:05   
Here is what is currently implemented:

"mapLayout texture {W} {H}" --- specify texture width/height for cutoff map.
This is required for all the other features. Also it allows to specify resolution for collisionStatic precomputation.
For example: if you set take a 3000 x 3000 patch which emits particles with 1000 x 1000 mapLayout resolution, then there will be one sample precomputed per every 3 units.
"mapLayour linear" is now parsed, but not yet supported anywhere in the code.

"cutoffTimeMap {path/to/tga/image}" --- manually specify texture with particle lifetimes.
Every texel stores a ratio in range from 0.0 to 1.0. Ratio 0.0 means that particle dies immediately, 1.0 means that it lives for its whole time, 0.5 means that it dies after half of its lifetime.
Note that normally mapper should use collisionStatic keyword, and NOT use this one.
But it might be helpful for some effects if you draw this image manually.
The ratio is encoded into color as ((B/256 + G)/256 + R)/256. If you draw your own map, just use grayscale image.

"collisionStatic 1" --- enables static collisions on this type of particles.
In order to make it work, you have to run "runParticle {path/to/map/file}" after dmapping the map.
Then cutoff textures will be created in directory textures/_prt_gen/, which are loaded by game code and used in a way similar to cutoffTimeMap.

"collisionStaticWorldOnly 1" --- only collide with world geometry when precomputing collisionStatic images.
This makes precomputation much faster, since it removes all models from collision detection.
This should not be used normally. Can only be useful if normal precomputation takes too much time on your map.
(0012164)
stgatilov   
01.02.2020 07:29   
(Last edited: 01.02.2020 07:31)
The new compiler tool "runParticle" precomputes the textures for collisionStatic particle systems.

It parses .map file, then creates temporary idRenderWorld from it. The render world reads .proc file and takes "local models" from there, i.e. all surfaces produced from brushes and patches. Then we iterate over all map entities, and add some of them into our render world as blockers. The exact criterion here is quite complicated since we want to exclude everything which may move or disappear. There is a spawnarg to override this decision. Note that we have to load .def-files here in order to obtain all spawnargs including inherited ones, but we do NOT precache any media when doing so.

Now we iterate over all map entities (including world) again to find particle emitters. Only particle-emitting surfaces are supported now. Also, only brushes and patches are supported as collisionStatic emitters. For every such entity, we load its static model (in fact, it was already loaded by render world from .proc file when it loaded map), and inspect its surfaces. If you find particle emitter with collisionStatic, then we generate a cutoff map. Also, there is a way to exclude particle emitter from collisionStatic computation via spawnarg, but obviously it won't work on world geometry.

When computing cutoff texture, we inspect particle stage settings and fail if we see something unsupported. Note that "texture" layout has severe restrictions on which particles it supports. Then iterate through texels of the future map, for each texel find a triangle which uses it and cast a ray through each texel. The hit is recorded into image buffer, which is finally saved into TGA image.
A few thing to note here:
1) Emitting surface should have texture coordinates [0..1] x [0..1]. Coordinates out of this range are not supported, and using smaller range would be a waste of storage.
2) Each texel must belong to exactly one triangle (well, except for boundary effects). If half of quadratic patch uses [0..1] x [0..1] texture area, and the other half uses the same area again, then the tool will break.
3) Since dmap splits a large patch into many surfaces (one surface per area), the tool actually computes and saves only a rectangular part of the whole map. It takes bounding box of vertices' texcoords, and saves the minimum subregion of the texture which covers it.
As for ray tracing, there are some builtin rules which cannot be overriden: ignore particle emitters, ignore dynamic models (e.g. md5), hit only solid & water contents.

When the game is running and a particle-emitting surface with collisionStatic flag is processed by the renderer, some special things happen.
First of all, it loads the texture as CPU-resident idImage. The path is hardcoded and contains the following info: entity name, surface index, and particle stage index. Note that there is nowhere to store this texture, so it is reloaded every frame. I.e. "globalImages->ImageFromFile" is called every frame, but internally it finds the loaded image and returns it without doing anything. Of course, the tweak with bounding box of vertices' texcoords is replicated here exactly as in the precomputing tool.
Then this image is sampled on CPU side with nearest filtering and clamping. This is the obvious part. If there is cutoffTimeMap in particle declaration, then it is used instead.

Overriding spawnargs are:
  particle_collision_static_blocker {0 or 1} --- force-exclude or force-include this entity as blocker in particle collision precomputation
  particle_collision_static_emitter 0 --- exclude all particle-emitting surfaces of this entity from particle collision precomputation

(0012171)
stgatilov   
02.02.2020 16:05   
A bunch of minor post-fixes:

r8548 Fixed crash if cutoff texture is not found.
r8550 Check mapLayout when cutoffTimeMap is set explicitly. If it is not "texture" with matching dimensions, then the map is dropped.
r8551 runParticle now complains about "mapLayout linear" and about "worldAxis".
r8554 Ignore dynamic models properly in runParticle tool.
(0012176)
stgatilov   
03.02.2020 17:23   
(Last edited: 03.02.2020 17:44)
More commits: 8561 and 8562.
Now collisionStatic images are preloaded when idRenderWorld reads .proc file (i.e. at map load time).
Also it fixes compatiblity with com_smp, although explicitly set cutoffTimeMap still does not work (see 0005141)

UPDATE: And commits 8563 and 8564 fixing the mess I recently made with latest commits =(

(0012583)
stgatilov   
01.06.2020 17:30   
A minor update due to Goldwell's feedback here:
  https://forums.thedarkmod.com/index.php?/topic/20291-beta-testing-208/&do=findComment&comment=447857

Hence, two changes:
svn rev 8746: now mapper can set "particle_collision_static_blocker 2" to force all surfaces of the entity to be blockers, regardless of their material or dynamic model
svn rev 8747: surfaces with "deform turbulent" material are no longer ignored as blockers --- this deform only changes texcoords.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5427 [The Dark Mod] Graphics normal N/A 22.11.2020 11:24 30.11.2020 05:11
Reporter: STiFU Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Move Frob-Highlight to GLSL
Description: Currently, material stages are used to implement frob-highlight, which was a neccessity back when we didn't have access to the engine source-code.

This method has various drawbacks:
-Writing the frob-highlight stage is easily forgotten -> Errorprone
-Frob-Highlight stage can be incorrect -> Errorprone
-Obfuscates/clutters up material definition

Moving to a GLSL shader avoids these issues and also opens the door for different types of frob-Highlight, as the simple ambient increase also has its drawbacks (you cannot see the frob highlight well in strongly lit areas).
Tags:
Steps To Reproduce:
Additional Information: After moving frob highlight to GLSL, we should also remove the frob-highlight stage from all existing materials and change the wiki accordingly.
Attached Files:
Notes
(0013050)
nbohr1more   
30.11.2020 05:11   
If the current highlight behavior is retained during the move to GLSL, we should make sure that SSAO is multiplied
to the result. The current highlight overrides SSAO shading in most cases.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5245 [The Dark Mod] Models normal have not tried 07.05.2020 12:23 30.11.2020 03:58
Reporter: Bikerdude Platform: PC  
Assigned To: Dragofer OS: Windows  
Priority: normal OS Version: 10  
Status: assigned Product Version: TDM 2.07  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Broken prefab: chest_old_loot1
Description: The chest is not pick-able and is missing a few arg's compared to the chest_metal prefab (that is pick-able)
Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files: chest_old_loot1.pfbx (10,251 bytes) 29.11.2020 22:05
https://bugs.thedarkmod.com/file_download.php?file_id=956&type=bug
Notes
(0012807)
Bikerdude   
09.10.2020 21:18   
Would it be helpfull if I fixed the prefab and added a link here..?
(0013047)
nbohr1more   
29.11.2020 20:14   
Yes please!

I am pretty sure that prefabs don't count as part of asset search when loading TDM in general so this should not affect existing missions.
(0013048)
Bikerdude   
29.11.2020 22:05   
Tested in-game, lid is now pickable.
(0013049)
nbohr1more   
30.11.2020 03:58   
Assigned to Dragofer to quality check and commit to SVN


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5435 [The Dark Mod] Textures normal always 29.11.2020 19:55 29.11.2020 19:55
Reporter: Bikerdude Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Broken texture: textures/darkmod/decals/dirt/scorch_flatbottom
Description: This decal texture isn't showing in-game.
Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5434 [The Dark Mod] Design/Coding normal sometimes 29.11.2020 16:14 29.11.2020 16:17
Reporter: MirceaKitsune Platform: x64  
Assigned To: OS: Linux openSUSE  
Priority: normal OS Version: Release  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when copying to clipboard: IA__gtk_check_menu_item_set_active / GTK_IS_CHECK_MENU_ITEM
Description: Sometimes when copying several entities and / or brushes, by shift-drag selecting them then pressing Control + C, DarkRadiant will crash. I posted the console output in the Additional Information field... it seems to be a bad assertion by IA__gtk_check_menu_item_set_active for GTK_IS_CHECK_MENU_ITEM, could be related to the Linux version exclusively.
Tags: Crash, Freeze, gtk
Steps To Reproduce: Select a lot of entities and brushes at once and use Ctrl + C to copy them. The crash should occur at that moment.
Additional Information: Gtk-Message: 18:08:13.955: Failed to load module "appmenu-gtk-module"

(darkradiant:5381): Gtk-CRITICAL **: 18:08:14.366: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed

(darkradiant:5381): Gtk-CRITICAL **: 18:08:14.366: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed

(darkradiant:5381): Gtk-CRITICAL **: 18:08:14.366: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed

(darkradiant:5381): Gtk-CRITICAL **: 18:08:14.366: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed

(darkradiant:5381): Gtk-CRITICAL **: 18:08:14.366: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed
The program 'darkradiant' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 68088 error_code 3 request_code 18 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
System Description
Attached Files:
Notes
(0013046)
MirceaKitsune   
29.11.2020 16:17   
Please move this to the DarkRadiant project: For some reason Mantis changed the active project on me while I was posting this, despite clicking the report button with DR selected... it got posted into the TheDarkMod project instead. I tried to edit the issue but I can't change the project of the issue any more.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5433 [The Dark Mod] Coding normal random 27.11.2020 18:36 27.11.2020 18:43
Reporter: duzenko Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: SVN  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Random crash when dynamically loading textures
Description: Navigating to a new location in game triggered this crash

Tags:
Steps To Reproduce:
Additional Information: Approx view org: (-1785 367 -60)

image.imgName: tdm_beggar_sleeves

image.loadStack: attached as screenshot

Stack trace

     [Inline Frame] TheDarkModx64NoTools.exe!idHashIndex::First(const int) Line 226 C++
     TheDarkModx64NoTools.exe!idDict::FindKey(const char * key=0x00007ff704bb645c) Line 446 C++
     [Inline Frame] TheDarkModx64NoTools.exe!idDict::GetString(const char *) Line 230 C++
     TheDarkModx64NoTools.exe!LoadStack::Level::Print(int indent) Line 89 C++
     TheDarkModx64NoTools.exe!LoadStack::PrintStack(int indent=2, const LoadStack::Level & addLastLevel={...}) Line 64 C++
> TheDarkModx64NoTools.exe!R_UploadImageData(idImage & image={...}) Line 1264 C++
     TheDarkModx64NoTools.exe!idImage::Bind() Line 1417 C++
     TheDarkModx64NoTools.exe!RB_BindVariableStageImage(const textureStage_t * texture, const float * shaderRegisters) Line 607 C++
     TheDarkModx64NoTools.exe!RB_STD_T_RenderShaderPasses_OldStage(const shaderStage_t * pStage=0x000001e752b48c30, const drawSurf_s * surf=0x000001e7329c3080) Line 523 C++
     TheDarkModx64NoTools.exe!RB_STD_T_RenderShaderPasses(const drawSurf_s * surf=0x000001e7329c3080) Line 836 C++
     TheDarkModx64NoTools.exe!RB_STD_DrawShaderPasses(drawSurf_s * * drawSurfs=0x000001e732970a50, int numDrawSurfs=64) Line 942 C++
     TheDarkModx64NoTools.exe!RB_STD_DrawView() Line 1282 C++
     TheDarkModx64NoTools.exe!RB_DrawView() Line 1143 C++
     TheDarkModx64NoTools.exe!RB_ExecuteBackEndCommands(const emptyCommand_t * cmds=0x000001e7329d9180) Line 832 C++
     TheDarkModx64NoTools.exe!R_IssueRenderCommands(frameData_t * frameData=0x00007ff705fdb240) Line 142 C++
     TheDarkModx64NoTools.exe!idRenderSystemLocal::EndFrame(int * frontEndMsec=0x0000000000000000, int * backEndMsec=0x0000000000000000) Line 641 C++
     TheDarkModx64NoTools.exe!idSessionLocal::UpdateScreen(bool outOfSequence) Line 2759 C++
     TheDarkModx64NoTools.exe!idCommonLocal::Frame() Line 2544 C++
     TheDarkModx64NoTools.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance=0x0000000000000000, char * lpCmdLine=0x000001e725565727, int nCmdShow=0) Line 1321 C++
     [External Code]
System Description
Attached Files: image.png (49,506 bytes) 27.11.2020 18:36
https://bugs.thedarkmod.com/file_download.php?file_id=955&type=bug
Notes
(0013043)
duzenko   
27.11.2020 18:43   
Can't reproduce but can see the error in console: couldn't load image and a stack printout


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5432 [The Dark Mod] Graphics minor sometimes 27.11.2020 18:23 27.11.2020 18:23
Reporter: duzenko Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: SVN  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Pink plates
Description: Some plates look pink
Tags:
Steps To Reproduce: Map: Briarwood Cathedral

setviewpos -1397.62 -83.38 204.25 9.5 163.2 0.0
Additional Information:
System Description
Attached Files: image.png (1,982,631 bytes) 27.11.2020 18:23
https://bugs.thedarkmod.com/file_download.php?file_id=954&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5431 [DarkRadiant] GUI normal always 26.11.2020 21:18 27.11.2020 12:09
Reporter: Bikerdude Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: confirmed Product Version: 2.7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Windows not properly repainted after resize
Description: If you resize any of the child windows (layers, arbitrary transform, surface inspector), the contents of the windows get corrupted Instead of moving and resizing as normal when you resize the window .
Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files: 2.9.2pre1_child_windows corruption.JPG (46,874 bytes) 26.11.2020 21:18
https://bugs.thedarkmod.com/file_download.php?file_id=952&type=bug
dr_2.7.0_resize.gif (735,765 bytes) 27.11.2020 11:36
https://bugs.thedarkmod.com/file_download.php?file_id=953&type=bug
Notes
(0013029)
greebo   
27.11.2020 07:44   
It appears this is a problem related to wxWidgets 3.1.3, since this is happening even in DarkRadiant 2.7.0.
In DR 2.6.0, which had been using wx 3.0.x, this problem is not occurring.
(0013032)
Bikerdude   
27.11.2020 11:24   
(Last edited: 27.11.2020 11:24)
In previous versions of DR the issue would only 'crush' the UI elements from the side/edge of the window being moved, for example if resizing from the bottom. But As soon and you make the window larger e.g. by dragging said side/edge down the crushed elements would go back to the correct size.

This is not happening in 2.9.2pre1, the UI elements stay partially crushed or mangled. and the only fix is to fully reduce size down so its only showing the header and then open again, and even then this take a few attempts.

And a bit more troubleshooting is showing the issue only happens vertically, not horizontally.
(0013033)
greebo   
27.11.2020 11:36   
This is what DR 2.7.0 does on my system
(0013035)
Bikerdude   
27.11.2020 12:09   
I am getting old as I dont remember 2.7 ever being that bad on my system. But sure enough its the same as in your gif -

- https://youtu.be/3u9cz0MpBtE


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5097 [DarkRadiant] GUI normal always 02.01.2020 15:13 26.11.2020 15:11
Reporter: Bikerdude Platform: PC  
Assigned To: greebo OS: Windows  
Priority: normal OS Version: 8.1  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.2  
    Target Version: 2.9.2  
Summary: Layer toggle controls can get out of sync (showing wrong icons)
Description: Where the button after being clicked on will remove the tick mark, but will show blue on the button.
Tags: layers window
Steps To Reproduce: Open DR -

- Use DR normally for while (so far longer than 2 hrs)
- Open the layers window,
- click on any of the layers buttons to hide or show a layer,
- the layer will hide and show as normal -

The issue -

- the color of the button WILL toggle off/on (so the layer is being hidden/revealed etc)
- but the tick will continue to be shown.
Additional Information: - only work around is to close and re-open layers window.
System Description i7-4790k, GTX1080Ti
Attached Files: layers child window.JPG (221,151 bytes) 02.01.2020 15:13
https://bugs.thedarkmod.com/file_download.php?file_id=783&type=bug
Capture.JPG (71,387 bytes) 19.11.2020 15:33
https://bugs.thedarkmod.com/file_download.php?file_id=949&type=bug
Notes
(0012468)
Bikerdude   
05.05.2020 15:42   
The only work around is to close and reopen the layers window.
(0012804)
Bikerdude   
09.10.2020 21:11   
Dont know if this is fixable, but this is still happening.
(0012857)
Bikerdude   
03.11.2020 12:31   
The work around is to close and re-open the effect window.
(0012874)
Bikerdude   
08.11.2020 20:03   
Still happening, regular as clockwork in 2.8
(0012885)
Bikerdude   
10.11.2020 09:39   
Is related to 005391
(0012907)
Bikerdude   
13.11.2020 16:52   
@Greebo, do you think this is also linked or related to the 'wxToggleButton' function somehow..?
(0012967)
Bikerdude   
17.11.2020 15:39   
Will test and see if this issue got resolved in 2.9pre3 as a result of the fix implemented in 0005391
(0012984)
Bikerdude   
18.11.2020 12:00   
Still preset in 2.9pre3.
(0012987)
greebo   
19.11.2020 03:38   
To clarify, the behaviour is that the layer is hidden but the tick mark is drawn on the corresponding toggle button as if it were visible?
(0012991)
Bikerdude   
19.11.2020 10:36   
(Last edited: 19.11.2020 13:50)
Hold fire for now, as I think the other layers window fix you have done for pre3 may have fixed it. I have had DR open for 2hours and so far the issue hasen't appeared.
(0012995)
Bikerdude   
19.11.2020 15:33   
Ok, so it turned out I just needed DR open for longer than 2hrs for the issue to happen again.

So in answer for your question, yes the behavior is that the layer is hidden but the tick mark is drawn on the corresponding toggle button as if it were visible. See attached, the only visible layers are default and manor_gnd.
(0012996)
Bikerdude   
19.11.2020 15:37   
I just spotted another issue related to this bug, when the above issue is happening the 'Show all' becomes un-togglable and stays grayed-out.
(0012998)
greebo   
19.11.2020 18:08   
Ok, so it seems that it's possible for the layers window to get its visual state out of sync with the state of the LayerSystem in the backend. Especially if opening and closing the dialog will fix it, because that's when the dialog will reload all its controls and sync the state with the LayerSystem.

There must be some steps leading up to that issue, do you remember doing anything special before that? Are you just clicking the toggles, or is this happening without any interaction?
Not sure if the run time plays any role, except for making the steps more likely to happen.
(0012999)
greebo   
19.11.2020 18:32   
I'll check in a change that might have an effect on this issue - maybe you can have a look at it in the next pre-release build.
(0013000)
Bikerdude   
19.11.2020 20:26   
Hi Greebo

Regarding states/steps, I am fairly sure I can just leave DR along without touching it and it will exibit the same issue. So tonight before going to bed I will load DR with a map loaded (bhm) and see whats its state is like in the morning.

And yes am more than happy to test the change with the next build.
(0013003)
Bikerdude   
20.11.2020 08:36   
Morning

So leaving DR running for 8hrs with no input didn't reproduce the issue.
(0013014)
greebo   
24.11.2020 16:45   
There's a new pre-release version (2.9.2pre2) available here, maybe you can check out if the behaviour is improved now.
https://drive.google.com/file/d/1xSFPORJp7XD_brI2B55fl-0EFXRYqAQt/view?usp=sharing
(0013015)
Bikerdude   
24.11.2020 17:01   
Downloading and will test first thing in the morning.
(0013023)
Bikerdude   
26.11.2020 10:08   
Am currently testing.
(0013024)
Bikerdude   
26.11.2020 13:40   
tested (2.9.2pre2) for a few hours this morning, and the issue hasn't recurred. So this tracker can be closed.

thanks for fixing this :-)
(0013025)
greebo   
26.11.2020 15:10   
Nice, thanks for testing


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
994 [DarkRadiant] Map Editing major N/A 22.07.2008 18:54 24.11.2020 19:53
Reporter: tels Platform:  
Assigned To: orbweaver OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Show attached (light) entities
Description: When an entity has some light or another entity attached, these are not visible in the editor. This makes it hard for mappers to see what exactly the entity represents.

The wish here would be that the attached entity/entities are drawn in dashed or dotted form, and these entities are selected together with the base entity.
Tags:
Steps To Reproduce:
Additional Information: As example see atdm:moveable_candle1
Attached Files:
Notes
(0004229)
tels   
08.01.2012 10:07   
Apparently, for lights, the combined light entites are also not rendered as lights, and it is not possible to adjust their radius/color easily, the mapper has to use the "set _color on flame" syntax manually.
(0012682)
orbweaver   
26.07.2020 20:31   
Adjusting severity to Major since while this is a feature request, it is a pretty serious limitation of the renderer and makes the lighting preview mode almost useless since no entity-based lights are actually shown as lights.
(0012722)
Judith   
11.08.2020 16:20   
(Last edited: 11.08.2020 16:24)
I think this might have something to do with the way with how these entities were made, i.e. as models with lights as attachments. In every other engine I used, lights with physical representation (model / static mesh) were always a child class of the light class itself. It was always like GeneralLightClass -> SpecificLightClass -> SpecificLightWithStaticMeshClass. In one of my TDM WIPs I made lights like that, and IIRC, they were visible in lit mode. Will check that when I have time.
(0013016)
orbweaver   
24.11.2020 19:53   
@Judith is correct — if object-based lights are children of the "light" class they should function correctly as lights in DR, and should even show the correct model if this is set as the "model" spawnarg (although they wouldn't show any additional attached objects, or particles). The problem is with non-light objects which spawn attached light entities at runtime, which are currently "invisible" to DR since it does not process attachments at all.

But for better or worse, we can't insist that the entire mod asset tree is restructured, and we need to handle this in DR somehow.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5425 [DarkRadiant] Saving and loading major N/A 22.11.2020 05:33 24.11.2020 16:28
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.2  
    Target Version: 2.9.2  
Summary: Automatic map saving can crash DarkRadiant
Description: Discussion here:
https://forums.thedarkmod.com/index.php?/topic/20647-dr-latest-build-19-crashing/
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5430 [DarkRadiant] GUI normal have not tried 23.11.2020 03:52 24.11.2020 13:39
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.2  
    Target Version: 2.9.2  
Summary: World geometry is blue and cannot be changed when no worldspawn entityDef is defined
Description: Reported here: https://forums.thedarkmod.com/index.php?/topic/20650-2d-views-geometry-is-blue-lines/

All the worldspawn brushes will fall back using the hardcoded blue-ish value <0.3 0.3 1> as wire shader when no entityDef is defined anywhere. The colour cannot be adjusted using the Colour Scheme editor, which makes mapping much harder on darker orthoview background colours.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: deep_xml_files_2.9.0.zip (5,442 bytes) 23.11.2020 03:52
https://bugs.thedarkmod.com/file_download.php?file_id=950&type=bug
Notes
(0013012)
greebo   
23.11.2020 03:53   
Attached above is a dump of the messed up colours.xml file.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5426 [DarkRadiant] Compilation/Build block always 22.11.2020 07:14 23.11.2020 11:50
Reporter: AdrianMay Platform: pc  
Assigned To: greebo OS: arch linux  
Priority: normal OS Version: rolling, now.  
Status: resolved Product Version: 2.9.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.2  
    Target Version: 2.9.2  
Summary: Can't build Radiant on current arch due to pybind breaking change
Description:
/home/ad/build/darkradiant/DarkRadiant/plugins/script/../../include/iscript.h|7 col 28| error: using typedef-name ‘using module = class pybind11::module_’ after ‘class’
|| 7 | namespace pybind11 { class module; class dict; }
|| | ^~~~~~
|| In file included from ScriptingSystem.h:5,
/usr/include/pybind11/pybind11.h|1017 col 7| note: ‘using module = class pybind11::module_’ has a previous declaration here
|| 1017 | using module = module_;
|| | ^~~~~~

Because: https://pybind11.readthedocs.io/en/stable/upgrade.html .... for pybind 2.6 ...

py::module has been renamed py::module_, but a backward compatible typedef has been included.

Tags:
Steps To Reproduce: Build Radiant on arch linux from source or from the AUR. I guess any system with pybind 2.6 will do.

Additional Information:
Attached Files:
Notes
(0013013)
AdrianMay   
23.11.2020 11:50   
Blimey that was fast. On a Sunday too. Thanks!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5429 [DarkRadiant] Design/Coding normal have not tried 22.11.2020 13:57 22.11.2020 13:59
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.2  
    Target Version: 2.9.2  
Summary: EntityClassManager vs. VirtualFileSystem initialisation order might prevent .def file parsing
Description: If the eclass module gets initialised before the VFS search paths are set by the GameManager, no files will be parsed.
Obviously this was not a problem before, but this was plain luck.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4132 [The Dark Mod] Design/Coding normal always 07.04.2015 17:14 22.11.2020 12:50
Reporter: grayman Platform:  
Assigned To: SteveL OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.03  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.04  
    Target Version: TDM 2.04  
Summary: Weather particle distribution should be more random
Description: A snow patch sometimes creates snowflakes that fall in line and descend like little soldiers shoulder-to-shoulder instead of being randomly distributed.

Rain splash patches tend to have more splash particles show up along one edge.

A small rain splash patch and a small rain patch will produce more particles than a large rain splash patch and a large rain patch.

All of which leads me to believe that particles like these are not 1 - positioned randomly or 2 - generated with a constant density across the patch.
Tags: particle
Steps To Reproduce:
Additional Information: I've never been able to change the density or randomness of a patch by changing its x/y scale.
Attached Files: rain_splash_heavy.jpg (87,750 bytes) 28.04.2015 21:04
https://bugs.thedarkmod.com/file_download.php?file_id=328&type=bug
Notes
(0007499)
SteveL   
28.04.2015 18:36   
The random number generator used by particles has a very small repeat cycle and is very naive which is enough to explain (1). But it sounds like something else is in play given the inconsistent distribution.
(0007500)
grayman   
28.04.2015 19:57   
Also, it appears that the same random numbers are applied to each patch in the same frame. If I have a set of steps and give each its own rain splash patch, you can stand at the top of the steps and, looking down, see that each patch paints the same splash in the same relative location, forming a line going down the steps.
(0007502)
SteveL   
28.04.2015 21:16   
I just attached a pic showing how easy this is to rep. It's 4 rain_splash_heavy square patches over 4 black_matt patches, seen by noclipping from above (contrast enhanced). All four including the big one have exactly the same pattern stretched across their surface, which confirms the density problem too. Changing the texture scale doesn't help.

Func emitter entities have a random "diversity" parameter which gets used as a random number seed for particle emissions, to stop them all looking like clones. Worldspawn patches are all one combined entity so can't have separate settings but it looks like they need to get an extra random number from somewhere. Maybe use one of their vert coordinates as a seed? I'm getting ahead of myself though, I'll go take a look what's going on in the code.
(0007503)
SteveL   
28.04.2015 21:58   
There's an easy workaround for the density problem. In the material def (tdm_weather.mtr), change line

deform particle2 tdm_rain_splash_heavy

to

deform particle tdm_rain_splash_heavy

There are 2 settings for weather patches in the engine, "deform particle" and "deform particle2". Deform particle2 is a variant of the original that specifically ignores the actual area of the patch when calculating particle densities. For some reason presumably lost in history, TDM weather materials have always used particle2.

It's too late to change the original def files unfortunately... mappers will probably have layered rain to get the right density.
(0007504)
SteveL   
28.04.2015 22:21   
The repetition problem has a workaround too. The weather patches are trying to use the same randomization method as func emitters, i.e. using the diversity shaderparm on the renderEntity as the random number seed. But all worldspawn patches are the same entity, so they all have the same seed. The diversity shaderparm is shaderparm5, so if you change some of your rain patches to be func_statics and set shaderparm5 to something different (range 0.0 -> 1.0), they'l stop being in sync with their neighbours.

Any ideas on how we can make both these things easier for future mappers without breaking old maps? I guess we can auto-randomize safely, but I don't have any ideas for the density problem.
(0007505)
grayman   
29.04.2015 02:00   
Using shaderparm5 fixed the problem on steps, thanks.

As for density, the best we can do is create new shaders that correct the density problem, and alert mappers of their existence. As you said, existing maps using the current shaders need to be left alone, because the mapper might have compensated for the bug, and now rely on the bug being left in place.
(0007506)
SteveL   
29.04.2015 06:40   
Assigned to myself because I think we should go ahead and randomize the patches automatically. Func emitters and func smokes already force a random shaderparm5 so weather patches can do something similar. Any given emitter needs its seed to stay constant during play, else particles would have no continuity from frame to frame, and worldspawn has nowhere to store a list of seeds, so we can use the patch vert positions in the calculation to get stable variation.

I thought of one more option for density that'd avoid duplicating the materials, but I'm not sure it'll be easier. We could make a new spawnarg for worldspawn, "weather_particle_mode" "0 (default) weather particle patterns are fit 1:1 over your patch, so a bigger patch will have less dense weather. 1 = constant density. The pattern is repeated over larger patches."
(0007568)
SteveL   
14.06.2015 18:52   
I've made an amendment that'll auto-randomize weather particles for worldspawn only, and only if the mapper hasn't set a shaderparm5 on worldspawn, using the centre point of the particle effect's bounding box as a random number seed, so adjacent patches won't look the same.
(0007583)
SteveL   
19.06.2015 18:28   
(Last edited: 19.06.2015 18:35)
Committed the random weather at rev 6508

renderer/tr_deform.cpp

(0007584)
SteveL   
19.06.2015 18:35   
I've made a separate tracker for the proposed new material definitions.
(0013010)
stgatilov   
22.11.2020 12:50   
I'm doing a major refactoring of all particle systems (0005138).

I think I'll change the way this randomizer works.
Dependence of rand seed on mesh coordinates is rather disturbing, given that I'd like to be able to exactly trace all particles in preprocessing phase for "collisionStatic" with "linear" layout.

Instead, I'll use hash of the following data:
  model name --- this includes area number for worldspawn
  surface index
  particle state index
I already have to determine all these values in order to find cutoffMap generated by offline preprocessing tool (collisionStatic feature).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5428 [The Dark Mod] Graphics feature N/A 22.11.2020 12:08 22.11.2020 12:08
Reporter: STiFU Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add a different frob-highlight for loot objects to make them better distinguishable from junk
Description: While the ultimate target is to design loot materials in such a way that they are already easily distinguishable from junk objects from a distance, a different frob highlight for loot could also help and make the game more accessible.

This should only be implemented once we have GLSL-Frob-Highlight.
Tags:
Steps To Reproduce:
Additional Information: https://forums.thedarkmod.com/index.php?/topic/20644-tips-for-finding-loot/&tab=comments#comment-453503
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3161 [The Dark Mod] Coding normal always 27.06.2012 16:02 22.11.2020 11:01
Reporter: grayman Platform:  
Assigned To: SteveL OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.03  
    Target Version: TDM 2.03  
Summary: Dousing a fireplace causes smoke to bounce
Description: When you put out a fire in a fireplace with a water arrow, the flames die, the light dies, and the dissipating smoke bounces up and down until it's gone.
Tags: particle
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0004674)
Springheel   
27.06.2012 21:36   
(Last edited: 27.06.2012 21:40)
Do you mean a flickering effect? I'm seeing that a lot lately.

I'm curious about whether there has been a change to the smoke particle.

(0004678)
grayman   
28.06.2012 02:30   
The smoke isn't flickering, it's bouncing as it dissipates, as if the particle origin is being recalculated each frame and the origin is moving up and down.
(0004680)
Springheel   
28.06.2012 20:45   
Huh. I'll have to look then. I've noticed what I would call flickering, but not bouncing.
(0007176)
SteveL   
29.11.2014 09:55   
(Last edited: 29.11.2014 14:54)
From this discussion: http://forums.thedarkmod.com/topic/16710-particle-request-candle-smoke/page__view__findpost__p__359471

There's a problem with the way the engine handles the randomizing of particles.

The engine wants to vary particles so that chimneys etc don't puff exactly in sync or exactly the same every time, but it needs to make sure that from frame to frame individual particle quads don't jump around the place randomly -- they need to appear to move smoothly. Like the rest of the renderer, it's also a stateless system -- no information is carried from one frame to the next. The way it gets to have all those qualities is that it uses a random number generator that spews out the same list of numbers for a given particle stage each frame. When a particle emitter starts up a random number sequence is initialized (seeded) using a few numbers: the particle's time offset, how many cycles it's gone through, and (optionally) shaderparm 5, which lets mappers start 2 identical particles in the same frame without them looking identical. For func emitters, the mapper doesn't have to remember to do it: the game code sets a random time offset before it passes the particle to the renderer for the first time. The starting position, path, and rotation speed of each particle quad are determined by numbers from that sequence, and then the age of the particle quad is used to determine how far along the "path" the quad is. When the next frame comes around, the parameters will be the same so the same sequence of "random" numbers gets generated and the particle quad moves smoothly.

How many of the random numbers from the sequence are used for each quad's calculations varies depending on its setup. Particles in a rectangular distribution use 3 random numbers in deciding their starting position. Particles in a cylindrical distribution use 5 for that. And aimed particles use more random numbers to work out their movements than view-aligned particles. But any given particle quad always uses the same number of random numbers each frame. So if the 11th number was used in generating "rotation speed" for a particle quad last frame, the 11th number will be used this frame too. When there are multiple quads in a particle stage (nearly always the case), the extra quads just carry on taking numbers from the same sequence. The second quad might use the 23rd number for rotation speed every frame.

The problem starts when the first particle quad dies. It stops consuming numbers from the random number generator, so suddenly quad # 2 starts to get its numbers. Quad # 2's age is still measured correctly, so it remains in approximately the right place, the right distance from the emitter, but its starting position, angle, and other characteristics are suddenly calculated from quad # 1's random number set. And quad # 3 will inherit quad # 2 old numbers, etc etc.

I'm not sure how to fix it yet. It'd be tempting to simply have the code throw away the required number of random numbers when it decides that quad # 1 doesn't need to be drawn, but it'd be unacceptable to break the "stateless" design pattern by having it remember how many numbers each quad needed last frame. Likewise it'd be unacceptable to put a list of the counts somewhere, which would mean remembering to update that list if ever we tweak the way particles are drawn.

(0007177)
SteveL   
29.11.2014 10:24   
(Last edited: 29.11.2014 10:25)
How random numbers get consumed:

= idParticleStage::CreateParticle()
--- Always consume and discard one rand
=== idParticleStage::ParticleOrigin()
----| If path is standard:
------| If distribution is random:
--------| If distribution is rectangular: Consume 3 rands
--------| If distribution is cylindrical: Consume 2 rands
--------| If distribution is spherical: Consume 3 rands
------| Else if distribution is conical: Consume 2 rands
----| Else if path is custom:
------| If path is Helix: Consume 3 rands
------| If path is Flies: Consume 4 rands
------| If path is Orbit: Consume 1 rand
------| If path is drip: 0 rands
=== idParticleStage::ParticleVerts()
----| Consume 1 rand for Angle.

ParticelVerts() calls ParticleOrigin() a second time for aimed particles, but it resets the random number sequence afterwards so that counts as 0.

(0007178)
SteveL   
29.11.2014 14:56   
(Last edited: 29.11.2014 14:56)
Fortunately, there's no need to know how the numbers are consumed, or to take account of the decision tree above. From the forum discussion:

There's no need to solve that problem, because there's no need for all the different quads in the same stage to share a random number sequence in the first place. They can each have their own sequence of random numbers. Instead of initialising the random number generators for each stage, using stage properites like time offset etc, we initialise it for each quad using those same stage properties plus the quad number! That way each quad in each stage gets a repeatable set of numbers of its own.

No repeated code, no flags to be passed to complicated functions, no need to touch any code other than the bit that sets up the random number sequence.

This will even simplify the existing setup in the engine. Right now the particle system maintains two random number sequences for each particle stage, because for looping/cycling particles there can be quads on screen from two different cycles at once, and we want successive cycles to look different. But if each quad has its own sequence, we don't need special case code for quads that happen to be in a different cycle.

There's no peformance cost for having more random number sequences. Each one is just a single number (int) that uses a fixed function to work out the next number.

(0007179)
SteveL   
29.11.2014 15:00   
At rev 6237

renderer/Model_prt.cpp
(0013009)
stgatilov   
22.11.2020 11:00   
(Last edited: 22.11.2020 11:01)
I think the easiest fix was to have:
* an outer random which is always stepped once per particle, regardless of whether it is dead or alive
* use its output to seed inner random, which is used to compute particle parameters.
I believe that's how it was done in the "particle deform" code.

Anyway, I'm now at the end of The Great Refactoring of Particle Systems (0005138), and I'm getting rid of the approach that I described just above in favor of the approach you implemented.
Basically, random seed for a particle is computed as:
  randSeed = Hash(index, particleCycle, randomizer)
Where:
  index --- index of particle
  particleCycle --- number of the cycle the particle lives through right now
  randomizer --- whatever external sources of randomness (aka diversity)
The only fun fact is that if I make hash function depend linearly on index, then I see obvious regularities in rain, so I made the dependency quadratic.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5424 [DarkRadiant] Map Editing normal unable to reproduce 21.11.2020 10:12 22.11.2020 06:48
Reporter: IZaRTaX Platform: pc  
Assigned To: greebo OS: Windows 7  
Priority: normal OS Version: x64  
Status: resolved Product Version: 2.9.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.2  
    Target Version: 2.9.2  
Summary: Up/down strafe movement not working in camera free look mode
Description: Pan camera view is broken, basically in the older version when you use the pan camera view it's CTRL+RMB and you move down and up,
here in 2.9.1 it moving backward and forward like you hit CTRL+SHIFT+RMB but inverted.

Even if I remove key mappings, put them to default it still not working.

"From the forum Greebo said everything":

2.8.0: With Ctrl held down moving the mouse left/right will pan make the camera strafe left/right, moving up/down will move the cam up/down. Holding down Ctrl+Shift moving up/down will move the camera forward/back.

2.9.0 With Ctrl held down only left/right and forward/back are working, up/down is not working.
Tags: Bug
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5422 [DarkRadiant] Saving and loading major sometimes 18.11.2020 15:35 20.11.2020 15:23
Reporter: Spooks Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.1  
    Target Version: 2.9.1  
Summary: DR freezes when saving from the "Exit DarkRadiant" dialogue
Description: The save on exit functionality is broken for me. When clicking "Save" in the "Do you want to save "mapname" before quitting?" dialogue I get an indefinite hang (the explorer dialogue doesn't show up). (Un)fortunately I can't seem to reproduce it consistently, but I'd say I get it 3/5 times.
Tags:
Steps To Reproduce: It can happen with a fresh map. Start DR, drag to make a brush, exit, click Save on the dialogue.
Additional Information: If it's hard to reproduce on others' ends I can provide a crashdump.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5096 [DarkRadiant] GUI normal random 02.01.2020 15:10 20.11.2020 09:29
Reporter: Bikerdude Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 8.1  
Status: acknowledged Product Version: 2.6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Selected objects/entites (grouped or selected) will randomly rotate about non-center pivot point, rather than on the spot,
Description: This happens with grouped models, func_static's and brush/patches or a combination of these items.
Tags: off-axis rotation
Steps To Reproduce: - Open DR
- Use DR for a while (again will need to do more testing to narrow down 'a while')
- Shift select a few items, eg brush, patch and entity for example>
- Click on the Arbitrary Transformation Window>
-- click on the axis you want to rotate.
-- and the group will rotate about a pivot point that isn't the center of the group.
- Toggling 'Rotate objects independently on/off resolves the issue, until it happens again after 'a while'
Additional Information:
System Description i7-4790k, GTX1080Ti
Attached Files: off-axis.jpg (431,464 bytes) 02.01.2020 15:10
https://bugs.thedarkmod.com/file_download.php?file_id=782&type=bug
Notes
(0012467)
Bikerdude   
05.05.2020 15:41   
This still happens in 2.08pre5 fyi.
(0012805)
Bikerdude   
09.10.2020 21:12   
(Last edited: 03.11.2020 12:32)
The only work around I have found for this is to deselect and re-select the 'rotate objects interdependently" button. This is the workaround untill it happens again, rince and repeat.
(0013004)
Bikerdude   
20.11.2020 08:37   
@Greebo, any idea's on this? or is this another one to add to the large pile of hard to resolve trackers...
(0013005)
greebo   
20.11.2020 09:28   
Thing is, those issues are hard to reproduce for me. Except for trying a little one or two minutes there's not much I can do, and if I can't repro it I can't fix it, so I pick a different issue or feature request out of the hundreds, which makes me feel more productive. I know mapping, but I'm not actively working on any map, so I never get into those situations that make the bug happen once in one or two hours of working on large maps.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5418 [The Dark Mod] AI normal N/A 17.11.2020 17:16 19.11.2020 14:40
Reporter: MirceaKitsune Platform: x64  
Assigned To: OS: Linux openSUSE  
Priority: none OS Version: Release  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: path_sleep ignores the "wait" and "wait_max" spawnargs, AI immediately stands up after laying down
Description: When the AI reaches a path_sleep entity in a path circuit, they will lay down but immediately get back up. The "wait" and "wait_max" values are completely ignored.

They work just as intended on path_sit who's functionality path_sleep follows, so I'm assuming something is wrong with path_sleep specifically. I noticed this on two different maps with different AI types and completely new path circuits so it's likely not some obscure map error either.
Tags:
Steps To Reproduce:
Additional Information: path_sleep is targeted by a path_corner and targets another path_corner. path_sleep has spawnargs "wait 10" and "wait_max 20".
System Description
Attached Files:
Notes
(0012990)
Judith   
19.11.2020 07:15   
Not a bug, wrong setup. Search for sleeping AI in TDM wiki.
(0012992)
MirceaKitsune   
19.11.2020 13:54   
I had already looked at this page before opening the report: https://wiki.thedarkmod.com/index.php?title=Path_Nodes path_sleep is only referenced once here, no special specific notes.

I looked at the one you suggested too: https://wiki.thedarkmod.com/index.php?title=Sleeping_AI It does seem to recommend targeting a path_wait with the path_sleep which I wasn't aware of.

This doesn't make a lot of sense to me still: If path_sit can directly use a "wait" and "wait_max" without having to target a path_wait, why is path_sleep different? It seems to be the same thing in terms of functionality, just that path_sleep has you lay down instead of sitting on a chair. So even if this isn't a bug like I initially thought, it still sounds like something might be out of order and good to look into... of course I don't know enough about the design to say this with certainty, opinions from other developers would be helpful here at this stage.
(0012993)
Judith   
19.11.2020 14:40   
Yup, there's a slight inconsistency, but that doesn't make it a bug. Path_waits and wait spawnargs might be worth discussing on TDM forums in terms of proposed feature or design change. You can use path_waits with path_sit and _sleep in the same way you use them with path_corners.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5107 [DarkRadiant] GUI normal always 05.01.2020 13:10 19.11.2020 05:32
Reporter: Dragofer Platform:  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: confirmed Product Version: 2.6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 'Change game/project' fails to save if a decent-sized .map was loaded
Description: If I have a sufficiently large .map loaded and then 'Change game/project' to a different FM project, then restart DR, the project setting has reverted back to what it was before.

The bug occurs 100% of the time with Perilous Refuge, but never with the smaller Rats Triumphant or a blank map.
Tags:
Steps To Reproduce: Preparation to get you in the same position as a mapper:
1) Download Perilous Refuge to your darkmod/fms folder.
2) Extract peril.pk4 to darkmod/fms/peril. You should now have darkmod/fms/peril/maps/peril.map, which DR can access.
3) Open DR and 'Change game/project' to peril.
4) Restart DR to make sure the current project is now peril.

Bug reproduction:
1) Open peril.map in DR.
2) 'Change game/project' to a different FM.
3) Restart DR. The current project is still peril.
Additional Information: Tested & confirmed in 2.6 and 2.7
Attached Files:
Notes
(0012073)
Dragofer   
05.01.2020 13:18   
Additional bug when I was isolating the cause of the above bug:
The frequent restarting and loading of my map seems to have broken something in DR's map loading.

First it became increasingly slow to load my map. After a few more restarts&reloads DR started to always crash after changing project.

I've restarted my pc and now DR hangs very long when 'loading textures', with the display in 3D view and orthoview black. Rats Triumphant loads eventually, but I lost patience with Perilous Refuge. Task manager shows DR stuck at 1588mb of RAM when loading Peril's textures.

Never seen this happen with normal use of DR.
(0012074)
Dragofer   
05.01.2020 13:33   
Additional details to my previous note: I have 8GB of RAM, and when DR stopped responding after changing project I used task manager to end the process. Maybe I've broken my user settings this way.
(0012075)
Dragofer   
05.01.2020 17:14   
Re: my notes 1 & 2: loaded up some other maps and now:
- DR 2.6 started throwing 'unhandled exception' as soon as opening a map reaches 'loading textures'.
- DR 2.7 is loading fine.

Would you like a ticket for this? The bug resulted from very atypical usage, but I have noticed before that DR starts to slow down after loading several large maps in a row.
(0012083)
greebo   
06.01.2020 04:25   
The second slowdown issue you described sounds strange, especially after you restarted your computer - it should definitely work fine after a reboot if it was caused by a memory or resource leak.

Can you try to backup your user settings and delete them? When DR settings are clean and your computer is freshly rebooted it really should just work fine, unless OS or hardware are starting to fail on your end.
(Reminds me, a button in DR clearing your user preferences, like a "reset to factory default" is maybe useful too).
(0012084)
greebo   
06.01.2020 04:27   
On a general note: it's best practice when tracking bugs to not mix them into a single report, for several reasons. Unless the two issues are *very* closely related, each should have its own entry.
(0012094)
greebo   
06.01.2020 16:19   
Investigating this mod changing problem, it appears the code is deadlocking when the DEF files are re-parsed. The ThreadedDefLoader starts parsing, notifies the EntityNode about the change, the entity refreshes its spawnargs and tries to load a model DEF, which deadlocks because the re-parsing is still in progress. The thread will sit there forever and will even prevent DR from properly shutting down since the EntityClassManager is waiting for any running parsing threads to finish before it shuts down the module.

I haven't ultimately tracked down the cause of the above problem to this deadlock, but to me it might be plausible that things are not properly switched to the new game path setup when threads are not finishing their work.
(0012989)
greebo   
19.11.2020 03:53   
An a lighter note, the problematic behaviour above has changed into a clean crash in 2.9.0.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5421 [DarkRadiant] GUI minor always 18.11.2020 13:07 19.11.2020 03:35
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: low OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version:  
Summary: Deleting multiple properties adds multiple events to undo queue
Description: It's possible to highlight multiple spawnargs in the entity inspector and right-click > cut (or now also delete) to delete them all in one go. However, pressing undo only restores one property at a time.

This makes it more difficult to get back to the state before the properties were deleted, since the mapper needs to monitor the entity inspector to ensure all properties have been restored.
Tags:
Steps To Reproduce: 1) Create an entity, i.e. a stagecoach model.
2) Select multiple spawnargs in the entity inspector and right-click > cut or delete.
3) Press ctrl - z. Only one spawnarg has been restored.
Additional Information: I haven't had a chance to test or try 2.9 yet so it's possible you've already fixed this while resolving:
0005290: [GUI] 'Delete property' is greyed out when multiple properties are selected
Attached Files:
Notes
(0012986)
greebo   
19.11.2020 03:35   
Yes, I just checked, this issue is not occurring in 2.9.0 anymore.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5290 [DarkRadiant] GUI minor N/A 10.07.2020 07:59 19.11.2020 03:34
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: 'Delete property' is greyed out when multiple properties are selected
Description: As per title, having multiple properties selected in the entity inspector will cause the 'Delete property' option in the right-click menu to become greyed out. The easy workaround is to use 'Cut' instead, but that overwrites whatever I may have in my copy/paste storage.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5389 [DarkRadiant] GUI normal have not tried 08.11.2020 21:02 18.11.2020 11:47
Reporter: Bikerdude Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: acknowledged Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: AMD/Radeon - Orthoview issue with flush brush/patch faces.
Description: Am using an RX 570 with 20.9.2 driver and am seeing a weird effect that looks like ZF with shadow/caulk and other textures
Tags:
Steps To Reproduce: - AMD - caulk/shadows textures seem to get given higher priority over other textures.

- nVidia - caulk/shadows textures get given equal priority with other textures.
Additional Information: Similar effect when far plane view is brought close to min distance, you get a horrendous mess (see last 3 attached images)
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files: dr_amd_1.JPG (58,321 bytes) 08.11.2020 21:02
https://bugs.thedarkmod.com/file_download.php?file_id=921&type=bug
dr_amd_2.JPG (43,620 bytes) 09.11.2020 10:59
https://bugs.thedarkmod.com/file_download.php?file_id=927&type=bug
dr_amd_3.JPG (102,317 bytes) 09.11.2020 10:59
https://bugs.thedarkmod.com/file_download.php?file_id=928&type=bug
dr_amd_4.JPG (96,106 bytes) 09.11.2020 10:59
https://bugs.thedarkmod.com/file_download.php?file_id=929&type=bug
amd_dr_1.8.1.JPG (465,256 bytes) 18.11.2020 10:32
https://bugs.thedarkmod.com/file_download.php?file_id=947&type=bug
amd_dr_2.0.JPG (473,944 bytes) 18.11.2020 10:32
https://bugs.thedarkmod.com/file_download.php?file_id=948&type=bug
Notes
(0012880)
Bikerdude   
09.11.2020 10:59   
(0012966)
Bikerdude   
17.11.2020 15:37   
@Greebo, would it be helpful if I sent you an AMD/ATi card?
(0012968)
greebo   
17.11.2020 18:18   
Thanks for the offer, but I don't own a desktop PC anymore. I've been using laptops for more than 10 years now.
Is this behaviour you observe something that doesn't happen in 2.8.0 or earlier?
(0012970)
Bikerdude   
17.11.2020 19:06   
It happens in 2.8 as well as 2.9, but I can test it previous versions no problem. How far back would you like me to go..?
(0012974)
greebo   
18.11.2020 02:52   
(Last edited: 18.11.2020 02:53)
I just wanted to make sure it's not something that has been introduced between 2.8.0 and the upcoming 2.9.0. I kind of prioritise regressions a bit higher than things that have been there for longer, at least right before release.

(That said, if there ever has been a version that has not been showing that problem, this info would of course be useful.)
(0012978)
Bikerdude   
18.11.2020 08:29   
Ok I will go and download all the previous versions and see if any of them DONT show this behavior.
(0012979)
Bikerdude   
18.11.2020 10:32   
(Last edited: 18.11.2020 11:47)
Went all the way back to 1.8.1, where the issue wasn't present, it only shows in 2.0 and above.

And on a sorta related note I noticed that 2.3 - 2.7 never allowed the user to choose the install folder destination, but before and after those version that functionality was available.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5420 [DarkRadiant] Map Editing crash have not tried 18.11.2020 10:57 18.11.2020 11:02
Reporter: Judith Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.1  
    Target Version: 2.9.1  
Summary: Crash when "Load last map at startup" is activated
Description: This time around the crash happens due to the OpenGLModule not having the font realised yet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5386 [DarkRadiant] GUI normal always 08.11.2020 20:22 18.11.2020 08:28
Reporter: Bikerdude Platform: PC  
Assigned To: OS: Windows  
Priority: high OS Version: 10  
Status: acknowledged Product Version: 2.8.0  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Orthoview in 2.9pre2 very laggy compared to 2.8
Description: 2.8 -
- Opened up The painters wife (large map), hide all layers bar city north and south.
- after a few seconds looking around with the mouse becomes smooth

2.9 -
- Opened up The painters wife, hide all layers bar city north and south.
- In the same section, looking around is very laggy and juddery.

Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files:
Notes
(0012876)
Bikerdude   
08.11.2020 20:26   
(Last edited: 09.11.2020 11:24)
Using the middle mouse button to move around the map is also quite bad.

nb. I have far plane clip mode disabled, due to it being impossible to use on an AMD gpu.
(0012894)
Bikerdude   
11.11.2020 10:17   
(Last edited: 13.11.2020 10:48)
Nuking the DR config folder from the "C:\Users\<username>\AppData\Roaming" does not fixe it. I have been swapping between 2.9 & 2.8 and was using 2.8 and didn't realize it.
(0012899)
Bikerdude   
13.11.2020 10:46   
Reopening as I have been flicking between 2.8 and 2.9pre2 to see if I could get to the bottom of this. While hiding layers helps, the 3D renderer in 2.9 makes DR feel like I have downgraded my graphics card to some generic pos.
(0012964)
Bikerdude   
17.11.2020 15:34   
Just in case something was tweaked, testing 2.9pre3, issue is the same.
(0012975)
greebo   
18.11.2020 03:38   
Only fired up the profiler a bit, and of course the performance is horrible since the map is huge. I couldn't spot anything in the Orthoview renderer that had been introduced just recently (since 2.8.0), so I won't do much now. For the moment being, I'll put that on the huge pile of issues tagged with "DR renderer sucks".
(0012977)
Bikerdude   
18.11.2020 08:28   
heh, ok thanks fella.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5116 [DarkRadiant] Models normal always 07.01.2020 10:09 18.11.2020 08:25
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.6.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Export patches: .ase has too many verts
Description: While re-exporting models in DR has been working fine, exporting patches as an .ase creates a model that has too many verts: so i.e. a cylinder with 32 polys will have 96 verts (each poly has 3 own verts). This doesn't seem to have any effect on ingame rendering.

The excess of verts persists when I import the model into Blender 2.79b. In the above example with the cylinder, I'm able to remove 64 verts when removing doubles.
Tags:
Steps To Reproduce: 1) Create a cylinder patch, give it ship_hull_medium as a texture and change subdivisions to 4 horizontal and 1 vertical. This shape has 34 vertices and 32 polys.
2) Select the cylinder and 'Export selected as model' with these settings

Output Format: .ase
Center objects around origin
Skip surfaces textured with caulk

The model has 3 verts for every 1 poly.
Additional Information: Tested & confirmed in 2.6, 2.7pre2, 2.7pre3
The attached archive and image also contains .lwo exports of a patch, as those are also misbehaving. (0005115)
Attached Files: export_patch.pk4 (506,808 bytes) 07.01.2020 10:09
https://bugs.thedarkmod.com/file_download.php?file_id=804&type=bug
export_patch_ase.png (114,055 bytes) 07.01.2020 10:09
https://bugs.thedarkmod.com/file_download.php?file_id=805&type=bug
export_patch_lwo.png (114,024 bytes) 07.01.2020 10:09
https://bugs.thedarkmod.com/file_download.php?file_id=806&type=bug
blender2.76.png (10,144 bytes) 17.11.2020 21:02
https://bugs.thedarkmod.com/file_download.php?file_id=943&type=bug
unknown.png (26,975 bytes) 17.11.2020 21:02
https://bugs.thedarkmod.com/file_download.php?file_id=944&type=bug
Notes
(0012444)
Bikerdude   
01.05.2020 12:49   
@Dragofer, might be worth testing this in 2.08 pre5 to see if the issue is still present
(0012965)
Bikerdude   
17.11.2020 15:36   
Is this related to 0005383?
(0012969)
Dragofer   
17.11.2020 18:40   
Not really, .ase meshes really do contain too much vertex data. This gets revealed when importing into Blender, where removing doubles gets rid of a ton of vertices (i.e. 96 gets reduced to 32).

But I think TDM has some kind of inbuilt removal of vertex doubles for .ase's, so they still look smooth ingame.
(0012971)
Bikerdude   
17.11.2020 19:07   
Ok will test it in 2.9pre3 just to see if its still present.
(0012972)
Bikerdude   
17.11.2020 21:02   
(Last edited: 17.11.2020 21:03)
I have tested this on a.ASE exported from 2.9pre3 and it looks to be fixed, as the total verts in Blender 2.76 matched what DR is showing (see attached)
(0012973)
greebo   
18.11.2020 02:50   
Yes, this should have been solved along with 0005115
(0012976)
Bikerdude   
18.11.2020 08:25   
(Last edited: 18.11.2020 08:25)
Nice work Greebo.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5372 [DarkRadiant] GUI normal random 29.10.2020 23:03 18.11.2020 04:01
Reporter: Spooks Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 2.8.0  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Orthoview brushes sometimes display as black
Description: I have the Black & Green color scheme for the orthoview grid, slightly modified. Black bg, grey grid, light green brushes, orange entities, so on. Two times now, I have started the program and opened a map only to have the "brushes" color (and only them) be "reset" to black. I put "reset" in scare quotes because I can't be sure, but I am guessing it reverts to the black of the default color scheme.
Tags:
Steps To Reproduce: I don't know how to reproduce this one reliably. A program restart fixes it.
Additional Information:
Attached Files:
Notes
(0012864)
greebo   
03.11.2020 18:00   
I can force this to happen when trying to drag a brush immediately after the orthoview is shown. Usually there is short lag in the application after startup before it accepts the newly drawn brush.
The reason is that the brush colour helper is executed during the app's idle phase, which might be just a tad to late in some scenarios. If worldspawn brushes are to be rendered before that idle event kicks in, you get the default worldspawn brush colour, which is black, as defined in its entityDef.

I can see if I can move that colour handling code to a more appropriate place which doesn't rely on the app's idle event.
(0012890)
Spooks   
11.11.2020 08:46   
2.9.0 pre2. Encountered it again. Whoops. Reopening.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5115 [DarkRadiant] Models normal always 07.01.2020 10:03 18.11.2020 02:48
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.6.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Export patches: .lwo loses smooth shading
Description: While re-exporting models in DR has been working fine, exporting patches as an .lwo creates a model that has lost smooth shading.
Polys count is a bit different than expected, i.e. a 16-sided cylinder patch with 34 vertices & 32 polys will have 34 vertices and 33 polys as an .lwo.

When I import an .lwo derived from a patch into Blender 2.79b, the model suddenly has 96 vertices (=each of the 32 faces has its own 3 vertices). Removing doubles will eliminate 64 vertices.
An .lwo derived from a model will have the correct number of vertices when imported into Blender.
Tags:
Steps To Reproduce: 1) Create a cylinder patch, give it ship_hull_medium as a texture and change subdivisions to 4 horizontal and 1 vertical. This shape has 34 vertices and 32 polys.
2) Select the cylinder and 'Export selected as model' with these settings

Output Format: .lwo
Center objects around origin
Skip surfaces textured with caulk

The model has no smooth shading ingame.
Additional Information: Tested & confirmed in 2.6, 2.7pre2, 2.7pre3
The attached archive and image also contains .ase exports of a patch, as those are also misbehaving. (0005116)
Attached Files: export_patch.jpg (140,171 bytes) 07.01.2020 10:03
https://bugs.thedarkmod.com/file_download.php?file_id=802&type=bug
export_patch.pk4 (506,808 bytes) 07.01.2020 10:03
https://bugs.thedarkmod.com/file_download.php?file_id=803&type=bug
Notes
(0012137)
Bikerdude   
12.01.2020 18:26   
This might be related to - https://bugs.thedarkmod.com/view.php?id=4767
(0012442)
Bikerdude   
01.05.2020 12:47   
(Last edited: 01.05.2020 12:56)
This issue is still happening as of the latest version of DR, 2.08 pre5

1. create a patch cylinder.
2. select export as .LWO and click 'replace with exported model' when exporting.
3. dmap/map and the exported model has lost all the smoothing.
(0012869)
Bikerdude   
08.11.2020 16:18   
(Last edited: 10.11.2020 09:38)
Nice work Greebo, this will save a lot of Blender time :-)
(0012882)
Dragofer   
09.11.2020 14:24   
Thanks! This one's highly appreciated.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5416 [DarkRadiant] Map Editing normal sometimes 16.11.2020 20:15 17.11.2020 18:17
Reporter: MirceaKitsune Platform: x64  
Assigned To: OS: Linux openSUSE  
Priority: low OS Version: Release  
Status: acknowledged Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Surface Inspector: Random offsets are sometimes assigned to faces when using Natural
Description: The issue occurs when selecting one or more brushes or faces, opening up the Surface Inspector, then clicking the Natural button under Modify Texture; Every now and then the textures are given an unpredictable offset. This happens even if you draw a simple cube brush, no diagonal edges or faces.

I just drew a brush to confirm this: After clicking Natural 3 times with the whole brush selected, all of its faces were given the offset H = 113, V = 14.
Tags:
Steps To Reproduce: Select one or more brushes or faces. Press S to open the Surface Inspector. Click the Natural button multiple times: Most of the time the vertical / horizontal offset will be correctly set to 0, 0... sometimes however, a random offset that makes no sense is given to the faces in cause.
Additional Information: Additionally, the Normalize button next to Natural doesn't seem to do anything in any circumstance and might be broken too. I'm not sure if this is related or another issue, I included it here as it seems related and I'd rather not open another issue for everything.
System Description
Attached Files: Screenshot_20201117_152403.png (148,305 bytes) 17.11.2020 13:36
https://bugs.thedarkmod.com/file_download.php?file_id=941&type=bug
user.xml (11,015 bytes) 17.11.2020 13:48
https://bugs.thedarkmod.com/file_download.php?file_id=942&type=bug
Notes
(0012956)
greebo   
17.11.2020 04:21   
Hm. Can't seem to be able to reproduce this. For me the values always stay at 0, I must have clicked a hundred times in various situations by now.
Maybe you can record it, or send me a sample map and tell me your steps?
(0012957)
MirceaKitsune   
17.11.2020 13:36   
(Last edited: 17.11.2020 13:39)
That's very odd. Could it be build specific, or perhaps tied to a preference? This might make it harder to debug since I'm not sure what on my system might be triggering it.

There doesn't seem to be any map that needs sending: I just opened up DR, drew a brush, selected it or one of its faces, then after clicking Natural 3 times I got the offsets (sometimes it takes more tries).

Here's a screenshot for now. The values you see in the surface inspector weren't input by me: They appeared after i clicked the Natural button a few times.

One thing I just noticed and can add: Whenever this happens on a brush, the offsets being set are apparently always the same. Like for the brush in the screenshot attached, the offset is either 0, 0 (what it should be) or (when the issue occurs) 101, 14... it doesn't matter which face I select either, the same bad offsets are randomly applied to any face I naturalize on that brush. If I draw another brush nearby and repeat the process on it, that brush also gets the same weird values, 101 with 14 here... same if I do it on multiple brushes, start a new map, restart DR, use a different texture on the brush, or pick a different grid size while doing it, also enabling or disabling texture lock doesn't influence it. On a larger and more complex map I'm working on, the only thing that changes is the values of those odd offsets, they seem to differ a bit but otherwise it's always the same thing.
(0012958)
greebo   
17.11.2020 13:47   
I notice that you haven't enabled the Texture Lock, something I cannot imagine is useful all the time.
Still, I cannot reproduce the behaviour, I event entered the same values in the entry boxes as you.

On a more general note, I'm not sure where the actual problem is. "Natural" is not even trying to create a 0,0 shift to the faces, it's mean to restore the scale as defined in the entry box, no other guarantees are given.
Also, what's the real-life benefit/loss of this behaviour, even if it was actually producing 0,0? Hitting "Natural" will never give you the final result for any brush you want to texture in a real map, you'll always end up manipulating the texturing in more steps after that, either by the mouse texture copy/paste, or fine-tuning shift, scale and rotation, or in the Texture Tool.
(0012959)
MirceaKitsune   
17.11.2020 13:48   
In case it might be preference related, here's my user.xml as well if it's somehow helpful.
(0012960)
MirceaKitsune   
17.11.2020 13:54   
I only enable Texture Lock when moving prefabs, for brushes with textures that loop fine I prefer leaving it off so offsets stay at 0 or a specific bump I set them to in just one direction.

I usually use Natural to reset the scale of faces to the default and clear any offsets. I thought that's what it's supposed to do, though I can imagine its technical meaning might be a little different. A strange offset randomly appearing when you click the button several times definitely looks like a bug however, that's what I find the issue to be.

Sometimes those random offsets do pose a visual problem too: While they often happen on hidden caulk textures in between brushes, I had an instance where I needed to reset the textures on a building face as they became offset due to this and out of sync with the rest of the wall.
(0012961)
greebo   
17.11.2020 14:16   
(Last edited: 17.11.2020 14:18)
Well, I for one wouldn't rely on any offsets on any face, only the resulting projection is important. Texture projection onto brush faces doesn't work with these shift values anyway, they are using a transformation matrix, which is the data that is written to the brushDef3 blocks in your map file.

The values in the Surface Inspector are often referred to as "fake" by the code comments in DR, they are reverse-calculated on the basis of the texture projection matrix. Whether the number is 0 or 20 or 15.5 is practically meaningless, it doesn't have to be round at all and it can be ignored most of the time. Just use the buttons to shift the texture around, to fine-tune any visual transitions to other surfaces, but don't get too hung up on these shift values to be 0.

And I'd definitely recommend using the other texturing tools in DR to get your results, don't just select everything and hit "Natural". Rather take one face as starting point and copy/paste it across the neighbouring surfaces, it will automatically create seamless results.
(0012962)
MirceaKitsune   
17.11.2020 14:23   
(Last edited: 17.11.2020 14:24)
Will keep that in mind, thanks for clarifying. I'll still post more info if I can figure out what might be causing the issue on my build, since the odd values appearing is still a bug that should ideally be fixed (the result should always be one and predictable for that particular face, not random). Perhaps try with my user.xml in the meantime, to make sure it's not preference related in some form.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5125 [DarkRadiant] Selection System normal always 12.01.2020 18:12 17.11.2020 14:57
Reporter: Dragofer Platform:  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: acknowledged Product Version: 2.6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Select Group Parts only selects members that are entity brushes/patches
Description: 'Select Group Parts' should allow the mapper to select individual members of a group. However, the only members I'm able to select are brushes/patches that are entities. Nothing happens if I click on anything else.
Tags:
Steps To Reproduce: 1) Create a brush and leave it as worldspawn
2) Clone the brush and convert it to func_static (or func_mover etc.)
3) Create a model: stagecoach.lwo
4) Group all 3 items together
5) Activate 'Select Group Parts' and try to select items in the group. The only item that can be selected is the brush-entity, no matter if shift-click/shift-alt-click/shift-drag select is tried.
Additional Information: I find the 'Group' function very useful as a more powerful alternative to 'Convert to func_static' for managing groups of brushes, patches and even other entities, but kept wondering why this button frequently didn't do anything and I had to ungroup everything to get at certain members.
Attached Files:
Notes
(0012135)
Dragofer   
12.01.2020 18:14   
Tested & confirmed in 2.6 and 2.7pre4.
(0012136)
greebo   
12.01.2020 18:22   
I think the problem here is the naming. This function has been there long before the actual grouping feature was added to DR, and its purpose is indeed what you described: to select parts of a func_* entity, previously often referred to as "func group". It's historically named, so I'd propose renaming that DR feature to something less confusing?
(0012138)
Dragofer   
12.01.2020 18:33   
The thing is, it does actually select members of both func_statics and groups, so the name 'Select Group Parts' is fitting with respect to what it does. Only that in the case of the latter it has to be a brush/patch entity, which looks like a bug to me.

Is there already another button that's designed for the purpose of selecting group members?
(0012139)
greebo   
12.01.2020 18:37   
Not yet, but there's a feature request for selecting members of a group: 0004863
(0012140)
Dragofer   
12.01.2020 18:41   
Ah, that's good, then we're all set when it comes to the bugtracker with these 2 issues. Looking forward to such a feature.
(0012963)
MirceaKitsune   
17.11.2020 14:54   
(Last edited: 17.11.2020 14:57)
Noticing this too and can confirm. This is mostly a hindrance when importing prefabs such as dressers with a lot of parts: You can select the brushes that make up the doors, but cannot select entities such as the key in the drawer or the candle sitting on top: For that you still need to ungroup everything, make your adjustments to those entities, then regroup the entire piece of furniture... very complicated by comparison.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4863 [DarkRadiant] Map Editing minor always 11.07.2018 22:35 17.11.2020 14:55
Reporter: kingsal Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Selecting within groups.
Description: If possible, would like the ability to select sub elements of a group without having to un-group and re-group. Similar to selecting within combined func_statics were I can hit a hotkey to toggle between group and sub-group modes.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5415 [DarkRadiant] Map Editing normal always 16.11.2020 20:03 17.11.2020 04:28
Reporter: MirceaKitsune Platform: x64  
Assigned To: OS: Linux openSUSE  
Priority: low OS Version: Release  
Status: acknowledged Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Clipper tool: Resulting faces have an unpredictable scale
Description: When using the clipper tool to cut brushes, the faces generated in between those cuts are assigned an unpredictable scale instead of the default one. This happens even if the cuts are straight lines (no diagonal edges / faces) and all textures existing on the brush have the same scale.
Tags:
Steps To Reproduce: First of all, in Preferences - Settings - Primitives ensure your default texture scale is set to a good value, in my case it's 0.25. Also check that in Preferences - Settings - Clipper you have the clipper tool uses caulk texture checkbox on.

Draw a bunch of brushes on your map, leave the default Caulk texture on them... if you select any face you should see that the texture scale is indeed 0.25. Now use the Clipper tool to cut different brushes in various directions. If you look in between them and select the faces resulting from those cuts, you should find that some of them have a different scale. In my case that almost always seems to be 1.00, however I've had cases where it was set to some other in-between number with a lot of decimals.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5403 [DarkRadiant] General normal always 13.11.2020 18:57 17.11.2020 04:13
Reporter: MirceaKitsune Platform: x64  
Assigned To: greebo OS: Linux openSUSE  
Priority: normal OS Version: Release  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version:  
Summary: Select Group Parts does not work
Description: DarkRadiant is supposed to allow you to select individual entities in a group using the option Select Group Parts (the icon with a rubix cube in the upper bar). However this doesn't appear to work: Clicking on this icon, either before or after I've selected a group of entities, does nothing. The only change is that the the icon to its left, Select Entities (the icon with a blue chess piece) gets turned on and off in its place. Toggling that icon doesn't allow me to select group parts either, the only workaround right now is to ungroup then edit the entity you need then group again (very annoying for groups with a lot of items).
Tags: Bug, Glitch
Steps To Reproduce: Import a prefab as a group or manually group a bunch of entities on your map. Try using the Select Group Parts option: It simply doesn't work and nothing happens.
Additional Information:
System Description
Attached Files:
Notes
(0012909)
greebo   
13.11.2020 19:16   
Possible duplicate of 0005380?
(0012910)
MirceaKitsune   
13.11.2020 19:18   
Sounds like the same thing. Should the fix be in latest Git master, or will it only get there once 2.9.0 is released? I'll confirm it's solved for me as well then.
(0012911)
greebo   
13.11.2020 19:22   
Right now, everything goes to the 2.9.0 branch, but I'm beginning to re-think that decision. I was thinking I might be working on one or two other features next to stabilising the release and waiting for feedback, but since there are so many reports incoming for 2.9.0, and I'm pretty much exclusively working on fixing those, I think there's not much benefit in keeping the master separate and free for feature development.
(0012952)
MirceaKitsune   
17.11.2020 03:38   
Just updated to latest Git master. Select grouped parts now seems to work in principle, but there's a major issue left: Apparently it only lets me select brushes! I'm unable to select any entities inside a group with it.

Additionally there's another problem though this is a tiny one: If you have a brush in a group selected then turn off the "select grouped parts" button, you'll still maintain that one brush selected. Normally toggling the feature off while having a group part selected should either select the entire group or deselect everything.
(0012953)
MirceaKitsune   
17.11.2020 03:39   
Reopening this to avoid opening yet another issue and for the same component, see my note above.
(0012954)
greebo   
17.11.2020 04:13   
What you're experiencing is I guess the same as in this issue 0005125. As discussed there, the feature you're using has a misleading name, as it was there long before grouping was implemented.
There's also another feature request for the thing you want to do: 0004863.

Setting this issue to resolved again, as the issue at hand was about the toggle button not working.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5411 [DarkRadiant] GUI normal always 15.11.2020 20:01 16.11.2020 19:54
Reporter: MirceaKitsune Platform: x64  
Assigned To: OS: Linux openSUSE  
Priority: normal OS Version: Release  
Status: acknowledged Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Surface Inspector: Can't set scale / offset / rotation for multiple surfaces simultaneously
Description: When selecting a whole brush or multiple faces, the fields allowing you to set the texture scale and offset and rotation in the Surface Inspector become grayed out. You can still use the arrows to offset them but can no longer edit the values manually.

This is bothersome as if you want to change the scale / offset / rotation of all textures on one or more brushes, you need to select each one and input the scale / offset / rotation you want. Previously you could type a number in and that scale / offset / rotation would be (re)set for all the selected faces.
Tags:
Steps To Reproduce: Press S to open the surface inspector and observe. If you select one face, you can input those texture parameters as numbers... if you select more than one face however, you can no longer type in a number to set that specific value on those faces.
Additional Information: I know this used to work in the past so it was likely changed recently. I'm hoping this is a bug and not an intentional change, and if it's the later that it can be rethought to bring back the ability of changing scale / offset / rotation on multiple faces at once.
System Description
Attached Files: Screenshot_20201115_214828.png (57,293 bytes) 15.11.2020 20:01
https://bugs.thedarkmod.com/file_download.php?file_id=940&type=bug
Notes
(0012945)
greebo   
16.11.2020 04:25   
I just checked against DR 2.6.0 and this was not possible there neither. I do get the point about the use case, but are you sure this used to work in the past?
(0012946)
MirceaKitsune   
16.11.2020 04:47   
I think so, but it's a vague memory at this point. I might also be confusing with NetRadiant (Xonotic's Radiant version) which is based on gtkRadiant too, it definitely allowed this years ago when I last used it. I think DR did too though.
(0012948)
greebo   
16.11.2020 07:19   
I went back the source history and the text entry boxes have been disabled for ages now. I think in GtkRadiant the entry boxes were enabled but empty, allowing to enter values.
(0012949)
MirceaKitsune   
16.11.2020 15:16   
Okay. The last time I felt I saw that working was around 2016 when I first started using DR, but maybe I'm confusing and it wasn't enabled then either. Hopefully it can be fixed now in any case, so the user doesn't have to select a face / change its properties / deselect / repeat with the next face whenever they need to change the scale on a whole set of faces.
(0012950)
greebo   
16.11.2020 19:05   
The texture copy/paste methods using the MMB might be more effective here, maybe.
(0012951)
MirceaKitsune   
16.11.2020 19:54   
I think it's still useful to just not gray out those fields so you can input a value and set it on all faces at once. I'm assuming it's a bug that it does this altogether, as I see no reason why it would disable the fields.

Different faces may have different scales / offsets / rotations of course, in which case the fields should show no value to indicate this. When inputting your own value still, that parameter should be set to your value on all those faces regardless what their past value was. IMO that's the desired functionality and IIRC how other Radiant forks work too.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5414 [The Dark Mod] Coding trivial N/A 16.11.2020 16:56 16.11.2020 16:56
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: low OS Version:  
Status: assigned Product Version: TDM 2.09  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.10  
Summary: Remove "g_entityBindNew 0" old code
Description: As long as new code it becomes well-tested, the old code should be removed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5409 [The Dark Mod] Coding crash sometimes 14.11.2020 13:01 16.11.2020 16:56
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.08  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version: TDM 2.09  
Summary: Unbinding entity B in C->B->A bind hierarchy broken
Description: It seems that bindMaster hierarchy and teamMaster/teamChain groups can be out of sync.
As the result of such data corruption, game shutdown is likely to crash, because entity tries to access its already deleted bindMaster on destruction.
Tags:
Steps To Reproduce: Unfortunately, it is currently reproduced only on the first beta version of William Steele 7:
1) Skip cutscene.
2) notarget/noclip.
3) spawn atdm:playertools_lockpick_triangle; spawn atdm:playertools_lockpick_snake
4) pick up the lockpicks (or you can bet your equipment not very far from your cell).
5) find the forge control (should be near 328 1632 55) room and unlock it.
6) set speed 4 for the forge, disable noclip, get out of the room (should get a bang).
7) now finish game by quickloading or quitting ---> crash.

Most likely it can be reproduced by doing the following:
1) bind A to B
2) bind B to C
3) unbind B from C
4) perhaps you also need entity B to go earlier than A in global sequence.
5) crash on game shutdown
Additional Information: Originally discussed here:
  https://forums.thedarkmod.com/index.php?/topic/20636-bindteam-refactoring/
Also in WS7 beta:
  https://forums.thedarkmod.com/index.php?/topic/20623-beta-testing-ws7-the-builders-forge/&do=findComment&comment=453114
Attached Files:
Notes
(0012936)
stgatilov   
14.11.2020 14:35   
I have reimplemented the teams/binds system in svn rev 8980.
The old code can be enabled by setting cvar "g_entityBindNew 0" (non-archived).

Looking through the code, it seems that the teamChain linked list should traverse through the whole tree of bound elements in PRE-ORDER traversal order:
  https://en.wikipedia.org/wiki/Tree_traversal#Pre-order_(NLR) (just there can be any number of sons, not always two)
This was clearly the intent of the authors, but it was not properly maintained on entity unbinding.
The QuitTeam method was the culprit: such method must not exist at all.

With the new implementation, this invariant is strongly maintained.
Only two methods which can change the structure of bind tree and team linked list are:
  EstablishBindToMaster
  BreakBindToMaster
In debug build, both of them check the invariant before and after modification (calling the ValidateBindTeam method).

As a side effect, I have broken movers with nonempty "team" spawnarg.
For now such cases cause immediate Error, since I think/hope they do not exist.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5413 [DarkRadiant] Design/Coding normal have not tried 16.11.2020 06:10 16.11.2020 09:39
Reporter: greebo Platform: Linux  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: DarkRadiant doesn't compile against wxGTK 3.1.4
Description: Using the latest dev release wxWidgets 3.1.4, and configuring DarkRadiant to use that one instead of the system-provided wxWidgets library, compilation fails in RenderPreview.cpp due to event handler registration problems.
Tags:
Steps To Reproduce:  wget https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.4/wxWidgets-3.1.4.tar.bz2
tar xf wxWidgets-3.1.4.tar.bz2
cd wxWidgets-3.1.4
./configure --with-opengl --prefix=/home/greebo/wx_install && make -j4 && make install

Then, in DarkRadiant's git root:

./configure --enable-darkmod-plugins --prefix=/home/greebo/dr --with-wx-config=/home/greebo/wx_install/bin/wx-config
make -j4 && make install
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5410 [DarkRadiant] General minor always 15.11.2020 14:43 16.11.2020 07:18
Reporter: MirceaKitsune Platform: x64  
Assigned To: greebo OS: Linux openSUSE  
Priority: low OS Version: Release  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Filtered textures aren't edited when modifying textures on the whole brush, no obvious way to tell which textures are locked
Description: This one's a very minor issue, I'm only reporting it to help polish the upcoming 2.9.0 release. There's a small behavior in DR that's a bit overhand: If you a select a brush containing a filtered texture, which is possible if you're drawing it with that texture or selected it before applying the filter and making it invisible, you can resize it but can't change any of the textures on it: Opening up the Surface Inspector and trying to assign another image does nothing.
Tags:
Steps To Reproduce: In this example I'll go with the Clip texture though any will do:

- Press T to open the texture browser. In its window find and select textures/common/clip, so that any new brushes you create are drawn with this texture.
- Under the Filter menu, make sure Clip Textures is enabled so brushes with this texture are normally hidden.
- Draw a new brush. It will have the Clip texture, and due to just being drawn and currently selected it will make an exception and not be filtered until you press Escape to deselect.

The problem: While this brush is selected, you can resize it or otherwise edit its geometry which is good. However if you try giving it another texture from either the Texture Browser or Surface Inspector, this won't work until you turn off the Clip Texture filter. This is a bit counter intuitive: While that filter should and does hide brushes with that texture, it shouldn't prevent you from changing a texture that you can currently see on a brush.
Additional Information: I noticed that if you give a brush multiple textures (eg: Caulk on one face and Clip on all others) then select the whole brush with Clip Textures filtered and try to assign a new texture to the brush, only the faces with Caulk will change while the faces with Clip remain unedited. This makes me wonder what would be best: On one side the filtered textures are locked and you aren't allowed to edit them which seems like the desired behavior... on the other side a texture you can see as selected doesn't change when editing the whole brush, which is overhand and goes against expectation (you may not even realize why this happens until you check your Filters).

Maybe instead it would be possible to make it more obvious that you're temporarily seeing a filtered face just because its brush is selected but can't edit that texture until you disable its filter, such as by making the selection blink or have a different color? Or instead hide the filtered faces even when the brush is selected, so the user doesn't have to wonder "which texture on this brush is currently filtered and won't change"... this would be a problem if the brush contains only filtered textures though, since then you're drawing a completely invisible box, so what we could do is just not draw the faces in cause but only the outline so just the shape of the brush can be seen there.
System Description
Attached Files:
Notes
(0012947)
greebo   
16.11.2020 05:39   
I can see the behaviour.
The issue also affects selected patches that carry a material that is filtered out, but are visible due their selection status.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5412 [DarkRadiant] General minor always 15.11.2020 20:20 16.11.2020 04:20
Reporter: MirceaKitsune Platform: x64  
Assigned To: greebo OS: Linux openSUSE  
Priority: low OS Version: Release  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Undo / redo system records cycling through textures (previewing) in the Surface Inspector shader browser
Description: When browsing through multiple textures in the Choose Shader window of the Surface Inspector, each texture you've browsed over (on the selected faces) are recorded by the undo / redo system, even if you clicked Cancel in which case they should normally be forgotten (you were only browsing and never actually applied them). This is mainly annoying as it fills the undo queue quickly and makes it harder to go back to other changes in need.
Tags:
Steps To Reproduce: - Select a face and open the Surface Inspector, then click on the folder icon to browse for a shader.
- Expand some directories and select a few textures, just use the arrow keys to rapidly navigate through them (which causes this inconvenience most easily). The texture will be applied to the face you currently have selected, which itself isn't a bad thing and desired.
- Now click the Cancel button to drop all changes.

Result: The textures on the selected faces will revert to the images they had before you started browsing for new ones. However if you hit Control + Z to undo, you'll be able to reproduce the entire history of cycling through that media browser window. Normally the undo system shouldn't record anything since you cancelled... if you had clicked okay instead, it should only record one change (the final texture you chose when clicking okay).
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5401 [DarkRadiant] GUI minor always 13.11.2020 11:07 15.11.2020 11:43
Reporter: Bikerdude Platform: PC  
Assigned To: greebo OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version:  
Summary: DR not always remembering window size and position between sessions
Description: In the past DR would take a few open/close actions to remember its window size/locations, but this doesn't appear to be the case anymore.

Even nuking the DR user config folder and going through several close/open cycles doesn't help. I suspect Windows 10 isnt helping here.

My current work around is to force size/position via a 3rd party app (http://www.desksoft.com/WindowManager.htm)
Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files:
Notes
(0012923)
greebo   
14.11.2020 08:48   
I need more specifics. Is there a multi-monitor setup involved? What is the state of DarkRadiant's windows that is supposed to be memorised? (A screenshot would be enough, then I can see whether the windows are placed on different monitors, their maximised state, etc.)
And if the position is not remembered, what happens instead?
(0012925)
Bikerdude   
14.11.2020 10:17   
Hi Greebo

- I do run dual screen normally, but atm I am running single screen.
- The size and position of the main window and the child windows should be memorized, but atm I am only having an issue with the main window.
- I have created a small video that hopefully explains the issue well enough, hopefully I dont sound too confusing.

https://youtu.be/lqMFxTcN2I0
(0012927)
greebo   
14.11.2020 13:22   
Can't view the video, it's "private"
(0012930)
Bikerdude   
14.11.2020 13:42   
Oops, forgot to make it as unlisted, try now.
(0012933)
greebo   
14.11.2020 14:18   
Thanks for the video. I can see the window shifting downwards after each startup, something it shouldn't do.
I can also observe that it completely forgets the position and moves it to towards the lower right, as it did in your video. I think this might be related to the window's dimensions extending below some screen boundary, but I have to check it out.
(0012935)
Bikerdude   
14.11.2020 14:28   
Oh man, I thought I was going nuts. Im glad (and not glad, coz you have to fix it) you were able to reproduce it.
(0012939)
greebo   
14.11.2020 17:40   
Added a fix, let's see if this improves things a bit
(0012942)
Bikerdude   
14.11.2020 23:15   
Greebo, your a little star!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5351 [DarkRadiant] Selection System feature N/A 03.10.2020 13:53 15.11.2020 07:14
Reporter: Dragofer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature: select linked entities
Description: Mappers sometimes deal with networks of entities targetting each other, most prominently when it comes to patrol paths. When there are multiple AIs patrolling an area, it can be difficult to visually pick out and follow the route of a specific AI, especially against the backdrop of the scenery.

My method of dealing with this has been to assign each AI's patrol nodes to a group, so I can click one node and see the whole network. It does make it a bit impractical to make changes, though, because I need to ungroup first and I need to make sure all involved layers are visible so I don't lose some of the nodes when I deselect them.

I was thinking a simple script that could automatically select all targets and targets of targets could make pathing routes easier to work with. Maybe it could be called "Select linked entities" and assigned to K, in analogy to Ctrl - K which makes entities target each other.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5371 [DarkRadiant] Map Editing minor always 29.10.2020 08:41 15.11.2020 07:05
Reporter: Spooks Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: [Surface Inspector] Fit Texture does not work if either Horiz. or Vert. scale are set to 0
Description: Obscure, I know.

The Fit Texture button doesn't fix 0 scale textures and if, say, horizontal scale is set to 1 but vertical scale is set to 0, pressing the button will reset both to 0.000...

The workaround is to press the Modify Texture: Natural first, which resets the scale values to the default scale.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012849)
greebo   
29.10.2020 16:28   
Confirmed. I'll change the code to replace the 0 scale value with a very small one, like 0.00001, and then proceed with the regular Fit algorithm.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5406 [DarkRadiant] Objectives normal N/A 13.11.2020 19:22 15.11.2020 05:16
Reporter: Geep Platform:  
Assigned To: OS: Win 10  
Priority: normal OS Version:  
Status: confirmed Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature: Add "Select entity..." button when editing certain Objective parameters
Description: Associated with every objective component, when selected for editing, are typically additional text fields. Whenever such a text field is of field type of "Name of single entity", it would be desirable to make visible a button, "Select entity...", that if pressed would allow choosing the name from a list of pre-existing entities. Typically, there is room for this button above the text field and right-justified with it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5100 [DarkRadiant] GUI minor random 02.01.2020 15:43 15.11.2020 05:12
Reporter: Bikerdude Platform: PC  
Assigned To: OS: Windows  
Priority: low OS Version: 8.1  
Status: acknowledged Product Version: 2.6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Middle-mouse click on a texture on a patch/brush face to move texture inspector to said texture
Description: Sometimes DR will randomly stop targeting (I assume that the right description) the texture in, texture inspector. The caveat is this has only happened once since using 2.7.0pre2 and the only fix was to restart, so this maybe be the issue of having a large map opened in DR for few hours causing this...
Tags:
Steps To Reproduce: - Open DR.
- Open a map or create a brush.
- Select and highlight a face on a brush>
-- then click on the face on a brush.
or
-- middle mouse button click on face of brush.
- Go back to texture inspector>
-- and Dr is then not showing the highlighted texture.
Additional Information:
System Description i7-4790k, GTX1080Ti
Attached Files:
Notes
(0012873)
Bikerdude   
08.11.2020 20:02   
Since 2.8, a related issue has started happening thats close enough to this one I figured I would post it in this tracker.

After a relatively short period of time (minutes rather than hours) middle mouse clicking on a selected face will not take you to the texture in media inspector.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5405 [DarkRadiant] General normal random 13.11.2020 19:14 15.11.2020 05:00
Reporter: MirceaKitsune Platform: x64  
Assigned To: greebo OS: Linux openSUSE  
Priority: normal OS Version: Release  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Darkradiant occasionally freezes when browsing sounds
Description: I don't know how to reproduce this one exactly as it's very probabilistic. If browsing for too long through the sound shader browser, DarkRadiant will eventually freeze and require killing the process. As the process doesn't actually crash but only becomes permanently unresponsive, I'm afraid I don't have any console output to go by.
Tags: Bug, Crash, Freeze, Glitch
Steps To Reproduce: Right-click a 2D viewport and add a speaker. In the soundshader browser that opens up, try browsing through some sounds. Open up as many directories as possible, play random sounds from the preview button, etc... I found that the most common trigger is when opening one of the larger directories under the Voices folder. Eventually DR will simply freeze in place and require killing the process.
Additional Information:
System Description
Attached Files: gdb.txt (11,235 bytes) 14.11.2020 13:31
https://bugs.thedarkmod.com/file_download.php?file_id=936&type=bug
gdb-2.txt (2,562 bytes) 14.11.2020 17:34
https://bugs.thedarkmod.com/file_download.php?file_id=937&type=bug
gdb-3.txt (16,133 bytes) 14.11.2020 17:36
https://bugs.thedarkmod.com/file_download.php?file_id=938&type=bug
gdb-4.txt (65,695 bytes) 14.11.2020 20:14
https://bugs.thedarkmod.com/file_download.php?file_id=939&type=bug
Notes
(0012922)
greebo   
14.11.2020 08:45   
I tried reproducing this in openSUSE, but couldn't get it to freeze so far.

When it happens to you, one thing you could try is to attach gdb to the running process ("gdb /path/to/darkradiant PID") with PID being darkradiant's process ID. After attaching, hit Ctrl-C in gdb to stop the process, then "bt" to get the stracktrace - maybe I can see where it is stuck.
(0012928)
MirceaKitsune   
14.11.2020 13:24   
Good idea, I'll try GDB next. I compile DR with the "--enable-debug" flag so hopefully GDB will offer useful info. But will it work? Like I said the engine doesn't actually crash, only freezes... not sure if GDB can pick up on that.

What I'd suggest trying just to be fully sure, as this is how I got it to occur last time: Open large sound directories in the browser, such as multiple character voice folders. Then hold the Down arrow key to quickly browse through many of them and make the selection roll down quickly. When I reported this and tried to get console output that's what I did.
(0012929)
MirceaKitsune   
14.11.2020 13:31   
Just tried gdb and sadly it's as I expected: No specific crash output as the application never actually crashes, only freezes forever. This is the only meaningful info I managed to get.
(0012932)
greebo   
14.11.2020 13:54   
Yes, I browsed like 2-3 minutes for sound files and played what felt like all of them - no freeze.

Did you try to hit Ctrl-C in gdb after DR froze? It should send a break signal to the application, at which point you can print out the stacktrace using the "bt" command in gdb.
(0012937)
MirceaKitsune   
14.11.2020 17:34   
Aha, think I got it to work! Here is the real backtrace.
(0012938)
MirceaKitsune   
14.11.2020 17:36   
Sorry: That output was incomplete and I can't edit my attachment in the previous note. Here's the correct one.
(0012940)
greebo   
14.11.2020 17:42   
Ah, I can see now that there's a locking issue going on.
Perhaps you can give it one more try and give me the stacktrace of all active threads? It's this gdb command: "thread apply all bt"
(0012941)
MirceaKitsune   
14.11.2020 20:14   
Sure, here it is.
(0012943)
greebo   
15.11.2020 04:48   
Thanks a lot, I think I found the problem now


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5385 [DarkRadiant] Renderer normal sometimes 08.11.2020 19:58 14.11.2020 14:26
Reporter: Spooks Platform:  
Assigned To: greebo OS: Windows  
Priority: normal OS Version: 7  
Status: resolved Product Version: 2.6.0  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version:  
Summary: Phantom Model Left Over in Model Selector Window
Description: This is a bug that I've encountered for as long as the similarly named one about models in the main program 3D window, hence I'm tagging it as 2.6.0. Incredibly, I've forgotten to report it for this long, considering it's a real eye-strain sometimes. I have just checked on 2.9.0pre2 and I managed to reproduce it very quickly.

A previously selected model in the "Choose a Model" dialogue can just stay in the 3D preview while new models are being selected, obscuring them. It remains scaled correctly, meaning smaller models get obscured more. A restart is needed to fix this.
Tags:
Steps To Reproduce: It is hard to tell how exactly this is reproducible. I'm fairly sure it involves undoing/redoing and clicking the "Choose model..." button. I've gotten it to manifest by:

Creating a couple of func_statics with different models.
Undoing/redoing and clicking "Choose model..." on either of them to change to a new model/check on the 3D preview window until the bug pops out.
Additional Information:
Attached Files: example of bug.jpg (216,610 bytes) 08.11.2020 19:58
https://bugs.thedarkmod.com/file_download.php?file_id=920&type=bug
Notes
(0012877)
Bikerdude   
08.11.2020 20:58   
Confirmed, but I think this has been a problem for a while, since version 2.6 or earlier.
(0012934)
Bikerdude   
14.11.2020 14:26   
Nice one Greebo,


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5402 [DarkRadiant] GUI normal sometimes 13.11.2020 18:46 14.11.2020 13:52
Reporter: MirceaKitsune Platform: x64  
Assigned To: greebo OS: Linux openSUSE  
Priority: normal OS Version: Release  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Model browser renders 3D previews for past models, overlaps current selection
Description: I've gotten this annoyance with DR since I started using it but never got around to reporting it. The model browser (potentially affects the entity and prefab browsers too) will occasionally draw a previous model you've selected on top of the current selection, causing both to display in the 3D preview and overlap. When this happens I either need to deal with the glitch or restart DarkRadiant to get rid of it till it occurs again.

Though I couldn't pinpoint the exact cause beyond doubt, what seems to trigger this appears to be using undo: If you add a model, undo with Control + Z, then try adding another model, you get the previously added model also being rendered in the window.
Tags: Bug, Glitch
Steps To Reproduce: Right-click in a 2D viewport and choose "Create model...". Play around with creating multiple models, duplicating, undoing / redoing your actions, etc. At some point when you open the Choose Model window again, you'll see additional models render on top of your currently selected preview.
Additional Information: Repro steps I found:

- Start DR
- Create Model > darmod/nautical/anchor.lwo
- Deselect
- Create Model > darkmod/nautical/boat.lwo
- Undo
- Create Model > both anchor and boat are rendered on top of each other
System Description
Attached Files: Screenshot_20201113_173857.png (142,506 bytes) 13.11.2020 18:46
https://bugs.thedarkmod.com/file_download.php?file_id=934&type=bug
Screenshot_20201114_013515.png (128,630 bytes) 13.11.2020 23:36
https://bugs.thedarkmod.com/file_download.php?file_id=935&type=bug
Notes
(0012918)
MirceaKitsune   
13.11.2020 23:36   
Confirming the entity browser can do it too.
(0012921)
greebo   
14.11.2020 07:57   
Apparently the scenegraph used by the ModelPreview is connected to the same global UndoSystem as the rest of the map, causing the interference.
The TraversableNodeSet::connectUndoSystem() method is accessing GlobalUndoSystem() - which needs to change.

The fix requires similar refactoring as in moving the LayerManager instance to the map's root node, to separate it from other scenes. This is more work, so I'm not going to fix this for the upcoming 2.9.0.
But maybe a quick fix can be done to purge existing models from the ModelPreview scene before doing anything.
(0012926)
MirceaKitsune   
14.11.2020 13:18   
That quick fix sounds like a good idea too if possible in a healthy way. While this one doesn't cause crashes or prevent using any features, it is annoying when a large model remains forgotten in the preview and you're currently looking at smaller models, as you won't be able to preview them and easily see exactly what you're selecting, due to the larger ghost model covering the mesh of what you're currently previewing.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4724 [The Dark Mod] Graphics feature N/A 03.01.2018 15:38 14.11.2020 13:47
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS: Windows  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.08  
    Target Version: TDM 2.08  
Summary: Investigate "borderless windowed" screen mode
Description: UPDATE: Many games have three modes today:
1) Windowed
2) Borderless Windows/Fullscreen
3) Fullscreen
Reopened the issue in order to implement these.

Please read also:
  http://forums.thedarkmod.com/topic/19766-fullscreen-topic/

OLD:
Most of modern games have such a screen mode, when:
1. The game plays in a window.
2. The window has no GUI elements (no border).
3. The window exactly covers the whole screen.
Such a mode is very convenient, particularly because it allows easy alt-tabbing at any moment.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0009969)
duzenko   
03.01.2018 15:50   
I think this is how it is now on Windows.
(0009971)
nbohr1more   
03.01.2018 15:55   
(Last edited: 03.01.2018 15:56)
Yes, 3568 seems to have made this the default behavior in Windows unless I'm misunderstanding the specifications.

To have Linux feature parity, we need 4190 merged.

(0009973)
stgatilov   
03.01.2018 17:46   
(Last edited: 03.01.2018 17:47)
Ok, I think it should be discussed in forum...
I don't understand resolutions and fullscreen in TDM any more.

It seems that fullscreen mode is simply broken now on Windows: there is no way to enable fullscreen. When I set lower resolution with fullscreen on, TDM just takes a fraction of the screen, which is surely not how fullscreen should work.
And yes: if resolution in TDM matches screen resolution, and fullscreen is on, then it is actually the "borderless windowed" mode I described, and not fullscreen mode.

(0009974)
nbohr1more   
03.01.2018 18:20   
The behavior differs depending on whether r_useFBO is enabled.

r_useFBO seems to sorta force native resolution without scaling the game resolution but alt-enter in and out of Windowless seems to cure it.

Similar problems were initially reported with Windows 8 DPI scaling but now the DPI scaling workarounds no longer seem to work.

May be related to 4402
(0010970)
stgatilov   
19.12.2018 12:45   
Moving to here (by nbohr1more):

Rev 15464 Trunk

Proposed Fullscreen solution applied

r_fullscreen = 0 corresponds to fullscreen = No (GUI)
r_fullscreen = 1 corresponds to fullscreen = Yes (GUI)
r_fullscreen = 2 corresponds to fullscreen = FSW (GUI) (Fullscreen Windowed)

Having "true" exclusive fullscreen ( r_fullscreen 1 ) feels much smoother and has less mouse input lag.
(0011873)
stgatilov   
22.11.2019 12:39   
The last update on this matter was done in svn rev 8403.

Right now there are three modes: windowed, fullscreen, and borderless.
Borderless differs from fullscreen very slightly: height of the TDM window is two pixels larger than height of the screen, so OS (at least Windows 10) treats it like any other window. This allows doing all types of switches (Alt+Tab, Win+Tab, Ctrl+Alt+Enter, Win, etc.) instantaneously without any blinking.
When fullscreen/borderless mode is enabled, the resolution chosen by player is completely ignored. I guess we should somehow gray it out.
(0011874)
stgatilov   
22.11.2019 13:27   
One more minor fix in svn rev 8416: now the resolution and aspect ratio shown in menu are updated when player switches to fullscreen.

Better Linux implementation is wanted here:
1) Linux side does not do anything special for borderless mode.
2) When player sets non-native resolution and fullscreen mode, then after reboot Linux implementation actually switches desktop resolution to the set values, while Windows implementation drops user resolution and uses the native one.
I hope this difference is not critical, so I'll mark the issue as resolved.
(0012931)
stgatilov   
14.11.2020 13:47   
It turned out that the borderless mode was not working at the moment it was implemented.
Because just after the code which supports it the height was reverted back if FBO is enabled.
At least, it is not working for me right now.

Anyway, fixed it in svn rev 8979.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5399 [DarkRadiant] General normal always 11.11.2020 14:47 14.11.2020 13:10
Reporter: MirceaKitsune Platform: x64  
Assigned To: greebo OS: Linux openSUSE  
Priority: normal OS Version: Release  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Conversation Editor won't add new actors, entity names are seen as null
Description: Yesterday I was learning about how the conversation editor in DarkRadiant (Git master) works, and in the process discovered a bug with this editor. When adding actors to the conversation, renaming them doesn't work and the entity names are seen as null strings, causing them to not be validated nor saved with the conversation changes.

First of all: If you click the Validate All button to confirm your actor exists on the map, you get the following error:

"The actor cannot be found in the current map"

Not only the actor entity is definitely there so the error is wrong, but notice there are double spaces when referring to it, instead of the word atdm_ai_proguard_1. This indicates that the actor name you just introduced, even if it shows up accordingly in the menu, is being ignored by the code... in its place a null string appears to be seen.

I also noticed that if you click ok to close the windows and confirm all changes, the actors field is empty the next time you open the conversation editor and select that entity and conversation. The actors you just created in that menu aren't even being registered at all.

Currently the only workaround is to select your atdm:conversation_info and manually add "conv_1_actor_1 atdm_ai_proguard_1" as a spawnarg. After you do this the conservation editor finds the actors, will successfully validate them, and you can proceed to add conversation actions successfully.
Tags: Bug, Glitch
Steps To Reproduce: Start by going to "Map -> Conversations". Create or select a conversation entity in the first list, then create a new conversation below and select it then edit it. In the new window you have an actors field: Hit the add button to create a new actor. Double-click the New Actor entry then rename it to one of the AI's on the map, for example atdm_ai_proguard_1. Hit "Validate All" to see the error message with empty strings... press okay on everything then reopen the editor to confirm the actors were never added.
Additional Information:
System Description
Attached Files: TbjZEsZ.png (447,321 bytes) 11.11.2020 14:47
https://bugs.thedarkmod.com/file_download.php?file_id=933&type=bug
Notes
(0012924)
greebo   
14.11.2020 09:34   
Re-opening as this breaks the wxMSW version. Needs more work.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5408 [DarkRadiant] Design/Coding normal have not tried 14.11.2020 08:00 14.11.2020 08:01
Reporter: greebo Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: All scene graphs connect to the same undo system, causing interference
Description: In Issue 0005402 interference of the two scenegraphs in the ModelPreview and the rest of the map can be observed, caused by the Nodes connecting to the same global undo system. The Undo System or the change tracking needs to be able to distinguish between the scenes, similar as the LayerManager refactoring done in the past.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5407 [DarkRadiant] Map Editing normal have not tried 14.11.2020 05:55 14.11.2020 05:57
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Entity Inspector always shows "Primitve 0" for any selected worldspawn primitive
Description: The counter doesn't update when changing the primitive selection anymore, it always shows the index 0.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5380 [DarkRadiant] Map Editing normal always 03.11.2020 20:13 14.11.2020 05:47
Reporter: kingsal Platform: windows  
Assigned To: greebo OS: 10  
Priority: normal OS Version: 64  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: DR2.9 beta Select Group Parts not working
Description: Select Group Parts is not working on func_statics. DR instead pops over to the select entity mode.
Tags:
Steps To Reproduce: Open any map with a brush based func_static and try to group select a part.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5397 [DarkRadiant] General normal always 11.11.2020 14:28 14.11.2020 05:44
Reporter: MirceaKitsune Platform: x64  
Assigned To: greebo OS: Linux openSUSE  
Priority: normal OS Version: Release  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: DarkRadiant crashes when using Map - Find Brush
Description: DarkRadiant (Git master) will crash when going to "Map -> Find Brush..." in the menus. This happens even on my simple test map as well as an empty map, thus it's likely something universal. The only error printed to the console is: Segmentation fault (core dumped)
Tags: Crash
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0012914)
Judith   
13.11.2020 20:59   
Not reproducible on win 7 x64, might be system related.
(0012916)
MirceaKitsune   
13.11.2020 21:54   
Hmmm... could be in that case. Maybe something wrong with the compilation of the Linux version? Unfortunately the console doesn't tell me much otherwise it might be easier to pinpoint the exact cause.
(0012920)
greebo   
14.11.2020 05:04   
Confirmed, it's also happening in Ubuntu 20.10.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5387 [DarkRadiant] Design/Coding crash always 08.11.2020 20:36 14.11.2020 05:00
Reporter: BielBdeLuna Platform: Linux  
Assigned To: greebo OS: Ubuntu  
Priority: normal OS Version: 20.10  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: segfault when applying a new material to a brush
Description: Using the last pull from the 2.9.0 branch from github.
segfaults when applying a new material to a brush from either the media tab or the textures tab

Tags: Crash; darkradiant
Steps To Reproduce: 1 - Open Darkradiant using doom3

2 - select the first material from the media tab: textures/alphalabs/a_enwall13c

3 - click and drag on the y/x 2D screen in order to create a brush with that texture, the brush is drawn in the 3d view as I creat it and draw with the correct material alright.

4 - select the next material on the list in the media tab: textures/alphalabs/a_enwall20d <-- SEGFAULT

it can also happen if you have a material-less brush with the default material and then you apply a material from the textures tab.

I provided the two GDB traces in the additional info.
Additional Information: when you apply the matarial from the media tab:

$ gdb darkradiant
GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from darkradiant...
(gdb) run
Starting program: /usr/local/bin/darkradiant
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff1b1a640 (LWP 53759)]
[New Thread 0x7ffff1319640 (LWP 53760)]

Thread 3 "gdbus" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff1319640 (LWP 53760)]
0x00007ffff69a766f in __GI___poll (fds=0x555555ac19f0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29 ../sysdeps/unix/sysv/linux/poll.c: El fitxer o directori no existeix.
(gdb) continue
Continuing.

Thread 2 "gmain" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff1b1a640 (LWP 53759)]
0x00007ffff69a766f in __GI___poll (fds=0x555555aadd60, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29 in ../sysdeps/unix/sysv/linux/poll.c
(gdb) continue
Continuing.

Thread 1 "darkradiant" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff243ba80 (LWP 53755)]
wxutil::TreeModel::GetParent (this=0x555556bfa970, item=...) at TreeModel.cpp:584
584 if (owningNode->parent != NULL)
(gdb) bt
#0 wxutil::TreeModel::GetParent(wxDataViewItem const&) const (this=0x555556bfa970, item=...) at TreeModel.cpp:584
0000001 0x00007ffff7a4d495 in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000002 0x00007ffff7a5084c in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000003 0x00007ffff7a51e9b in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000004 0x00007ffff6230eff in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000005 0x00007ffff623696a in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000006 0x00007ffff62402d5 in gtk_tree_view_set_model () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000007 0x00007ffff7a4bb0e in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
#8 0x00007ffff7a4c84e in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000009 0x00007ffff79a5daa in wxDataViewModel::Cleared() () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000010 0x00005555557879d4 in ui::TexturePreviewCombo::refreshInfoTable() (this=0x555556bb2a40) at ui/common/TexturePreviewCombo.cpp:62
0000011 0x0000555555787dbc in ui::TexturePreviewCombo::SetTexture(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (this=0x555556bb2a40, tex=...) at ui/common/TexturePreviewCombo.cpp:54
0000012 0x000055555571391b in ui::MediaBrowser::handleSelectionChange() (this=0x555555af9410) at ui/mediabrowser/MediaBrowser.cpp:958
0000013 0x00007ffff7199661 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000014 0x00007ffff71999fa in wxEvtHandler::SearchDynamicEventTable(wxEvent&) () at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000015 0x00007ffff7199a94 in wxEvtHandler::TryHereOnly(wxEvent&) () at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000016 0x00007ffff7199b4b in wxEvtHandler::ProcessEventLocally(wxEvent&) () at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000017 0x00007ffff7199bf1 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000018 0x00007ffff719997b in wxEvtHandler::SafelyProcessEvent(wxEvent&) () at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000019 0x00007ffff7a59f97 in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000020 0x00007ffff5c37b56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000021 0x00007ffff5c50bbf in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000022 0x00007ffff5c50da3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000023 0x00007ffff623d34b in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000024 0x00007ffff6245690 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000025 0x00007ffff62b3cff in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000026 0x00007ffff5c37b56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000027 0x00007ffff5c50bbf in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000028 0x00007ffff5c50da3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000029 0x00007ffff60bb531 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000030 0x00007ffff5c3ad14 in g_cclosure_marshal_VOID__BOXEDv () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000031 0x00007ffff5c37b56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000032 0x00007ffff5c50bbf in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000033 0x00007ffff5c50da3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000034 0x00007ffff60b8046 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
--Type <RET> for more, q to quit, c to continue without paging--ret
0000035 0x00007ffff60b963f in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000036 0x00007ffff60bc803 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000037 0x00007ffff60820c0 in gtk_event_controller_handle_event () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000038 0x00007ffff625441d in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000039 0x00007ffff62ad6fb in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000040 0x00007ffff5c378fa in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000041 0x00007ffff5c49f0e in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000042 0x00007ffff5c50586 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000043 0x00007ffff5c50da3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000044 0x00007ffff6256514 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000045 0x00007ffff6104d50 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000046 0x00007ffff6106a93 in gtk_main_do_event () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000047 0x00007ffff5ddee89 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
0000048 0x00007ffff5e138e6 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
0000049 0x00007ffff58944db in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000050 0x00007ffff5894788 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000051 0x00007ffff5894aa3 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000052 0x00007ffff61059fd in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000053 0x00007ffff74e8bf5 in wxGUIEventLoop::DoRun() () at /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
0000054 0x00007ffff704dd41 in wxEventLoopBase::Run() () at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000055 0x00007ffff70153da in wxAppConsoleBase::MainLoop() () at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000056 0x00007ffff70a173d in wxEntry(int&, wchar_t**) () at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000057 0x000055555564f7c2 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at main.cpp:7
(gdb) continue
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
quit



when you apply the material from the textures tab:

$ gdb darkradiant
GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from darkradiant...
(gdb) run
Starting program: /usr/local/bin/darkradiant
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff1b1a640 (LWP 54044)]
[New Thread 0x7ffff1319640 (LWP 54045)]

Thread 3 "gdbus" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff1319640 (LWP 54045)]
0x00007ffff69a766f in __GI___poll (fds=0x555555abcde0, nfds=2, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
29 ../sysdeps/unix/sysv/linux/poll.c: El fitxer o directori no existeix.
(gdb) continue
Continuing.

Thread 2 "gmain" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff1b1a640 (LWP 54044)]
0x00007ffff69a766f in __GI___poll (fds=0x555555aaa820, nfds=1, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
29 in ../sysdeps/unix/sysv/linux/poll.c
(gdb) continue
Continuing.
Thread 1 "darkradiant" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff243ba80 (LWP 54040)]
wxutil::TreeModel::GetParent (this=0x555556d428b0, item=...)
    at TreeModel.cpp:584
584 if (owningNode->parent != NULL)
(gdb) bt
#0 wxutil::TreeModel::GetParent(wxDataViewItem const&) const
    (this=0x555556d428b0, item=...) at TreeModel.cpp:584
0000001 0x00007ffff7a4d495 in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000002 0x00007ffff7a5084c in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000003 0x00007ffff7a51e9b in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000004 0x00007ffff6230eff in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000005 0x00007ffff623696a in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000006 0x00007ffff62402d5 in gtk_tree_view_set_model ()
    at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000007 0x00007ffff7a4bb0e in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
#8 0x00007ffff7a4c84e in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000009 0x00007ffff79a5daa in wxDataViewModel::Cleared() ()
    at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000010 0x00005555557879d4 in ui::TexturePreviewCombo::refreshInfoTable()
    (this=0x555556bdcd00) at ui/common/TexturePreviewCombo.cpp:62
0000011 0x0000555555787dbc in ui::TexturePreviewCombo::SetTexture(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    (this=0x555556bdcd00, tex=...) at ui/common/TexturePreviewCombo.cpp:54
0000012 0x000055555571391b in ui::MediaBrowser::handleSelectionChange()
    (this=0x555555bf5e80) at ui/mediabrowser/MediaBrowser.cpp:958
0000013 0x0000555555713bf1 in ui::MediaBrowser::setSelection(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    (this=0x555555bf5e80, selection="\220\322A\230\377\177\000\000\340\327A\230\--Type <RET> for more, q to quit, c to continue without paging--ret
377\177\000\000\320\336A\230\377\177\000\000P\340A\230\377\177\000\000\320\340A\230\377\177", '\000' <repeats 26 times>, "\320\320A\230\377\177\000\000\370\320A\230\377\177\000\000\370\320A\230\377\177\000\000\060\333A\230\377\177\000\000\000\000\000\000\000\000\000\000\060\333A\230\377\177\000\000\006\000\000\000\000\000\000\000\070\333A\230\377\177\000\000\000\000\000\000\000\000\000\000\025\002\000\000\000\000\000\000\300\031$\367\377\177\000\000\200\326A\230\377\177\000\000\220\330A\230\377\177", '\000' <repeats 34 times>...)
    at ui/mediabrowser/MediaBrowser.cpp:638
0000014 0x00005555557115a2 in ui::MediaBrowser::onShaderClipboardSourceChanged()
    (this=0x555555bf5e80) at ../include/imodule.h:414
0000015 0x00007ffff0578cca in sigc::internal::signal_emit0<void, sigc::nil>::emit(sigc::internal::signal_impl*) (impl=0x555556cb6d50)
    at /usr/include/sigc++-2.0/sigc++/signal.h:798
0000016 0x00007ffff081e165 in sigc::signal0<void, sigc::nil>::emit() const
    (this=0x555555a3e7b8) at /usr/include/sigc++-2.0/sigc++/signal.h:2803
0000017 selection::ShaderClipboard::sourceChanged() (this=0x555555a3e750)
    at selection/shaderclipboard/ShaderClipboard.cpp:53
0000018 0x00005555556f3eb5 in ui::TextureBrowser::selectTextureAt(int, int)
    (this=<optimized out>, mx=<optimized out>, my=<optimized out>)
    at /usr/include/c++/10/bits/shared_ptr_base.h:1324
0000019 0x00007ffff7199661 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--ret
0000020 0x00007ffff71999fa in wxEvtHandler::SearchDynamicEventTable(wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000021 0x00007ffff7199a94 in wxEvtHandler::TryHereOnly(wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000022 0x00007ffff7199b4b in wxEvtHandler::ProcessEventLocally(wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000023 0x00007ffff7199bf1 in wxEvtHandler::ProcessEvent(wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000024 0x00007ffff719997b in wxEvtHandler::SafelyProcessEvent(wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000025 0x00007ffff7509f7e in ()
    at /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
0000026 0x00007ffff62ad6fb in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000027 0x00007ffff5c378fa in g_closure_invoke ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000028 0x00007ffff5c4a4b3 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000029 0x00007ffff5c50586 in g_signal_emit_valist ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000030 0x00007ffff5c50da3 in g_signal_emit ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000031 0x00007ffff6256514 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000032 0x00007ffff6104d50 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000033 0x00007ffff6106a93 in gtk_main_do_event ()
--Type <RET> for more, q to quit, c to continue without paging--ret
    at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000034 0x00007ffff5ddee89 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
0000035 0x00007ffff5e138e6 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
0000036 0x00007ffff58944db in g_main_context_dispatch ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000037 0x00007ffff5894788 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000038 0x00007ffff5894aa3 in g_main_loop_run ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000039 0x00007ffff61059fd in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000040 0x00007ffff74e8bf5 in wxGUIEventLoop::DoRun() ()
    at /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
0000041 0x00007ffff704dd41 in wxEventLoopBase::Run() ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000042 0x00007ffff70153da in wxAppConsoleBase::MainLoop() ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000043 0x00007ffff70a173d in wxEntry(int&, wchar_t**) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000044 0x000055555564f7c2 in main(int, char**)
    (argc=<optimized out>, argv=<optimized out>) at main.cpp:7
(gdb) continue
Continuing.
Couldn't get registers: El procés no existeix.
Couldn't get registers: El procés no existeix.
(gdb) [Thread 0x7fffea5f0640 (LWP 54077) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
quit
Attached Files:
Notes
(0012879)
greebo   
09.11.2020 04:08   
Crash confirmed in Ubuntu 20.10 with wxWidgets 3.0.5


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3419 [The Dark Mod] Coding minor always 15.05.2013 10:47 14.11.2020 04:07
Reporter: tels Platform:  
Assigned To: tels OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.00  
    Target Version: TDM 2.00  
Summary: in-game downloader does not randomize the server URLs
Description: This means the download will always try the first server, and upon success, download from there.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0005471)
tels   
15.05.2013 14:14   
Fixed with revision #5795. The list of URLs for the in-game FM downloader is now build by inserting at a random place and thus the URLs get mixed fairly well.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5396 [The Dark Mod] Design/Coding normal always 11.11.2020 14:18 13.11.2020 22:00
Reporter: MirceaKitsune Platform: x64  
Assigned To: OS: Linux openSUSE  
Priority: normal OS Version: Release  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Geometry becomes displaced when converting a func_static to a light entity
Description: Be aware that in this case I'm reporting something that might be intended to stay broken, as it's a slightly unorthodox thing I tried to do. As you know some light casting entities can be given 3D models by setting "model /foo/bar.lwo" on the entity, which is used by lamps to know how to color emissive textures with the light when toggled / flickering. This works properly when the light is given an external model (ase, obj, lwo) but things start to go wrong if you attempt to convert a bunch of brushes to func_static then turn them into a light. I did so because I wanted to create a light entity out of brushes, namely a neon out of a set of cylinder patches... I achieved this by keeping my func_static separate from the light entity in the end, but during my attempt to unify them I discovered quite a bit of breakage.

The issue happens in both DarkRadiant and while playing TheDarkMod, both will glitch out if you have a brush func_static converted to a light. What happens is that the geometry of the brush always changes its location and becomes offset from the center of the light entity. Things seem to work otherwise, but the func_static always needs to be converted to a light at origin 0 0 0, and even then you can't move or rotate the entity as this will cause the brushes to become displaced.
Tags: Bug, Glitch
Steps To Reproduce: Draw a bunch of brushes and / or patches. Select them all, right click in a 2D viewport, choose "convert to func_static". Now open the entity window with the N key, select the classname spawnarg, and modify it from "classname func_static" to "classname light".

At first everything may appear normal. However the brushes will have slid in a seemingly random direction; If you reload the map or try dragging the entity to move it, you should see them snap to the side, also you'll be dragging the light entity while its geometry stays in place. Even worse, if you go into Select Vertices mode, you will see the vertices of the brushes in one location but its real geometry in another (see the attached screenshot showing this effect).
Additional Information:
System Description
Attached Files: 8MAEusI.png (796,396 bytes) 11.11.2020 14:18
https://bugs.thedarkmod.com/file_download.php?file_id=931&type=bug
Notes
(0012901)
Judith   
13.11.2020 11:41   
This is just a wrong way to do it. You don't convert a func_static or a model to a light entity class. You add a "model" spawnarg to light entity. You can also have a model and attach a light source via spawnarg.
(0012908)
MirceaKitsune   
13.11.2020 18:34   
Yeah, I was hoping that converting a func_static to a light would be the same thing as adding a light and giving it the "model" spawnarg. If this issue could be resolved maybe it would work the same way then. But that's probably too complicated to do now, I mainly opened this just so it's known and don't expect too much can be done about it.
(0012913)
Judith   
13.11.2020 20:47   
You are changing one entity class to another, so that happens in all instances. It's a consistent and predictable behavior, not an issue.
(0012915)
MirceaKitsune   
13.11.2020 21:52   
What if I was able to create the entity without changing it? Currently if I select a group of brushes and try to convert them to a light, I get a plain light entity which only uses their radius but drops the model. I'm assuming it couldn't be solved this way either?
(0012917)
Judith   
13.11.2020 22:00   
https://wiki.thedarkmod.com/index.php?title=Combined_light_entities


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5393 [DarkRadiant] GUI normal always 10.11.2020 09:35 13.11.2020 19:24
Reporter: Bikerdude Platform: PC  
Assigned To: greebo OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: DR 2.9pre2 wont load from recently opened maps list
Description: Clicking on any of the last 5 opened maps does nothing.
Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files: Untitled.jpg (224,223 bytes) 10.11.2020 09:35
https://bugs.thedarkmod.com/file_download.php?file_id=930&type=bug
Notes
(0012889)
Spooks   
11.11.2020 08:44   
I tried and I couldn't reproduce this.
(0012891)
Bikerdude   
11.11.2020 09:15   
hmm, we are seeing some anomalies with this version. By that I wasnt able to reproduce some of the bugs you reported.

Back to this bug this is what I see in the console right after loading DR -

"Auto-saving registry to user settings path.
Cannot execute command LoadMRUMap: Command not found.
Auto-saving registry to user settings path."

@Spooks, when you click on a recent map and you post what you get in the console? it might help me/us troubleshoot the issue.
(0012892)
Spooks   
11.11.2020 09:26   
Nothing unusual,
"Open file [filepath].map from filesystem...success.
Auto-saving registry to user settings path.
Using Doom 3 format to load the data.
Open file [filepath].darkradiant from filesystem...success.
Parsing info file..."
(0012893)
Bikerdude   
11.11.2020 10:04   
I might just try and nuke all the config files reverting to a Vanilla state and see if that fixes it.
(0012895)
Bikerdude   
11.11.2020 10:19   
This can be closed, can confirm nuking the DR config folder from the "C:\Users\<username>\AppData\Roaming" fixes it.
(0012905)
greebo   
13.11.2020 16:49   
This is due to some XML tags in the user.xml file that are created after using DR 2.9.0.

Have a look in your user.xml file in the AppData Roaming folder. It's very likely that it contains statement bindings created by 2.9.0, like these:

<commandsystem>
  <binds>
  <bind name="MRUOpen1" value="LoadMRUMap 1"/>
  <bind name="MRUOpen2" value="LoadMRUMap 2"/>
  <bind name="MRUOpen3" value="LoadMRUMap 3"/>
  <bind name="MRUOpen4" value="LoadMRUMap 4"/>
  <bind name="MRUOpen5" value="LoadMRUMap 5"/>
  </binds>
  </commandsystem>

You can remove those from the user.xml (but close DR first), this ought to fix it.
(0012906)
greebo   
13.11.2020 16:51   
I'll assign this me, to add code preventing those tags from being written to user.xml.
(0012912)
Bikerdude   
13.11.2020 19:24   
thanks Greebo.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5404 [The Dark Mod] Objectives normal sometimes 13.11.2020 19:04 13.11.2020 19:04
Reporter: Geep Platform: Win 10  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unreliable "item is in location" objective
Description: An objective with component type "item is in location" often can not be made to work, either at all, or episodically.

Tags:
Steps To Reproduce: Here are consecutive posts by three different people in 2019 noticing the problem:
https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/page/350/&tab=comments#comment-438097

And I can't get it to work for me at all in late 2020. This is with a "Name of single entity" used for both Entity and Location. The latter is an info_tdm_objective_location as required and specified by the wiki description. The Entity placed (dropped in the location from inventory) was a moveable scroll with usual central origin and the required spawnarg "objective_ent 1". Following earlier forum suggestions, I also set that spawnarg on the location... made no difference.
Additional Information: I'm moving on to the recommended workaround alternative: "Two entities are within a radius of each other".

I'll also put a warning to others on the wiki page describing this component.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5391 [DarkRadiant] GUI normal have not tried 09.11.2020 12:52 13.11.2020 16:44
Reporter: Bikerdude Platform: PC  
Assigned To: greebo OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: On/off Selection issue with layers window
Description: - open any map
- open the layers window
- press LMB slowly but repeatedly (0.5 seconds or lower between clicks)

half of the time the layer will stay selected.
Tags:
Steps To Reproduce:
Additional Information: This is related to https://bugs.thedarkmod.com/view.php?id=5097
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files:
Notes
(0012886)
Bikerdude   
10.11.2020 09:40   
Is related to 0005097
(0012902)
greebo   
13.11.2020 16:39   
Found the source of this issue: when clicking repeatedly and fast enough, the wxToggleButton is receiving double-click events, which are then translated to toggle events - clicking three times fast in a row will issue 4 toggle events. Confirmed at least in the wxMSW implementation.
(0012903)
Bikerdude   
13.11.2020 16:43   
Nice work Greebo!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5395 [The Dark Mod] Physics feature always 11.11.2020 13:49 13.11.2020 11:32
Reporter: MirceaKitsune Platform: x64  
Assigned To: OS: Linux openSUSE  
Priority: low OS Version: Release  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Player needs horizontal movement to fall to the ground when the "gravity" spawnarg is set
Description: I plan to create a few maps that will use low gravity such as certain fantasy realms. I learned that the way to lower gravity for both the player and moveables (eg: when you pick up and throw a candle) is to change the gravity spawnarg on worldspawn. I tried this on my test map and set "gravity 100". It works in principle but is accompanied by an issue that currently makes it impossible to enable in a FM without bad results.

If the player jumps vertically (while standing perfectly still on the ground and not moving horizontally) while the gravity argument is set, they will no longer fall to the ground after reaching the peak of the jump but remain suspended in mid air instead. The player will only fall in low gravity maps if they are moving horizontally, in which case they are properly attracted back to the ground at the desired (lower or higher) rate.
Tags: Bug, Glitch, Physics
Steps To Reproduce: Set "gravity 100" on any worldspawn brush then recompile your map with dmap and start it up. Stand perfectly still and don't walk. Press jump to launch yourself in the air. Once you're reached the peak of the jump you'll remain suspended, until you press a movement key to attempt walking in which case you'll start falling to the ground again.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5400 [The Dark Mod] Feature proposal feature N/A 13.11.2020 10:29 13.11.2020 10:31
Reporter: stgatilov Platform:  
Assigned To: cabalistic OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.08  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version: TDM 2.10  
Summary: Initial support for gamepad controls
Description: Developer-only discussion:
  https://forums.thedarkmod.com/index.php?/topic/20503-gamepad-support/
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012898)
stgatilov   
13.11.2020 10:31   
Done in svn rev 8964 (by Cabalistic).

Note that there are no gamepad input mappings active by default (except for the main menu). That's still something we need to sort out.
Follow this guide to actually make the gamepad work: https://github.com/fholger/thedarkmodvr/wiki/Gamepad-support


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5292 [The Dark Mod] Sound System normal always 11.07.2020 21:21 11.11.2020 22:07
Reporter: MirceaKitsune Platform: x64  
Assigned To: OS: Linux openSUSE  
Priority: normal OS Version: Release  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stuttering sound and performance loss when using OpenAL HRTF
Description: Enabling the new OpenAL HRTF feature causes the sound to shutter (break up) to the point of becoming just random noises, while even graphical performance will stutter if starting up a game. If you wait for roughly 1 second to 1 minute, the issue eventually goes away and you start hearing sound normally as well as getting acceptable performance... the problem does however occur at every startup when that option is enabled.
Tags:
Steps To Reproduce: Enable Settings - Audio - OpenAL HRTF then restart: You should hear garbled sound on next startup.
Additional Information: TDM 2.08 (x64) on Linux openSUSE Tumbleweed (amdgpu / MESA)
System Description
Attached Files:
Notes
(0012652)
MirceaKitsune   
12.07.2020 13:37   
I looked in Darkmod.log, the in-game console, and the bash console when running the engine from it. There's one suspicious message which appears to be spammed countless times among other normal messages:

AL lib: (EE) ALCplaybackAlsa_mixerNoMMapProc: available update failed: Broken pipe
(0012897)
MirceaKitsune   
11.11.2020 22:07   
I played around with some of the settings in alsoft.ini (needs to be copied to alsoft.conf on Linux). Preliminary testing shows some great news: I may have found the culprit!

The issue appears to go away once I set "period_size = 64". Going at the other end, "period_size = 8192" also doesn't seem to do it oddly, but that causes a huge delay for all sounds. The issue is when I set it to a middle value like "period_size = 1024" to "period_size = 4096", that's what seems to cause it almost constantly... the distortions differ slightly based on this value. I can even add other improvements like "frequency = 48000" and it works!

I'll update if I still encounter it with these changes too. In the meantime please consider if based on this results, it might be a good idea to change the default value of period_size to something lower, seeing how this helps solve the problem. Any reason why it can't be 64 by default? The problem only seems to occur from 512 (very rare and brief then) and up (almost always starting from 1024), even a 256 should be safe if a slightly higher default is needed for other reasons.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5392 [DarkRadiant] GUI normal have not tried 09.11.2020 17:23 09.11.2020 18:48
Reporter: Bikerdude Platform: PC  
Assigned To: greebo OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Lost some keyboard shortcuts - 2.9pre2
Description: Bizarrely I had lost and had to reconfigure some keyboard short cuts

- ctrl-t , Thickening patches.
- shift-c, Create patch cap.
Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files:
Notes
(0012883)
greebo   
09.11.2020 17:47   
I can't bring back your shortcuts, but I added a remapping to the 2.9.0 config such that it shouldn't happen again for other users upgrading from 2.8.0.
(0012884)
Bikerdude   
09.11.2020 18:48   
Thanks Greebo.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5373 [DarkRadiant] Compilation/Build crash always 30.10.2020 04:14 09.11.2020 02:41
Reporter: BielBdeLuna Platform: Linux  
Assigned To: greebo OS: Ubuntu  
Priority: high OS Version: 20.10  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version:  
Summary: segfault when selecting a material in the media/textures list
Description: darkradiant was compiled from Github from: https://github.com/codereader/DarkRadiant.git
on this commit: https://github.com/codereader/DarkRadiant/commit/6e3df58918b6114f7650a8489549bfc97af49174

I get a segfault when selecting a material from the texture window

I provided a GDB stacktrace in the additional info.
Tags: Crash
Steps To Reproduce: Select the first texture in Doom3 set of textures within the texture window: textures / alphalabs / a_enwall13c

you'll get an imediate segfault
Additional Information: the stacktrace of gdb:

$ gdb darkradiant
GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from darkradiant...
(gdb) run
Starting program: /usr/local/bin/darkradiant
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff1b1a640 (LWP 29327)]
[New Thread 0x7ffff1319640 (LWP 29328)]

Thread 3 "gdbus" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff1319640 (LWP 29328)]
0x00007ffff69a766f in __GI___poll (fds=0x555555ab90a0, nfds=2, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
29 ../sysdeps/unix/sysv/linux/poll.c: El fitxer o directori no existeix.
(gdb) continue
Continuing.

Thread 2 "gmain" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff1b1a640 (LWP 29327)]
0x00007ffff69a766f in __GI___poll (fds=0x555555aa8f90, nfds=1, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
29 in ../sysdeps/unix/sysv/linux/poll.c
(gdb) continue
Continuing.
[New Thread 0x7fffa2ffd640 (LWP 29354)]

(darkradiant:29323): Gtk-WARNING **: 03:13:36.084: Negative content height -3 (allocation 1, extents 2x2) while allocating gadget (node checkbutton, owner GtkCheckButton)

(darkradiant:29323): Gtk-WARNING **: 03:13:36.084: for_size smaller than min-size (0 < 14) while measuring gadget (node check, owner GtkCheckButton)

(darkradiant:29323): Gtk-CRITICAL **: 03:13:36.084: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton

(darkradiant:29323): Gtk-WARNING **: 03:13:36.084: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node check, owner GtkCheckButton)

(darkradiant:29323): Gtk-WARNING **: 03:13:36.084: Negative content height -3 (allocation 1, extents 2x2) while allocating gadget (node checkbutton, owner GtkCheckButton)

(darkradiant:29323): Gtk-WARNING **: 03:13:36.084: for_size smaller than min-size (0 < 14) while measuring gadget (node check, owner GtkCheckButton)

(darkradiant:29323): Gtk-CRITICAL **: 03:13:36.084: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton

(darkradiant:29323): Gtk-WARNING **: 03:13:36.084: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node check, owner GtkCheckButton)

(darkradiant:29323): Gtk-WARNING **: 03:13:36.084: Negative content width -1 (allocation 1, extents 1x1) while allocating gadget (node scrolledwindow, owner GtkScrolledWindow)

(darkradiant:29323): Gtk-CRITICAL **: 03:13:36.085: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar

(darkradiant:29323): Gtk-WARNING **: 03:13:36.085: Negative content width -17 (allocation 1, extents 9x9) while allocating gadget (node entry, owner GtkEntry)

(darkradiant:29323): Gtk-WARNING **: 03:13:36.085: Negative content width -17 (allocation 1, extents 9x9) while allocating gadget (node entry, owner GtkEntry)

(darkradiant:29323): Gtk-WARNING **: 03:13:36.085: Negative content width -19 (allocation 1, extents 10x10) while allocating gadget (node button, owner GtkButton)

(darkradiant:29323): Gtk-WARNING **: 03:13:36.085: Negative content width -1 (allocation 1, extents 1x1) while allocating gadget (node scrolledwindow, owner GtkScrolledWindow)

(darkradiant:29323): Gtk-WARNING **: 03:13:36.085: Negative content width -14 (allocation 20, extents 17x17) while allocating gadget (node button, owner GtkButton)

(darkradiant:29323): Gtk-WARNING **: 03:13:36.085: Negative content height -1 (allocation 1, extents 1x1) while allocating gadget (node scrolledwindow, owner GtkScrolledWindow)

(darkradiant:29323): Gtk-CRITICAL **: 03:13:36.086: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar

(darkradiant:29323): Gtk-CRITICAL **: 03:13:36.086: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar

(darkradiant:29323): Gtk-CRITICAL **: 03:13:36.086: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar

(darkradiant:29323): Gtk-WARNING **: 03:13:36.086: Negative content width -14 (allocation 20, extents 17x17) while allocating gadget (node button, owner GtkButton)

(darkradiant:29323): Gtk-WARNING **: 03:13:36.087: Negative content width -17 (allocation 1, extents 9x9) while allocating gadget (node entry, owner GtkEntry)
[New Thread 0x7fffa27fc640 (LWP 29355)]
[New Thread 0x7fffa18fb640 (LWP 29356)]
[New Thread 0x7fffa0e7a640 (LWP 29357)]
[Thread 0x7fffa0e7a640 (LWP 29357) exited]
--Type <RET> for more, q to quit, c to continue without paging--ret

Thread 1 "darkradiant" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff243ba80 (LWP 29323)]
wxutil::TreeModel::GetParent (this=0x555556c28370, item=...)
    at TreeModel.cpp:586
586 return owningNode->parent->item;
(gdb) bt
#0 wxutil::TreeModel::GetParent(wxDataViewItem const&) const
    (this=0x555556c28370, item=...) at TreeModel.cpp:586
0000001 0x00007ffff7a4d457 in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000002 0x00007ffff7a5084c in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000003 0x00007ffff7a51e9b in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000004 0x00007ffff6230eff in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000005 0x00007ffff623696a in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000006 0x00007ffff62402d5 in gtk_tree_view_set_model ()
    at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000007 0x00007ffff7a4bb0e in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
#8 0x00007ffff7a4c84e in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000009 0x00007ffff79a5daa in wxDataViewModel::Cleared() ()
    at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000010 0x0000555555785f84 in ui::TexturePreviewCombo::refreshInfoTable()
    (this=0x555556c05c00) at ui/common/TexturePreviewCombo.cpp:62
0000011 0x000055555578636c in ui::TexturePreviewCombo::SetTexture(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    (this=0x555556c05c00, tex=...) at ui/common/TexturePreviewCombo.cpp:54
0000012 0x0000555555711eb5 in ui::MediaBrowser::handleSelectionChange()
    (this=0x555555ab2dc0) at ui/mediabrowser/MediaBrowser.cpp:954
0000013 0x00005555557121a1 in ui::MediaBrowser::setSelection(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    (this=0x555555ab2dc0, selection="\220\322A\214\377\177\000\000\340\327A\214\--Type <RET> for more, q to quit, c to continue without paging--ret
377\177\000\000\320\336A\214\377\177\000\000P\340A\214\377\177\000\000\320\340A\214\377\177", '\000' <repeats 26 times>, "\320\320A\214\377\177\000\000\370\320A\214\377\177\000\000\370\320A\214\377\177\000\000\060\333A\214\377\177\000\000\000\000\000\000\000\000\000\000\060\333A\214\377\177\000\000\006\000\000\000\000\000\000\000\070\333A\214\377\177\000\000\000\000\000\000\000\000\000\000\025\002\000\000\000\000\000\000\300\031$\367\377\177\000\000\200\326A\214\377\177\000\000\220\330A\214\377\177", '\000' <repeats 34 times>...)
    at ui/mediabrowser/MediaBrowser.cpp:636
0000014 0x000055555570fb32 in ui::MediaBrowser::onShaderClipboardSourceChanged()
    (this=0x555555ab2dc0) at ../include/imodule.h:414
0000015 0x00007ffff057ab3a in sigc::internal::signal_emit0<void, sigc::nil>::emit(sigc::internal::signal_impl*) (impl=0x555556cad780)
    at /usr/include/sigc++-2.0/sigc++/signal.h:798
0000016 0x00007ffff081fbf5 in sigc::signal0<void, sigc::nil>::emit() const
    (this=0x555555a77cc8) at /usr/include/sigc++-2.0/sigc++/signal.h:2803
0000017 selection::ShaderClipboard::sourceChanged() (this=0x555555a77c60)
    at selection/shaderclipboard/ShaderClipboard.cpp:53
0000018 0x0000555555711f15 in ui::MediaBrowser::handleSelectionChange()
    (this=0x555555ab2dc0) at ../include/imodule.h:414
0000019 0x00007ffff7199661 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000020 0x00007ffff71999fa in wxEvtHandler::SearchDynamicEventTable(wxEvent&) ()
--Type <RET> for more, q to quit, c to continue without paging--ret
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000021 0x00007ffff7199a94 in wxEvtHandler::TryHereOnly(wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000022 0x00007ffff7199b4b in wxEvtHandler::ProcessEventLocally(wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000023 0x00007ffff7199bf1 in wxEvtHandler::ProcessEvent(wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000024 0x00007ffff719997b in wxEvtHandler::SafelyProcessEvent(wxEvent&) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000025 0x00007ffff7a59f97 in () at /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0
0000026 0x00007ffff5c37b56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000027 0x00007ffff5c50bbf in g_signal_emit_valist ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000028 0x00007ffff5c50da3 in g_signal_emit ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000029 0x00007ffff623d34b in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000030 0x00007ffff6245690 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000031 0x00007ffff62b3cff in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000032 0x00007ffff5c37b56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000033 0x00007ffff5c50bbf in g_signal_emit_valist ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000034 0x00007ffff5c50da3 in g_signal_emit ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--ret
0000035 0x00007ffff60bb531 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000036 0x00007ffff5c3ad14 in g_cclosure_marshal_VOID__BOXEDv ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000037 0x00007ffff5c37b56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000038 0x00007ffff5c50bbf in g_signal_emit_valist ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000039 0x00007ffff5c50da3 in g_signal_emit ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000040 0x00007ffff60b8046 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000041 0x00007ffff60b963f in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000042 0x00007ffff60bc803 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000043 0x00007ffff60820c0 in gtk_event_controller_handle_event ()
    at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000044 0x00007ffff625441d in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000045 0x00007ffff62ad6fb in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000046 0x00007ffff5c378fa in g_closure_invoke ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000047 0x00007ffff5c49f0e in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000048 0x00007ffff5c50586 in g_signal_emit_valist ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000049 0x00007ffff5c50da3 in g_signal_emit ()
    at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000050 0x00007ffff6256514 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
--Type <RET> for more, q to quit, c to continue without paging--ret
0000051 0x00007ffff6104d50 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000052 0x00007ffff6106a93 in gtk_main_do_event ()
    at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000053 0x00007ffff5ddee89 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
0000054 0x00007ffff5e138e6 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
0000055 0x00007ffff58944db in g_main_context_dispatch ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000056 0x00007ffff5894788 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000057 0x00007ffff5894aa3 in g_main_loop_run ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000058 0x00007ffff61059fd in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0
0000059 0x00007ffff74e8bf5 in wxGUIEventLoop::DoRun() ()
    at /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
0000060 0x00007ffff704dd41 in wxEventLoopBase::Run() ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000061 0x00007ffff70153da in wxAppConsoleBase::MainLoop() ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000062 0x00007ffff70a173d in wxEntry(int&, wchar_t**) ()
    at /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
0000063 0x000055555564f412 in main(int, char**)
    (argc=<optimized out>, argv=<optimized out>) at main.cpp:7
(gdb) continue
Continuing.
Couldn't get registers: El procés no existeix.
Couldn't get registers: El procés no existeix.
(gdb) [Thread 0x7fffa18fb640 (LWP 29356) exited]
[Thread 0x7fffa27fc640 (LWP 29355) exited]
[Thread 0x7ffff1319640 (LWP 29328) exited]
[Thread 0x7ffff1b1a640 (LWP 29327) exited]
--Type <RET> for more, q to quit, c to continue without paging--ret

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
Attached Files:
Notes
(0012850)
greebo   
30.10.2020 16:52   
Thanks for the detailed report!
(0012875)
BielBdeLuna   
08.11.2020 20:11   
the issue seems to be resolved now


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5383 [DarkRadiant] Models normal always 08.11.2020 05:30 08.11.2020 16:29
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version:  
Summary: Reported Polycount for LWO models is one too high
Description: The LWO PicoModel importer generates too many indices in the index array, it looks like this:

0 0 0 0 1 2 ...

The first three indices are all 0, forming a degenerate face, but it also misleads the RenderablePicoModelSurface::getNumTriangles() which is calculating the number of tris by dividing the length of the index array by 3.
Tags:
Steps To Reproduce: Model: tdm_models01.pk4\models\darkmod\mechanical\receiver_antenna.lwo is reported to have 61 polys, but it only has 60 (check it out in Blender)
Additional Information:
Attached Files: receiver_antenna_lwo.png (36,030 bytes) 08.11.2020 05:30
https://bugs.thedarkmod.com/file_download.php?file_id=918&type=bug
Notes
(0012868)
greebo   
08.11.2020 05:56   
The problem is that in pm_lwo.c:300 the polycount is upped a tad too early

/* We haven't discarded this polygon, so bump the surface polycount */
surfacePolyCount++;

Since this variable is used to calculate the array offset when storing the indices later. The array will auto-adjust, so no buffer overrun will occur, but the first three indices will remain at their initialised values: 0 0 0


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5250 [The Dark Mod] Distribution major N/A 11.05.2020 09:45 08.11.2020 04:01
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: high OS Version:  
Status: assigned Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: New differential update and weekly builds
Description: Full description is provided here:
  https://forums.thedarkmod.com/index.php?/topic/19837-208-new-tdm_update/

The rough idea is to:
1) Add new type of manifests, listing all files inside zips with secure BLAKE2 hashes.
2) Differential update over HTTP, downloading chunks directly from zips (strongly ties updater to zip file format).
3) Allow using several manifest/sources to build single version of TDM.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012486)
cabalistic   
11.05.2020 10:20   
Purely out of curiosity: why BLAKE2, specifically? :)
(0012487)
stgatilov   
11.05.2020 10:28   
It is quite recent and secure. And among such hashes, this one is very fast.

Since the updater will update from arbitrary current state, it will have to compute hashes of the whole TDM installation every launch.
This is the biggest downside of the new system, so the speed of hashing matters a lot.
(0012488)
stgatilov   
11.05.2020 10:29   
Moreover, it is 32-bit BLAKE2 hash, since our Windows updater is still 32-bit =)
Although it we would stop providing 32-bit build of TDM out of the box, it would probably make sense to make updater 64-bit too.
(0012489)
cabalistic   
11.05.2020 10:40   
Ok, fair enough :) Btw. the BLAKE2 website states that BLAKE3 is available and even faster :D

What is not clear to me, though, is if the speed comparisons against other hash algorithms take hardware acceleration into account? For example, SHA1 and SHA256 have specific SSE instructions supported by Intel and Ryzen CPUs.
(0012490)
stgatilov   
11.05.2020 11:10   
I think SHA instructions are not taken into account, because only the most recent CPUs have them. I wouldn't rely on them either.
BLAKE2 uses something like SSE2 which is taken into account and is in fact required by most software.
Besides, are there instructions to accelerate SHA2 and SHA3 computation?

BLAKE3 did not even come out when I searched for a hash function. And I don't see any security analysis of it yet.
(0012491)
cabalistic   
11.05.2020 11:17   
SHA-256 and SHA-224 are supported as part of the SHA-2 family, but nothing above that. Also you're right; it appears that Intel has chosen to implement those instructions only on a subset of specialized CPUs, and for standard desktop CPUs the instructions are only available from Cannon Lake upwards. So actually, AMD with Ryzen now has probably more widespread support for it than Intel :D
(0012644)
stgatilov   
02.07.2020 17:30   
I decided to settle on FLTK for GUI.
Perhaps one day we can use it for tools --- although we should decide if it would be better or worse than ImGui.

Added third-party libs: svn rev 8784 and 8786.

First version of installer committed in svn rev 8790 and 8791.
Of course, nothing works properly there =) I have just started.

The zipsync subdirectory will be kept in sync with my GitHub repo:
  https://github.com/stgatilov/zipsync
But updating that repo is purely my own responsibility, of course.
(0012647)
stgatilov   
09.07.2020 16:49   
After a lot more fixes, the installer has been published for preliminary testing:
  https://forums.thedarkmod.com/index.php?/topic/20460-new-tdm_installer-and-dev-builds/
(0012661)
stgatilov   
19.07.2020 12:53   
(Last edited: 19.07.2020 12:53)
Something like 7 updates to tdm_installer has already been published, and it is fairly usable now.

I have also written a detailed wiki article about it:
  https://wiki.thedarkmod.com/index.php?title=Tdm_installer_and_zipsync
(0012865)
stgatilov   
08.11.2020 04:01   
Added two new features:

1) Better mirrors handling.
First of all, mirrors can now be weighted in config file --- for better load balancing.
Second, if one mirror goes down, it does not prevent installation now.
Except for the core files (installer, config, target manifest), which must always come from the main TDM server.

2) Added "unattended" mode.
In theory, it allows installing TDM as part of some script.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4635 [The Dark Mod] Design/Coding normal always 15.10.2017 17:22 07.11.2020 17:28
Reporter: VanishedOne Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.05  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: New portalSky method is see-through like caulk skies... which isn't always desirable
Description: g_enablePortalSky 2 prevents the skybox clipping models. As with caulk skies, this is usually desirable, but see the attached image for a case where it isn't.
Tags:
Steps To Reproduce:
Additional Information: The workaround for a mapper in this situation seems to be to make a copy of the portal_sky material and call it portal_sky2 or something. (So the issue may not need fixing, but it's worth documenting that mappers may do this.)
Attached Files: portalsky.png (213,407 bytes) 15.10.2017 17:22
https://bugs.thedarkmod.com/file_download.php?file_id=500&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5382 [DarkRadiant] Map Editing feature unable to reproduce 07.11.2020 10:31 07.11.2020 15:47
Reporter: IZaRTaX Platform: PC  
Assigned To: OS: Windows 7 Ultimate Edition ‎X64  
Priority: normal OS Version: 2/26/2019  
Status: acknowledged Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Merge patch connect patches
Description: You can split patch but you cannot connect patch, honestly I would like a way to connect patches if it possible like that.
https://www.youtube.com/watch?v=WpNIcrvm4tw

OD Radiant has the similar tools and open source check here > https://sourceforge.net/p/odblur/code/HEAD/tree/code/OverDose%20Tools/ODRadiant/
> https://overdose-game.com/sdk.html

https://forums.thedarkmod.com/uploads/monthly_2020_11/od_t.png.9b87ee463ae745b800cdeb3296171f48.png

I hope you'll do it in the future :)
Tags: merge patch connect patch
Steps To Reproduce: Merge / combine patch
Additional Information: Good luck if you can release it !
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5381 [DarkRadiant] Map Editing normal have not tried 07.11.2020 04:31 07.11.2020 04:32
Reporter: greebo Platform: Linux  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Linux: Can't copy / paste items, no clipboard module attached
Description: Running into another little issue with DarkRadiant recently: I can no longer copy and paste brushes and entities. When I attempt to DR tells me there's no clipboard module attached.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5366 [DarkRadiant] Compilation/Build normal always 24.10.2020 06:40 07.11.2020 04:23
Reporter: MirceaKitsune Platform: Linux  
Assigned To: greebo OS: openSUSE  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Binaries are installed differently by Automake in openSUSE and requires lib->lib64 symlink
Description: Following the discussion here:

https://forums.thedarkmod.com/index.php?/topic/20599-darkradiant-git-master-compiles-but-wont-start-missing-libraries-and-modules/

There seems to be a difference in openSUSE compared to regular Ubuntu when it comes to SITE_CONFIG, DarkRadiant is installed in lib64, but still tries to access files through the "lib" folder
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5374 [DarkRadiant] Saving and loading crash always 30.10.2020 23:02 07.11.2020 04:19
Reporter: Spooks Platform:  
Assigned To: greebo OS:  
Priority: high OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Ctrl+C attempts to save the map, then crashes DarkRadiant
Description: As above. Keybindings point to "Ctrl~C" being "Copy". I even re-set it and tried again. Crash.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012852)
greebo   
01.11.2020 07:48   
I got the crash (and fixed that in source), but I can't get it to ask me to save the map.
Can you elaborate what you are doing to get the save prompt?
(0012853)
Spooks   
01.11.2020 19:39   
The prompt that flashes is "Attempting to write to file" or something to the effect. It has no buttons, just a progress bar (that doesn't progress any before crashing FWIW). I've been thinking that it might not be EXACTLY the same prompt as the "saving map" one, I can't see what that one says at the start because it goes by too fast.

I am not doing anything besides pressing Ctrl+C to get that to show up. If you thought I meant something like the "Save File" folder dialogue window, none of that shows up, sorry for not being super clear.
(0012854)
greebo   
02.11.2020 12:11   
What you're seeing is the map progress dialog, which I guess hasn't been there before 2.9.0. If it's too distracting, then I can see into suppressing it somehow.
(0012863)
Spooks   
03.11.2020 17:31   
If it's just a progress bar for saving the chunk of map as it's getting put in the clipboard I'm neutral on having it visible or not. If it should stay I only suggest that it's renamed - if it can be for that particular instance of it showing up - to something like "saving to clipboard" as writing "to file" can give the wrong impression.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5379 [DarkRadiant] Design/Coding normal have not tried 03.11.2020 19:06 03.11.2020 19:07
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Log file not created in Windows
Description: The Windows port doesn't write the log file to c:\users\blah\appdata\roaming\darkradiant like it used to.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5360 [The Dark Mod] TDM Updater normal have not tried 15.10.2020 10:20 03.11.2020 15:45
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.08  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version: TDM 2.09  
Summary: Error "Assertion pos != std::string::npos" when starting updater
Description: Cannot use the tdm_installer due to error:
  ERROR: Assertion pos != std::string::npos failed in G:\TheDarkMod\darkmod_src\tdm_installer\zipsync\Path.cpp on line 80
The error happens straight on startup.
Tags:
Steps To Reproduce:
Additional Information: (Reported by Bikerdude)
Attached Files: log.txt (5,299 bytes) 15.10.2020 10:21
https://bugs.thedarkmod.com/file_download.php?file_id=910&type=bug
Notes
(0012816)
stgatilov   
15.10.2020 10:21   
The logfile.
(0012817)
stgatilov   
15.10.2020 10:29   
The problem originally happened when downgrading from dev1610-8948 to 2.08.
(0012818)
stgatilov   
15.10.2020 10:32   
The problem has disappeared by removing all files starting with __repacked__.
It seems that restoration code in CommandLine.cpp is buggy.
(0012862)
stgatilov   
03.11.2020 15:44   
Fixed in svn rev 8968.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5378 [The Dark Mod] Textures normal always 03.11.2020 15:28 03.11.2020 15:37
Reporter: Bikerdude Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Broken Particle - pagan_orb_effect
Description: There are 4 stages for this particle and 3 of them point to missing shaders -

Stage1 - textures/particles/bfgballblast - suggest 'textures/decals/dirtblast' and change colour to 0.060 0.170 0.070 1.000 to match 'stage 0'
Stage2 - textures/sfx/vp1 - shows in DR with no texture, assume this is normal?
Stage3 - textures/particles/p_lightning6 - suggest 's_lightening2_whi' instead

Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
67 [DarkRadiant] Map Editing feature always 28.01.2007 19:38 03.11.2020 12:39
Reporter: SneaksieDave Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: suspended Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Patch Splitting
Description: I'm not even sure this is possible, but if so, this would be a big one. :)

Basically, the same way the clipper operates on brushes, the same tool or one similar to clip patches. I assume it would be a matter of deleting the current patch and then rebuilding the same geometry with two patches split along the cut line. Sounds simplistic enough, and I imagine D3 would handle it - you can make some really flexible geometry with patches - but I guess the math could be a nightmare.

Example: A round tower with windows cut out of it. Currently this must be done by hand-shaping all required patches. It is managable, but tricky and time consuming. With this functionality, it'd be a matter of making a cylinder, and then a few appropriate cuts.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0000046)
orbweaver   
29.01.2007 11:13   
It should be possible to cut patches by creating two new patches, with matching edge vertices along the cut line. However, it cannot be guaranteed that the curvature will match the original patch, so there might be visible bump along the join.
(0000047)
greebo   
29.01.2007 12:08   
(Last edited: 29.01.2007 12:08)
I believe keeping the curvature is very hard to do, as the tesselation of the patch consists of a lot of bezier curves. Cutting through the curve means that you have to reversely calculate two patches that end exactly at that edge, which I doubt to be possible with appropriate accuracy.

Maybe it would be possible to split a patch along its control vertices (as Orbweaver suggested), but this could be hard as well.

Imagine a 90° patch where you cut along the "corner" vertices. The new patches would form a perfectly sharp edge (similar to the turning off the "smoothing" of faces in Blender).

(0000715)
greebo   
21.06.2007 10:00   
I set this to suspended, I don't quite believe that this is feasible.
(0006800)
nbohr1more   
24.07.2014 13:05   
Can this be marked as resolved:

http://forums.thedarkmod.com/topic/16090-patch-splitting-in-dark-radiant-new-version-29-mar/

?
(0006801)
SteveL   
24.07.2014 15:50   
(Last edited: 24.07.2014 15:51)
I didn't know about this tracker issue when fiddling with that script.

To be clear, the script doesn't solve the hardest problem discussed here, which would let a patch be cut along any line. It only makes a cut along an existing row or column of control vertices.

But it does let you do the thing requsted in the original OP -- cut window and door holes in a round cylinder, as demo'd in the video. You just have to add some control verts first. In my map which I make very slow progress on, I have round towers with thick walls and cross-shaped loopholes on the outside that the player can apparently look in and out of ("apparently": there's a cheat for performance). You just have to set up your control verts first and then texture it before cutting up the patch because you'll have no chance of getting the textures lined up again if you try to adjust it in any way after snipping the cylinder into 40-odd parts.

(0012859)
Bikerdude   
03.11.2020 12:39   
(Last edited: 03.11.2020 12:39)
Can this be looked at for DR 2.9..? that said this is a very old bug so I will check if it is even relevant any more.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5124 [DarkRadiant] Design/Coding normal always 12.01.2020 12:54 03.11.2020 12:30
Reporter: Bikerdude Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: DR slow/laggy to move light sources around - on large maps
Description: This is an old bug - if you have to move a light source around or adjust its light radious - its very very laggy. Current work around is to select the light and/or the objecting near where you moving the light to and press shift-h then its smooth again.
Tags:
Steps To Reproduce: - Open DR.
- Go into Orthoview.
- Select any light source (models or pure source)
- press LMB and move the entity around
Additional Information: My guess is when the entity count goes above a certain paint DR is running into some kind of issue, that causing the lag.
Attached Files:
Notes
(0012439)
Bikerdude   
01.05.2020 12:38   
(Last edited: 01.05.2020 12:39)
Is it possible to know whats causing the lag, or is it just not realisticlly fixable..?
(0012443)
greebo   
01.05.2020 12:49   
There's a lot going on when manipulating lights in large maps. It's due to the way DR is keeping track of lit objects, which is in fact very inefficient.
It can be fixed by changing the way it's done, but of course this is not exactly trivial.
(0012856)
Bikerdude   
03.11.2020 12:30   
Well the work around I have for this is to press 'shift-H' to hide everything bar the light and or model I am trying to move around.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5376 [The Dark Mod] Coding crash always 01.11.2020 17:54 01.11.2020 17:54
Reporter: grayman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Quiet crash if a script has syntax problems
Description: When TDM is trying to load a new mission, if there are syntax problems with the <mymission>.script file, TDM can quietly crash without saying why.

It would be nice if TDM's script parser identified when there's a syntax problem, and displayed a message saying so, w/o just going away. The exact location in the script file would be nice, but the minimum would be to declare that there's a problem with the script file.

This can save time for those of us who include lots of scripting in our missions, but occasionally screw up a nested comment or some other syntax problem.

Thanks.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5375 [DarkRadiant] Compilation/Build normal have not tried 31.10.2020 04:46 01.11.2020 05:31
Reporter: PranQster Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version:  
Summary: Build failure in Mageia 8
Description: checking for GL/glew.h... yes
checking for main in -lGLEW... no
configure: error: GLEW not found

I have built DR many times in the past, and always make sure the dependencies are installed, etc. I have never had an issue w/ GLEW dependencies before. DR 2.8.0 built properly for me a few months ago, but now I get this.

lib64glew-devel
Version: 2.1.0-5.mga8
        Currently installed version: 2.1.0-5.mga8
        Group: Development/C
        Architecture: x86_64
        Size: 1584 KB
Tags:
Steps To Reproduce:
Additional Information: https://forums.thedarkmod.com/index.php?/topic/20608-darkradiant-290-pre-release-testing/&do=findComment&comment=452644
Attached Files:
Notes
(0012851)
greebo   
01.11.2020 05:31   
Resolved, it works again in Mageia 8, except for the google test linker test. The latter has been broken by a recent change to autoconf's c.m4, where AC_LANG_CALL(C++) doesn't deal with the main symbol correctly.
https://lists.gnu.org/archive/html/bug-autoconf/2020-10/msg00056.html


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5370 [DarkRadiant] General normal always 28.10.2020 05:02 31.10.2020 10:57
Reporter: grayman Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Cubic clip button doesn't toggle.
Description: Details here:

https://forums.thedarkmod.com/index.php?/topic/20608-darkradiant-290-pre-release-testing/&tab=comments#elControls_452548_menu
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5338 [DarkRadiant] Design/Coding normal have not tried 21.09.2020 03:55 28.10.2020 05:14
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Split Camera code into model and UI
Description: Some algorithms contained in the core binary rely on the camera position and angles, so even without any UI attached the core module needs to maintain one or more ICameraView instances.

The plan is to split off the ICameraView parts and move them to the core module, managed by a GlobalCameraViewManager. Leave the rest of the CamWnd implementation in the UI binary.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5346 [DarkRadiant] Map Editing normal N/A 28.09.2020 17:24 27.10.2020 07:38
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: TDM Game Connection Plugin
Description: Following the discussion in https://forums.thedarkmod.com/index.php?/topic/20493-connection-to-tdm-with-automation/

The game connection plugin can communicate with the running TDM game to facilitate tasks and perform camera synchronisation.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012809)
Bikerdude   
09.10.2020 21:21   
I have been playing with this for a few weeks and the changes made in DR dont always replicate in TDM. Whe n I get the time I will have to make a test map to demonstrate.
(0012843)
greebo   
27.10.2020 04:09   
Settings this to resolved until further feedback arrives.
(0012844)
Bikerdude   
27.10.2020 07:38   
I haven't been using this function that much due to the automation not being consistent, which I think is more not understanding fully how I am supposed to be using it and wanting to just get on with mapping.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3872 [The Dark Mod] AI normal always 08.10.2014 19:29 26.10.2020 23:08
Reporter: grayman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 2.02  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unused "return_with_help*" barks
Description: These barks aren't being used:

return_with_help
return_with_help_escaped

They should be used when a fleeing AI has returned to the scene of the crime with an armed escort.

This might be difficult to do, because the only reason a fleeing AI would return is to search the area himself. It only appears that he's bringing someone back with him.

We need to add code to the Flee task that brings the AI back to the search area iff he finds an armed friend who can return with him. Then we'll know it's time to play the above barks when they get to where they're going.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011571)
Springheel   
10.02.2019 18:58   
(Last edited: 10.02.2019 19:00)
Ok, the addition is complete for all humanoid sets (monsters don't need these barks).

Full description of when these barks would be appropriate:

"snd_request_help" -- this is played by an AI that was in flee state, found a friendly guard, and is currently requesting that the guard follow them back to the player's location. Ex. "Follow me!"

"snd_return_with_help" -- this is played by an AI that was in flee state, found a friendly guard, is being followed by that friendly guard, and then spots the player. Ex "See, I told you! There he is!"

"snd_return_with_help_escaped" -- this is played by an AI that was in flee state, found a friendly guard, is being followed by that friendly guard, returns to the spot where the player was last seen, but the player can no longer be seen. Ex. "He was right here, I swear."

It may be worth considering whether this behaviour makes sense for AI who are fleeing due to damage. Should a heavily wounded AI come back to the danger zone himself, even to lead other guards there? Or would this make sense only for civilian AI?

(0012842)
grayman   
26.10.2020 23:08   
Removing myself as "Assigned To" because I doubt I will ever have time to work on it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4326 [The Dark Mod] AI normal random 25.05.2016 18:48 26.10.2020 23:07
Reporter: grayman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.04  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Searching AI problem in Awaiting the Storm
Description: AI have a difficult time on the second floor of Awaiting the Storm, while searching for and attacking the player in tight quarters.
Tags:
Steps To Reproduce: Use the attached savegames, or if they no longer work when 2.04 is released, recreate the scene by running through AtS and gathering up 2 or more guards to chase you to the 2nd floor dining room.
Additional Information:
Attached Files: storm_saves.zip (3,135,910 bytes) 25.05.2016 18:48
https://bugs.thedarkmod.com/file_download.php?file_id=404&type=bug
Notes
(0008172)
grayman   
25.05.2016 19:38   
First reported here:

http://forums.thedarkmod.com/topic/18074-beta-testing-204/page-4#entry389531
(0009260)
grayman   
16.09.2017 18:09   
Removing target release version. Will target to 2.07 when that shows up on the list of revs.
(0009760)
grayman   
11.12.2017 21:57   
In my set of sources, this one might have some work I've already done on this:

Y:/TDM/TDMSource/darkmod_src_2.04_4326
(0010972)
nbohr1more   
19.12.2018 14:16   
2.08?
(0010973)
grayman   
19.12.2018 17:54   
I tested this in 2.07 beta, and it looks much better than I remember it back when this issue was filed. I did some work in 2.07 in the area of chasing/throwing, so maybe that had a positive effect here.

3 guards chasing me around while I was up on the tables. They were either chasing or swatting me with swords or throwing rocks. No treadmilling at any time. I ran back and forth to several tables, so I covered a fair amount of space.

If a couple other people can check it, and it looks okay, I would just close it as fixed in 2.07.

If problems persist, move it to 2.08.
(0010974)
nbohr1more   
19.12.2018 17:58   
Thanks for the confirmations. In feedback until more beta testing data comes back. I'll double check too.
(0010988)
nbohr1more   
20.12.2018 04:47   
Hmm...

I'm seeing pretty much the 2.04 behavior here.

Coordinates where I stopped and allowed AI to chase me:

-641.01 -707.5 276.25 : 12.1 -2.29 0
(0012841)
grayman   
26.10.2020 23:07   
Removing myself as "Assigned To" because I doubt I will ever have time to work on it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4955 [The Dark Mod] Mapping minor always 10.01.2019 04:33 26.10.2020 23:07
Reporter: stgatilov Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: confirmed Product Version: TDM 2.07  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Wrongly black interaction light on a crate
Description: Originally reported here:
  http://forums.thedarkmod.com/topic/19774-beta-testing-207/page-9#entry432791
There is a video also.
Tags:
Steps To Reproduce: 1) Start "William Steele 4: The Warrens" FM
2) Execute: setviewpos 5362.51 1166.37 583.25 53.6
3) Look at the crate under candle. You can also move candle around.

Note that the problem only appears with "enhanced" interaction shader.
Additional Information:
Attached Files: issue4955_normals.png (485,188 bytes) 26.01.2019 08:10
https://bugs.thedarkmod.com/file_download.php?file_id=716&type=bug
Notes
(0011291)
stgatilov   
10.01.2019 04:34   
The reason for issue is that when the ARB interaction shader was ported to GLSL, some clamps got missing. Here is the full story:
  http://forums.thedarkmod.com/topic/19064-glsl-interaction-shader/page-10#entry432850
(0011292)
stgatilov   
10.01.2019 04:38   
(Last edited: 16.01.2019 16:58)
Fixed in rev 15546.

Note that while clamps are exactly the same, and the code is logically the same, one subtle difference from the ARB version remains.
In ARB version, all dot products (NdotL, NdotH, NdotV) were computed from TANGENT-space normal and directions.
In GLSL version, all these dot products are computed from world-space normal and directions.
The difference means slight difference in interpolation errors.

UPDATE: There was an error in the initial description saying that ARB version used object space. It used tangent space, which makes a big difference.
Anyway, it turns out that interpolation matters.

(0011359)
stgatilov   
16.01.2019 17:01   
Follow-up problem:
  http://forums.thedarkmod.com/topic/19774-beta-testing-207/page-10#entry433034
(0011385)
STiFU   
17.01.2019 11:36   
Fix confirmed on WS4. Since the follow-up problem is now resolved, this one can be set to fixed, too.
(0011504)
stgatilov   
26.01.2019 05:00   
Since beta207-06, this problem happens again. It is caused by moving from world space back into tangent space (which is required for good mesh smoothing).

I compared it with TDM 2.05, and the problem happens there too.
I think this problem will not be in shader: the crate itself has to be fixed. Something is wrong with it.
(0011508)
stgatilov   
26.01.2019 08:12   
Attached an image obtained using:
  r_showTangentSpace 3
  r_skipAmbient 3
  r_skipInteractions 1
It shows normal of each fragment encoded into color.

It is clear that good crates have flat normal with sharp changes on the edges, while the crates with the problem have smoothly changing normal over a large flat face, and sometimes normal even changes smoothly from one face to another when going over an edge.
(0011980)
stgatilov   
30.12.2019 04:55   
In my opinion the model of the crate is bad.
This is the map-specific model (I guess a merge of several standard models):
  // entity 6909
  {
  "classname" "func_static"
  "name" "func_static_1140"
  "model" "models/darkmod/map_specific/steele/smythe_5.lwo"
  "origin" "5449.81 1280.2 564.684"
  "rotation" "1 0 0 0 1 0 0 0 1"
  }

I'm moving this to mapping category, assigning to author for now.
Also reducing priority/severity, since it does not stop players from enjoying the FM.
(0012840)
grayman   
26.10.2020 23:07   
Removing myself as "Assigned To" because I doubt I will ever have time to work on it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4982 [The Dark Mod] AI normal N/A 31.01.2019 13:10 26.10.2020 23:07
Reporter: grayman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 2.07  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: KO'ed AI should drown faster
Description: There have been reports of KOing AI and dropping them into water, expecting they'll drown.

But it takes a long time.

Investigate and make sure that drowning is more realistic. (I.e. there's no 'grace period' like there is with the player, who is conscious.)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011531)
STiFU   
01.02.2019 18:23   
As far as I can tell, AI use the same airless damage routine as the player. Hence, reducing their airtics should already do the trick.
(0011533)
grayman   
01.02.2019 19:00   
(Last edited: 01.02.2019 19:01)
AI and the Player use different routines. (UpdateAir())

What I was looking for was if AI were KO'ed, not to let the "grace period" apply. That code is already there. So reducing the airtics for a KO'ed AI won't change anything, since it's already reduced to 0 each time the AI breathes.

One problem I see is the setting of m_AirCheckInterval, which is set once at spawn time, to a random duration of 1-5 seconds. So if an AI is assigned a value near 5, he'll drown more slowly than an AI who's assigned a value near 1.

To provide more uniformity, m_AirCheckInterval should prolly be recalculated each time UpdateAir() is run, rather than use a fixed value set at spawn time.

Math with current code:

Assume 100 health.
Air damage is 10.
Quick-dying KO'ed AI will die in (1 + random interval)*health/damage, so (1+0)*100/10 = 10 seconds. Slower dying AI can take up to (1+4)*100/10 = 50 seconds. It's these later guys that are prolly causing the reports to come in.

Math with random intervals recalculated each breath:

(1+4/2)*100/10 = 30 seconds.

To make them die more quickly, the "4" can be lowered, so a random duration will be between, say, 1s and 3s, which would reduce death to

(1+2/2)*100/10 = 20 seconds.

Something like that.

(0012839)
grayman   
26.10.2020 23:07   
Removing myself as "Assigned To" because I doubt I will ever have time to work on it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4222 [The Dark Mod] Coding normal have not tried 28.09.2015 23:56 26.10.2020 23:06
Reporter: grayman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 2.03  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Might be a Mission Stats problem with registering alerts
Description: Look through the code and reconcile the use of:

Pre_AlertAI()
Event_AlertAI()
SetAlertLevel()

and the old way of doing things, which probably only involved

AlertAI()
Tags:
Steps To Reproduce:
Additional Information: CMissionData::AlertCallback() needs to be called for the rise in alert level to be registered with the stats. It might be that this is bypassed for certain alerts.

Find out if it's this way on purpose, or does AlertCallback() need to be moved inside SetAlertLevel().
Attached Files:
Notes
(0007808)
grayman   
29.09.2015 01:54   
(Last edited: 29.09.2015 01:54)
Rather than having an AI tell MissionData about alert level increases as they are happening, it would be more accurate for stats purposes to precede this line in IdleState::Init()

    owner->m_recentHighestAlertLevel = 0; // grayman 0003472

with a call to MissionData to record an 'episode' of increasing alertness.

This guarantees only one registration per 'episode' and eliminates the possibility of registering multiple times as an AI goes up and down and up and down in alert level after leaving IdleState.

Ditto for AlertIdleState::Init().

(0007827)
grayman   
01.10.2015 11:48   
From demagogue:

"My intuition is it could be defined in a time band. If the level is ramped up in less than maybe 3 or 5 seconds, it should count only the highest, as if it's one event.

But if it's more than that, they count separately, the logic being you were under alert and could have gotten out, but didn't, so get separate punishment.

Or more generally, after 3 seconds or so in a dynamic situation, it's more fair to call the 2 interactions separate "events"."
(0007917)
grayman   
26.12.2015 02:39   
Moving to 2.05 because it's a large design change which could hinder getting 2.04 out in a timely manner.
(0009261)
grayman   
16.09.2017 18:34   
Moving to 2.07 due to the amount of work involved.
(0010902)
grayman   
13.12.2018 12:40   
Moving to 2.08 for the same reason: big design change.

I'll try to get to it after 2.07 is released.
(0011128)
nbohr1more   
26.12.2018 07:21   
In the hopes of getting at least the loot total to render,
I went poking around with this again.

setting a static int for:

int MissionStatistics::GetFoundLootValue() const
{
    static int sum = 0;

in MissionStatistics will render value out of x for loot but the value
will be totally incorrect.

I tried moving up the codebase to where LOOT_COUNT is inherited from
but thus far have not been able to compile anything set to static up there.
(0012838)
grayman   
26.10.2020 23:06   
Removing myself as "Assigned To" because I doubt I will ever have time to work on it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2758 [The Dark Mod] GUI normal always 15.05.2011 13:27 26.10.2020 23:06
Reporter: jacobalbano Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 10.04  
Status: assigned Product Version: TDM 1.05  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Arms detach from body on pause
Description: When pausing the game while an arrow is drawn, the player's arms detach from the camera for as long as the attack key is held down.
Tags:
Steps To Reproduce: Select any arrow
Begin attack
Without releasing the attack key, open the pause menu
Still holding the attack key, press the pause button again to close the menu
Move the player around.
Additional Information:
Attached Files:
Notes
(0010938)
nbohr1more   
15.12.2018 19:57   
Unable to reproduce:

1) There is no pause menu button other than escape (ESC) to menu
2) Escaping to menu with the weapon held at attack does not produce this issue when returning
3) The closest function we have to pause it g_stopTime and it does not cause the arm to become detached.

The only thing even close to this issue in current builds is issue 2509
(0010939)
jacobalbano   
15.12.2018 20:17   
(Last edited: 15.12.2018 20:38)
With all due respect, unless this has been fixed in a version that has yet to be released, it's *not* "fixed". See below for a video that I just recorded minutes ago, on the most recent version of TDM.

https://www.youtube.com/watch?v=xHLMmA5J3l0

(0010940)
jacobalbano   
15.12.2018 20:29   
This also happens with melee weapons:

https://www.youtube.com/watch?v=bbuM81VASCI

The only difference here is that your weapon is permanently locked a backswing and you can't even switch to another item.

> There is no pause menu button other than escape (ESC) to menu

This is the button I was referring to, yes.

Was there any attempt made to reproduce this or was it simply deemed unlikely to be valid?
(0010941)
grayman   
15.12.2018 20:58   
Haha! That's pretty funny.

greebo apparently was able to reproduce it originally, but he never fixed it.

Since then, it got covered over by the sands of time.

I reproduced it in the SVN version.

I don't know if I can fix it in 2.07, but if not, I'll put it on the 2.08 TODO list.
(0010942)
nbohr1more   
16.12.2018 02:25   
Thanks for the video.
It took a little fiddling but I can now reproduce this issue as well.
(0012501)
nbohr1more   
13.05.2020 04:53   
This still happens in 2.08 but I cannot reproduce the "locked" melee issue.

I can release the un-tethered sword-arm and everything returns to normal.

Can anyone reproduce the "lock" issue?
(0012515)
nbohr1more   
14.05.2020 19:40   
Shall I move this to 2.09?
(0012518)
grayman   
15.05.2020 09:09   
I have no time to look at this, so please move to 2.09.
(0012837)
grayman   
26.10.2020 23:06   
Removing myself as "Assigned To" because I doubt I will ever have time to work on it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4881 [The Dark Mod] Sound normal always 05.09.2018 13:51 26.10.2020 23:06
Reporter: grayman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 2.06  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Apply EFX to location of player's ear, and not the player's origin
Description: I came across this comment in PlayerView.cpp:

// TODO: Support overriding the location area so that reverb settings can be applied for listening thru doors?

What this means (for example) is if the player is in a wooden room using wooden room reverb settings, and he leans against a door leading to a stone room using stone room reverb settings (different location), he should hear the stone room settings and not the wooden room settings.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010757)
grayman   
05.09.2018 13:54   
(Last edited: 05.09.2018 13:55)
Making this change would automatically use the correct reverb if the mapper is using a Listener entity (new in 2.07).

The reverb settings at the Listener entity would be used instead of those at the player's origin.

So if the player is standing in a wooden room and listening to sounds in a stone room somewhere else, he'll hear the stone room reverb.

(0010966)
nbohr1more   
19.12.2018 03:50   
2.07 beta has begun. I presume this is moved to 2.08?
(0012530)
nbohr1more   
20.05.2020 17:13   
Moving to 2.09
(0012836)
grayman   
26.10.2020 23:05   
Removing myself as "Assigned To" because I doubt I will ever have time to work on it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5258 [The Dark Mod] Sound normal always 21.05.2020 21:09 26.10.2020 23:05
Reporter: grayman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: func_listener not working in a cinematic?
Description: Investigate whether a func_listener works in a cinematic (Cutscene).

It appears the only time you can pick up Cutscene sound effects (separate speakers) is when the player is nearby. Placing a listener nearby to take over what the player hears (while keeping him safe elsewhere) doesn't work.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012835)
grayman   
26.10.2020 23:05   
Removing myself as "Assigned To" because I doubt I will ever have time to work on it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5259 [The Dark Mod] AI minor random 22.05.2020 18:00 26.10.2020 23:05
Reporter: duzenko Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Crash in game code
Description: Looks like a FrobDoor has a spwanArgs not initialized properly ?
Tags:
Steps To Reproduce: Start Ulysses 1
Progress to see Sheriff sitting at the table at the foot of the staircase (basement exit)
Shoot an arrow at him
AI alerts, soon crashes with this stacktrace

     [Inline Frame] TheDarkModx64NoTools.exe!idHashIndex::First(const int) Line 226 C++
     TheDarkModx64NoTools.exe!idDict::FindKey(const char * key=0x00007ff72510cc68) Line 446 C++
     [Inline Frame] TheDarkModx64NoTools.exe!idDict::GetString(const char *) Line 230 C++
     [Inline Frame] TheDarkModx64NoTools.exe!idDict::GetBool(const char *) Line 246 C++
> TheDarkModx64NoTools.exe!idAI::CanPassThroughDoor(CFrobDoor * frobDoor=0x000002d32420a014) Line 5809 C++
     TheDarkModx64NoTools.exe!ai::State::OnFrobDoorEncounter(CFrobDoor * frobDoor=0x000002d32420a014) Line 5393 C++
     TheDarkModx64NoTools.exe!idAI::GetMovePos(idVec3 & seekPos={...}) Line 5043 C++
     TheDarkModx64NoTools.exe!idAI::AnimMove() Line 5957 C++
     TheDarkModx64NoTools.exe!idAI::Think() Line 2588 C++
     TheDarkModx64NoTools.exe!idGameLocal::RunFrame(const usercmd_t * clientCmds=0x000000dcfdbff2d0, int timestepMs) Line 3212 C++
     TheDarkModx64NoTools.exe!idSessionLocal::RunGameTic(int timestepMs=16) Line 3052 C++
     TheDarkModx64NoTools.exe!idSessionLocal::RunGameTics() Line 3095 C++
     TheDarkModx64NoTools.exe!idSessionLocal::FrontendThreadFunction() Line 3141 C++
     [Inline Frame] TheDarkModx64NoTools.exe!idSessionLocal::StartFrontendThread::__l2::<lambda_16de5467341aba11472bb29a736528b0>::operator()(void *) Line 3233 C++
     TheDarkModx64NoTools.exe!<lambda_16de5467341aba11472bb29a736528b0>::<lambda_invoker_cdecl>(void * x) Line 3235 C++
     [External Code]

Additional Information: ent->name {len=11 data=0x000002d36e15f520 "cellar_bot1" alloced=20 ...}

frobdoor center = {x=136.000000 y=848.000000 z=60.0000000 }
Attached Files: savegames.7z (3,948,911 bytes) 23.05.2020 07:39
https://bugs.thedarkmod.com/file_download.php?file_id=860&type=bug
Notes
(0012541)
grayman   
23.05.2020 05:31   
Can you provide a savegame just before the sheriff? (I don't know where to get my weapons.)
(0012545)
duzenko   
23.05.2020 07:39   
(Last edited: 23.05.2020 07:41)
Attached
The save format is current svn. Ignore any svn revision checks possible.
Regret the crash is not reproducible easily. I did encounter it today once again, but that's it.
The frob door center position should be enough to identify the entity?
(0012557)
grayman   
26.05.2020 01:01   
The two savegames lead to crashes using a force-load with the latest SVN.

I'll need a savegame from beta6.

Thx.
(0012578)
grayman   
29.05.2020 11:47   
Can I get a savegame from SVN showing the problem?

Please provide the rev number of the build.
(0012579)
grayman   
29.05.2020 12:11   
I checked the spawnargs on the door and see nothing wrong.

If this needs to be fixed in 2.08, please set the target release.
(0012834)
grayman   
26.10.2020 23:05   
Removing myself as "Assigned To" because I doubt I will ever have time to work on it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5361 [DarkRadiant] Design/Coding normal have not tried 18.10.2020 13:40 26.10.2020 08:52
Reporter: greebo Platform: Linux  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Unit testing infrastructure (Linux)
Description: Google tests are supported in Windows/VC++ by running the tests through Visual Studio. This issue's target is to have the unit tests up and running in Linux/GCC.

- configure.ac should detect whether the libgtest-dev library is available
- Makefile.am adjustments
- Maybe removal of boost.test
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012832)
greebo   
26.10.2020 08:52   
It's now possible to run the unit tests after make install by invoking make check:

./configure
make
make install
make check


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5367 [DarkRadiant] Compilation/Build normal have not tried 24.10.2020 06:43 26.10.2020 08:50
Reporter: greebo Platform: Linux  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Need better Python detection in configure.ac
Description: The configure script doesn't work very well with mixed Python2 and Python3 installations, where various combinations of python-config, python3-config, Python2 vs. Python3 runtime can occur on systems. The configure script needs to focus on detecting the version of the available python-config in a better way. Right now it's possible that configure.ac will think it's dealing with Python3, but a python-config of a lesser version is used for compilation and linking.
Tags:
Steps To Reproduce:
Additional Information: https://forums.thedarkmod.com/index.php?/topic/20599-darkradiant-git-master-compiles-but-wont-start-missing-libraries-and-modules/
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5368 [DarkRadiant] Compilation/Build normal have not tried 24.10.2020 14:09 25.10.2020 17:03
Reporter: greebo Platform: Linux  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Console warning in Linux when loading libradiantcore.so: undefined symbol: RegisterModule
Description: /home/greebo/dr/lib/darkradiant/modules/libradiantcore.so: undefined symbol: RegisterModule
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5364 [DarkRadiant] GUI feature always 22.10.2020 20:04 25.10.2020 16:51
Reporter: Judith Platform: x64  
Assigned To: OS: Windows  
Priority: low OS Version: 7  
Status: confirmed Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Better visual representation of light entities in views
Description: Lights in DR have always been represented by a wireframe 'diamond' that uses the color value set up in a _color spawnarg. If you use a dark color scheme for DR (and I suppose many mappers do), finding lights in your map that have intensity below RGB 96 becomes a real problem. You can misplace a few lights this way, and finding them later or debugging light-related problems gets difficult.

How about giving our 'diamond' a permanent black wireframe or outline, and filling it with light _color value? Something along these lines.
Other engines typically use icons/sprites for entities, but I guess that sounds like a lot of work.
Tags:
Steps To Reproduce: - Go to View -> Colors
- Switch the color scheme to dark
- Place a light entity and change its color to RGB 64
- Deselect the light.
- Zoom out the view. Now try to find the light ;)
Additional Information:
System Description Intel Core i7 3.06 GHz, 16 GB RAM, GTX 1060 6 GB
Attached Files: Clipboard01.png (6,031 bytes) 22.10.2020 20:18
https://bugs.thedarkmod.com/file_download.php?file_id=913&type=bug
Notes
(0012820)
Judith   
22.10.2020 20:18   
Example light.
(0012827)
orbweaver   
25.10.2020 15:09   
Would it help if there was an option to disable colouring of light entities, and make them all a single colour (e.g. the bright magenta that was the default before we had per-light colouring)?
(0012828)
Judith   
25.10.2020 16:51   
I think that should work, yeah :)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4414 [The Dark Mod] Tweaking trivial have not tried 07.11.2016 18:38 24.10.2020 03:27
Reporter: duzenko Platform:  
Assigned To: duzenko OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.05  
    Target Version: TDM 2.05  
Summary: See if skybox can be rendered faster
Description: Currently TDM
1 - draws skybox filling entire framebuffer
2 - copies framebuffer to a texture sized power of two
3 - uses the skybox texture to render geometry (?)
It could save few millisecond/milliwatts if we drew skybox in the end, skipping the copy-to-texture step and utilizing Z-test to skip invisible pixels.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008450)
duzenko   
07.11.2016 18:39   
Stuck at a road block - can't see where the skybox texture is used.
But it's not a glproc.
(0008452)
nbohr1more   
07.11.2016 19:48   
Hmm

// skybox surfaces need a dynamic texgen
    switch( shader->Texgen() ) {
        case TG_SKYBOX_CUBE:
            R_SkyboxTexGen( drawSurf, tr.viewDef->renderView.vieworg );
            return;
        case TG_WOBBLESKY_CUBE:
            R_WobbleskyTexGen( drawSurf, tr.viewDef->renderView.vieworg );
            return;
}

in R_AddDrawSurf in tr_light.cpp
(0008454)
duzenko   
07.11.2016 20:32   
(Last edited: 13.11.2016 15:57)
Put a breakpoint on each of these two - none were hit in Thief's Den or Rift

(0008455)
duzenko   
07.11.2016 20:36   
(Last edited: 07.11.2016 20:45)
Chalice of Kings, however, did hit R_WobbleskyTexGen.
It also does not lose the sky after r_skipcopytexture 1.

(0008456)
nbohr1more   
07.11.2016 22:16   
What about here:

if ( drawSurfs[0]->material->GetSort() >= SS_POST_PROCESS ) {
        if ( r_skipPostProcess.GetBool() ) {
            return 0;
        }

        // only dump if in a 3d view
        if ( backEnd.viewDef->viewEntitys && tr.backEndRenderer == BE_ARB2 ) {
            globalImages->currentRenderImage->CopyFramebuffer( backEnd.viewDef->viewport.x1,
                backEnd.viewDef->viewport.y1, backEnd.viewDef->viewport.x2 - backEnd.viewDef->viewport.x1 + 1,
                backEnd.viewDef->viewport.y2 - backEnd.viewDef->viewport.y1 + 1, true );
                    
        }
        backEnd.currentRenderCopied = true;
}

in draw_common.cpp > RB_STD_DrawShaderPasses

What you might be looking into is the sort order. The problem being that we don't want the skybox to write over other surfaces.
(0008474)
duzenko   
13.11.2016 15:54   
(Last edited: 13.11.2016 18:46)
I think this code is responsible for blur, eye-blood, etc.
...
tdm_portal_sky.mtr has this: map _currentRender
This is how it probably links skybox as texture but I still don't know where it texgen's it (except for rarely used wobblesky)
...
At this point I don't see how the skybox can be drawn last since surfaces like water, eye-blood, smoke, etc would be overwritten. Unless there is a way to draw it right after opaque surfaces???
Still the question remains if copy-to-texture can be avoided.
...
The idea here is to somehow make the skybox surfaces completely invisible. That way it will just show the skybox pixels left from the previous stage.
...
The texgen could be TG_SCREEN

(0008476)
nbohr1more   
13.11.2016 18:49   
Since it doesn't seem to be possible to avoid the copy operation without some serious structural changes, I went back to look into _currentRender itself.

At the end of the chain in image_load.cpp is CopyFramebuffer.

This is where the actual GL calls to copy the framebuffer for _currentRender images are provoked.

Maybe see if the legacy GL calls there can be updated with modern FrameBuffer based commands?
(0008477)
duzenko   
13.11.2016 18:51   
(Last edited: 13.11.2016 18:57)
No, actually I think copy can be avoided.
If the "ceiling" is not drawn at all then the skybox pixels could be already there from the previous stage.
...
Right now I am looking at how to identify "ceiling" geometry to skip in back renderer.
...
Could it be surf->material->GetName() = "textures/smf/portal_sky" ???

(0008478)
nbohr1more   
13.11.2016 19:00   
Looks like a good lead:

RenderWorld_load.cpp

idRenderWorldLocal::AddWorldModelEntities

// add the world model for each portal area
// we can't just call AddEntityDef, because that would place the references
// based on the bounding box, rather than explicitly into the correct area
(0008479)
duzenko   
13.11.2016 19:01   
(Last edited: 13.11.2016 19:45)
That worked but the pixels aren't there. Does it glClear somewhere?
...
What if don't do qglClear( GL_COLOR_BUFFER_BIT ) at all? Sounds like a weird but valid optimization.
...
Pixels still not there even after r_clear 0. However world pixels are not cleared.
...
There appears to be a mysterious black plane above the ceiling.

(0008481)
duzenko   
14.11.2016 18:42   
(Last edited: 14.11.2016 19:08)
Dumping framebuffer step-by-step shows that the black thing happens in RB_STD_FillDepthBuffer
...
In RB_RenderDrawSurfListWithFunction
...
RB_T_FillDepthBuffer writes to color buffer ???

(0008482)
duzenko   
14.11.2016 19:50   
Changed the renderer to skip the skybox surfaces in both depth pass and shader pass.
Texture copy skipped as well.
This behaviour is controlled by the g_enablePortalSky cvar.
(0008489)
duzenko   
16.11.2016 13:09   
Moved the filtering code from back to front renderer to save a few more CPU cycles.
Added skybox debug tool.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5363 [The Dark Mod] Coding normal always 20.10.2020 21:51 20.10.2020 21:54
Reporter: kingsal Platform:  
Assigned To: OS: Windows 10  
Priority: normal OS Version: 64  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Func_fractures have incorrect sounds after loading save game
Description: It looks like idBrittles are not saving their snd_shatter spawnargs on save game/load? A map will start off with the appropriate fracture sound, but on loading a saved game it will default to a kind of wooden hit noise.

Tags:
Steps To Reproduce: You have to try it a couple times, but load up the test map. Break a few windows, save and then load your game. You'll see that some windows make no sound or a quiet "wooden" sound.
Additional Information:
Attached Files: fracture_test.map (10,205 bytes) 20.10.2020 21:51
https://bugs.thedarkmod.com/file_download.php?file_id=911&type=bug
fracture_test2.map (10,989 bytes) 20.10.2020 21:54
https://bugs.thedarkmod.com/file_download.php?file_id=912&type=bug
Notes
(0012819)
kingsal   
20.10.2020 21:54   
(Updated test map )Added black jack.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5200 [DarkRadiant] Design/Coding normal N/A 28.03.2020 09:04 18.10.2020 13:40
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Unit testing infrastructure
Description: DarkRadiant is severly lacking an infrastructure to perform unit and integration tests.
While some math methods have been tested by code in the past, there's nothing here to enable testing all of DR's interfaces or map editing algorithms.
It's hard to implement such a unit testing facility long after the project started, but it would really help.

If possible, this infrastructure should be cross-platform, but I personally wouldn't mind if it's MSVC only if that's the most convenient solution. Since DR is developed mostly on the Windows platform, and the Windows build needs 100% to be done before each release.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012776)
greebo   
17.09.2020 17:57   
New status is: there's a Google Test project added in the VC++ solution, it can set up an Application Context and initialise the DarkRadiant core binary.
Next step is to implement the actual tests and set up the game data in a minimalist PK4.
(0012777)
greebo   
17.09.2020 18:01   
Setting this to resolved for the moment being. The first unit test to be written will likely be more challenging than the following ones, at least the basic ground work of separating UI from functionality and cleaning up the dependencies of the core module is done now.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5356 [DarkRadiant] Map Editing normal always 11.10.2020 14:31 13.10.2020 17:04
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Moving a clipper point always sets position on one axis back to 0
Description: Orthoview shows only 2 axis at a time. Whenever a clipper point is moved in orthoview, its position on the 3rd axis resets to 0.

For example, everytime a clipper point is moved while in XY orthoview, the point's Z position returns to 0. This makes it almost impossible to use all 3 clipper points for a cut that's not on a plane with one of the 3 axis.
Tags:
Steps To Reproduce: 1) Draw a new 128x128x128 brush that's about 1000 units distant from the map origin in all 3 axis.
2) With the brush selected, activate the clipper tool and place clipper points 0 and 1 on the brush.
3) Press ctrl-tab a few times to change view directions in orthoview to see that both clipper points are within the brush on all 3 axis.
4) Move clipper point 0 by a few increments.
5) Press ctrl-tab. Clipper point 0 has shifted back to 0 on the axis that wasn't visible in step 4.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5358 [DarkRadiant] GUI minor N/A 11.10.2020 17:54 13.10.2020 16:18
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: low OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Skin listing issues in Skin Chooser
Description: There are a couple issues with the way the Skin Chooser lists skins:

1) the list isn't alphabetical, which can make it difficult to manually find skins
2) in the 'All skins' folder, but not in the 'Matching skins' almost every skin and folder is listed twice. This is even without any FM installed in 2.08. Some of the rare exceptions are "addition_dirty" and "addition_darktimber".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012815)
greebo   
13.10.2020 03:55   
It seems the duplication is due to a change in wxWidgets 3.1.x: http://trac.wxwidgets.org/ticket/18405
I'm not 100% sure it's a regression or a sloppy tree model handling in DarkRadiant's code, I need to dig deeper.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5357 [DarkRadiant] GUI feature N/A 11.10.2020 17:41 12.10.2020 17:34
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: low OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Add search function in Skin Chooser
Description: The Skin Chooser is one of the last choosers that doesn't have a search function. Usually one can get by perfectly fine without this because all specific skins are listed at the top and they're usually few in number.

In some cases, a search function would be quite useful, though:
- models with huge numbers of skins, i.e. painting skins and their torn versions (especially if the mapper's got large custom texture packs)
- finding & applying a skin that's not specific to that model
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5359 [DarkRadiant] Map Editing feature N/A 12.10.2020 11:46 12.10.2020 14:31
Reporter: Dragofer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature: mirror the rotation & origin of non-bsp entities
Description: Currently the 3 mirror buttons on the left pane have little or no effect when applied to anything that’s not made of brushes or patches (bsp). This is understandable because true mirroring can’t be achieved without creating a new version of the model.

However, I think it’d be a powerful tool if these buttons were able to mirror at least the rotation and origin of such entities. This could for example be used to mirror the layout of clutter prefabs to better fit the available space, or to much more easily create symmetric arrangements of rotated models. I’ve attached 2 demonstration pics showing how mirroring would provide added value compared to rotating.

This would still have limitations for asymmetric models. In that case the mapper could either adjust the arrangement manually or change the model to a mirrored version.
Tags:
Steps To Reproduce:
Additional Information: Some entities use "angle" (2D) instead of "rotation" (3D), maybe that might require separate handling?
Attached Files: mirror-rotate1.jpg (85,736 bytes) 12.10.2020 11:46
https://bugs.thedarkmod.com/file_download.php?file_id=908&type=bug
mirror-rotate2.jpg (127,358 bytes) 12.10.2020 11:46
https://bugs.thedarkmod.com/file_download.php?file_id=909&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5263 [DarkRadiant] Map Editing normal sometimes 25.05.2020 21:29 11.10.2020 16:19
Reporter: Geep Platform:  
Assigned To: greebo OS: win10  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: "Model Scaler" doesn't handle model duplication correctly (or perhaps consistently)
Description: If, after using DR's "Model Scaler" functionality to scale a model, you hit the space key to create a duplicate, it creates a new *unscaled* object, which is really not what you want. This makes it harder to make multiple copies of the same sized item.

JackFarmer confirms that problem, but reports that for him, sometimes hitting the space key actually does create a scaled duplicate. So it may be a consistency issue, or maybe it depends on if you scale up or down, or some other aspect of the model or scaling.

Tags:
Steps To Reproduce: Create a model (e.g., a laundry sheet).
Scale it larger with "Model Scaler".
Hit space bar to make duplicate.
Is the duplicate identical? (desired behavior) or the original size (undesired behavior)?
Additional Information: Workaround: save the resized model as a new model in the mission's model folder.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5350 [DarkRadiant] Map Editing normal N/A 02.10.2020 18:19 10.10.2020 09:18
Reporter: Dragofer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Pasting textures with Ctrl-MMB-dragging rapidly fills up undo queue
Description: Dragging the mouse with Ctrl + MMB is a fast way to transfer a texture to a large number of surfaces. However, this quickly fills up the undo queue because every .x seconds a paste action is performed, even if the texture has already been pasted onto the surface. This makes it more difficult to undo changes, i.e. when an unintended surface was accidentally pasted onto or if trying out various textures for a room. Sometimes the whole queue is filled up by paste actions.

Maybe the paste action could be skipped if the current and new texture parameters are identical?
Tags:
Steps To Reproduce: 1) Draw 2 brushes. Texture one with textures/darkmod/wood/boards/rough_wood_brown, the other with textures/darkmod/wood/boards/rough_wood_brown_dull.
2) MMB in camera view on the rough_wood_brown brush to copy its texture.
3) Hold down Ctrl and MMB-drag the mouse in camera view across the other brush's surface, keeping the mouse in motion for a second or two.
4) Hold down Ctrl-Z until you're back to the original state.
Additional Information:
Attached Files:
Notes
(0012810)
Bikerdude   
09.10.2020 21:23   
Ah this might explain why when I MMB click on a brush surface that DR then dosen't take me to said texture in media inspector?
(0012812)
Dragofer   
10.10.2020 09:18   
"Ah this might explain why when I MMB click on a brush surface that DR then dosen't take me to said texture in media inspector? "
This works without problems for me on various maps, don't recall encountering that before except when sometimes the "Textures" tab doesn't show many of the textures used in the map.

Anyway this bug is about the fact that Ctrl-MMB pasting fills up the undo queue way too fast.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5352 [DarkRadiant] GUI minor N/A 03.10.2020 14:01 09.10.2020 21:25
Reporter: Dragofer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Entities with invalid classname and no model have no visual representation
Description: As per the title, if an entity's classname doesn't exist and it has no model spawnarg, it's invisible and unselectable in both camera view & orthoview. I've recently found I've got a few of these floating around in my map, after I renamed some entity defs.

I was thinking they could be given a "Shader not found" box, just like when an entity has an invalid value for its "model" spawnarg.
Tags:
Steps To Reproduce: 1) Create entity -> target_relay. This entity has no model spawnarg.
2) Change the classname to "bogus". The entity disappears from view and can't be selected anymore, except via the entity list (J).
Additional Information:
Attached Files:
Notes
(0012811)
Bikerdude   
09.10.2020 21:25   
+1

I have a workaround I used for this, but it would be really helpful for troubleshooting for a null object to be shown in DR so we can either fix or nuke said entity.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5244 [The Dark Mod] Coding normal have not tried 05.05.2020 15:28 09.10.2020 21:14
Reporter: Bikerdude Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't move in noclip whith shouldered AI
Description: see below
Tags:
Steps To Reproduce: - Fly around in noclip.
- knock out an and pickup and AI.
- go to move and your stuck in place.
- you have type noclip twice in the console to be able to move again while shouldering an Ai,
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5235 [DarkRadiant] GUI feature N/A 01.05.2020 12:34 09.10.2020 18:55
Reporter: Bikerdude Platform: PC  
Assigned To: greebo OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 2.7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Highlight a model in orthoview and its selected in 'map info' inspector
Description: Feature request:

When listing models in a map by poly count, click main menu>map>map info, then click on the models tab and then the polys column. Click on polys column to reorder from largest to smallest and then highlight/click-on a model from the list. (see attached)

What would would useful is if doing the above action the model above is then selected in orthoview, the same what its shown in the Entity list inspector.
Tags:
Steps To Reproduce:
Additional Information:
System Description GTX 1080Ti, Ryzen 3700X, Soundblaster-Z
Attached Files: Untitled.jpg (445,646 bytes) 01.05.2020 12:34
https://bugs.thedarkmod.com/file_download.php?file_id=844&type=bug
Notes
(0012441)
greebo   
01.05.2020 12:45   
Yes, sounds useful
(0012795)
Bikerdude   
08.10.2020 09:52   
thanks greebo.
(0012803)
greebo   
09.10.2020 18:55   
Implemented in git. I made it analogous to the Shader Info Tab, so you can right-click the entry in the model info tab and select or deselect the entities using that model path.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5355 [DarkRadiant] Saving and loading normal always 07.10.2020 05:28 09.10.2020 16:56
Reporter: elojalapeno Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Very simple 4x4 floor, trying to export as .OBJ results in distorted UV
Description: I'm trying to make a simple modular assets, and the very first one I'm doing is 4x4 floor. Looks great in Radiant, but when trying to export as .OBJ and viewing it in other apps, it seems like only the first 4 brushes looks proper.

First I thought maybe the 2k texture was too big, but downscaling it didn't help, I tried to cover all surfaces in texture as well but no result. I have no idea why it's like this right now. I used to export pre-made maps without such basic issues before.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: UE4Editor_stBexo7vWc.png (337,398 bytes) 07.10.2020 05:28
https://bugs.thedarkmod.com/file_download.php?file_id=901&type=bug
DarkRadiant_5RanKr5DVE.png (321,400 bytes) 07.10.2020 05:28
https://bugs.thedarkmod.com/file_download.php?file_id=902&type=bug
SM_modular_floor_square_01_winter_tiles2.obj (18,829 bytes) 07.10.2020 05:28
https://bugs.thedarkmod.com/file_download.php?file_id=903&type=bug
modular1.map (9,306 bytes) 07.10.2020 05:28
https://bugs.thedarkmod.com/file_download.php?file_id=904&type=bug
4x4_blender.jpg (368,678 bytes) 09.10.2020 16:56
https://bugs.thedarkmod.com/file_download.php?file_id=907&type=bug
Notes
(0012796)
elojalapeno   
08.10.2020 19:35   
Sorry for wrongly labeling the 'priority'! I have tried exporting few more times, but always some rows come out distorted, even when exporting on per brush setting.
(0012798)
greebo   
09.10.2020 14:14   
It appears the vt coordinates have really high values in the OBJ file above. I'll try to check it out if I can reproduce it.
(0012801)
greebo   
09.10.2020 16:54   
I opened the map you attached and exported it to OBJ. The texture coordinates in the file look pretty much the same, but Blender seems to import it without troubles:
(0012802)
greebo   
09.10.2020 16:56   


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5326 [DarkRadiant] Models major always 11.08.2020 09:19 09.10.2020 14:22
Reporter: elojalapeno Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Exporting .obj lacks .mtl; UV is inverted; scale by 2.54 ?
Description: When exporting parts of the map as .obj file, there is no .mtl for material/texture info. This would be very useful to know what exactly should be used.
Another issue is that .obj files appear to have inverted UV.
Would it be possible to add scale on export?
Tags: model, model export
Steps To Reproduce:
Additional Information:
Attached Files: UE4Editor_nsCsa8UL6k.png (1,448,147 bytes) 11.08.2020 09:19
https://bugs.thedarkmod.com/file_download.php?file_id=892&type=bug
TEMP.zip (762 bytes) 11.08.2020 17:45
https://bugs.thedarkmod.com/file_download.php?file_id=893&type=bug
testmodel.7z (17,065 bytes) 09.10.2020 14:22
https://bugs.thedarkmod.com/file_download.php?file_id=905&type=bug
Notes
(0012721)
greebo   
11.08.2020 14:06   
Thanks for stopping by!
I'm not very proficient when it comes to handling OBJ files - can you give me a few more directions? Like a working .OBJ and .MTL file, or a comparison of expected and actual results when using the export? Then I can try to fix it.
(0012723)
elojalapeno   
11.08.2020 17:45   
Thanks for your response! I didn't expect it so fast.
Format is purely text based.
I guess you will have to read materials from radiant, and parse that into .mtl file. Here is a 1 object sample with one material applied .OBJ:

[CODE]# Blender v2.83.2 OBJ File: ''
# www.blender.org
mtllib sample.mtl
g stedoorpanel1_d
v 1.000000 1.000000 -1.000000
v 1.000000 -1.000000 -1.000000
v 1.000000 1.000000 1.000000
v 1.000000 -1.000000 1.000000
v -1.000000 1.000000 -1.000000
v -1.000000 -1.000000 -1.000000
v -1.000000 1.000000 1.000000
v -1.000000 -1.000000 1.000000
vt 0.625000 0.500000
vt 0.875000 0.500000
vt 0.875000 0.750000
vt 0.625000 0.750000
vt 0.375000 0.750000
vt 0.625000 1.000000
vt 0.375000 1.000000
vt 0.375000 0.000000
vt 0.625000 0.000000
vt 0.625000 0.250000
vt 0.375000 0.250000
vt 0.125000 0.500000
vt 0.375000 0.500000
vt 0.125000 0.750000
vn 0.0000 1.0000 0.0000
vn 0.0000 0.0000 1.0000
vn -1.0000 0.0000 0.0000
vn 0.0000 -1.0000 0.0000
vn 1.0000 0.0000 0.0000
vn 0.0000 0.0000 -1.0000
usemtl Material
s off
f 1/1/1 5/2/1 7/3/1 3/4/1
f 4/5/2 3/4/2 7/6/2 8/7/2
f 8/8/3 7/9/3 5/10/3 6/11/3
f 6/12/4 2/13/4 4/5/4 8/14/4
f 2/13/5 1/1/5 3/4/5 4/5/5
f 6/11/6 5/10/6 1/1/6 2/13/6
[/CODE]

And here is corresponding .MTL file:
[CODE]
# Blender MTL File: 'None'
# Material Count: 1

newmtl Material
Ns 323.999994
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.800000 0.800000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.450000
d 1.000000
illum 2
map_Kd textures\\base_door\\stedoorpanel1_d.tga
map_Kn textures\\base_door\\stedoorpanel1_d
map_Ks textures\\base_door\\stedoorpanel1_s.tga
[/code]

Long story short, map_Kd/Kn/Ks correspond to matching diffuse/normal/specular textures. When this is included, all textures should load automatically.

As for inverting UV, that's going to be a lot of numbers I think. I could probably export sample brush from Radiant, fix it in Blender, and then show you final .obj so you can see the differences for yourself.
Is there any discord for more real-life communication?
(0012724)
elojalapeno   
11.08.2020 17:46   
Oh I can't edit it now, but obviously instead of "Material", it should actually using corresponding material name. I think in Doom 3 case it's always the color map filename?
(0012725)
greebo   
11.08.2020 17:52   
Thanks for the examples. Anything that I can compare to is helpful. I'm not sure myself right now, but does Doom 3 handle OBJ files? Or are you using some other engine?
Don't hold your breath on the fix though, I'm currently tied up in other things, so it might be a while.
(0012726)
elojalapeno   
11.08.2020 17:54   
My final destination is UE4, however once this is implemented, it would literally work with every 3D software like Maya, Blender, Unity, 3DS Max...
The current file is fully workable, just requires manual rework of inverting UV and recreating materials.

I haven't looked into materials in Radiant, been a while since I really dipped into that, but maybe at the very least it would be possible to put all 'shaders' into a single text file to ease this process? Just text information about material name and textures it's using. Many materials are using filename + suffixes like _d _local _s, but not everything is matching.
(0012730)
VanishedOne   
12.08.2020 14:24   
Possibly related to my experience with the UVs at https://bugs.thedarkmod.com/view.php?id=4099#c7853
(0012731)
elojalapeno   
12.08.2020 18:54   
The steampowered link you have posted is dead. Do you have a copy of its content?
(0012732)
VanishedOne   
12.08.2020 21:03   
(Last edited: 12.08.2020 21:04)
I'm afraid I didn't find anything in the Wayback Machine. But I remember that when I tried loading an OBJ from DR into UVMapper Classic it popped up an offer to fix it automatically, and that was all it took to make it usable in Sculptris's paint mode. Probably the 'message about out of range UV coordinates' mentioned in http://www.render-lab.com/Render-Lab_UV_tut.htm and https://community.foundry.com/discuss/topic/41014/solved-uv-out-of-range-with-uv-mapper?mode=Post&postID=371929
(0012799)
greebo   
09.10.2020 14:19   
In the current development version. I've adjusted the OBJ exporter to write a MTL file next to it. As soon as I have a pre-release build available, I'll post in the forums (https://forums.thedarkmod.com/index.php?/forum/51-darkradiant-feedback-and-development/), so maybe you might want to set an alert on that subforum to get notified.

Thing is, I can not tell at this point if the "map_Kd" paths are meant to be absolute file system paths like C:/temp/texture.png or whether they are meant to be relative to the OBJ file.
When importing the OBJ file in Blender, there's the option "Image Search" where Blender tries to locate the mentioned texture files in the folder of the MTL file (including subfolders) - and it's working. Not sure though how Lightwave or others are treating the MTL file.
(0012800)
greebo   
09.10.2020 14:22   
Here's a test model export I created with the current dev build. It contains the models folder as one would expect it in a D3/Q4 mod.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5354 [The Dark Mod] Feature proposal normal have not tried 04.10.2020 17:23 04.10.2020 17:23
Reporter: Geep Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature: Pointfiles for Debugging of Info_Location Overlaps
Description: When the info_location system is used for ambient light and sound, after dmap and during the "map <FM>" phase, any info_locations that overlap are so reported to the console as a warning. However, diagnosis of the actual problem cause is difficult.

It is proposed, if technically feasible, to extend the pointfile system to help with this diagnosis. In particular, what is desired is a pointfile that runs between the two info_location objects involved in the overlap, via an info-location-overlap path.

The name style of such pointfiles should be clearly different from that of the visportal pointfiles. A suggestion is:

pointfile_<info_location_name1>_overlaps_<info_location_name2>.lin
Tags:
Steps To Reproduce:
Additional Information: Related forum posts about debugging an overlap:
https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=451983
https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=452084

It is recognized that, if the naming of pointfiles is modified, a system that cycles through pointfiles automatically in DR, instead of needing manual renaming, could be impacted by this.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5353 [The Dark Mod] Feature proposal normal have not tried 04.10.2020 16:55 04.10.2020 16:55
Reporter: Geep Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature: Finer-grained DMap Warning for "dropped" visportals
Description: During DMAP, warnings about visportal problems already provide some categorization (e.g., "dropped" vs "useless"). It is proposed, if technically feasible, to differentiate the "dropped" category further, into -
- "dropped (bad seal)"
- "dropped", all other cases
where "bad seal" means that some part of the visportal edge is not in worldspawn. (I'm not married to "bad seal" as a phrase... substitute any other you like.)

Ideally, the "bad seal" tag would be applied both to the console warning as shown, and incorporated into the filename of the corresponding pointfile. The reason for doing this is that the mapper could see at a glance which visportal failures are due to bad seals, and so prioritize the fixing of those. Oftentimes, fixing bad seals makes some of the other visportal warnings go away.
Tags:
Steps To Reproduce:
Additional Information: It is recognized that, if the naming of pointfiles is modified, a system that cycles through pointfiles automatically in DR, instead of needing manual renaming, could be impacted by this.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5345 [DarkRadiant] Sound System minor N/A 27.09.2020 20:51 04.10.2020 16:32
Reporter: Geep Platform:  
Assigned To: greebo OS:  
Priority: low OS Version: Win 10  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Feature: Display Estimated Duration of Sound Clip
Description: When adding a speaker (or pretending to) and previewing available sound shaders and their ogg files, it would be helpful to know (when a particular ogg file is highlighted) what the approximate clip duration is.

How this may be calculated is suggested in https://exiftool.org/forum/index.php?topic=4284.0
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012792)
Geep   
04.10.2020 16:32   
Thanks!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5306 [DarkRadiant] General normal N/A 21.07.2020 11:31 03.10.2020 19:53
Reporter: Goldwell Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Add a 'Reload Sounds' options to the menu
Description: Currently we can reload models/skins/scripts/materials/etc however if you wish to update sounds it requires restarting dark radiant in order for them to show up in the sound picker window.
Tags:
Steps To Reproduce: 1. Open up Dark Radiant

2. Add a new sound to your sndshader file

3. Try to view the new sound in DR
Additional Information:
Attached Files:
Notes
(0012791)
kingsal   
03.10.2020 19:53   
Yes! Thanks for the fix greebo


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5310 [DarkRadiant] General feature N/A 28.07.2020 11:47 03.10.2020 03:17
Reporter: stgatilov Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Add a way to teleport to coordinates (via Console Command or Python)
Description: The TDM game has commands:
  getviewpos
  setviewpos x y z a b c
The first one prints coordinates and Euler angles, the second one teleports player to coordinates and orients by angles.
Note that angles are options, since in most cases user don't need them.

It would be great to have similar feature in DR, be it a separate dialog or just a scripting command.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012758)
AluminumHaste   
24.08.2020 17:55   
CTRL+MIDDLEMOUSE button can move the camera to a point in one of the ortho views
MIDDLEMOUSE button + move cursor changes the camera to look at the mouse in the ortho views

In DR they are called Drag Camera and Drag View

You should be able to get what you want using those two.
(0012759)
stgatilov   
25.08.2020 04:37   
With ortho view, I can only set two coordinates. How to set third coordinate?
And for it to happen, I have to monitor coordinates while moving mouse, which takes some time and effort.
(0012789)
greebo   
02.10.2020 16:31   
In the recent master branch, getting or setting the camera position via C++ code can be done like this:

// This might throw an std::runtime_error if no camera is present
auto& camera = GlobalCameraManager().getActiveView();

// Get the current position and angles
Vector3 orig = camera.getCameraOrigin();
Vector3 angles = camera.getCameraAngles();

// Set the current position and angles
camera.setCameraOrigin(orig);
camera.setCameraAngles(angles);

// Or set both at the same time
camera.setOriginAndAngles(orig, angles);

I'll have a look at exposing that functionality to the CommandSystem and Python scripts.
(0012790)
greebo   
03.10.2020 03:17   
New console commands available:

 SetActiveCameraPosition "100 40 50"
 SetActiveCameraAngles "30 10 20"

Camera angles are pitch,yaw,roll in degrees.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5348 [DarkRadiant] GUI trivial always 30.09.2020 18:41 02.10.2020 16:21
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Clipper cursor persists when switching out of clipper mode
Description: When hovering the cursor over clipper points (placed by LMB when the clipper tool is active), the cursor turns into a cross. If I switch out of the clipper tool (i.e. press W) while my cursor is in that position, it'll remain a cross indefinitely in orthoview.

This can be reversed by passing the cursor over a clipper point again.
Tags:
Steps To Reproduce: 1) Activate the clipper tool (X), left click to place a clipper point.
2) Hover the cursor over this clipper point. It turns into a cross.
3) Without moving the mouse, go into translate mode by pressing W. The cursor is now always a cross in orthoview.

To undo, return to the clipper tool, place a new clipper point and pass the cursor over the point.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5105 [The Dark Mod] Script/Def feature N/A 03.01.2020 13:22 02.10.2020 11:38
Reporter: Dragofer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.07  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow entities to pass self when calling script functions
Description: Entities like atdm:target_callscriptfunction or most trigger brushes currently don't seem to be able to pass variables when they call script functions. This makes them unsuitable for calling script functions with variable parameters. An example would be: void reusable_script(entity mover, entity speaker, entity button). Scriptobjects may already do this, but are more difficult for mappers to learn and use.

As an alternative to a similar ticket I opened for this issue, I'd like to suggest that scriptfunctions can be passed "self" to refer to the entity from which they were called, similar to scriptobjects. This would allow the mapper to store variables on the calling entity as spawnargs, enhancing the mapper's ability to achieve diverse scripted effects.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012047)
Dragofer   
03.01.2020 15:52   
Related ticket: 0005103 Allow script functions to be called with parameters


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5103 [The Dark Mod] Script/Def normal N/A 03.01.2020 10:55 02.10.2020 11:37
Reporter: Dragofer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.07  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow script functions to be called with parameters
Description: Methods for calling script functions with parameters from ingame entities are few and usually require defining scriptobjects, which have a steeper learning curve than plain script functions.

This makes it more difficult to reuse a scripted setup because many spawnargs, entity names and script functions need to be renumbered by hand. An example for the kind of script I'd like to reuse is:
void reusable_script(entity mover, entity speaker, entity button).

I'd like to propose adding new spawnargs to atdm:target_callscriptfunction and various trigger brushes. They get passed when the script is called:
param1
param2
param3 etc.

In the above example, I could point param1 to the func_mover, param2 to the speaker and param3 to the button.
Ideally I'd like to be able to clone the whole setup and have the param spawnargs updated to the new entity names.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012039)
Dragofer   
03.01.2020 10:57   
Please send me a PM if you'd like me to construct a test map.
(0012048)
Dragofer   
03.01.2020 15:53   
Related ticket: 0005105 Allow entities to pass self when calling script functions


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5342 [DarkRadiant] GUI feature N/A 26.09.2020 16:37 02.10.2020 10:42
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Feature: display which file an entity or soundshader is defined in
Description: Currently finding the definition for a particular entity or soundshader requires manually going through the list of .def or .sndshd files and searching in the ones that seem most likely to contain the definition. This can become time consuming in particular when the entities are obscure (i.e. "impact results") or don't follow conventions (i.e. where an entity is located in a .def file named after its author).

This is in contrast to the Media browser, which lists all materials as well as which .mtr file they've been defined in. It also has the option to right-click to "Show Shader Definition", making it even easier (a matter of seconds) to view how those materials were done or to make variants.

I think having an extra line in the Entity Chooser and Sound Chooser pointing to the file where the entity/sound shader has been defined would be a great time saver. Having an option to right-click entries in the list and "Show Definition", or a button that shows the definition for the currently selected entry, would be really convenient too.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: entitychooser.png (14,892 bytes) 02.10.2020 05:15
https://bugs.thedarkmod.com/file_download.php?file_id=899&type=bug
soundchooser.png (20,486 bytes) 02.10.2020 05:15
https://bugs.thedarkmod.com/file_download.php?file_id=900&type=bug
Notes
(0012787)
greebo   
02.10.2020 05:15   
(0012788)
Dragofer   
02.10.2020 10:42   
Thanks! This marks the end of those tedious searches through TDM's long lists of definition files. That alone will save a lot of time for anyone deriving & tweaking defs (even without some way of bringing up entity definitions in a child window with copy-pasteable text).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5347 [DarkRadiant] Map Editing crash always 30.09.2020 12:35 01.10.2020 04:16
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Crash if pressing backspace while drawing a brush
Description: If I'm left-click & dragging to draw a brush, but press backspace before releasing the left mouse button, DR tries to delete the brush but crashes.
Tags:
Steps To Reproduce: Left-click & drag to create a new brush. Without releasing the LMB, press backspace. The brush is deleted, but you still see the info describing its location and dimensions and DR crashes (stops responding).
Additional Information:
Attached Files:
Notes
(0012786)
greebo   
30.09.2020 18:30   
Confirmed, though I had to try a few times to make it happen.

Stacktrace:
     DarkRadiant.exe!scene::getNodeIndices(const std::shared_ptr<scene::INode> & node) Line 127 C++
> DarkRadiant.exe!ui::EntityInspector::getEntityFromSelectionSystem() Line 1202 C++
     DarkRadiant.exe!ui::EntityInspector::updateGUIElements() Line 564 C++
     DarkRadiant.exe!ui::EntityInspector::onIdle() Line 598 C++
     DarkRadiant.exe!wxutil::SingleIdleCallback::_onIdle(wxIdleEvent & ev) Line 35 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 658 C++


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5180 [DarkRadiant] Design/Coding tweak N/A 15.03.2020 04:35 29.09.2020 16:47
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Simplify Commands and Event registration
Description: Right now we have lots of calls looking like this:

    GlobalEventManager().addCommand("DeleteSelection", "DeleteSelection");

For UI elements being able to target commands, an event has to be created and named. Usually this event is directly linked to the a command or statement in the CommandSystem, which is named exactly the same. The EventManager code should be made more intelligent to automatically detect whether a command with a certain name is present in the CommandSystem, without having the modules register proxy events with the same name.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5344 [DarkRadiant] Map Editing normal have not tried 27.09.2020 15:56 27.09.2020 17:38
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Change CSG Merge such that only brushes sharing the same parent entity get merged
Description: To avoid the problems mentioned in 0005336 the CSG merge algorithm should not try to merge brushes that don't belong to the same entity.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012785)
Dragofer   
27.09.2020 17:38   
After reading about this new change, I've just tried the following on 2.8.0:

1) Create a brush, texture it with a snow texture
2) Duplicate it and move the new brush so it's adjacent to the first
3) Convert both to func_static -> Select the func_static -> Hit CSG Merge -> DR crashes

So both brushes are in the same entity, but still crash DR when attempting to merge. That said, if I use "Select Group Parts" first, then select the 2 brushes individually, then the merge works fine.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5336 [DarkRadiant] Map Editing crash always 10.09.2020 12:52 27.09.2020 16:20
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Crash when using CSG Merge on brushes that are entities
Description: If I attempt to merge 2 mergeable brushes with CSG Merge, but at least one of them is in a func_static, DR crashes.

The crash doesn't happen if the brushes aren't mergeable, i.e. they're not adjacent or their shapes aren't compatible.
Tags:
Steps To Reproduce: 1) Draw a brush.
2) Duplicate the brush and move it next to the first brush, such that they can be merged.
3) Convert one of the brushes to func_static.
4) Select both brushes and click "CSG Merge". DR crashes.
Additional Information:
Attached Files:
Notes
(0012783)
greebo   
20.09.2020 08:47   
Confirmed. But I had to select the non-entity brush first, and the func_static brush second to make it crash. Selecting the func_static first will not crash DR.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5343 [DarkRadiant] Design/Coding normal have not tried 27.09.2020 12:37 27.09.2020 16:20
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Unit Test Infrastructure Phase 2
Description: The radiant core binary can be instantiated independently of the user interface binary now.
Running more than one test keeps running into obstacles now, since the static reference caches in the global module accessors get stale once the first test is shutting down the module registry.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5341 [The Dark Mod] Sound normal always 23.09.2020 09:11 24.09.2020 00:55
Reporter: Dragofer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Menu Music can't be switched off during a mission
Description: In audio settings there's an option to toggle "Main Menu Music" "On" or "Off". However, both for me and at least one other user, this setting doesn't stop the main menu music if a map is loaded. It only restarts the soundtrack every time the setting is toggled.

This only happens if Main Menu Music was set to On when the map was started. If it was Off, then the setting will work normally ingame.
Tags:
Steps To Reproduce: 0) Start TDM and make sure "Main Menu Music" is set to "On". If it's "Off", the bug won't occur, the setting will work normally ingame.
1) Load into a map.
2) Once you're ingame, open the main menu and go to Settings -> Audio.
3) Toggle "Main Menu Music". This only restarts the soundtrack.
Additional Information:
Attached Files:
Notes
(0012784)
sneaker   
24.09.2020 00:49   
I'm the other reporter. For me, it doesn't matter whether the main menu music setting is off or on before mission start; the music will always play in the menu once I'm in a mission. The menu music setting does work outside of when no mission is ongoing (e.g. upon game startup and after quit mission).

Fyi, I'm on linux (fedora 32) if it matters. Also I'm currently running a locally recompiled 2.08 tagged source, but I've noticed this issue for awhile now.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5340 [The Dark Mod] Coding normal always 21.09.2020 14:25 21.09.2020 14:25
Reporter: Geep Platform:  
Assigned To: OS: Win 10  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OSPathToRelativePath mystery warning
Description: First seen in a large map under 2.07, and continuing under 2.08:

"WARNING:idFileSystem::OSPathToRelativePath failed on "

That is, the warning is truncated, or reporting an empty path string. Is it possible to change the warning to provide more info about context/cause/solution?
Tags:
Steps To Reproduce: While this always recurs in my large map, whether it is reproducible elsewhere, I dunno. It was first noticed when 3 items (scaled model of a bar counter, scaled model of a 4-post awning, and a standing brazier) were added to the map. Reverting and then adding any 1 of the 3 items would trigger the warning. So it seemed not to be related to a specific texture or entity, but rather some overflow, corruption, or resource depletion.

The forums indicate this truncated string was seen a few time in the distant past, and reportedly sometimes cured by avoiding "bad" textures.
Additional Information: Here is a fragment from qconsole.log, with the 3 instances of the warning displayed:
...
  0.2 seconds for BuildLightShadows
WARNING:Couldn't load image: makeIntensity( textures/decals/stain01b_s)
WARNING:idFileSystem::OSPathToRelativePath failed on
glprogs/heatHazeWithDepth.vfp 17
GL_PROGRAM_ERROR_STRING_ARB:
GL_PROGRAM_ERROR_POSITION_ARB < 0 with error
Linking GLSL program heatHazeWithDepth ...
glprogs/heatHazeWithDepth.vfp 18
GL_PROGRAM_ERROR_STRING_ARB:
GL_PROGRAM_ERROR_POSITION_ARB < 0 with error
WARNING:idFileSystem::OSPathToRelativePath failed on
WARNING:idFileSystem::OSPathToRelativePath failed on
...

Note regarding the above GL_PROGRAM_ERROR warnings (and others not shown) -
Earlier in DMap, during "Checking optional OpenGL extensions...", all features were verified as present in my system's driver except:

X - GL_EXT_depth_bounds_test not found

Maybe that is causing the GL_PROGRAM_ERRORs during glprogs calls?
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5339 [The Dark Mod] Coding normal always 21.09.2020 14:04 21.09.2020 14:04
Reporter: Geep Platform:  
Assigned To: OS: Win 10  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OSPathToRelativePath warning about tdm_collision_metal
Description: During DMap, the following warning was seen:

WARNING:idFileSystem::OSPathToRelativePath failed on //tdm_collision_metal
Tags:
Steps To Reproduce: It occurs if you have objects movable spear2 or padlock_square. (No doubt others too). Removing such objects removes the warning.
Additional Information: This was first noticed under 2.08. Present earlier? Don't know.

I will also be reporting: "OSPathToRelativePath mystery warning", but this is probably unrelated.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5248 [DarkRadiant] GUI normal always 10.05.2020 16:19 20.09.2020 08:16
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Difficulty editor doesn't show classnames when typing instead of selecting them from the dropdown list
Description: Neither the list on the left half, nor the properties window on the right half, shows the classnames of the entities to which the parameters apply.

For example, if I make the rule 'assign "solid" "0" to all func_statics on Easy', I can see "solid" and "0", but the classname fields are blank.
Tags:
Steps To Reproduce: 1) Map -> Difficulty Editor -> Add
2) Classname: "func_static", Spawnarg: "solid", Argument: "0", drop-down list: "Assign" -> Save.
3) The rule has been added to the list on the left. It starts expanded, showing solid = 0, but the top-tier with the arrow, where I suppose the classname should be, is blank.
4) Ok -> Map -> Difficulty Editor
5) Click the arrow to expand the list -> click on solid = 0. The "classname" field in the right half of the window is blank & greyed out.
Additional Information:
Attached Files:
Notes
(0012782)
greebo   
20.09.2020 08:01   
Confirmed, but interestingly only func_static classes. func_aasobstacle seems to work fine.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5289 [DarkRadiant] Saving and loading normal N/A 09.07.2020 11:27 20.09.2020 07:56
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Particle editor creates .prt files incorrectly
Description: Creating a new .prt file via the Particle Editor (either by creating a new particle or copying an existing one) will result in a file that has a '..prt' extension. Trying to start the game with such a file among the assets will trigger a blue error window complaining that it can't load that file.

On a related note, if I manually type in '.prt' at the end of the file name in the Particle Editor's new file dialog, the file never gets created but DR behaves as if it exists (probably storing it in some kind of temporary memory) until DR gets restarted.
Tags:
Steps To Reproduce: 1) Open the Particle Editor
2) Click New
3) Name the particle 'test_particle'
4) Name the file 'test_particle'.
5) Check the particles folder: test_particle..prt as been created.

Alternatively:
4) Name the file 'test_particle.prt'
5) Check the particles folder: nothing has been created.
6) Check the particle editor: test_particle is selectable and is purported to be stored in particles/test_particle.ptr
7) Restart DR. The particle editor no longer lists test_particle.
Additional Information:
Attached Files:
Notes
(0012781)
greebo   
20.09.2020 06:32   
I can confirm the first part about the file name with the double-dot, but I can't confirm the second part. When I hit save, the file test_particle.prt gets written correctly.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5337 [DarkRadiant] GUI crash sometimes 20.09.2020 03:44 20.09.2020 04:52
Reporter: greebo Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.9.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Crash in PrefabChooser dialog when using type-search while a prefab is loaded
Description: Due to the Progress Dialog triggering event processing, there seems to be a re-entrancy problem happening, causing another prefab to be loaded before the current one is finished loading.
Tags:
Steps To Reproduce:
Additional Information: Stacktrace:
        DarkRadiantCore.dll!std::_Ref_count_base::_Decref() Line 650 C++
     DarkRadiantCore.dll!std::_Ptr_base<scene::IMapRootNode>::_Decref() Line 884 C++
     DarkRadiantCore.dll!std::shared_ptr<scene::IMapRootNode>::~shared_ptr<scene::IMapRootNode>() Line 1133 C++
     DarkRadiantCore.dll!std::shared_ptr<scene::IMapRootNode>::operator=<map::RootNode>(const std::shared_ptr<map::RootNode> & _Right) Line 1143 C++
     DarkRadiantCore.dll!map::MapResource::load() Line 128 C++
> DarkRadiant.exe!ui::PrefabSelector::handleSelectionChange() Line 503 C++
     DarkRadiant.exe!ui::PrefabSelector::onSelectionChanged(wxDataViewEvent & ev) Line 528 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 658 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::CallEventHandler(wxEvtHandler * handler, wxEventFunctor & functor, wxEvent & event) Line 670 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventIfMatchesId(const wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event) Line 1417 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::SearchDynamicEventTable(wxEvent & event) Line 1887 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryHereOnly(wxEvent & event) Line 1608 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line 3912 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventLocally(wxEvent & event) Line 1545 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEvent(wxEvent & event) Line 1518 C++
     wxmsw313ud_core_vc14x_x64.dll!wxScrollHelperEvtHandler::ProcessEvent(wxEvent & event) Line 200 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindowBase::ProcessWindowEvent(wxEvent & event) Line 863 C++
     DarkRadiant.exe!wxutil::TreeView::JumpToSearchMatch(const wxDataViewItem & item) Line 595 C++
     DarkRadiant.exe!wxutil::TreeView::Search::HighlightMatch(const wxDataViewItem & item) Line 449 C++
     DarkRadiant.exe!wxutil::TreeView::Search::HandleKeyEvent(wxKeyEvent & ev) Line 473 C++
     DarkRadiant.exe!wxutil::TreeView::_onChar(wxKeyEvent & ev) Line 560 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 658 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::CallEventHandler(wxEvtHandler * handler, wxEventFunctor & functor, wxEvent & event) Line 670 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventIfMatchesId(const wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event) Line 1417 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::SearchDynamicEventTable(wxEvent & event) Line 1887 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryHereOnly(wxEvent & event) Line 1608 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line 3912 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventLocally(wxEvent & event) Line 1545 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEvent(wxEvent & event) Line 1518 C++
     wxmsw313ud_core_vc14x_x64.dll!wxScrollHelperEvtHandler::ProcessEvent(wxEvent & event) Line 200 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindowBase::ProcessWindowEvent(wxEvent & event) Line 863 C++
     wxmsw313ud_core_vc14x_x64.dll!wxDataViewMainWindow::OnChar(wxKeyEvent & event) Line 4182 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 658 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::CallEventHandler(wxEvtHandler * handler, wxEventFunctor & functor, wxEvent & event) Line 670 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventIfMatchesId(const wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event) Line 1417 C++
     wxbase313ud_vc14x_x64.dll!wxEventHashTable::HandleEvent(wxEvent & event, wxEvtHandler * self) Line 1023 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryHereOnly(wxEvent & event) Line 1612 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line 3912 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventLocally(wxEvent & event) Line 1545 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEvent(wxEvent & event) Line 1518 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::SafelyProcessEvent(wxEvent & event) Line 1636 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindowBase::HandleWindowEvent(wxEvent & event) Line 1556 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::HandleChar(unsigned __int64 wParam, __int64 lParam) Line 6319 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWHandleMessage(__int64 * result, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3339 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3873 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWndProc(HWND__ * hWnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2940 C++
     user32.dll!UserCallWinProcCheckWow() Unknown
     user32.dll!DispatchMessageWorker() Unknown
     user32.dll!IsDialogMessageW() Unknown
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWSafeIsDialogMessage(tagMSG * msg) Line 2805 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWProcessMessage(tagMSG * pMsg) Line 2689 C++
     wxmsw313ud_core_vc14x_x64.dll!wxGUIEventLoop::PreProcessMessage(tagMSG * msg) Line 145 C++
     wxmsw313ud_core_vc14x_x64.dll!wxGUIEventLoop::ProcessMessage(tagMSG * msg) Line 163 C++
     wxmsw313ud_core_vc14x_x64.dll!wxGUIEventLoop::Dispatch() Line 229 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::Dispatch() Line 408 C++
     wxmsw313ud_core_vc14x_x64.dll!wxGUIEventLoop::DoYieldFor(long eventsToProcess) Line 395 C++
     wxbase313ud_vc14x_x64.dll!wxEventLoopBase::YieldFor(long eventsToProcess) Line 155 C++
     wxbase313ud_vc14x_x64.dll!wxEventLoopBase::Yield(bool onlyIfNeeded) Line 116 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::Yield(bool onlyIfNeeded) Line 415 C++
     DarkRadiant.exe!ui::MapFileProgressHandler::handleFileOperation(map::FileOperation & msg) Line 132 C++
     DarkRadiant.exe!sigc::bound_mem_functor1<void,ui::MapFileProgressHandler,map::FileOperation &>::operator()(map::FileOperation & _A_a1) Line 1851 C++
     DarkRadiant.exe!std::_Invoker_functor::_Call<sigc::bound_mem_functor1<void,ui::MapFileProgressHandler,map::FileOperation &> &,map::FileOperation &>(sigc::bound_mem_functor1<void,ui::MapFileProgressHandler,map::FileOperation &> & _Obj, map::FileOperation & <_Args_0>) Line 1579 C++
     DarkRadiant.exe!std::invoke<sigc::bound_mem_functor1<void,ui::MapFileProgressHandler,map::FileOperation &> &,map::FileOperation &>(sigc::bound_mem_functor1<void,ui::MapFileProgressHandler,map::FileOperation &> & _Obj, map::FileOperation & <_Args_0>) Line 1579 C++
     DarkRadiant.exe!std::_Invoker_ret<void,1>::_Call<sigc::bound_mem_functor1<void,ui::MapFileProgressHandler,map::FileOperation &> &,map::FileOperation &>(sigc::bound_mem_functor1<void,ui::MapFileProgressHandler,map::FileOperation &> & <_Vals_0>, map::FileOperation & <_Vals_1>) Line 1598 C++
     DarkRadiant.exe!std::_Func_impl_no_alloc<sigc::bound_mem_functor1<void,ui::MapFileProgressHandler,map::FileOperation &>,void,map::FileOperation &>::_Do_call(map::FileOperation & <_Args_0>) Line 927 C++
     DarkRadiant.exe!std::_Func_class<void,map::FileOperation &>::operator()(map::FileOperation & <_Args_0>) Line 970 C++
     DarkRadiant.exe!radiant::TypeListener<map::FileOperation>::operator()(radiant::IMessage & message) Line 116 C++
     DarkRadiant.exe!std::_Invoker_functor::_Call<radiant::TypeListener<map::FileOperation> &,radiant::IMessage &>(radiant::TypeListener<map::FileOperation> & _Obj, radiant::IMessage & <_Args_0>) Line 1579 C++
     DarkRadiant.exe!std::invoke<radiant::TypeListener<map::FileOperation> &,radiant::IMessage &>(radiant::TypeListener<map::FileOperation> & _Obj, radiant::IMessage & <_Args_0>) Line 1579 C++
     DarkRadiant.exe!std::_Invoker_ret<void,1>::_Call<radiant::TypeListener<map::FileOperation> &,radiant::IMessage &>(radiant::TypeListener<map::FileOperation> & <_Vals_0>, radiant::IMessage & <_Vals_1>) Line 1598 C++
     DarkRadiant.exe!std::_Func_impl_no_alloc<radiant::TypeListener<map::FileOperation>,void,radiant::IMessage &>::_Do_call(radiant::IMessage & <_Args_0>) Line 927 C++
     DarkRadiantCore.dll!std::_Func_class<void,radiant::IMessage &>::operator()(radiant::IMessage & <_Args_0>) Line 970 C++
     DarkRadiantCore.dll!radiant::MessageBus::sendMessage(radiant::IMessage & message) Line 66 C++
     DarkRadiantCore.dll!map::MapImporter::addEntity(const std::shared_ptr<scene::INode> & entityNode) Line 72 C++
     DarkRadiantCore.dll!map::Doom3MapReader::parseEntity(parser::DefTokeniser & tok) Line 257 C++
     DarkRadiantCore.dll!map::Doom3MapReader::readFromStream(std::basic_istream<char,std::char_traits<char>> & stream) Line 45 C++
     DarkRadiantCore.dll!map::MapResource::loadFile(std::basic_istream<char,std::char_traits<char>> & mapStream, const map::MapFormat & format, const std::shared_ptr<map::RootNode> & root, const std::string & filename) Line 340 C++
     DarkRadiantCore.dll!map::MapResource::loadMapNodeFromStream(std::basic_istream<char,std::char_traits<char>> & stream, const std::string & fullpath) Line 316 C++
     DarkRadiantCore.dll!map::MapResource::loadMapNode::__l2::<lambda>(std::basic_istream<char,std::char_traits<char>> & mapStream) Line 297 C++
     DarkRadiantCore.dll!std::_Invoker_functor::_Call<void <lambda>(std::basic_istream<char,std::char_traits<char>> &) &,std::basic_istream<char,std::char_traits<char>> &>(map::MapResource::loadMapNode::__l2::void <lambda>(std::basic_istream<char,std::char_traits<char>> &) & _Obj, std::basic_istream<char,std::char_traits<char>> & <_Args_0>) Line 1579 C++
     DarkRadiantCore.dll!std::invoke<void <lambda>(std::basic_istream<char,std::char_traits<char>> &) &,std::basic_istream<char,std::char_traits<char>> &>(map::MapResource::loadMapNode::__l2::void <lambda>(std::basic_istream<char,std::char_traits<char>> &) & _Obj, std::basic_istream<char,std::char_traits<char>> & <_Args_0>) Line 1579 C++
     DarkRadiantCore.dll!std::_Invoker_ret<void,1>::_Call<void <lambda>(std::basic_istream<char,std::char_traits<char>> &) &,std::basic_istream<char,std::char_traits<char>> &>(map::MapResource::loadMapNode::__l2::void <lambda>(std::basic_istream<char,std::char_traits<char>> &) & <_Vals_0>, std::basic_istream<char,std::char_traits<char>> & <_Vals_1>) Line 1598 C++
     DarkRadiantCore.dll!std::_Func_impl_no_alloc<void <lambda>(std::basic_istream<char,std::char_traits<char>> &),void,std::basic_istream<char,std::char_traits<char>> &>::_Do_call(std::basic_istream<char,std::char_traits<char>> & <_Args_0>) Line 927 C++
     DarkRadiantCore.dll!std::_Func_class<void,std::basic_istream<char,std::char_traits<char>> &>::operator()(std::basic_istream<char,std::char_traits<char>> & <_Args_0>) Line 970 C++
     DarkRadiantCore.dll!map::MapResource::openFileStream(const std::string & path, const std::function<void __cdecl(std::basic_istream<char,std::char_traits<char>> &)> & streamProcessor) Line 456 C++
     DarkRadiantCore.dll!map::MapResource::loadMapNode() Line 295 C++
     DarkRadiantCore.dll!map::MapResource::load() Line 120 C++
     DarkRadiant.exe!ui::PrefabSelector::handleSelectionChange() Line 503 C++
     DarkRadiant.exe!ui::PrefabSelector::onSelectionChanged(wxDataViewEvent & ev) Line 528 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 658 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::CallEventHandler(wxEvtHandler * handler, wxEventFunctor & functor, wxEvent & event) Line 670 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventIfMatchesId(const wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event) Line 1417 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::SearchDynamicEventTable(wxEvent & event) Line 1887 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryHereOnly(wxEvent & event) Line 1608 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line 3912 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventLocally(wxEvent & event) Line 1545 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEvent(wxEvent & event) Line 1518 C++
     wxmsw313ud_core_vc14x_x64.dll!wxScrollHelperEvtHandler::ProcessEvent(wxEvent & event) Line 200 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindowBase::ProcessWindowEvent(wxEvent & event) Line 863 C++
     wxmsw313ud_core_vc14x_x64.dll!wxDataViewMainWindow::SendSelectionChangedEvent(const wxDataViewItem & item) Line 3328 C++
     wxmsw313ud_core_vc14x_x64.dll!wxDataViewMainWindow::OnMouse(wxMouseEvent & event) Line 4877 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 658 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::CallEventHandler(wxEvtHandler * handler, wxEventFunctor & functor, wxEvent & event) Line 670 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventIfMatchesId(const wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event) Line 1417 C++
     wxbase313ud_vc14x_x64.dll!wxEventHashTable::HandleEvent(wxEvent & event, wxEvtHandler * self) Line 1023 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryHereOnly(wxEvent & event) Line 1612 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line 3912 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventLocally(wxEvent & event) Line 1545 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEvent(wxEvent & event) Line 1518 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::SafelyProcessEvent(wxEvent & event) Line 1636 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindowBase::HandleWindowEvent(wxEvent & event) Line 1556 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::HandleMouseEvent(unsigned int msg, int x, int y, unsigned int flags) Line 5871 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWHandleMessage(__int64 * result, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3154 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3873 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWndProc(HWND__ * hWnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2940 C++
     user32.dll!UserCallWinProcCheckWow() Unknown
     user32.dll!DispatchMessageWorker() Unknown
     user32.dll!IsDialogMessageW() Unknown
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWSafeIsDialogMessage(tagMSG * msg) Line 2805 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWProcessMessage(tagMSG * pMsg) Line 2689 C++
     wxmsw313ud_core_vc14x_x64.dll!wxGUIEventLoop::PreProcessMessage(tagMSG * msg) Line 145 C++
     wxmsw313ud_core_vc14x_x64.dll!wxGUIEventLoop::ProcessMessage(tagMSG * msg) Line 163 C++
     wxmsw313ud_core_vc14x_x64.dll!wxGUIEventLoop::Dispatch() Line 229 C++
     wxbase313ud_vc14x_x64.dll!wxEventLoopManual::ProcessEvents() Line 237 C++
     wxbase313ud_vc14x_x64.dll!wxEventLoopManual::DoRun() Line 283 C++
     wxbase313ud_vc14x_x64.dll!wxEventLoopBase::Run() Line 90 C++
     wxmsw313ud_core_vc14x_x64.dll!wxDialogModalData::RunLoop() Line 63 C++
     wxmsw313ud_core_vc14x_x64.dll!wxDialog::ShowModal() Line 192 C++
     DarkRadiant.exe!ui::PrefabSelector::ShowModal() Line 255 C++
     DarkRadiant.exe!ui::PrefabSelector::ChoosePrefab(const std::string & curPrefab) Line 326 C++
     DarkRadiant.exe!ui::OrthoContextMenu::callbackAddPrefab() Line 333 C++
     DarkRadiant.exe!std::_Invoker_pmf_pointer::_Call<void (__cdecl ui::OrthoContextMenu::*)(void),ui::OrthoContextMenu * &>(void(ui::OrthoContextMenu::*)() _Pmf, ui::OrthoContextMenu * & _Arg1) Line 1579 C++
     DarkRadiant.exe!std::invoke<void (__cdecl ui::OrthoContextMenu::*&)(void),ui::OrthoContextMenu * &>(void(ui::OrthoContextMenu::*)() & _Obj, ui::OrthoContextMenu * & <_Args_0>) Line 1579 C++
     DarkRadiant.exe!std::_Invoker_ret<std::_Unforced,0>::_Call<void (__cdecl ui::OrthoContextMenu::*&)(void),ui::OrthoContextMenu * &>(void(ui::OrthoContextMenu::*)() & <_Vals_0>, ui::OrthoContextMenu * & <_Vals_1>) Line 1615 C++
     DarkRadiant.exe!std::_Call_binder<std::_Unforced,0,void (__cdecl ui::OrthoContextMenu::*)(void),std::tuple<ui::OrthoContextMenu *>,std::tuple<>>(std::_Invoker_ret<std::_Unforced,0> __formal, std::integer_sequence<unsigned __int64,0> __formal, void(ui::OrthoContextMenu::*)() & _Obj, std::tuple<ui::OrthoContextMenu *> & _Tpl, std::tuple<> && _Ut) Line 1402 C++
     DarkRadiant.exe!std::_Binder<std::_Unforced,void (__cdecl ui::OrthoContextMenu::*)(void),ui::OrthoContextMenu *>::operator()<>() Line 1442 C++
     DarkRadiant.exe!std::_Invoker_functor::_Call<std::_Binder<std::_Unforced,void (__cdecl ui::OrthoContextMenu::*)(void),ui::OrthoContextMenu *> &>(std::_Binder<std::_Unforced,void (__cdecl ui::OrthoContextMenu::*)(void),ui::OrthoContextMenu *> & _Obj) Line 1579 C++
     DarkRadiant.exe!std::invoke<std::_Binder<std::_Unforced,void (__cdecl ui::OrthoContextMenu::*)(void),ui::OrthoContextMenu *> &>(std::_Binder<std::_Unforced,void (__cdecl ui::OrthoContextMenu::*)(void),ui::OrthoContextMenu *> & _Obj) Line 1579 C++
     DarkRadiant.exe!std::_Invoker_ret<void,1>::_Call<std::_Binder<std::_Unforced,void (__cdecl ui::OrthoContextMenu::*)(void),ui::OrthoContextMenu *> &>(std::_Binder<std::_Unforced,void (__cdecl ui::OrthoContextMenu::*)(void),ui::OrthoContextMenu *> & <_Vals_0>) Line 1598 C++
     DarkRadiant.exe!std::_Func_impl_no_alloc<std::_Binder<std::_Unforced,void (__cdecl ui::OrthoContextMenu::*)(void),ui::OrthoContextMenu *>,void>::_Do_call() Line 927 C++
     DarkRadiant.exe!std::_Func_class<void>::operator()() Line 970 C++
     DarkRadiant.exe!wxutil::MenuItem::execute() Line 39 C++
     DarkRadiant.exe!ui::OrthoContextMenu::onItemClick(wxCommandEvent & ev) Line 581 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 658 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::CallEventHandler(wxEvtHandler * handler, wxEventFunctor & functor, wxEvent & event) Line 670 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventIfMatchesId(const wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event) Line 1417 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::SearchDynamicEventTable(wxEvent & event) Line 1887 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryHereOnly(wxEvent & event) Line 1608 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line 3912 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventLocally(wxEvent & event) Line 1545 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEvent(wxEvent & event) Line 1518 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::SafelyProcessEvent(wxEvent & event) Line 1636 C++
     wxmsw313ud_core_vc14x_x64.dll!wxMenuBase::DoProcessEvent(wxMenuBase * menu, wxEvent & event, wxWindow * win) Line 667 C++
     wxmsw313ud_core_vc14x_x64.dll!wxMenuBase::SendEvent(int itemid, int checked) Line 643 C++
     wxmsw313ud_core_vc14x_x64.dll!wxMenu::MSWCommand(unsigned int __formal, unsigned short id_) Line 799 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::HandleCommand(unsigned short id_, unsigned short cmd, HWND__ * control) Line 5747 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWHandleMessage(__int64 * result, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3179 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3873 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWndProc(HWND__ * hWnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2940 C++
     user32.dll!UserCallWinProcCheckWow() Unknown
     user32.dll!CallWindowProcW() Unknown
     opengl32.dll!00007ff810283919() Unknown
     user32.dll!UserCallWinProcCheckWow() Unknown
     user32.dll!DispatchMessageWorker() Unknown
     wxmsw313ud_core_vc14x_x64.dll!wxYieldForCommandsOnly() Line 2369 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::DoPopupMenu(wxMenu * menu, int x, int y) Line 2400 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindowBase::PopupMenu(wxMenu * menu, int x, int y) Line 3022 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindowBase::PopupMenu(wxMenu * menu, const wxPoint & pos) Line 1276 C++
     DarkRadiant.exe!ui::OrthoContextMenu::Show(wxWindow * parent, const BasicVector3<double> & point) Line 127 C++
     DarkRadiant.exe!ui::XYWnd::onContextMenu() Line 447 C++
     DarkRadiant.exe!ui::XYWnd::onGLMouseButtonRelease(wxMouseEvent & ev) Line 1606 C++
     DarkRadiant.exe!std::_Invoker_pmf_pointer::_Call<void (__cdecl ui::XYWnd::*)(wxMouseEvent &),ui::XYWnd * &,wxMouseEvent &>(void(ui::XYWnd::*)(wxMouseEvent &) _Pmf, ui::XYWnd * & _Arg1, wxMouseEvent & <_Args2_0>) Line 1579 C++
     DarkRadiant.exe!std::invoke<void (__cdecl ui::XYWnd::*&)(wxMouseEvent &),ui::XYWnd * &,wxMouseEvent &>(void(ui::XYWnd::*)(wxMouseEvent &) & _Obj, ui::XYWnd * & <_Args_0>, wxMouseEvent & <_Args_1>) Line 1579 C++
     DarkRadiant.exe!std::_Invoker_ret<std::_Unforced,0>::_Call<void (__cdecl ui::XYWnd::*&)(wxMouseEvent &),ui::XYWnd * &,wxMouseEvent &>(void(ui::XYWnd::*)(wxMouseEvent &) & <_Vals_0>, ui::XYWnd * & <_Vals_1>, wxMouseEvent & <_Vals_2>) Line 1615 C++
     DarkRadiant.exe!std::_Call_binder<std::_Unforced,0,1,void (__cdecl ui::XYWnd::*)(wxMouseEvent &),std::tuple<ui::XYWnd *,std::_Ph<1>>,std::tuple<wxMouseEvent &>>(std::_Invoker_ret<std::_Unforced,0> __formal, std::integer_sequence<unsigned __int64,0,1> __formal, void(ui::XYWnd::*)(wxMouseEvent &) & _Obj, std::tuple<ui::XYWnd *,std::_Ph<1>> & _Tpl, std::tuple<wxMouseEvent &> && _Ut) Line 1402 C++
     DarkRadiant.exe!std::_Binder<std::_Unforced,void (__cdecl ui::XYWnd::*)(wxMouseEvent &),ui::XYWnd *,std::_Ph<1> const &>::operator()<wxMouseEvent &>(wxMouseEvent & <_Unbargs_0>) Line 1442 C++
     DarkRadiant.exe!std::_Invoker_functor::_Call<std::_Binder<std::_Unforced,void (__cdecl ui::XYWnd::*)(wxMouseEvent &),ui::XYWnd *,std::_Ph<1> const &> &,wxMouseEvent &>(std::_Binder<std::_Unforced,void (__cdecl ui::XYWnd::*)(wxMouseEvent &),ui::XYWnd *,std::_Ph<1> const &> & _Obj, wxMouseEvent & <_Args_0>) Line 1579 C++
     DarkRadiant.exe!std::invoke<std::_Binder<std::_Unforced,void (__cdecl ui::XYWnd::*)(wxMouseEvent &),ui::XYWnd *,std::_Ph<1> const &> &,wxMouseEvent &>(std::_Binder<std::_Unforced,void (__cdecl ui::XYWnd::*)(wxMouseEvent &),ui::XYWnd *,std::_Ph<1> const &> & _Obj, wxMouseEvent & <_Args_0>) Line 1579 C++
     DarkRadiant.exe!std::_Invoker_ret<void,1>::_Call<std::_Binder<std::_Unforced,void (__cdecl ui::XYWnd::*)(wxMouseEvent &),ui::XYWnd *,std::_Ph<1> const &> &,wxMouseEvent &>(std::_Binder<std::_Unforced,void (__cdecl ui::XYWnd::*)(wxMouseEvent &),ui::XYWnd *,std::_Ph<1> const &> & <_Vals_0>, wxMouseEvent & <_Vals_1>) Line 1598 C++
     DarkRadiant.exe!std::_Func_impl_no_alloc<std::_Binder<std::_Unforced,void (__cdecl ui::XYWnd::*)(wxMouseEvent &),ui::XYWnd *,std::_Ph<1> const &>,void,wxMouseEvent &>::_Do_call(wxMouseEvent & <_Args_0>) Line 927 C++
     DarkRadiant.exe!std::_Func_class<void,wxMouseEvent &>::operator()(wxMouseEvent & <_Args_0>) Line 970 C++
     DarkRadiant.exe!wxutil::FreezePointer::onMouseUp(wxMouseEvent & ev) Line 186 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 658 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::CallEventHandler(wxEvtHandler * handler, wxEventFunctor & functor, wxEvent & event) Line 670 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventIfMatchesId(const wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event) Line 1417 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::SearchDynamicEventTable(wxEvent & event) Line 1887 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryHereOnly(wxEvent & event) Line 1608 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line 3912 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEventLocally(wxEvent & event) Line 1545 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::ProcessEvent(wxEvent & event) Line 1518 C++
     wxbase313ud_vc14x_x64.dll!wxEvtHandler::SafelyProcessEvent(wxEvent & event) Line 1636 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindowBase::HandleWindowEvent(wxEvent & event) Line 1556 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::HandleMouseEvent(unsigned int msg, int x, int y, unsigned int flags) Line 5871 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWHandleMessage(__int64 * result, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3154 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWindow::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3873 C++
     wxmsw313ud_core_vc14x_x64.dll!wxTopLevelWindowMSW::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 346 C++
     wxmsw313ud_core_vc14x_x64.dll!wxFrame::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 912 C++
     wxmsw313ud_core_vc14x_x64.dll!wxWndProc(HWND__ * hWnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2940 C++
     user32.dll!UserCallWinProcCheckWow() Unknown
     user32.dll!DispatchMessageWorker() Unknown
     wxmsw313ud_core_vc14x_x64.dll!wxGUIEventLoop::ProcessMessage(tagMSG * msg) Line 169 C++
     wxmsw313ud_core_vc14x_x64.dll!wxGUIEventLoop::Dispatch() Line 229 C++
     wxbase313ud_vc14x_x64.dll!wxEventLoopManual::ProcessEvents() Line 237 C++
     wxbase313ud_vc14x_x64.dll!wxEventLoopManual::DoRun() Line 283 C++
     wxbase313ud_vc14x_x64.dll!wxEventLoopBase::Run() Line 90 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::MainLoop() Line 380 C++
     wxbase313ud_vc14x_x64.dll!wxAppConsoleBase::OnRun() Line 302 C++
     wxmsw313ud_core_vc14x_x64.dll!wxAppBase::OnRun() Line 336 C++
     wxbase313ud_vc14x_x64.dll!wxEntryReal(int & argc, wchar_t * * argv) Line 507 C++
     wxbase313ud_vc14x_x64.dll!wxEntry(int & argc, wchar_t * * argv) Line 184 C++
     wxmsw313ud_core_vc14x_x64.dll!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ * __formal, char * __formal, int nCmdShow) Line 306 C++
     DarkRadiant.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * __formal, int nCmdShow) Line 7 C++
     DarkRadiant.exe!invoke_main() Line 107 C++
     DarkRadiant.exe!__scrt_common_main_seh() Line 288 C++
     DarkRadiant.exe!__scrt_common_main() Line 331 C++
     DarkRadiant.exe!WinMainCRTStartup() Line 17 C++
     kernel32.dll!00007ff83a707bd4() Unknown
     ntdll.dll!00007ff83b86ce51() Unknown
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5288 [DarkRadiant] GUI feature N/A 09.07.2020 10:46 19.09.2020 18:02
Reporter: Dragofer Platform:  
Assigned To: greebo OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Exit search field in child window by pressing escape
Description: A little annoyance after searching within child windows, i.e. 'Create Model', is that pressing escape closes the whole child window, so the only way to dismiss the search field is to wait some time. During that time, my arrow keys only let me cycle through search results, which is inconvenient because I often use the search function only to get in the approximate location of what I'm looking for (i.e. "arrow_broadhead" if I want to see all available arrow soundshaders).
Tags:
Steps To Reproduce: 1) Right-click > 'Create speaker...'.
2) Start typing 'arrow_broadhead' to bring up a search field.
3) Press escape. The whole child window closes, instead of only dismissing the search field.
Additional Information:
Attached Files:
Notes
(0012779)
greebo   
18.09.2020 04:01   
Confirmed, at least for the Sound Chooser. Other Tree Views embedded in the main window or the ModelChooser behave correctly. Have to investigate what the difference between those windows is.
(0012780)
Dragofer   
18.09.2020 22:54   
I can also add that this behaviour occured in the Prefab Chooser.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5234 [The Dark Mod] Coding normal always 30.04.2020 15:37 19.09.2020 15:22
Reporter: t405 Platform: Linux  
Assigned To: OS: Arch  
Priority: low OS Version: 5.6.7  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: compilation: scons configuration and documentation
Description: If scons is really no longer supported as a compilation method, then only one thing needs to be done:

The wiki and COMPILING.txt need to be brought in sync and the scons configuration files removed from the svn repo.

If people are still using scons, then this will be helpful.

After trying to compile according to the wiki instructions, using scons, a number of errors occurred. Most of these errors were due to the code being written in python2 and being incompatible with python3.

The problematic files were

SConstruct
sys/scons/scons_utils.py
tdm_update/SConstruct
tdm_update/scons_utils.py

I was confused by the conflicting instructions in the wiki and in COMPILING.txt

the last update on the wiki is older ( 14:58, 30 September 2019‎ Duzenko ) than the svn ( r8453 | cabalistic | 2019-12-19 14:51:53 -0500 (Thu, 19 Dec 2019) )
Tags:
Steps To Reproduce: I checked out the svn repo 8693 and attempted to compile using the wiki instructions

Immediately got an error:
scons: Reading SConscript files ...
  File "/home/shawn/Code/darkmod-svn-wd/trunk/SConstruct", line 150
    print 'Loading build configuration from ' + conf_filename + ':'
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print('Loading build configuration from ' + conf_filename + ':')?

There were a number of other errors: a missing module (popen2) and problems with the pickle and raise syntax.
Additional Information:     Compilation was successful after I patched the files by translating them with 2to3, cleaning them up with black, and manually fixing the other errors.

`uname -a`:
 Linux 5.6.7-arch1-1 0000001 SMP PREEMPT Thu, 23 Apr 2020 09:13:56 +0000 x86_64 GNU/Linux
`scons --version | xargs`:
 SCons by Steven Knight et al.: script: v3.1.2.__BUILD__, 2019-12-17 02:06:27, by none on none engine: v3.1.2.__BUILD__, 2019-12-17 02:06:27, by none on none engine path: [/usr/lib/python3.8/site-packages/SCons] Copyright (c) 2001 - 2019 The SCons Foundation
`black --version`:
 black, version 19.10b0

Patch is included in uploads.
Attached Files: scons-fix-python3-001.patch (43,655 bytes) 30.04.2020 15:37
https://bugs.thedarkmod.com/file_download.php?file_id=843&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5269 [DarkRadiant] General trivial always 01.06.2020 17:48 18.09.2020 03:54
Reporter: stgatilov Platform:  
Assigned To: greebo OS:  
Priority: low OS Version:  
Status: resolved Product Version: 2.6.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.9.0  
    Target Version: 2.9.0  
Summary: Escaped EOLN in entity spawnarg is turned into real EOLN
Description: The D3 engine can show text in some location, which is used only for debugging.
The contents of such text is written in the value of "text" spawnarg of entity of "text" class.
The problem is that D3 parser forbids putting a real EOL into spawnargs, that causes a hard parsing error.

For 2.08 I have fixed the problem by turning "\n" into EOL character in the code of the text entity.
Now I can write multiline text labels by using "\n" in the text string.

The problem is that when I open such a map in DR and then save it back, every "\n" in spawnarg value is turned into actual EOL character, making the map unparsable.
I wonder if it can be fixed easily?...
Tags:
Steps To Reproduce: Download the FM attached to wiki page about "particle collision":
  https://thedarkmod.blob.core.windows.net/various/wiki_rain_testcollision/test_raincollision.zip
It is also committed to the assets SVN repo of TDM.
Open it in DR, then save it.
Now either try to dmap it or simply search for "\n" in the .map file.
Additional Information:
Attached Files:
Notes
(0012778)
greebo   
18.09.2020 03:54   
Added a \n escaping function in the D3 entity key value exporter. Let's hope this doesn't have any unwanted side effects.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5335 [The Dark Mod] Coding minor always 06.09.2020 19:29 06.09.2020 19:29
Reporter: unode Platform: Linux  
Assigned To: OS: NixOS  
Priority: normal OS Version: 20.03  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Missing "math.h" include in "tdm_update/ConsoleUpdater.cpp"
Description: In "tdm_update/ConsoleUpdater.cpp" line 448 (as of https://svn.thedarkmod.com/publicsvn/darkmod_src/tags/2.08/tdm_update/ConsoleUpdater.cpp) , the function "floor" is used but "math.h" is not included causing compilation to fail.


Adding "#include <math.h>" was enough to solve the compilation failure.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5297 [The Dark Mod] GUI normal N/A 17.07.2020 12:48 01.09.2020 17:32
Reporter: Dragofer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: suspended Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: AF Editor: make spawned ragdolls frobable
Description: On the bottom left of the AF editor is a "Spawn" button that spawns a ragdoll in T-Pose in front of the player. It's not frobable, however, so it can't be dragged around in order to test the physics.
Tags:
Steps To Reproduce:
Additional Information: The AF Editor's originally intended way is to use g_dragEntity 1, which is Doom 3's old system of dragging bodies. It differs wildly from TDM's system, however.
Attached Files:
Notes
(0012689)
stgatilov   
30.07.2020 17:38   
Still, it is a very good find that it is possible to drag spawned AFs like this:
  1) set "g_dragEntity 1" in console
  2) point some AF, and press left mouse button (attack)
  3) move mouse around without releasing the button
Recording this just for the history.
  
I think adding frobability should not be hard.
(0012690)
stgatilov   
30.07.2020 17:41   
Should I just set "frobable 1", or should I make the new entity inherit some base class?
I mean, there are lots of spawnargs in moveable_base, atdm:frobable_base.
(0012691)
stgatilov   
30.07.2020 17:51   
I managed to get the right feel of frob-dragging guard's AF by setting:
  From atdm:frobable_base:
    frobable 1
    grabable 1
  From atdm:env_ragdoll_base:
    drag_force_mod 10

Without the last argument, the body is too heavy to be dragged.
That's the specific hack for guards, and I think I should not apply it for all AFs.
The same issue applies to shouldering guard's body: I cannot see if some AF is guard or not.

So... I think the best I can do is to set frobable and grabable.
Or I can inherit atdm:frobable_base, which seems to also have these:
    "frob_action_script" "frob_trigger"
    "used_action_script" "frob_trigger"
What are they for? Are they needed?
(0012692)
Dragofer   
30.07.2020 21:11   
(Last edited: 30.07.2020 21:16)
Ah, the absent drag_force_mod explains why editor-spawned ragdolls behaved so much differently than when I just killed an AI to get the ragdoll, I could barely move it. I think having that hack is very important for physics testing - could it maybe be an extra setting in the first tab of the editor that applies itself to spawned bodies, for testing? When the AF is finished the creator can add that force modifier as a spawnarg to the ragdoll entity def.

Frobable 1 and Grabable 1 are a good start.

The action scripts' function is to make the frobable entity trigger its targets when it gets frobbed or triggered, so they have no relevance here.
(0012693)
stgatilov   
31.07.2020 04:12   
You can set tdm_drag_force_max 10 times higher than default, and it should have the same effect.
(0012694)
Dragofer   
31.07.2020 06:54   
That's good to know and can serve as a workaround, but it's not good to need console commands in order to use the AF Editor properly - the entire process of generating an AF is already very clunky.

From my view it'd be much appreciated if there were that extra "Drag Force Modifier" field in the 1st tab under "Physics" that applies its value to spawned ragdolls.
(0012695)
stgatilov   
31.07.2020 07:28   
Committed the simple change in svn rev 8905.

As for modifier in GUI, I think putting it into random location is no good.
A new tab should be added for entity settings, which needs some work.
I'll return to it if I have time.
(0012775)
stgatilov   
01.09.2020 17:31   
(Last edited: 01.09.2020 17:32)
The reason for suspending is my post here:
  https://forums.thedarkmod.com/index.php?/topic/20485-future-of-in-game-editor-tools/&do=findComment&comment=451309
Basically, I think I will rewrite the whole AF editor in the end (0005333).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5333 [The Dark Mod] Coding feature N/A 31.08.2020 04:12 01.09.2020 17:32
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.10  
Summary: Reimplement AF editor: either in-game with FLTK, or in DarkRadiant with game connection
Description: DR-TDM game connection feature is going to make most of the in-game editors obsolete.
Since it is hard to change existing AF editor, it would probably make sense to reimplement it.
As a bonus, that would allow dropping all current in-game tools and removing MFC completely.

There are two possible ways to reimplement it:
1) Implement as in-game editor, but use FLTK for GUI.
2) Implement as DarkRadiant dialog, and use game connection to provide live preview.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3793 [The Dark Mod] Feature proposal normal have not tried 22.07.2014 18:41 01.09.2020 17:31
Reporter: nbohr1more Platform: ALL  
Assigned To: OS: ALL  
Priority: normal OS Version: ALL  
Status: suspended Product Version: SVN  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Replace script interpreter with a JIT implementation
Description: Currently, all script events are interpreted from text in real-time rather than
being pre-compiled as binary. Quake 3 had a JIT compiler for scripts and it improved performance as well as script debugging.

http://fabiensanglard.net/doom3/scripting_vm.php

Discussion:

http://forums.thedarkmod.com/topic/15178-tdm-engine-development-page/page__view__findpost__p__350460

Revelator details:

http://llvm.org/builds/

these hook into msvc2010 through 2013 so you can use clang with msvc.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006792)
nbohr1more   
22.07.2014 18:43   
Related: 0003623
(0008811)
stgatilov   
29.04.2017 05:01   
I don't think using LLVM is wise.
It is a huge, constantly changing, windows unfriendly project, do you really think it is OK to depend on it?
Here is a bit about how large it is:
  http://cseweb.ucsd.edu/~jvoung/llvm_size_report/
And here it is explained how "get started" with it:
  http://llvm.org/docs/GettingStartedVS.html
(it is mentioned there that at least MSVC2015 is required)

Also, the simplest way to implement JIT-compiler is to translate bytecode into native code. In order to get better error reports, it is necessary to change the frontend, i.e. add better error diagnostocs to ID's compiler. How can LLVM help with it?
You might be dreaming of replacing ID's compiler with Clang, but I'm pretty sure that even slightest differences between doom3 scripting language and clang would be almost impossible to fix in the huge clang codebase.
(0008812)
stgatilov   
29.04.2017 05:09   
If we need better performance for scripts execution, then it is possible to compile them into native code on initialization.
Carmack implemented such compilation for Quake 3 in several days. He wrote templates manually, writing down binary x86 code in hex representation.

In our case, we should support x86/x64 differences, and MSVC/GCC + windows/linux. The asmjit library can help here: it allows to write single code to support all of these cases. And it is not so big and tricky.
  https://github.com/asmjit/asmjit
Writing compiler to native code is as simple as providing assembly code (well, in C++-wrapped form) for all 123 opcodes of the interpreter. Indeed, the resulting binary would not be optimal (LLVM could do better), but do we need utmost performance of scripts?
(0008814)
nbohr1more   
30.04.2017 00:30   
Yes good points on LLVM. That's probably more of a quagmire than our current boost dependency mess.
(0009067)
stgatilov   
08.08.2017 17:03   
I think doing anything for this issue does not make sense unless there is any evidence that improving script performance would make game run noticeably faster. Currently I doubt it greatly.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4545 [The Dark Mod] Graphics normal always 13.06.2017 08:02 01.09.2020 16:49
Reporter: gerv Platform: x86-64  
Assigned To: stgatilov OS: Linux  
Priority: normal OS Version: Ubuntu 16.04  
Status: resolved Product Version: TDM 2.05  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.08  
    Target Version:  
Summary: Gamma and brightness controls have no effect on external monitor
Description: I have a Thinkpad Carbon X1 Gen 4 running Ubuntu 16.04 64-bit. It has a native resolution of 2560x1440. It's connected via a Thinkpad OneLink+ dock to an external monitor, resolution 1920x1200.

When I am using the external monitor, with the internal LCD disabled, the gamma and brightness controls have no effect. They only work when I am using the built-in LCD panel. Restarting TDM also has no effect. The default settings for the external monitor are far too light. I can make things a bit better by setting r_lightScale to 1 or some other value < 2, but that's not supposed to be the way this works, is it?

There seems to be someone else here with a similar problem (comment 0000009):
http://forums.thedarkmod.com/topic/18533-gamma-or-brightness-settings-have-no-effect-on-brightness-on-debian-sid-with-an-sapphire-rx-480/?hl=gamma
Tags:
Steps To Reproduce: Adjust Gamma and Brightness settings while external monitor enabled
Additional Information:
Attached Files:
Notes
(0008905)
duzenko   
13.06.2017 09:29   
Are any Doom-family games able to control gamma/brightness for you?
(0008906)
gerv   
13.06.2017 09:56   
I've not played any other similar games on this machine. Can you tell me where I can easily download and try one out?
(0008907)
duzenko   
13.06.2017 09:57   
(Last edited: 13.06.2017 09:58)
Maybe steam/gog?
Don't know any free games like that except TDM.

(0008908)
gerv   
13.06.2017 10:22   
Ah :-| I try and run only open source software on my machine. Are there no other Doom-engine-based open source games?
(0010998)
nbohr1more   
20.12.2018 16:55   
Soft gamma in 2.07 should work on external monitors.

I guess we'd also need a "soft brightness" mode?
(0011002)
duzenko   
21.12.2018 09:50   
Would it make sense to add it where r_lightscale is being used now?
(0012247)
stgatilov   
28.02.2020 03:35   
Due to the changes in 0004705, gamma and brightness are now always applied as part of postprocessing shader.
It is highly unlikely that this issue will be present in 2.08.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4532 [The Dark Mod] Sound System normal have not tried 15.05.2017 09:23 01.09.2020 16:47
Reporter: duzenko Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.06  
    Target Version: TDM 2.06  
Summary: TDM crashes at startup if no sound device is available on Windows
Description: Steps to repeat: disable all your sound devices in Windows Sound options dialog, Playback tab (Windows 10).
An error will be raised in idSoundSample::Load

        if (errorCode != AL_NO_ERROR)
            IssueSoundSampleFailure("idSoundCache: WAV error generating OpenAL hardware buffer", errorCode, name.c_str());

Expected behavior: TDM should start and run with no sound.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008946)
stgatilov   
02.07.2017 08:19   
Fixed in revision 6996.

Actually, there is already s_noSound cvar which disabled all sounds. I did a small fix related to issue 4534, after which it works properly.
Now this cvar is enabled automatically if no OpenAL device is found. It is accompanied by message to console: "OpenAL: no device found, sound disabled"
(0010747)
duzenko   
01.09.2018 19:36   
The original issue is fixed however it still crashes when exiting the game :(
(0010759)
duzenko   
12.09.2018 06:40   
> TheDarkModNoTools.exe!idSoundEmitterLocal::StopSound(const int channel) Line 979 C++
     TheDarkModNoTools.exe!idEntity::StopSound(const int channel, bool broadcast) Line 4614 C++
     TheDarkModNoTools.exe!idActor::~idActor() Line 799 C++
     TheDarkModNoTools.exe!idAI::~idAI() Line 659 C++
     [External Code]
     TheDarkModNoTools.exe!idGameLocal::MapClear(bool clearClients) Line 2433 C++
     TheDarkModNoTools.exe!idGameLocal::MapShutdown() Line 2495 C++
     TheDarkModNoTools.exe!idSessionLocal::UnloadMap() Line 1334 C++
     [Inline Frame] TheDarkModNoTools.exe!idSessionLocal::Stop() Line 314 C++
     TheDarkModNoTools.exe!Session_Disconnect_f(const idCmdArgs & args) Line 693 C++
     TheDarkModNoTools.exe!idCmdSystemLocal::ExecuteTokenizedString(const idCmdArgs & args) Line 482 C++
     [Inline Frame] TheDarkModNoTools.exe!idCmdSystemLocal::ExecuteCommandText(const char *) Line 504 C++
     TheDarkModNoTools.exe!idCmdSystemLocal::BufferCommandText(cmdExecution_t exec, const char * text) Line 565 C++
     TheDarkModNoTools.exe!idSessionLocal::HandleMainMenuCommands(const char * menuCommand) Line 877 C++
     TheDarkModNoTools.exe!idSessionLocal::DispatchCommand(idUserInterface * gui, const char * menuCommand, bool doIngame) Line 998 C++
     TheDarkModNoTools.exe!idSessionLocal::MenuEvent(const sysEvent_s * event) Line 1052 C++
     TheDarkModNoTools.exe!idSessionLocal::ProcessEvent(const sysEvent_s * event) Line 2235 C++
     [Inline Frame] TheDarkModNoTools.exe!idEventLoop::ProcessEvent(sysEvent_s ev) Line 149 C++
     TheDarkModNoTools.exe!idEventLoop::RunEventLoop(bool commandExecution) Line 184 C++
     TheDarkModNoTools.exe!idCommonLocal::Frame() Line 2427 C++
     TheDarkModNoTools.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 1363 C++
     [External Code]
     [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] Unknown
(0010833)
stgatilov   
06.12.2018 12:47   
Failed to reproduce.

I exited from game normally several times, both from release and debug builds with debugger attached, both from game and from menu, with Alt+F4 and with menu buttons.
Probably it is some rare bug.
(0010835)
duzenko   
06.12.2018 15:51   
Looking at the stack it could be AI talking - did you test that?
(0010838)
stgatilov   
06.12.2018 16:32   
I gathered five angry guards around me, hoping that at least one of them would talk. It is hard to know when someone speaks with no sound =)
(0012774)
stgatilov   
01.09.2020 16:47   
I cannot reproduce the problem it was reopened for.
And since nobody else complained in two years, I return it to resolved state.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4341 [The Dark Mod] Sound normal have not tried 07.06.2016 18:58 01.09.2020 16:44
Reporter: grayman Platform:  
Assigned To: stgatilov OS:  
Priority: high OS Version:  
Status: resolved Product Version: TDM 2.04  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version: TDM 2.09  
Summary: Conversation sound will abort during a save
Description: This popped up during 2.04 beta test.

Spooks said: "Also, any time you quick save while a sound is playing, e.g. a conversation is going on, the sound will cut out. Noticed it ever since I stared testing and iirc I tested it on 2.03 and it happens there too, so I thought to leave it, but I'll mention it, no harm in doing it."
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008203)
Spooks   
08.06.2016 12:12   
I believe any sort of speaker initiated sound will cut out after a quicksave. The wind sound that plays when the doors of the monastery in Exhumed open, for instance, will stop playing when you save.

Loading will actually resume playing the sound from where it left off, even if it cut out at savetime to begin with, so only saving is affected.
(0011275)
nbohr1more   
09.01.2019 20:20   
ConversationSystem.cpp has savegame attributes... I wonder why these are failing?
(0011478)
nbohr1more   
22.01.2019 23:24   
(Last edited: 22.01.2019 23:34)
A hunch of sorts...

The savegame process calls a sound pause operation but it may be that this is tied to other pause requests.

Related to the topic of "Pause"...

The "pause" system key used to call the pause "event" but is now throwing an unrecognized command. Find out when "Pause" was broken...

(0012773)
stgatilov   
01.09.2020 16:44   
Fixed in svn rev 8962.

The status of OpenAL source was checked to see if sound was complete.
This is wrong, because when game is unpaused, all OpenAL sources are usually long finished, since nobody pushed new data to them during pause.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5334 [The Dark Mod] Graphics minor always 01.09.2020 16:32 01.09.2020 16:34
Reporter: stgatilov Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: SVN  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: White rectangle blinks when in-game text appears
Description: When hints come up in the New Job FM, they start with a fast glimpse of white rectangle.
Rectangle quickly disappears, and the text starts slowly fading in from nonexistance.

Note: messages like "Objective Complete" don't have this problem.
Tags:
Steps To Reproduce: 1) Start New Job FM.
2) Come to some place with a hint (better save just before it).
I believe the first such place is when two guards are talking (arrival at streets).

I reproduced it with old backend.
Tried toggling other things like uncapped FPS, SMP, 64-bit color --- does not help.
Additional Information:
Attached Files: Darkmod.cfg (13,238 bytes) 01.09.2020 16:34
https://bugs.thedarkmod.com/file_download.php?file_id=897&type=bug
Notes
(0012772)
stgatilov   
01.09.2020 16:34   
Config file.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5053 [The Dark Mod] AI minor always 13.09.2019 16:29 01.09.2020 16:16
Reporter: VanishedOne Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.07  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.08  
    Target Version:  
Summary: Lanternbot still has lit appearance after 'knockout'
Description: When a lanternbot is 'killed', parm7 is faded to 0 by tdm_ai_lanternbot::onDeath(), which fades down the bright yellow flickering of the lantern glass surface using the lanternbot_lit material.

However, lanternbots can also be disabled with the blackjack, and when that happens the actual light goes out but the lit material on the body is unchanged.
Tags:
Steps To Reproduce:
Additional Information: Speaking of lanternbot_lit colouration, why are the diffuse colour parms multiplied by each other?

{
        blend diffusemap
        map models/md5/chars/steambots/bc_lanternbot
        rgb parm0 * parm1 * parm2
    }

The lanternbot has default "_color" "0.7 0.64 0" so presumably the result is rgb 0.
Attached Files:
Notes
(0011990)
stgatilov   
30.12.2019 17:58   
By the way, a live lantern bot can be found in "In The Black" FM by executing: setviewpos 4448 3744 16
(0011994)
stgatilov   
31.12.2019 06:34   
Added "ko_immune" "1" to base steambot in svn rev 15760.
It was intended that bots cannot be knocked out, but "ko_zone" "" has no effect because damage zones are not defined (and are consequently all empty strings too).
The bot is also immune to gas, so I guess nobody will ever knock it out again =)
(0012000)
VanishedOne   
31.12.2019 13:36   
Intended or not, that's a pretty major gameplay change in the difficulty of dealing with an AI that's been around for years. Did you consult anyone else?

When wesp5 wanted oil lamps made snuffable through frobbing to bring them in line with candles, his proposal was rejected on the grounds that maps' gameplay design shouldn't be changed retroactively, even if in principle the idea was sound.
(0012003)
stgatilov   
31.12.2019 19:17   
Well, I wrote about it on public forums.
Speaking of lantern bots, the difficulty change is minor, since they can be killed with a sword just as easily.
(0012005)
VanishedOne   
01.01.2020 14:11   
Oh, I see. Linking to thread: https://forums.thedarkmod.com/index.php?/topic/11155-lanternbot-relations/&tab=comments#comment-442370

Fair point, most missions do provide the sword and blackjack at the same time, though it isn't universal.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4364 [The Dark Mod] Feature proposal normal always 16.08.2016 22:08 31.08.2020 17:02
Reporter: nbohr1more Platform: ALL  
Assigned To: duzenko OS:  
Priority: normal OS Version:  
Status: assigned Product Version: SVN  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: RGTC Normal Map compression
Description: Serpentine added some code for LATC loading in TDM but was planning on automating the conversion process and found that Intel does not support LATC so RGTC was planned as a replacement.

In lieu of automating the conversion, we could probably just add the format and externally convert the textures in batches.
Tags:
Steps To Reproduce:
Additional Information: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_texture_compression_rgtc.txt
Attached Files:
Notes
(0008269)
nbohr1more   
16.08.2016 22:13   
External work:

https://github.com/revelator/The-Darkmod-Experimental/commit/d4fcae9ce064b6020a8f7e11210aab36160f2a9e

https://github.com/revelator/The-Darkmod-Experimental/commit/e844559504fcd26a7061c3fa9af7c087d50a6ab9

Need to double-check and assumptions and create test assets.
(0008270)
nbohr1more   
16.08.2016 22:15   
Recent Discussion:

http://forums.thedarkmod.com/topic/18280-texture-file-size-project-reduce-loading-time-and-vram-requirement/#entry393250

Key Point:

If this project fails, the other option is to compress only low-detail normal maps with RxGB and encode high-detail normal maps as uncompressed DDS with mip-maps.
(0008275)
nbohr1more   
19.08.2016 23:35   
It seems that the swizzle is already disabled so RxGB cannot be used until that change is reverted.
(0008312)
nbohr1more   
08.09.2016 21:47   
(Last edited: 12.09.2016 15:43)
RGTC may need a specific shader implementation.

Perhaps use cgc to convert the GLSL implementation here:

https://github.com/eXistence/fhDOOM/commit/6de59bde47824f1e678a045d91ec660a4c66247d

cgc:

http://http.developer.nvidia.com/Cg/cgc.html

Will need to test because I am getting some (conflicting) reports that RGTC decodes in hardware to a standard RGBA image that the shader can read natively.

(0008313)
nbohr1more   
11.09.2016 13:32   
(Last edited: 12.09.2016 14:45)
For the contingency where RGTC does not render as RGBA to the ARB bind, the best option I can think of is to create a new SL_BUMPC map type and bumpcImage with associated GL texture client then selectively populate them depending on compression args, missing images, etc.

(0008315)
nbohr1more   
13.09.2016 18:56   
(Last edited: 13.09.2016 19:54)
Encoding details:

http://ptgmedia.pearsoncmg.com/images/9780321552624/downloads/0321552628_AppK.pdf

Another implementation:

https://github.com/ioquake/ioq3/blob/master/code/renderergl2/tr_image_dds.c

and another

http://trac.openscenegraph.org/projects/osg//changeset/11710/

(0008316)
nbohr1more   
13.09.2016 19:33   
(Last edited: 13.09.2016 20:35)
RGTC2 (unsigned) = BC5U

GL_COMPRESSED_RED_GREEN_RGTC2_EXT 0x8DBD

According to GPU whiz Aras P.

BC5 = ATI2N_XY

https://github.com/GPUOpen-Tools/Compressonator/commit/de71057d788683a2093fc85fd78c07111aac8825

Why is this so darned unclear that even AMD has to be corrected by application devs...

(0009341)
nbohr1more   
24.09.2017 14:56   
http://forums.thedarkmod.com/topic/19064-glsl-interaction-shader/page-4#entry411600
(0009342)
nbohr1more   
24.09.2017 14:57   
Some work done but it's not likely to be complete before 2.06 code freeze.
(0010511)
duzenko   
10.06.2018 11:01   
Svn rev 7444.
Compression to RGTC when loading uncompressed normal maps with image_useNormalCompression = 2.
I can't see significant memory usage improvements though.
TODO: allow loading pre-compressed normal maps.
For that I would need a test map with two bump materials: normal and precompressed for comparision.
(0010512)
duzenko   
10.06.2018 13:21   
Edited interaction shader to support this
(0012297)
duzenko   
22.03.2020 18:14   
Moving to 2.09 because the assets have not been converted yet
(0012771)
stgatilov   
31.08.2020 17:02   
I suggest moving it to 2.10.

In 2.09, all shaders are fixed to work with RGTC compression.
Also, it are turned on by default.
We can see how 2.09 beta goes with RGTC on, and if nobody complains about it, do assets conversion shortly after 2.09 is released.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5323 [The Dark Mod] Coding normal N/A 09.08.2020 02:01 31.08.2020 16:55
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Improve menu GUI and remove unexpected overrides of menu GUI files
Description: It seems that about 20 FMs override menu files which should not be overridden.
This often have bad effect of being unable to change or fix these files.

It would be good to add missing capabilities to core GUI, and remove overriding files from FMs.
Tags:
Steps To Reproduce:
Additional Information: Discussions:
  https://forums.thedarkmod.com/index.php?/topic/20515-repacking-fms-cinematics/
  https://forums.thedarkmod.com/index.php?/topic/20516-custom-gui-refactoring/
Attached Files:
Notes
(0012719)
stgatilov   
09.08.2020 03:25   
Here are some necessary customizations I've heard about:
* Skipping some screen(s) in briefing sequence: BRIEFING, success, diffuculty, objectives
* Changing background image: title, briefing (figures on title page should be removable)
* Changing music
* Changing "wait until ready screen" (already works well)
* "problem with the custom guis is how long and full of comments they are, making it difficult to find something specific."

A better thing would be refactor GUI code, so that every screen includes some customizable file.
I'm not sure I'll be able to do it...
(0012733)
stgatilov   
14.08.2020 05:46   
Huge effort spent on refactoring state skipping in GUI scripts.
Now MainMenuModeSelect simple calls same-named C++ cmd, instead of doing all the complicated logic by itself.

As the result, it allowed to properly implement disabling of the following FM-owned states:
  //#define ENABLE_MAINMENU_BRIEFING_VIDEO 0
  //#define ENABLE_MAINMENU_BRIEFING 0
  //#define ENABLE_MAINMENU_DIFF_SELECT 0
  //#define ENABLE_MAINMENU_SHOP 0
  //#define ENABLE_MAINMENU_SUCCESS 0
In order to achieve that, I introduced pseudostates MM_STATE_FORWARD and MM_STATE_BACKWARD, which don't define any GUI. Somewhat similar to MM_STATE_MAINMENU, it is detected by state switching code (which is now in C++) and redirected to proper target state.
(0012734)
stgatilov   
14.08.2020 05:56   
(Last edited: 31.08.2020 16:46)
Speaking of commits, the following preliminary ones add new features and don't change/break any behavior:
  r8923. Fixed GUI cmd concatenation bug. That was responsible for hazards like "initChoicelog", not the overflow.
  r8924+r8948. Set mapStartCmd GUI variable when "start new game" is clicked. Before that, it was set independently in shop and in objectives code.
  r8925. Added public method idUserInterface::ResetWindowTime.
  r8926. Added public method to idParser for getting defines. This is going to be used to access FM-customized GUI defines from C++ code.
  r8927. All defines in GUI scripts which are present at the end of parsing are saved now. They can be accessed with GetStateXXX methods, prepending '#' charactar to the name of define.
  r15993. Updating comments with information about new (FFmpeg-based) videos.
  r15995. Removed unused MainMenuWatchDog and commented Debug from GUI scripts.

This pair of commits refactors MainMenuModeSelect (moves to C++):
  r8928. Implemented GUI command mainmenumodeselect. It replaces the code from "MainMenuModeSelect::onTime 0" in GUI scripts.
  r15996. Big chunk of GUI code in "MainMenuModeSelect::onTime 0" replaced with call to "mainmenumodeselect" C++ command.
They can already break FMs which override GUI files which they should NOT override.

This pair adds FORWARD/BACKWARD system and supports states skipping:
  r8929. Added FORWARD/BACKWARD actions and implemented state skipping in "mainmenumodeselect" cmd.
  r15997. Added FORWARD/BACKWARD main menu pseudostate, use it where appropriate, supported state skipping.
(0012746)
stgatilov   
22.08.2020 06:21   
I have extracted the major changes into branch 8323_mainmenu and reverted them in trunk.

The following commits were moved:
  8928, 8929
  15996, 15997
(0012769)
stgatilov   
31.08.2020 16:53   
Here are some more changed which went into trunk.

This is generic change (not even for GUI) --- logfile improvement:
  r8954. When writing messages to logfile (DM_LOG), print relative path to source file instead of absolute.

Adding detailed logging for GUI scripts (enabled under LC_MAINMENU/LT_DEBUG settings in darkmod.ini):
  r8955. Save source location in every idGuiScript and print it when gui cmd is issued.
  r8956. Report all events happening to all windows to logfile, with a simple spam filter.
Without it I could hardly debug any of the stupid problems that I face all the time!

One "decapsulation" method:
  r8957. Added idSession::GetGui method, allowing to get active, mainmenu, etc. GUI at any moment.

And minor cleanup of GUI code:
  r16012. Main menu cleanup: notime 0 should be everywhere.
(0012770)
stgatilov   
31.08.2020 16:55   
And these changes went into branch.

Music is now tied to main state, no more separate state switcher.
  r8959. Music state is now tied to main state (aka "mode"). MainMenuMusicSelect GUI script should no longer be used.
  r16014. MainMenuMusicSelect is now empty: music is controlled by C++ code, tied to the main "mode" state.

Serious change of how initialization works (due to problems with menu after engine restart):
  r16015. Major changes in how MainMenuStartUp works.
  r8960. Drop main menu "mode" explicitly when starting game and when changing language.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5301 [The Dark Mod] GUI normal have not tried 17.07.2020 12:50 31.08.2020 04:13
Reporter: Dragofer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: AF Editor Useability
Description: This ticket is intended for collecting tickets associated with fixing or improving the AF Editor's useability.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5328 [The Dark Mod] Models normal N/A 16.08.2020 23:50 30.08.2020 14:33
Reporter: VanishedOne Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: TDM 2.08  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Sack has black regions
Description: The tdm_sack03 material - used by models/darkmod/containers/sack_closed.lwo and models/darkmod/containers/sack_pile01.lwo - uses the diffuse texture models/darkmod/props/textures/sack02_d. This has a black region where the alphatested holes used by the tdm_sack02 material go (the alpha channel for that seems additionally to be in the sack02_local normal map). Since sack03 isn't alphatested, the region just shows up as ugly black blodges (I thought it was a shadowing error at first).

Presumably there *should* be a sack03 diffusemap that looks like a higher-res version of the editor image, which doesn't have the blacked-out region.
Tags:
Steps To Reproduce:
Additional Information: I'm wondering whether this issue is new in 2.08, since I have a sack pile in a w.i.p. map and never noticed this problem under 2.07.

There's a sack2_local.tga that may be a clone of sack03_local.tga; I've no idea whether anything uses it. tdm_sack02 actually uses sack02_local.tga.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5307 [The Dark Mod] Graphics normal always 21.07.2020 15:41 30.08.2020 13:56
Reporter: cabalistic Platform:  
Assigned To: duzenko OS:  
Priority: normal OS Version:  
Status: assigned Product Version: TDM 2.09  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: TDM 2.09  
Summary: Accountant 1: machine arrows have black background
Description: Load mission "The Accountant 1" and go to the coordinates from the screenshot. The depicted machinery has some gauges with an arrow that with 2.09 renders with a black background. In 2.08 the background is transparent as it should be, *unless* you set "image_useNormalCompression 2", in which case the same error is visible.

It happens during interaction rendering for the ambient light in both the old and new backend. Given the reproducibility in 2.08, it likely has to do with the normal map compression changes?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: ac1_2020-07-21_12.41.06.jpg (598,502 bytes) 21.07.2020 15:41
https://bugs.thedarkmod.com/file_download.php?file_id=887&type=bug
Notes
(0012665)
duzenko   
21.07.2020 16:26   
Can we fix this on the map level?
tdm_epi_shader_electrical.mtr > transformer_needle_a

The bump stage (blend bumpmap) wants to alpha test which makes no sense

Same applies to transformer_needle_b
(0012666)
cabalistic   
21.07.2020 18:49   
I guess it depends how many materials are affected, and how complicated it would be to work around it in code.
(0012668)
nbohr1more   
22.07.2020 02:22   
I believe that original Doom 3 respects alpha on the bump stage. It can be used to fade away the bump pattern at the edge of a decal (etc).

The needle material doesn't really need it though.
(0012670)
duzenko   
22.07.2020 07:09   
@nbohr1more

You're confusing alpha and alphaTest here, no?
(0012671)
nbohr1more   
22.07.2020 18:29   
Hmm, I suspect that this is another variant of "DDS does not work with Image Program functions" since we
always revert whenever someone accidentally converts a glass normalmap to DDS.

Does RGTC mode still respect:

forceHighQuality
highquality
uncompressed

keywords that prevent the on-the-fly conversion or fallback DDS loading?
(0012672)
duzenko   
22.07.2020 19:06   
Gee, @nbohr1more, your hard line breaks keep freaking me out :>

> Hmm, I suspect that this is another variant of "DDS does not work with Image Program functions" since we
> always revert whenever someone accidentally converts a glass normalmap to DDS.

I disagree. The image file in question is a .tga. It has been reported that image-normal-compression somehow affects this bug but I don't feel like bothering with that since I have already found what's causing it and suggested a fix not related to RGTC.
I could speculate that maybe it has something to do with the default alpha the GL spec requires RG format implicitly to generate which is different to what D3 filled in on 24-bit .tga files. But generally I don't care.

To be completely honest it's possible to fix this also on the renderer level, but it will have a side effect potentially causing other glitches somewhere else.

> Does RGTC mode still respect:

>forceHighQuality
>highquality
>uncompressed

> keywords that prevent the on-the-fly conversion or fallback DDS loading?

We don't really have DDS's for normal maps, do we? I can't remember which keyword controls dds/jpg/tga loading and which controls on-the-fly compression. But again I don't care because I assume the render quality difference to be negligible for bumpmaps, especially compared with stock TDM diffuse maps. It's more of a VRAM conservation/load speed choice than anything else.
(0012766)
VanishedOne   
30.08.2020 13:56   
Re. alpha in normal maps, I just noticed this in the renderbump docs at https://www.iddevnet.com/doom3/bumpmaps.html

'The alpha channel of the normal map will contain a mask if there were areas in the map that did not directly map to geometry. This can be copied to a diffuse map to use with the alpha test option for per-pixel opacity. Note that if you use the normal map as a template for the specular map, you should explicitly clear or remove the alpha channel, because it will prevent more efficient compression forms from being used.'

So it seems normal (no pun intended) for the internal renderbump tool to produce a normal map with an alpha channel, but as per id's docs you're expected to copy it to diffuse if you want it for alphaTest. It's quite likely not everyone who's used renderbump has actually seen that passage, though.

(The fish I ported from Arx:EoS has an unused normal map that's fully alpha transparent everywhere but the fish's eye; I experimented with it a bit, but I think in the end I packaged it without enabling it in the material decl.)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5141 [The Dark Mod] Coding minor always 03.02.2020 17:16 27.08.2020 13:36
Reporter: stgatilov Platform:  
Assigned To: stgatilov OS:  
Priority: normal OS Version:  
Status: resolved Product Version: TDM 2.07  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: TDM 2.09  
    Target Version: TDM 2.09  
Summary: idImage::ActuallyLoadImage should always load CPU-side data
Description: Right now if someone attemps to load an image from frontend, the request is simply ignored.
It is expected that when someone would need the texture for drawing, it will get requested again from backend.

However, particle collision feature uses CPU-resident textures to cut off particles.
Such textures are ALWAYS loaded from frontend, never from backend.
Hence, if you don't load such texture during level load, then it will never get loaded no matter how hard you ask for it.

This should be fixed.
The data gets loaded from file immediately, regardless of frontend/backend.
The uploading to GPU should only happen from backend when requested.
Tags: particle
Steps To Reproduce: 0) In idRenderWorldLocal::ParseModel, temporarily comment out preload code.
1) Install test_raincollision FM.
2) Set "com_smp 1".
3) Start new game or execute "map rain".
4) Check that rain stops on obstacles (at least on roof). "Use r_showTris 1" to make it easier.
Additional Information:
Attached Files:
Notes
(0012762)
stgatilov   
27.08.2020 13:33   
I made a partial fix in svn rev 8950.
I simply masked the load disabling for CPU-resident images:
    void idImage::ActuallyLoadImage( bool allowBackground ) {
        ...
        if ( session->IsFrontend() && !(residency & IR_CPU) ) {
            common->Printf( "Trying to load image %s from frontend, deferring...\n", imgName.c_str() );
Unfortunately, it is logically wrong for IR_BOTH images, since they can now get loaded to GL from frontend thread.
But I'm not sure we have any such images.
Default image is the only IR_BOTH, and it gets loaded from backend.

To be honest, I did not remember ever seeing this message in game console.
(0012763)
stgatilov   
27.08.2020 13:34   
Also committed a bit of refactoring in svn rev 8949.

Before that cubemaps were loaded straight in idImage::ActuallyLoadImage.
Now they are loaded in two steps just like ordinary textures:
  R_LoadImageData: loads from file on disk to cpuData
  R_UploadImageData: loads from cpuData to GL and purges cpuData (customizable via residency flag)
(0012764)
stgatilov   
27.08.2020 13:36   
While I did not do what the title of the issue says, by original problem with cutoffTimeMap and collisionStatic maps is fully fixed.
So I'll mark this issue as resolved.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5320 [The Dark Mod] Design/Coding feature always 03.08.2020 17:36 25.08.2020 15:23
Reporter: AluminumHaste Platform:  
Assigned To: AluminumHaste OS:  
Priority: low OS Version:  
Status: assigned Product Version: TDM 2.08  
Product Build: Resolution: open  
Proje