Newbie DarkRadiant Questions

[grayman]

You shouldn't have to set any spawnargs on the lantern.

 

If you use these spawnargs on your AI:

 

"def_attach5" "atdm:prop_lantern_on"

"pos_attach5" "hand_l"

 

the lantern automatically comes with these spawnargs:

 

"extinguish_on_drop" "1"

"extinguish_on_drop_delay" "4" // in seconds

"extinguish_on_drop_delay_random" "4" // random time added to base delay time

 

By default, then, the lantern should extinguish between 4 and 8 seconds after dropping.

 

For a lantern, however, if it lands upright, it won't go out.

 

Other rules:

 

- If the player picks up the lantern before it goes out, it stays lit

- If the lantern falls in water, it goes out even if it lands upright.

[buck28]

Posted Today, 12:12 PM Grayman said:

You shouldn't have to set any spawnargs on the lantern

 

Since the lantern is not visible in DR, and spawns at game start; I didn't think you could add spawnarg to it?

I put what you have above on the AI, according to the article.

I did add: drop_when_ragdoll after def_attach" and pos_attach" and it seems to work fine.

Edited October 28, 2014 by buck28

[grayman]

Objects, in general, have their default spawnargs defined in the darkmod/def/*.def files. The lantern appears in "tdm_prop_items.def", where the "extinguish*" spawnargs are defined.

 

You should only have to put the "def_attach5" and "pos_attach5" spawnargs on the AI. You get everything else automagically.

[buck28]

Ahah! Thank you sir... That makes sense.

[grayman]

To see this for yourself, do the following:

 

Bring up the "Create entity" window and choose Props/atdm:prop_lantern_on.

 

This places a lantern in your map.

 

Select it and scroll down through its spawnargs until you see the ones for "extinguish*".

[SteveL]

Thanks for the clarifications grayman. I should have guess it'd "just work"

[buck28]

This places a lantern in your map.

 

So by doing the above, you can see a lantern in DR? I'm confused now.

[SteveL]

So by doing the above, you can see a lantern in DR? I'm confused now.

 

grayman only suggested that so that you can examine the spawnargs in DR and see that the "extinguish_on_drop" spawnargs come automatically with the standard lantern. That's not how to do it for real. The correct way to set up an AI carrying a lantern is the def_attach one that you've used, where you don't get to see it in DR.

[grayman]

So by doing the above, you can see a lantern in DR? I'm confused now.

 

You only do that so you can see its spawnargs.

 

Once you've looked at them, you're free to delete the lantern if you don't want it in your map.

[buck28]

Okay. That's what I thought. Thanks guys...

[Goldwell]

Does anyone know how to change it so that once you add an alpha level to a custom texture it doesn't make it brighter?

 

My texture looks great until I add the alpha (which is needed for the edges) and then suddenly the texture appears brighter ingame.

 

Here is the material code for it

 

 

textures/carpet/persiancarpet1

{

noshadows

surftype15

description "carpet"

qer_editorimage textures/carpet/persiancarpet1

bumpmap textures/carpet/persiancarpet1_local

diffusemap textures/carpet/persiancarpet1

{

blend diffusemap

map textures/carpet/persiancarpet1

alphatest 0.5

}

{

if (global5 == 1)

blend add

map textures/carpet/persiancarpet1

scale 1, 1

red global2

green global3

blue global4

}

{

if (global5 == 2)

blend add

program ambientEnvironment.vfp

vertexParm 0 1, 1, 1, 1 // UV Scales for Diffuse and Bump

vertexParm 1 1, 1, 1, 1 // (X,Y) UV Scale for specular

vertexParm 2 global2, global3, global4, 1

fragmentMap 0 cubeMap env/gen1

fragmentMap 1 textures/carpet/persiancarpet1_local // Bump

fragmentMap 2 textures/carpet/persiancarpet1 // Diffuse

fragmentMap 3 _black // Specular

}

}

 

 

[Springheel]

You've got two diffusemap stages. Delete the first one.

[SteveL]

Does anyone know how to change it so that once you add an alpha level to a custom texture it doesn't make it brighter?

 

You're applying the persiancarpet1 texture 3 times there...

"blend add" will always brighten. "blend blend" will tone it down to non-luminous transparency. "blend filter" will darken. You can adjust the alpha with the alpha keyword and the amount of color with the rgb (or separate red, green, blue) keywords. NB alpha materials don't use lighting, they are fullbright, so you have to adjust the rgb parameter manually to fit the lighting level in your scene.

You can't mix alphatesting and an alpha blend in the same material stage though... What effect are you going for?

[Goldwell]

You've got two diffusemap stages. Delete the first one.

 

Ah that fixed it, thank you

[Goldwell]

You're applying the persiancarpet1 texture 3 times there...

"blend add" will always brighten. "blend blend" will tone it down to non-luminous transparency. "blend filter" will darken. You can adjust the alpha with the alpha keyword and the amount of color with the rgb (or separate red, green, blue) keywords. NB alpha materials don't use lighting, they are fullbright, so you have to adjust the rgb parameter manually to fit the lighting level in your scene.

You can't mix alphatesting and an alpha blend in the same material stage though... What effect are you going for?

 

I was going for this sort of effect http://i.imgur.com/n4YMbT5.jpg and yeah I didn't realize I was overdoing it on the diffuse stuff. but after deleting it, the texture is no longer over bright and the edges of my carpet look correct

[Springheel]

"diffusemap" is just shorthand for "blend diffusemap map". You use the second one if you need to add further spawnargs, like alphatest or rgb values.

[Goldwell]

<removed>

 

I have just decided to cut out this part from my map. So please ignore this post.

Edited November 4, 2014 by Goldwell

[Moonbo]

Hey Goldwell,

 

This might be barking up the wrong tree, but here it goes. I had a situation in my upcoming FM where certain transparent textures had draw-order render bugs with the portal_sky texture that are somewhat similar to your screenshot. I'm not sure if that's what's happening here (and hopefully someone comes along with an easier answer), but if it is, then my solution was to create a new portal_sky material that overwrote the default one. Here's the material that I used (just paste this into a .mtr file and it should work):

 

 

 

//custom portal_sky with "blend add" added to the material to solve draw order issues with transparent textures.

 

textures/smf/portal_sky

{

qer_editorimage textures/editor/portal_sky

forceOpaque // will still seal levels

noshadows

noimpact

sort portalSky

 

{

blend add

map _currentRender

 

clamp

screen

 

// fix up the projection based on the screen coords

translate global6 * 0.5, global7 * 0.5

scale global6 * 0.5, global7 * 0.5

}

/*

{

vertexProgram portalSky.vfp

fragmentProgram portalSky.vfp

fragmentMap 0 _currentRender

}

*/

}

 

 

 

 

