Newbie DarkRadiant Questions

[Geep]

I see @nbohr1more just helpfully added the g_timeModifier to the "Console Useful Commands" list. The bug report discussion mentions that a "too high" value will break physics, but hopefully the "g_timeModifier 2" example in Console Useful Commands doesn't count as too high.

[OGDA]

What exactly is
Patch > Matrix > Redisperse > Rows/Columns
for?

My guess was that it should distribute vertices evenly if you add additional rows in the patch, but I made several patches, moved vertices, added rows and columns in between/at the end but the Redisperse never seems to change anything on the patch/vertices.

----

Edit:
Ok, now I found that it somehow seems to remove the additional bezier curves, if some vertices are on different Z-levels, so the patch goes from round edges to hard edges.

Edited April 30, 2021 by OGDA

[Frost_Salamander]

I'd like to use the containers/openable/MerryChest1.pfb prefab in TDM prefabs.  However, for some reason the lid doesn't open.  I've tried various things to try and fix it, but I can't figure out what's wrong with it. I even tried re-creating the lid (revert to worldspawn, then convert  back to a mover_door and re-adding the properties), but same issue.

Has anyone else tried using it?  I realize the other 'footlocker' prefabs work fine, but I like the look of this one as it looks a bit more like a travel trunk, which is what it's supposed to be in the map.

Edited May 12, 2021 by Frost_Salamander

[Geep]

@Frost_Salamander, no direct experience, but I see that William Steele 4 - The Warrens has an entity called "MerryChest1Lock", so maybe that's something to look at. Perhaps some problem with frob_master / frob_peer / froblock?

[Geep]

On a different topic, I need a clue for this problem.

I have the player following an pathed AI at a distance. Ordinarily the AI holds up at a waitfortrigger path node, then the player passes through a triggeronce that targets the AI, causing it to continue on the path to the next node (which is also a waitfortrigger, that is triggered elsewhere). Imagine the path is linear and this is the physical layout:

player>>>               [triggeronce]                      ai>>>  [corner][waitfortrigger]                [corner][waitfortrigger]

Ordinarily this work fine. The problem comes if the player arrives too fast, and the player fires the trigger once before the AI is at the waitfortrigger. Then the trigger signal is lost and the AI stalls at the first waitfortrigger.

Moving the [triggeronce] closer to the [corner][waitfortrigger] is not desirable for story reasons.

Adding a second "backup" [triggeronce] on the path between the existing [triggeronce] and the first [corner][waitfortrigger] would be problematic as well: if the ai had already reached the second [corner][waitfortrigger], the backup trigger would incorrectly release it from its wait.

How to make this reliable?

[JackFarmer]

9 hours ago, Geep said:

On a different topic, I need a clue for this problem.

I have the player following an pathed AI at a distance. Ordinarily the AI holds up at a waitfortrigger path node, then the player passes through a triggeronce that targets the AI, causing it to continue on the path to the next node (which is also a waitfortrigger, that is triggered elsewhere). Imagine the path is linear and this is the physical layout:

player>>>               [triggeronce]                      ai>>>  [corner][waitfortrigger]                [corner][waitfortrigger]

Ordinarily this work fine. The problem comes if the player arrives too fast, and the player fires the trigger once before the AI is at the waitfortrigger. Then the trigger signal is lost and the AI stalls at the first waitfortrigger.

Moving the [triggeronce] closer to the [corner][waitfortrigger] is not desirable for story reasons.

Adding a second "backup" [triggeronce] on the path between the existing [triggeronce] and the first [corner][waitfortrigger] would be problematic as well: if the ai had already reached the second [corner][waitfortrigger], the backup trigger would incorrectly release it from its wait.

How to make this reliable?

I am not sure if I understand completely, but I could imagine, that the following should work:

Possibility #1:

1. Place the ai waitfortrigger above, where the ai stands once it arrives at the relevant corner. Make sure that the ai cannot touch the waitfortrigger now

2. Create an invislbe translate door mover (without sound, noclipmodel and not froabable)  at the same height as the waitfortrigger entity. Give it a translate value so that it touches the below standing ai  when it is triggered. Bind these two entities together

3. Let the player's tirggeronce entity target the invisible translate door mover

 

Possibility #2:

The "objective" is completed, as soon as two conditions occur:

a. Player has triggered something

b. AI hast triggered something

 

Conclusion: you could control it via a trigger count:

 

 

 

