Newbie DarkRadiant Questions

[SteveL]

Ah, the same problem you had last time. The game want to pass no info in this time, but you had your function set up to receive one piece of info. Glad you got it sorted. It does quickly get easier

[Moonbo]

I have an AI which sits on a (monsterclipped) bench. He sits fine but if the player sneaks past him, he will first alert. When he first alerts he will stand up, and start going in circles non-stop. By fiddling with sit distances I can get it so that the AI just stands up, circles once and then sits down (as opposed to circling forever) but I can't get the AI to either 1) not stand up at all (why would he stand just to sit back down?) or 2) not circle at all. Any advice on this one?

[grayman]

I have an AI which sits on a (monsterclipped) bench. He sits fine but if the player sneaks past him, he will first alert. When he first alerts he will stand up, and start going in circles non-stop. By fiddling with sit distances I can get it so that the AI just stands up, circles once and then sits down (as opposed to circling forever) but I can't get the AI to either 1) not stand up at all (why would he stand just to sit back down?) or 2) not circle at all. Any advice on this one?

what does he do if you remove the monsterclip and bench?

 

remove monsterclip only?

 

remove bench only?

[grayman]

=deleted=

[Moonbo]

Hey Grayman,

 

If either the bench or their monster clip is there the spinning behavior happens. I delete both of them then there is no problem.

[grayman]

If you can make a copy of that area, including any path nodes the AI is following, and the behavior still happens, you can PM me the copy and I'll look at it.

 

If it doesn't reproduce the problem, then PM me a copy of the map.

 

Otherwise, I've no way of knowing what this particular AI is doing. There are too many variables.

[Moonbo]

Thanks Grayman,

 

I'll send you a PM :-).

[Deshtat]

Hey there!

 

So I am making progress thanks to you all, and everything is going fine. I still have a minor problem I would like to ask you about, though :

 

I created some unfrobable doors that will shut behind the player each time he successfully passes a step of the level. This way, he can't go back, and the engine saves some useless rendering. The problem is that the AIs of the previous areas keep reacting to the player's noises, even though they are not in the same room anymore.

 

Do you know if there is a way to disable them completely?

I first thought about teleporting them in a spare room, but I would like to know if there are more saving options.

 

Thanks in advance!

[Springheel]

Do you have vis portals in these doors? If not, sound will go right through them.

[Moonbo]

If you do have visportals on the doors I would try adding the spawnarg "loss_closed" and setting it to a large number like "30". This will stop sound from passing through the door when it's closed (assuming it's touching a visportal and seals off the section).

[Deshtat]

Nevermind, I had some visportals indeed, but it seems that the doors were not touching it enough for it too work properly. Thanks!

[Deshtat]

Another quick question : what is the difference between the "solid" and the "noclipmodel" spawnargs?

[161803398874989]

Okay, so here's what I don't get. In Fidcal's A-Z guide, you are taught to create a torch model and then add the light to it. However, after adding these lights my map start crashing, so I removed them. Much to my surprise, the map is still well-lit! However, in the Darkradiant preview, everything's still pitch black. What is going on here? How can I modulate the light intensity from torches and the like?

[AluminumHaste]

Yeah, when creating a torch entity, the entity has a light that's created at map start, so DarkRadiant won't show it.

The entities no longer have a light bound to it like it used to be.

 

File a bugtracker for DarkRadiant, this has bothered me also.

[Moonbo]

Hey 1618,

 

With the current setup of torches a light is bound to the torch by default, but is not visible in Dark Radiant, only in game. If you want to have a light where you can modify the radius, you'll have to remove this default light and manually bind a light to the torch. Here are the steps to take:

 

1) Look at the torch spawnarg called "def_attach". This is the name of the entity bound to the light (it will probably something named "light_torchflame_small". Keep note of that and then replace that name in the spawnarg with "-". This blanks out the attached entity so that the game doesn't spawn the light when the map starts. If you were to load up the map at this point you'd see the torch is now unlit.

 

2) Spawn a light to bind to the torch. For consistency I create an entity which is the same as the one in the "def_attach" spawnarg on the torch (i.e. if the def_attach entity is "light_torchflame_small" I would spawn that). Just go into the entity inspector and create one in the map.

 

3) Now, use the bind spawnarg on the spawned light to connect it to the torch. Then move the light to where you'd expect to see it (i.e. the tip of the torch).

 