Make sure to dmap after overwriting the material. Note that this makes the portal_sky texture transparent in Dark Radiant for some reason but I haven't seen any other side-effects.

Edited November 4, 2014 by Moonbo

[Goldwell]

Hey Goldwell,

 

This might be barking up the wrong tree, but here it goes. I had a situation in my upcoming FM where certain transparent textures had draw-order render bugs with the portal_sky texture that are somewhat similar to your screenshot. I'm not sure if that's what's happening here (and hopefully someone comes along with an easier answer), but if it is, then my solution was to create a new portal_sky material that overwrote the default one. Here's the material that I used (just paste this into a .mtr file and it should work):

 

 

 

//custom portal_sky with "blend add" added to the material to solve draw order issues with transparent textures.

 

textures/smf/portal_sky

{

qer_editorimage textures/editor/portal_sky

forceOpaque // will still seal levels

noshadows

noimpact

sort portalSky

 

{

blend add

map _currentRender

 

clamp

screen

 

// fix up the projection based on the screen coords

translate global6 * 0.5, global7 * 0.5

scale global6 * 0.5, global7 * 0.5

}

/*

{

vertexProgram portalSky.vfp

fragmentProgram portalSky.vfp

fragmentMap 0 _currentRender

}

*/

}

 

 

 

 

Make sure to dmap after overwriting the material. Note that this makes the portal_sky texture transparent in Dark Radiant for some reason but I haven't seen any other side-effects.

 

Just tested in game and sadly it didn't work, thanks for trying to help!

[Moonbo]

Ah well :-P.

[Moonbo]

This is probably a question for Springheel: right now with every walk cycle an AI moves forward by a specific amount. Is there a way to change the amount of forward movement with each walk/run animation (outside of speeding up/slowing the animation)?

[Springheel]

There are spawnargs to alter the speed; other than that you would have to make a new animation, afaik.

[Moonbo]

Okay, thanks Springheel, I guess I'll just have to tweak values until I find a good balance.

[Goldwell]

Does anyone know what the alarm levels are for the entity "atdm:alarm_sound"

 

I have everything setup correctly however it only says that you should use either "alarm" in the sprS-propagate spawnarg (which alerts the whole map) or "alarm_mild" which also alerts the whole map for me.

 

I went through the wiki and searching the forum trying to find what other levels there are and even tried myself by using "alarm_mild" or "alarm_low" but i'm not having any success.

[SteveL]

The default sound volumes are 90, 77, and 66 for spgrs_alarm_loud, _alarm, and alarm_mild.

 

You can change the volume with the alert_volume_mod spawnarg on the atdm:alarm_sound. A value of -20 will bring alarm_mild down to 46 volume, for example.

 

NB tweak it after you are fully visportalled as that'll affect the route that sound has to take.

NB2 the "team" spawnarg doesn't currently work on alarms. All AI will hear it, not just one specified team.