Edited May 13, 2021 by JackFarmer

[Frost_Salamander]

10 hours ago, Geep said:

@Frost_Salamander, no direct experience, but I see that William Steele 4 - The Warrens has an entity called "MerryChest1Lock", so maybe that's something to look at. Perhaps some problem with frob_master / frob_peer / froblock?

that's what I thought as well, but it all seems to be set up correctly according to this, and also comparing it to one of the footlockers that works.  

I'll play around with it some more, but either way it seems to be a bug in the assets.  I tried to use the same prefab for Hare in the Snare part 1 but gave up on it then.

[Destined]

9 hours ago, Geep said:

On a different topic, I need a clue for this problem.

I have the player following an pathed AI at a distance. Ordinarily the AI holds up at a waitfortrigger path node, then the player passes through a triggeronce that targets the AI, causing it to continue on the path to the next node (which is also a waitfortrigger, that is triggered elsewhere). Imagine the path is linear and this is the physical layout:

player>>>               [triggeronce]                      ai>>>  [corner][waitfortrigger]                [corner][waitfortrigger]

Ordinarily this work fine. The problem comes if the player arrives too fast, and the player fires the trigger once before the AI is at the waitfortrigger. Then the trigger signal is lost and the AI stalls at the first waitfortrigger.

Moving the [triggeronce] closer to the [corner][waitfortrigger] is not desirable for story reasons.

Adding a second "backup" [triggeronce] on the path between the existing [triggeronce] and the first [corner][waitfortrigger] would be problematic as well: if the ai had already reached the second [corner][waitfortrigger], the backup trigger would incorrectly release it from its wait.

How to make this reliable?

My idea would be to create a backup regular path_corner: When the player activates the trigger the target on the path_corner before the path_waitfortrigger (let's call it path_conrer_1) gets changed from the path_waitfortrigger to the backup path_corner.

That way you have two cases: player is slower -> The AI reaches path_corner_1, continues to path_waitfortrigger, waits, player activates trigger, AI continues, the target on the path_corner_1 gets changed, but has no effect, as the AI is already past it.

player is faster -> target on path_corner_1 is changed from path_waitfortrigger to backup path_corner, AI reaches path_corner_1, now targets backup path_corner, walks on without requiring a trigger.

The only problem I would see is, if the player activates the trigger between the AI reaching path_corner_1 and the path_waitfortrigger, but if you place path_corner_1 right before the path_waitfortrigger (or even at the same place), this should reduce the time window so much, that it should not be nearly impossible to happen.

[Geep]

@JackFarmer, @Destined, some great ideas. The translating door sounds a bit finicky in placement, but either the objective method (with a hidden objective doing the counting) or the bypass-waitfortrigger method seem straightforward. I'll probably try the latter first. It may be that no waitfortrigger node is needed at all... just a path corner with no target as a place to wait, and the alternative path corner with a target continuing  the path. And the player triggers a change-path between these for the AI. (Using a triggerOnceEntity specific to the player, of course. And I've got some triggered SFX that are involved too, so reality will be a bit more complicated than the problem description.)

[Geep]

Got it to work, adhering more closely to @Destined plan. Except changeTarget is not effective if the AI is already on the way to the affected node. So I put in an extra interim node immediately preceding it. Seems to work now.

[datiswous]

On 5/12/2021 at 10:47 PM, Frost_Salamander said:

I'd like to use the containers/openable/MerryChest1.pfb prefab in TDM prefabs.  However, for some reason the lid doesn't open.  I've tried various things to try and fix it, but I can't figure out what's wrong with it. I even tried re-creating the lid (revert to worldspawn, then convert  back to a mover_door and re-adding the properties), but same issue.

Has anyone else tried using it?  I realize the other 'footlocker' prefabs work fine, but I like the look of this one as it looks a bit more like a travel trunk, which is what it's supposed to be in the map.

Don't know if you managed to find it by now, but what you have to do:

1. Select the chest and click on: Edit -> Ungroup Selection
2. Select only the lid and go to the Entity details
3. Check what name is given. Then only select the body and change the frob_peer and target to the name of the lid.

MerryChest2 has the same issue. Also, the naming of MerryChestBody and MerryChestLid etc. is not consistent with the naming of the MerryChest prefabs.

Edited May 15, 2021 by datiswous

[datiswous]

