Newbie DarkRadiant Questions

[cvlw]

1 minute ago, Obsttorte said:

@cvlwAre you sure it is the ai that you are colliding with? They have lots of stuff attached to them (armor, weapons et al.) and I am not sure whether the content flags get transfered to attached entities upon change.

I am not sure if it is the ai or the ai parts colliding.  Right now, I don't know how to address the ai parts in script code.  I just address the ai by name arg.   I can't tell what is being collided by the other ai kicking the body.

This is an AI that is knocked out (or dead) laying on the ground, and other ai are running into it and kicking it around as they flail about searching for the culprit.  So you can hear the kicking as they hit the body, often repeatedly.  The player can move on/over/through the body without any collision.

This is just an odd scenario I am dealing with trying to get my ideas into a mission.  The direct solution is to make the body non-solid.  I will try other things or even just let it go.

Thanks again.

Clint

 

 

[Obsttorte]

Well, if the player can walk through it but not the ai then it is probably hard-coded behaviour transferable to ai. The question is whether this makes sense, as the ai may rely on bumping into the body to detect it when in darkness.

The entities bound to the ai are def_attached, so you could look up script functions related to that. If it is for a specific ai, you could either check the entity definition or create a modified version where the attachments are non-solid to begin with if you don't need them to be.

[Dragofer]

An alternative option to make attachments non-solid is to set spawnargs in the format "set x on y" "z". In this case it would be something like "set solid on armor" "0".

y is the name_attach (not the $name). You can see what the attachment name is by checking the AI's spawnarg list for "name_attach" spawnargs, matching the "def_attach" spawnargs.

For example, "def_attach2" "atdm:breastplate01", "name_attach2" "armor" -> y is "armor".

[Obsttorte]

The script function getNextKey allows you to go through all spawnargs with a specific prefix (like def_attach for attached entities).

[Dragofer]

1 hour ago, Obsttorte said:

The script function getNextKey allows you to go through all spawnargs with a specific prefix (like def_attach for attached entities).

Problem in this case is that def_attach only returns the classname (entity type) of the attached entity, while name_attach is not the actual name of the attached entity, but an internal name to allow other spawnargs to modify this attachment.

[Obsttorte]

Yeah. It would probably be the best approach if this is a special scenario for only one ai to create a custom one for that purpose. Allthough it would be easier to give useful tips if it would be clear what @cvlwis aiming for.

[cvlw]

Thanks all for the thoughts on this.  I am not quite ready to make a single-purpose ai entity for this as it is just a quirk resulting from natural game mechanics.

My intent is/was for the player to ko or kill a "boss" ai and then drop the body out a window into a crowd of lackeys on the same team (to send a dramatic message).  Think of other maps where you drop a body someplace as an objective.

As it is, the body gets surrounded and the other ai who repeatedly run into it. All you hear is a lot of flopping/kicking sounds as they do it and the body bopping around on the ground.

I think I will do this:  create a ragdoll entity with the same appearance, shouldered name, and dead name as the boss ai and override the SND_BOUNCE* inherited spawnargs with NOSOUND.  Then teleport the ragdoll in when the boss is tossed out the window.  This won't stop the kicking of the body, but the incessant sounds will stop!  So, half a win, I think.

 

[Frost_Salamander]

I have some AI in my FM that are sleeping.  Some in a chair, some on a bed.  Sometimes they die if you blackjack them.  There are logs in the console saying they are taking 'landing damage'.  In one case it was 252 damage at once.  Other times it was several small amounts like 5, 7, etc.

Does anyone known what causes this and how best to avoid it?  I've heard things like use moveable chairs and making sure the AI isn't touching them, but I don't want the AI to be sitting on air if you move the chair, or see them floating above the chair/bed just to avoid this.

[geegee]

Does anyone know what this console error warning is about?

WARNING:Source with 2 surfaces. snapshot func_static, scaling: no, needFinish: no       

Does this indicate a degenerate solid (made into func_static)?  Is there any way to trace the culprit?

That's my more important question.

_____________

WARNING:Couldn't load image: dds/textures/particles/arcturus_fire              
  [map entity: atdm_campfire_typical_1]                                        
  [decl: light_fireflames_typical in def/tdm_lights.def]                       
  [model: typical_campfire01.prt]                                              
  [decl: typical_campfire01 in particles/tdm_fire.prt]                         
  [decl: arcturus_fire in materials/tdm_particles.mtr]                         
  [image: dds/textures/particles/arcturus_fire]

I checked, the dds image is there.  Perhaps the wrong format?

That error attaches to atdm:campfire_typical
It doesn't attach to atdm:campfire_small

which to my eyes appears identical to atdm:campfire_typical

