Newbie DarkRadiant Questions

[joebarnin]

36 minutes ago, JackFarmer said:

At this point, I think we all just have to say once again that I am brilliant. Man, I almost fear my superbrain to explode!

 

 

[Geep]

On 10/5/2024 at 6:37 PM, boissiere said:

You might consider setting the 3 following CVars.

tdm_ai_debug_blocked
tdm_ai_showdest
tdm_ai_showtasks

Added to https://wiki.thedarkmod.com/index.php?title=Pathfinding
as new section "Viewing AI Current Path Goals and Obstacles"

[thebigh]

LOL, you could have a guard "patrol" by having him chase a single path_corner around and continually teleport it out of his reach.

Actually, now that I mention it, this might be a way to get an AI to follow a curved path.

[Geep]

To https://wiki.thedarkmod.com/index.php?title=Teleporting_entities , under the topic "Making an AI Start a Path after Teleporting", at the end I've added a description of this new method, as:

  Technique 3: "Kicking a Single Path Target Down the Road"

Plus a link to the wizard discussion above about

  Visual and Sound Effects During Teleport

[datiswous]

On 10/9/2024 at 4:42 PM, grodenglaive said:

You just need to have the AI hit a trigger brush that triggers the teleport before they can reach the path corner.

Instead of a triggerbrush, maybe it's possable to specify the distance as a condition for teleporting. So if the distance is the same or smaller than a certain amount a teleport happens.

And / Or you could specify they have to be in the same info_location, or visleaf for example.

Edited October 11 by datiswous

[grodenglaive]

That might work. Could be convenient if you needed to move the path target a lot.

[DeTeEff]

I'm having problems with keys in my mission. I've made them stackable and droppable and when you stack some and drop and pick up, they seem to loose their name in the stack so they don't work on the door anymore. Locked doors use the keys entity name to open with the 'used_by' spawnarg but I wonder if there is a way to use the inv_name in some way... 

[JackFarmer]

2 hours ago, DeTeEff said:

I'm having problems with keys in my mission. I've made them stackable and droppable and when you stack some and drop and pick up, they seem to loose their name in the stack so they don't work on the door anymore. Locked doors use the keys entity name to open with the 'used_by' spawnarg but I wonder if there is a way to use the inv_name in some way... 

try
'used_by_inv_name'

[DeTeEff]

5 hours ago, JackFarmer said:

try
'used_by_inv_name'

I tried to put

used_by_inv_name Door 4 key

but it doesn't work

[JackFarmer]

24 minutes ago, DeTeEff said:

I tried to put

used_by_inv_name Door 4 key

but it doesn't work

Could by_classname or category also be an option?

 

[DeTeEff]

Still a no...

[thebigh]

Might have to use scripting then.

 

[JackFarmer]

9 hours ago, DeTeEff said:

Still a no...

Are the keys in question def-attached to AI entities?

Why do you need the keys to be stackable? Are these stackable keys meant to open only one specific (or several) door(s)? Or do you just want to avoid inventory cluttering?

Edited October 12 by JackFarmer

[DeTeEff]

3 hours ago, JackFarmer said:

Are the keys in question def-attached to AI entities?

Why do you need the keys to be stackable? Are these stackable keys meant to open only one specific (or several) door(s)? Or do you just want to avoid inventory cluttering?

There are both entity attached keys AND laying keys in the mission. There are several instances with the same keys so they need to be stackable, and to avoid cluttering in the inv I want them droppable. It's not game breaking but I want to fix this bug...

[JackFarmer]

1 minute ago, DeTeEff said:

There are both entity attached keys AND laying keys in the mission. There are several instances with the same keys so they need to be stackable, and to avoid cluttering in the inv I want them droppable. It's not game breaking but I want to fix this bug...

Hm, I am afraid, in this case, we will need not a fake, but a real superbrain to look into the problem.

@joebarnin: Jeff, do you think you have time to assist our friend here?

[joebarnin]

2 hours ago, JackFarmer said:

Hm, I am afraid, in this case, we will need not a fake, but a real superbrain to look into the problem.

@joebarnin: Jeff, do you think you have time to assist our friend here?

I’ll take a look

[Geep]

I wonder if renaming the inventory name so it contains no space would make a difference.

[joebarnin]

Okay, I think I see the problem.

I have two keys, same inv_name. They both stack and can be dropped:

 

And a door:

Each key opens the door fine. If I pick up both keys, the "stack" still opens the door.

The problem occurs when I have a stack of keys (in this case, two), and I drop one of them. When the stack size is >= 2, the dropped key is created based on the classname of the item (which in this case is atm:key_mysterious). The unique spawnargs of the original key are ignored, so the inv_droppable, inv_stackable, and inv_name spawnargs are not used. In this case, the dropped key is named "Mysterious Key" (the default inv_name for that classname), it is not droppable or stackable, and is "name" is generated on the fly (in this case "idMoveable_atdm:key_mysterious_7").