In missions I often get a short scary moment because I hear a door opening, when I actually open a chest. I guess these chest prefabs are based on door-behavior, because the sounds are still the same.

[Frost_Salamander]

On 5/15/2021 at 2:36 AM, datiswous said:

Don't know if you managed to find it by now, but what you have to do:

1. Select the chest and click on: Edit -> Ungroup Selection
2. Select only the lid and go to the Entity details
3. Check what name is given. Then only select the body and change the frob_peer and target to the name of the lid.

MerryChest2 has the same issue. Also, the naming of MerryChestBody and MerryChestLid etc. is not consistent with the naming of the MerryChest prefabs.

Hi @datiswousthanks for this.  I did end up sorting it out, but by redoing the lid.  I missed the underlying cause so thanks for pointing that out. Is this is sort of thing that should go in the bug tracker?  Happy to add it if so...

[Dragofer]

11 hours ago, Frost_Salamander said:

Hi @datiswousthanks for this.  I did end up sorting it out, but by redoing the lid.  I missed the underlying cause so thanks for pointing that out. Is this is sort of thing that should go in the bug tracker?  Happy to add it if so...

If a core prefab doesn't work out of the box that should definitely go on the bug tracker. Thanks for doing so.

[Frost_Salamander]

11 hours ago, Dragofer said:

If a core prefab doesn't work out of the box that should definitely go on the bug tracker. Thanks for doing so.

That has now been raised: https://bugs.thedarkmod.com/view.php?id=5616

[datiswous]

8 hours ago, Frost_Salamander said:

That has now been raised: https://bugs.thedarkmod.com/view.php?id=5616

Sorry, I tested again and could not reproduce the problem . What did happen yesterday though is that I was browsing through the prefabs and found that there were a lot of them double in the prefab selection interface. One of them (that was not double) gave DR a freeze (program does not respond anymore). Then I remembered that I installed @Springheel's prefabs which can be downloaded from here:

https://www.youtube.com/watch?v=sz5u398AgP4 (see link in the details)

So I removed the extra prefabs which are now probably all in core anyway and the downloads are probably outdated. And indeed I just tested and concluded that the old MerryChest prefabs have bugs while the current core prefabs don't.

So the bug report can be closed I think, if indeed this was also the cause of the problem which @Frost_Salamander had. @Springheel should remove the link to the prefab downloads in that youtube video every new mapper views, I think.

 

[Acolytesix]

To think I was here back in 2011 and never finished that ambitious Bamburger Castle (UK) FM. But now, I,m gonna give it another try with a smaller mansion (out of the Hudson Valley in New York) instead  

Just gotta finish The Painter's Wife 1st. That FM is huge!!   

[A_2]

I have three questions regarding texture alignment across vertex-manipulated brushes. 

1. I am making a cavern in DarkRadiant. I am doing this by using the "clip" tool to cut brushes into wedges and then moving their vertices around. It is my understanding that making irregular/'terrain'-type geometry out of brushes will result in some degree of performance improvement versus making it out of either patches or imported models. Is this correct?

2. While I have had no difficulty getting these brushes' vertices to align, I cannot say the same about their textures, which seem to require a great deal of fine-tuning, not only through panning, but also stretching and rotation, to align adequately. None of the "surface inspector" tools seem to help. I recall that Source's "Hammer" editor had an "align textures to camera" function[1] which could be used to avert this kind of thing. Is there anything like that in DarkRadiant?

3. In an earlier thread[2], someone recommended creating caulk brushes, putting flat patches over them, and texturing the patches. Are there drawbacks to this approach?

Thank you for your time. This image should illustrate what my problem is.

Edited May 18, 2021 by A_2

[OrbWeaver]

42 minutes ago, A_2 said:

1. I am making a cavern in DarkRadiant. I am doing this by using the "clip" tool to cut brushes into wedges and then moving their vertices around. It is my understanding that making irregular/'terrain'-type geometry out of brushes will result in some degree of performance improvement versus making it out of either patches or imported models. Is this correct?

No.

There is zero performance benefit in doing this, and creating complex shapes with brushes is more likely to result in map leaks or bad geometry generated (e.g. missing triangles). The result will also look bad because the level of detail you can create with large flat surfaces is low, and there is no smoothing applied, so the results will look more like Thief 2 than a modern game.

Quote