So I suppose atdm:campfire_typical should be the same, but with an enhanced fire that doesn't render because not found.

Anyway I use the error-free atdm:campfire_small to get rid of the warning.

_____________

eta:  found the source of the 2 surfaces error.  I have a SEED targeting a simple 3x3 patch func_static.  In the attached map the patch is textured with a 2-sided tdm "ivy" vegetation decal.

No error from the func_static alone, the error happens when I use SEED to generate a field of them.

I figure it's harmless.

ivy.map

Edited July 31, 2022 by geegee

[Dragofer]

On 7/27/2022 at 11:26 PM, Frost_Salamander said:

I have some AI in my FM that are sleeping.  Some in a chair, some on a bed.  Sometimes they die if you blackjack them.  There are logs in the console saying they are taking 'landing damage'.  In one case it was 252 damage at once.  Other times it was several small amounts like 5, 7, etc.

Does anyone known what causes this and how best to avoid it?  I've heard things like use moveable chairs and making sure the AI isn't touching them, but I don't want the AI to be sitting on air if you move the chair, or see them floating above the chair/bed just to avoid this.

That's anyone's guess, I think. Maybe grayman knew the cause, but didn't know the fix or get around to it.

That said, I don't think anyone's reported knockout fatalities in my FMs - maybe worth comparing your method?

2 hours ago, geegee said:

Does anyone know what this console error warning is about?

WARNING:Source with 2 surfaces. snapshot func_static, scaling: no, needFinish: no       

Does this indicate a degenerate solid (made into func_static)?  Is there any way to trace the culprit?

That's my more important question.

_____________

WARNING:Couldn't load image: dds/textures/particles/arcturus_fire              
  [map entity: atdm_campfire_typical_1]                                        
  [decl: light_fireflames_typical in def/tdm_lights.def]                       
  [model: typical_campfire01.prt]                                              
  [decl: typical_campfire01 in particles/tdm_fire.prt]                         
  [decl: arcturus_fire in materials/tdm_particles.mtr]                         
  [image: dds/textures/particles/arcturus_fire]

I checked, the dds image is there.  Perhaps the wrong format?

That error attaches to atdm:campfire_typical
It doesn't attach to atdm:campfire_small

which to my eyes appears identical to atdm:campfire_typical

So I suppose atdm:campfire_typical should be the same, but with an enhanced fire that doesn't render because not found.

Anyway I use the error-free atdm:campfire_small to get rid of the warning.

 

I haven't heard of that warning. Snapshot sounds like it would have to do with cubemaps... By the way, I learned recently that if you use "testmap" it's actually a combination of "dmap" and "devmap". Devmap is the same as map except that you will get console warnings that are usually hidden. Maybe that's what you're using?

The arcturus_fire material was one of those fixed as part of a wider effort to systematically find and eliminate console warnings generated from core assets. In any case, asset bugs are best reported on bugs.thedarkmod.com to avoid them getting buried in forum threads.

[Frost_Salamander]

29 minutes ago, Dragofer said:

That said, I don't think anyone's reported knockout fatalities in my FMs - maybe worth comparing your method?

I didn't do anything weird I don't think. I just used the usual path nodes to make the AI sit and sleep.  Only one person mentioned it, but I tested it myself and sure enough most times damage was dealt to the AI, and maybe 20-30% of the time it was enough to kill them.  I might set up a little test map and share it if anyone's interested in looking into it.  At the end of the day I'm not too bothered by it - it's just something that seems like it probably shouldn't happen though.

[geegee]

42 minutes ago, Dragofer said:

I haven't heard of that warning.

I updated my post with a .map file showing the cause is SEED targeting a 3x3 patch func_static with a 2-sided decal texture.  The patch func_static doesn't generate the error, Seed targeting it and distributing it does.

[geegee]

On 7/27/2022 at 2:26 PM, Frost_Salamander said:

Does anyone known what causes this and how best to avoid it?

I've run into that problem several times when working on my maps.  In a couple of cases for sitting AI I've moved the chair/bench further away from other geometry, walls etc., and it was fixed.  Seems that the AI bounces a bit when getting KO'ed and sometimes gets trapped in the geometry. 

[joebarnin]

45 minutes ago, geegee said:

I've run into that problem several times when working on my maps.  In a couple of cases for sitting AI I've moved the chair/bench further away from other geometry, walls etc., and it was fixed.  Seems that the AI bounces a bit when getting KO'ed and sometimes gets trapped in the geometry. 

I concur. I've seen this a couple of times when developing maps. I ended up moving the chair around a bit, as @geegeesuggests. Not a very satisfying solution, since I'm never really sure I totally fixed the problem (the deaths happen intermittently in the first place).