This behavior is confirmed in a code comment:

// Stackable items only have one "real" entity for the whole item stack.
// When the stack size == 1, this entity can be dropped as it is,
// otherwise we need to spawn a new entity.

The upshot is that the dropped key behaves incorrectly: it has the wrong name, so it won't open the door. It isn't stackable or droppable anymore either. If I drop the "second" key (the last one in the inventory stack), it'll have the correct name and spawn args, so it will work to open the door. 

Now, solutions. It would be nice to use used_by_inv_name, used_by_category, or used_by_classname. But this wiki entry says right at the top "DOES NOT WORK FOR DOORS - use the normal key method". So those spawnargs don't work for doors.

One possibility is to avoid key stacking in the first place. As soon as the player grabs a key, delete all of the other keys that can open that same door (I think @JackFarmer did this his most recent mission?). So for example, keys A B and C all open a door. If the player picks up A, delete B and C. If they pick up B, delete A and C. And so on. That way the keys will never stack, and you avoid the whole problem. It kind of avoids the key accumulation problem too.

@DeTeEff Will that work for you?

[Uncertain Title]

Have a friend who is interested in Dark Radiant and wanted to look at my map. When they load it, all models that I've made appear as grey boxes.

If they try to create a model, my models don't appear. I did include my models inside the fm, so I'm not sure how to get it to recognize it as a valid directory.

Not even selecting 'Reload Models' gets it to recognize it.

Anyone have any ideas of how to fix this?

[DeTeEff]

If you add the standard keys, the one's designed as the dev team "intended" they are stackable, but never dropable. I made custom keys to allow dropping just because some people like that (ghosters for example). I love that you took time to look into this and your findings confirm my thoughts on the problem.

I just have to revert to use non dropable keys, and the problem will go away.

[DeTeEff]

1 minute ago, Uncertain Title said:

Have a friend who is interested in Dark Radiant and wanted to look at my map. When they load it, all models that I've made appear as grey boxes.

If they try to create a model, my models don't appear. I did include my models inside the fm, so I'm not sure how to get it to recognize it as a valid directory.

Not even selecting 'Reload Models' gets it to recognize it.

Anyone have any ideas of how to fix this?

I believe that has to do with folder structure and paths. When you built the mission, you probably used an isolated project approach and that means DarkRadiant goes into your fms folder to look for your stuff, not "out in the wild" ie the "root" TDM folder...

Some more skilled person should probably confirm my tips before you start rummaging around with the files though

[Uncertain Title]

3 minutes ago, DeTeEff said:

I believe that has to do with folder structure and paths. When you built the mission, you probably used an isolated project approach and that means DarkRadiant goes into your fms folder to look for your stuff, not "out in the wild" ie the "root" TDM folder...

Man, I sure hope not; I had to restart my project once already because of that exact issue.

 

OH I should have included that playing the mission works perfectly fine. There's no issues with the models at all!

[DeTeEff]

4 minutes ago, Uncertain Title said:

Man, I sure hope not; I had to restart my project once already because of that exact issue.

 

OH I should have included that playing the mission works perfectly fine. There's no issues with the models at all!

Where in the folder structure do the models live?

I guess they're stashed away in the fms folder? Then,when you open DR without specifying which mission you're working on, the paths are wrong because DR looks for them in the root folder.

[DeTeEff]

@Uncertain Title I have the same issue with my "module building map" because I put all my custombuilt stuff in a folder so I get notified when something in a mission is missing. Nowadays I always use an isolated approach when building because it's nerve wracking to have to search through all custom assets to add to the mission so nothing gets left behind. Because when you play test your mission by yourself, the game doesn't distinguish between local assets and assets that is needed in the mission you're playing. So when your players play the mission, they will be missing files. It's like camping in the living room and always go to the bathroom to piss and the kitchen to drink and then believe you got the camping mojo down. Then when you're out in the wild you realise that water is scarce and there's no toilet to be found! Sorry for long post and strange allegorical sidetracks.

[Uncertain Title]

13 minutes ago, DeTeEff said:

Where in the folder structure do the models live?

This is what the directory path looks like:

4 minutes ago, DeTeEff said:

Because when you play test your mission by yourself, the game doesn't distinguish between local assets and assets that is needed in the mission you're playing. So when your players play the mission, they will be missing files.

That does make sense, and that's what caused me to restart the project before.

My friend is able to play the map on their own computer with no issues, however. In-game the map looks exactly the same as mine. It's just this...annoying issue with the models not appearing in Dark Radiant specifically

9 minutes ago, DeTeEff said:

 Sorry for long post and strange allegorical sidetracks.

Don't worry about it! I appreciate any help I can get.