2. While I have had no difficulty getting these brushes' vertices to align, I cannot say the same about their textures, which seem to require a great deal of fine-tuning, not only through panning, but also stretching and rotation, to align adequately. None of the "surface inspector" tools seem to help. I recall that Source's "Hammer" editor had an "align textures to camera" function[1] which could be used to avert this kind of thing. Is there anything like that in DarkRadiant?

Not as far as I know. You can copy textures from different surfaces using various combinations of mouse button and modifier key, which might help in some situations, but I've never seen any way to project textures based on the camera position.

Quote

3. In an earlier thread[2], someone recommended creating caulk brushes, putting flat patches over them, and texturing the patches. Are there drawbacks to this approach?

I suppose this would be useful if you wanted to create a flat but non-rectangular shape (like a trapezoid door) and you wanted the texture to align to the edges of the patch. If the flat patches are rectangular I don't see how this would be any better than just putting the texture on the brush itself.

Of course for non-flat surfaces, patches (with caulk brushes behind if needed) are definitely the way to go if you can't or don't want to use a 3D modelling tool.

[STRUNK]

Darkradiant doesn't work anymore : O

Anyone know how to fix this?
Here is the log file:

darkradiant.log

Never mind, it works again, Somehow installing powershell 7 on my machine f*cked things up.
I uninstalled it and now it's fine again : )
 

Edited May 18, 2021 by STRUNK

[JackFarmer]

@STRUNK

I am not sure, but isn't that the problem that shows up if something went wrong with the Roaming folder?

@A_2

I made no good experiences with sloped brushes for cave floors; the player could not move properly on them.  I am with Orbweaver on this; use patches for ceiling, floors and walls. Place Monsterclip below the floor patches for AI pathfinding.

Edited May 18, 2021 by JackFarmer

[A_2]

2 hours ago, OrbWeaver said:

No.

There is zero performance benefit in doing this, and creating complex shapes with brushes is more likely to result in map leaks or bad geometry generated (e.g. missing triangles). The result will also look bad because the level of detail you can create with large flat surfaces is low, and there is no smoothing applied, so the results will look more like Thief 2 than a modern game.

Not as far as I know. You can copy textures from different surfaces using various combinations of mouse button and modifier key, which might help in some situations, but I've never seen any way to project textures based on the camera position.

I suppose this would be useful if you wanted to create a flat but non-rectangular shape (like a trapezoid door) and you wanted the texture to align to the edges of the patch. If the flat patches are rectangular I don't see how this would be any better than just putting the texture on the brush itself.

Of course for non-flat surfaces, patches (with caulk brushes behind if needed) are definitely the way to go if you can't or don't want to use a 3D modelling tool.

Thank you. Are there any limits on the quantity and/or complexity of patches you can have in a map?

[Springheel]

3 hours ago, A_2 said:

I have three questions regarding texture alignment across vertex-manipulated brushes. 

1. I am making a cavern in DarkRadiant. I am doing this by using the "clip" tool to cut brushes into wedges and then moving their vertices around. It is my understanding that making irregular/'terrain'-type geometry out of brushes will result in some degree of performance improvement versus making it out of either patches or imported models. Is this correct?

2. While I have had no difficulty getting these brushes' vertices to align, I cannot say the same about their textures, which seem to require a great deal of fine-tuning, not only through panning, but also stretching and rotation, to align adequately. None of the "surface inspector" tools seem to help. I recall that Source's "Hammer" editor had an "align textures to camera" function[1] which could be used to avert this kind of thing. Is there anything like that in DarkRadiant?

 

 

 

You can use quite complex patches if you want, although multiple, small patches are better than one giant one.  Performance hits come more from lighting and shadowcasting than number of polys.

 

This might be helpful: 

 

[datiswous]

I have a problem with resizing lights. When I'm resizing (by dragging with left mouse button outside the light box), the light also moves with my mouse movement. Could this be a bug, or is this some kind of setting, or I'm missing something?

See what happens:

It does not happen when resizing a brush.

Edited May 28, 2021 by datiswous

[Dragofer]

9 hours ago, datiswous said:

I have a problem with resizing lights. When I'm resizing (by dragging with left mouse button outside the light box), the light also moves with my mouse movement. Could this be a bug, or is this some kind of setting, or I'm missing something?

See what happens:

It does not happen when resizing a brush.

That very much looks like a bug. Maybe it's caused by one of your settings or a combination of them, i.e. using the entity origin as the centre for transformations.

Would be interesting if this happens on an older version of DR too.

In any case  @greebo