That should be it, now when you launch your map you should see a torch just like normal, except now that you can see the bound light in Dark Radiant you can tweak the radius, color, etc. Hope that helps but let me know if you have any questions. You can always open up my FM 'Requiem' in Dark Radiant as I have quite a few torches set up this way in order to avoid light overlap.

Edited February 21, 2015 by Moonbo

[Obsttorte]

It's easier. The attachments have names. The light attached to a torch is usually called flame. Via the spawnarg "set spawnarg on attachmentname" you can change the spawnargs of attached entities.

 

For example, if you want to reduce the flame light radius to 128x128x128, you would add the following spawnarg on the light entity:

 

"set light_radius on flame" "128 128 128"

The A-Z guide is pretty outdated, and many approaches shown there are more complicated as neccessary. It's just a basic starting guide, not a summary of all mappers knowledge, so read the other wiki articles regarding mapping etc, too

[Sotha]

I'm trying to an animated AI, which would work the same way as the sitting AI:

Play enter anim -> cycle anim -> play exit anim.

 

Previously I've done this by replacing the sitting(enter), sitting(idle) and sitting(exit) anims, but cannot use this setup. (For some reason my AI falls through the floor if I do this. Accessing the anims via path_anims do not make the AI fall through the floor. I have no clue why anim playing behaves differently between path_anim and the sitting anim replacing.)

 

Is it possible to use the path nodes like this: path_anim(plays enter anim) -> path_cycleanim (plays the cycling part) -> path_anim(plays exit anim)?

This works, but there always is an ugly glitch between the anim nodes, when the AI winks to idle pose and then continues the animations. Is it possible to blend between the animation nodes so that there is no one frame idle post glitching?

[Obsttorte]

Maybe the spawnargs blend_in and blend_out do the trick. Try setting them to zero for the values between two anim nodes.

1. first path_anim blend_out to zero
2. path_cycleanim both blend_in and blend_out to zero
3. on the last path_anim blend_in to zero

[161803398874989]

The A-Z guide is pretty outdated, and many approaches shown there are more complicated as neccessary. It's just a basic starting guide, not a summary of all mappers knowledge, so read the other wiki articles regarding mapping etc, too

Might it not be a good idea to update it?

[Obsttorte]

There are a lot of additional informations in other wiki articles. As said, one should not only read this six pages and think he or she knows everything there is to know about mapping.

 

It could be updated anyways, but I am not going to mess in others wiki articles. In addition, if I change things and describe them the way I handle them, other mappers will do that, too and we could end up in a mess of different approaches etc..

 

I guess the best idea would be to first start a thread to get answers from skilled mappers on how they approach certain fundamental things, so we have a base for a summary that could serve the purpose Fidcals wiki article currently does, or at least add to it.

[Dunedain19]

Might it not be a good idea to update it?

 

Sure, but that means finding someone who is both willing and has the time to do so.

 

Also, as Obs has correctly noted above me - the A-Z is not the be all and end all of the knowledge that one will require over the course of building a mission. Once you've grasped the essentials, I would likewise recommend that you create a dedicated thread for your own questions, or simply search/ask here in the "Newbie Questions" thread.

 

Word to the wise: be careful about suggesting wiki updates around STiFU - or you'll receive a response similar to the one I got in "Dunedain19's Stuff" - when I suggested that a certain wiki needed TLC... ;-)

Edited February 22, 2015 by Dunedain19

[Obsttorte]

@Dunedain: I think you took Stifu's response more serious then it was intented to be. We germans have a very special kind of humour

[Dunedain19]

@Obs: I am learning that - hence, the ;-) at the end.

[161803398874989]

 

 

Also, as Obs has correctly noted above me - the A-Z is not the be all and end all of the knowledge that one will require over the course of building a mission.

I get that, but the way setting up lights is described currently in the wiki is flat-out stupid in the current situation.

 

 

 

It could be updated anyways, but I am not going to mess in others wiki articles.

I find this to be a weird sentiment. The whole point of a wiki article is that anyone with permissions can edit and update it to better reflect current information. Overtime users are going to drop out of wiki editing, so this model allows others to keep wiki pages up to date. Articles with your name on it as author are better suited to a forum IMO. Wiki articles are supposed to be dynamic.

[Springheel]

It could be updated anyways, but I am not going to mess in others wiki articles.

 

 

At the very least, it might be worth adding a caveat and a link? "This method of lighting is now outdated, see XXXX"