[Geep]

On 7/31/2022 at 7:23 PM, joebarnin said:

I concur. I've seen this a couple of times when developing maps

In the Sleeping AI wiki article, I've replaced the "Known bugs" section at the end, discarding Fidcal's circa-2009 items, and putting in this problem and another relatively recent unsolved one from the bugtracker.

[thebigh]

Can the tiny spiders be made to patrol, or do they just wander around aimlessly no matter what?

[Dragofer]

5 hours ago, thebigh said:

Can the tiny spiders be made to patrol, or do they just wander around aimlessly no matter what?

The animal_patrol spawnarg governs that.

[Frost_Salamander]

I have some questions about frob boxes.  In the screen shot below, you can see the frob box for the wall_lever01.pfb prefab.  In my FM, I made the lever non-frobable while you were outside the room it was in because you could frob it through the wall, and I didn't want to reduce the frob_distance.  However, when you make it non-frobable, the frob box becomes solid, and if the player passed by that wall outside the room, it would appear they were being blocked by an invisible entity.  

I didn't really understand the problem at first so I just moved the lever.  Since then I've played around with the spawnargs and have realised you can just change the frob box size, or get rid of it altogether.

So questions are:

• Is the frob box supposed to become solid when the entity is not frobable?  If so, why?
• This prefab works fine without the frob box, is it really needed?
• If the frob box is needed, why is it so big?

[Obsttorte]

35 minutes ago, Frost_Salamander said:

• Is the frob box supposed to become solid when the entity is not frobable?  If so, why?
• This prefab works fine without the frob box, is it really needed?
• If the frob box is needed, why is it so big?

• No
• Not necessarely, although I am not sure whether the engine falls back to the collision model or to the AABB of the model if no frob box is defined. The first would be sub-optimal, but not a big thing either. I think the main purpose is to make small objects like coins easier to frob by providing them with frob boxes that are bigger then the actual model.
• I would assume that either the prefab author made a typo or didn't know what he was doing Consider it a bug.

[Frost_Salamander]

23 minutes ago, Obsttorte said:

• No
• Not necessarely, although I am not sure whether the engine falls back to the collision model or to the AABB of the model if no frob box is defined. The first would be sub-optimal, but not a big thing either. I think the main purpose is to make small objects like coins easier to frob by providing them with frob boxes that are bigger then the actual model.
• I would assume that either the prefab author made a typo or didn't know what he was doing Consider it a bug.

The frob box becoming solid doesn't seem to be limited to this prefab - I just added one to another model and the same thing happened. However, I think it's probably not really an issue, and is only a problem in this case because the frob box is way bigger than it should be.

I'll raise a bug about the prefab frob box being too large and mention the solid thing in there. If someone thinks that's a bug as well they can look into it.

[Frost_Salamander]

Does anyone know what's causing this weird effect?  Besides looking strange, it also causes my framerate to tank heavily - like -150 FPS.  This is a brush with the lamp post material (tdm_streetlamp_metal) applied to it with a light shining on it.

Also, the effect (along with the FPS drop) goes away if I change the brush to a func_static, which I am probably going to do anyways.  I see similar effects on some other metal materials as well (e.g. iron_flat), but not to this extreme.

 

[nbohr1more]

1 hour ago, Frost_Salamander said:

Does anyone know what's causing this weird effect?  Besides looking strange, it also causes my framerate to tank heavily - like -150 FPS.  This is a brush with the lamp post material (tdm_streetlamp_metal) applied to it with a light shining on it.

Also, the effect (along with the FPS drop) goes away if I change the brush to a func_static, which I am probably going to do anyways.  I see similar effects on some other metal materials as well (e.g. iron_flat), but not to this extreme.

 

I suspect that something in the DMAP precision is generating too many triangles for this brush.

What does it look like with r_showTris 2 ?

Does the same thing happen with a fresh dmap via the 2.11 Development Build ?

[Frost_Salamander]

5 minutes ago, nbohr1more said:

I suspect that something in the DMAP precision is generating too many triangles for this brush.

What does it look like with r_showTris 2 ?

oh yeah:

 

5 minutes ago, nbohr1more said:

Does the same thing happen with a fresh dmap via the 2.11 Development Build ?

I'll try that a bit later and get back to you.  Is this a known problem then?

[Frost_Salamander]

same on 2.11. I tried recreating the brush and it didn't help (if that's a thing).

[Frost_Salamander]

Hmm I tried a couple of different things, both of which seemed to fix it:

• I cut it into sections instead of running it right through that lamp post
• moving it out from directly under the lamp post (not sure if it's the post itself or the light attached to it that was the problem).

Edited September 20, 2022 by Frost_Salamander