Newbie DarkRadiant Questions

[peter_spy]

I don't work with other formats, but .ase is a plain text file and it has the material path there:

Quote

*MATERIAL_LIST {
    *MATERIAL_COUNT 1
    *MATERIAL 0 {
        *MATERIAL_NAME "Material #32"
        *MATERIAL_CLASS "Standard"
        *MATERIAL_AMBIENT 0.5880    0.5880    0.5880
        *MATERIAL_DIFFUSE 0.5880    0.5880    0.5880
        *MATERIAL_SPECULAR 0.9000    0.9000    0.9000
        *MATERIAL_SHINE 0.1000
        *MATERIAL_SHINESTRENGTH 0.0000
        *MATERIAL_TRANSPARENCY 0.0000
        *MATERIAL_WIRESIZE 1.0000
        *MATERIAL_SHADING Blinn
        *MATERIAL_XP_FALLOFF 0.0000
        *MATERIAL_SELFILLUM 0.0000
        *MATERIAL_FALLOFF In
        *MATERIAL_XP_TYPE Filter
        *MAP_DIFFUSE {
            *MAP_NAME "Map #12"
            *MAP_CLASS "Bitmap"
            *MAP_SUBNO 1
            *MAP_AMOUNT 1.0000
            *BITMAP "//base/textures/buildercompound/tiling/wall01"
            *MAP_TYPE Screen
            *UVW_U_OFFSET 0.0000
            *UVW_V_OFFSET 0.0000
            *UVW_U_TILING 1.0000
            *UVW_V_TILING 1.0000
            *UVW_ANGLE 0.0000
            *UVW_BLUR 1.0000
            *UVW_BLUR_OFFSET 0.0000
            *UVW_NOUSE_AMT 1.0000
            *UVW_NOISE_SIZE 1.0000
            *UVW_NOISE_LEVEL 1
            *UVW_NOISE_PHASE 0.0000
            *BITMAP_FILTER Pyramidal
        }
    }
}

IIRC, you don;t have to do that with .lwo

[Dragofer]

@Frost_SalamanderYou can view the model in DR's 'Create model' menu to see what material name its surfaces currently use, then create a material definition with the same name that references your custom textures. The diffusemap and specularmap should be .dds in DXT1 with mipmaps (if transparent: DXT5), the normalmap should be .tga without RLE compression.

@peter_spyYou can rename the materials on an .ase model by opening it in a text editor, but this is not possible with .lwo since the format has compression. But you could work around by using DR to re-export the .lwo as an .ase so its materials can be modified without using a dedicated modelling app.

[peter_spy]

By the way, and maybe I'm misremembering this, but somehow you can't use .dds normalmaps at all now? I know there will be compression artifacts, but you'd expect you can use them, e.g. as a last resort, if you want to bring down the FM package size hard. I think it worked as for all other images. In 2.08 .dds normalmaps are just ignored, however compressed.

Edit: yup, there are articles on the wiki that you shouldn't compress normalmaps to dds, but it was possible.

Edited February 23, 2021 by peter_spy

[Geep]

Quote

What I meant is: can I load a TDM fan mission I have build in dark radiant and hit a single button (in dark radiant) to start dark mod with my mission loaded and syncronised ready to play?

@kin, since no one responded otherwise, I think what you have here is a New Feature Request. You can add it to the bug tracker if you have an account (bugs.thedarkmod.com) or ask someone (including me) to do that for you. I have no opinion on whether it's technically feasible.

[jonri]

I made a light entity that has a model property, which I found to be quite convenient trying out different placements. I was wondering if it is possible to set properties on the model itself rather than the light in this setup.

Specifically, I'd like to set noshadows on the model but not the light. If it's not possible, I'll separate them back out as I think I've got my placement set.

[Obsttorte]

You could try it the other way round. Instead of using a light entity with a model you could use a model with a def_attached light. This way the spawnargs refer to the model used and changes to the light can either be done by using a custom light attached and specifying the spawnargs in the respective def (if you want uniform looking lights) or via set spawnarg on attachment_name.

 

EDIT: There seem to be a spawnarg called noshadows_lit in addition to the noshadows one. I assume that this one may do what you ask for. However, on the models I've checked it is already set to 1. Are you sure the light model is casting a shadow?

 

[jonri]

11 hours ago, Obsttorte said:

You could try it the other way round. Instead of using a light entity with a model you could use a model with a def_attached light. This way the spawnargs refer to the model used and changes to the light can either be done by using a custom light attached and specifying the spawnargs in the respective def (if you want uniform looking lights) or via set spawnarg on attachment_name.

I was trying to avoid this approach so that I didn't lose the ability to see the light volumes in DR.

11 hours ago, Obsttorte said:

EDIT: There seem to be a spawnarg called noshadows_lit in addition to the noshadows one. I assume that this one may do what you ask for. However, on the models I've checked it is already set to 1. Are you sure the light model is casting a shadow?

Now this put me on the right track!  The noshadows_lit spawnarg doesn't exist on the regular light entity, but it does on atdm:static_electric_light_lit_quiet_base.  I just switched my entity to inherit from that and then it had noshadows_lit both defined and set to 1 by default.  This fixed my shadowing issue and since it's still a light I can see its volume in DR.  Thanks!

[VanishedOne]

My func_pendulum is silent. Am I overlooking something, or are these spawnargs from the entityDef not actually implemented?

	"editor_snd snd_open"		"sound to play when opening."
	"editor_snd snd_close"		"sound to play when closing."
	"editor_snd snd_opened"		"looping sound for it's opened state."

 

[Dragofer]

13 minutes ago, VanishedOne said:

My func_pendulum is silent. Am I overlooking something, or are these spawnargs from the entityDef not actually implemented?

	"editor_snd snd_open"		"sound to play when opening."
	"editor_snd snd_close"		"sound to play when closing."
	"editor_snd snd_opened"		"looping sound for it's opened state."

 

Those look like leftover spawnargs from a door, not something a func_pendulum would have.

You could just use s_shader, that always plays.

[VanishedOne]

My guess was that someone added them on the grounds that a pendulum is effectively a sort of binary mover (like the way levers and buttons have snd_open). But there doesn't seem to be any actual support.

Yes, I'll have to fall back to having a loop playing. Edit: or this.

Edited February 24, 2021 by VanishedOne

[Obsttorte]

A pendulum isn't a door, though. The latter moves at constant speed, a pendulum doesn't.

 

You could try "snd_accel", "snd_decel" and "snd_move".

[VanishedOne]

Actually doors don't have to move at constant speed, although I imagine they won't produce as nice a motion as a dedicated pendulum.

 

[Obsttorte]

Yeah, they have an acceleration and deceleration part. The pendulum movement however is calculated from the length of it iirc. So the approach is slightly different.

[Frost_Salamander]

What's the best way to have something block a door from opening? Most things I try, the door just passes through them (model furniture), or gets pushed (moveable entities). If I make the entity nonPushable, again the door just passes through it.

Ideally I would like to use one of the rock entities, as I would like to be able to move it out of the way afterwards.  Or if I did want to use a model, is there something I could do to it to make it behave this way?

Edited February 26, 2021 by Frost_Salamander

[Geep]

Here's a hack solution I used recently. Create a movable (I guess a rock in your case) that gets pushed, but it can't really move because the other side of it runs into something immobile, like a world spawn chunk. Yet the player can pick the rock up and let the door open, or a script can remove the rock when no longer needed.

[Geep]

I've gotten myself confused about keys on AI and doors. Am I correct that all the following are true?

1. If a key on an AI is pickpocketed, by default the AI can no longer go through a closed door needing that key
2. Most gamers and game developers would recommend the opposite: letting the AI still go through the door
3. That is achieved by adding spawnarg "can_unlock<num> <door name>" on the AI
4. There is no difference between def_attached and bound keys in this regard
5. There is no difference between def_attached and bound keys in ANY aspect of key use (not counting visual-appearance-when-animated issues)

I recognize that (2) is an opinion, while the the others are factual.

Edited February 26, 2021 by Geep
added caveat in parenthesis to (5)

[Petike the Taffer]

I plan to build a castle courtyard or two for a mission I'd like to develop.

My layout for the courtyard is such that it has an "upper floor" on its sides, specifically, a walkway on the walls surrounding it (and accessed by stairs), some of these walls being part of the defensive system of the castle.

If I want to get the best performance possible out of the courtyard, would it be for the best if I gave it a transparent ceiling at the level of the "upper floor" and make that "upper floor" area a whole separate room or series of corridor-like rooms, with an inaccessible transparent room between them ?

The inaccessible room would be essentially the upper part of the courtyard, its top inner side equipped with a skybox animation (or static background) and the lower room of the courtyard would have its ceiling above the area where the player character can comfortably jump upward.

I don't want to make a tall courtyard room with a skybox that kills the performance anytime the player goes outside. (And yes, I am using visportals everywhere, don't worry.)

[Geep]

@Petike the Taffer, a few thoughts...

I dunno about the transparent room idea. Maybe you could achieve the same thing (I'm guessing a minor improvement in performance in some circumstance) with lots less effort by using a horizontal visportal at the interface between floors.

A design with a spire or tower in the center of the courtyard, extending up to the skybox, could serve as an anchor for radial visportals to the courtyard walls. Festoon with worldspawn buttresses and arches as needed to make that work.

[JackFarmer]

5 hours ago, Geep said:

I've gotten myself confused about keys on AI and doors. Am I correct that all the following are true?

1. If a key on an AI is pickpocketed, by default the AI can no longer go through a closed door needing that key
2. Most gamers and game developers would recommend the opposite: letting the AI still go through the door
3. That is achieved by adding spawnarg "can_unlock<num> <door name>" on the AI
4. There is no difference between def_attached and bound keys in this regard
5. There is no difference between def_attached and bound keys in ANY aspect of key use (not counting visual-appearance-when-animated issues)

I recognize that (2) is an opinion, while the the others are factual.

Whether an AI carries a key or not is not decisive for opening the door; this ability only depends on the spawnarg "Can unlock door". This means that the particular AI can still open the door in question, even if the attached key has been stolen.

Edited February 26, 2021 by JackFarmer

[peter_spy]

5 hours ago, Petike the Taffer said:

I don't want to make a tall courtyard room with a skybox that kills the performance anytime the player goes outside. (And yes, I am using visportals everywhere, don't worry.)

As long as nothing has changed on this during developement lately, the skybox is a sort of subview that is always rendered by default (or at least it uses GPU memory), even when player's inside. This is info_portal sky, which acts as a virtual 360° camera.

If you want something more simple, you could just make a cubemap material and then apply in to 'ceiling' brushes for outside. Then it will be rendered only when you get outside, but its performance impact should be minimal.

[Frost_Salamander]

7 hours ago, Geep said:

Here's a hack solution I used recently. Create a movable (I guess a rock in your case) that gets pushed, but it can't really move because the other side of it runs into something immobile, like a world spawn chunk. Yet the player can pick the rock up and let the door open, or a script can remove the rock when no longer needed.

Yeah I did see that behavior as well actually, but you're right it is a hack.  Does anyone know if that's the only option, or what property of an entity makes doors stop on them?  There must be something about the AI entity that does this...

[Dragofer]

8 minutes ago, Frost_Salamander said:

Yeah I did see that behavior as well actually, but you're right it is a hack.  Does anyone know if that's the only option, or what property of an entity makes doors stop on them?  There must be something about the AI entity that does this...

It's possible that the AI re-reads the spawnargs for what doors it's allowed to open. You could try adding a frob Response to the key (Entity -> Stim/Response... -> Response) with an effect that sets the canUnlock spawnarg on that AI to -.

 

1 hour ago, peter_spy said:

As long as nothing has changed on this during developement lately, the skybox is a sort of subview that is always rendered by default

In my experience the skybox is only rendered when the player can see an area containing a portal_sky surface, you can see this when standing in a caulk-textured room and opening a door to a portal_sky-textured room. I don't know how GPU memory is handled, though.

[peter_spy]

17 minutes ago, Dragofer said:

In my experience the skybox is only rendered when the player can see an area containing a portal_sky surface, you can see this when standing in a caulk-textured room and opening a door to a portal_sky-textured room. I don't know how GPU memory is handled, though.

I've been meaning to recheck that some time ago but I forgot. I remember looking at the stats in older engine versions, and the additional subview + DCs and other stuff for skybox were always there. It's cool if this had been taken care of though

Edited February 26, 2021 by peter_spy

[Obsttorte]

I agree with what Dragofer posted. The skybox is only rendered when there is at least one surface within the currently rendered areas that has the portal_sky texture on it. This doesn't imply that this surface or the skybox as such is neccessarely visible. I am not sure what older engine version you are refering to, but it was always the case since I started working with the code, so I would assume for about 10 years at least. Actually I assume it was always like that.

@Petike the Taffer there are essentially two "easy" ways to keep performance issues low in a scene like you are describing it.

1. Make the courtyard cramped, as non-convex as possible without it starting to look odd. This also makes gameplay more interesting compared to one giant cuboid where everything is observable for the player.
2. Use static skies instead of portal skies.

You can also combine both approaches, but I would start with (1).

 

I don't understand what you mean with your transparent room idea. If it is transparent it won't block the player's view and thus not contribute to improving performance.

[peter_spy]

1 hour ago, Obsttorte said:

I agree with what Dragofer posted. The skybox is only rendered when there is at least one surface within the currently rendered areas that has the portal_sky texture on it. This doesn't imply that this surface or the skybox as such is neccessarely visible. I am not sure what older engine version you are refering to, but it was always the case since I started working with the code, so I would assume for about 10 years at least. Actually I assume it was always like that.

 

To be more precise and in terms of actual mapping scenarios:

1) If you have a portalsky surface in a current visleaf, but it's not in your field of view – it still gets rendered.

2) If you have a series of visleafs divided with portals, but with no additional setup (like doors or func_portals that force portals to close) – skybox still gets rendered, even if you see portals as marked as closed in your debug view.

Only with portals that are forced to be closed by doors, func_portals and such, the portalsky skybox doesn't add to your performance stats and texture memory.

Edited February 26, 2021 by peter_spy