Newbie DarkRadiant Questions

[peter_spy 1500]

You have the same problem with your FM by the way, the folder name was like scroll1.1 and when I tried to dmap, I got a message that the file does not exist.

Edited November 4 by peter_spy

[MirceaKitsune 213]

Just now, peter_spy said:

You have the same problem with your fm by the way the folder name was like scroll1.1 and when I tried dmap, I got a message that the file does not exist.

Yeah, that 1.1 should be deleted (I only put it in the zip name though). "dmap scroll.map.map" would have probably worked but with my weird results.

[Geep 224]

Kudos to peter_spy for spotting to that. I seldom use autocomplete with dmap myself. Usually I just hit uparrow until I get to the recent command of interest.

[STRUNK 270]

When I make a square cylinder patch it looks square from the top but round from the side ingame. When I export it as an .ase it also looks like that, when I export it as .iwo it looks square, and the filesize is 10 times smaller. What is causing this?

Other question; I made a model where I put more pieces of these cylinders together because of complex curving, so the there are a lot of duplicate points (I guess). Does this make the model more complex for rendering, or doesn't it matter?

[Dragofer 1287]

It's been a fairly longstanding bug that patches exported in DR as .lwo's lose smooth shading and therefore look clunky. The workarounds are to export as .ase or fix it in Blender by removing doubles on a material-by-material basis.

.lwo is a compressed numeric format while .ase is an uncompressed text based format. They have the same size when they're compressed into a .zip or when they're ue.npacked ingame, so it's mostly a matter of storage space on your harddrive.

I think it's fine to use multiple smaller patches for more complex shapes.

[STRUNK 270]

Ok, clear. But .. I wanted in the first place to have the square cylinders to look also square in game. How should I properly make a square "cylinder" patch, so I can bend it, that looks the same as a square brush? Something is different with how the texture looks ...

[Obsttorte 1487]

Patches are intented for round surfaces, so edges shared by two tris of the same patch will always have the same Vertex normal and therefore look smooth and round. If you want something edgy-looking, use Brushes.

[STRUNK 270]

@Obsttorte

But brushes can't be bend like patches .. right?

Althoug it looks nice, it was intended to be squared bars .. and it only does when exporting it as an .iwo :

 

Ok, found it; I can make a Simple Patch Mesh and make it the form I want, then thicken patch : )

Edited November 8 by STRUNK

[MirceaKitsune 213]

I've had a question for a while, good to look into while I'm still experimenting with a test map; I was wondering if it's possible to change the size of an AI, even by defining your own atdm:ai_* character in a custom def file. Is it theoretically possible to create midgets or giants? I'm not aware of a "size" parameter that can rescale the entire AI.

If it were possible, I'm assuming the path-finding algorithm needs to adapt and understand when an AI is too big to walk through some doors or small enough to walk through spaces not accessible to normal people (eg: vents). It would also be wise to re-scale the damage such an AI can deal, so shrunken characters deal less damage per blow while enlarged ones more.

In addition: Is it possible to change the size of the head relative to the body? Would be useful in cases where you want a character with a smaller or larger head. Similarly I'm assuming the head definition must allow some scale parameter.

[STRUNK 270]

@MirceaKitsune

I had sort of the same question about changing the size of AI models. This was the answer:

 

[demagogue 1242]

It's probably a good idea for every mapper to get familiar with Blender (or their modeling app of choice) for little tasks like this anyway. It's practically the Photoshop of mapping. We should all should know it well enough to jump in, throw something together and import it into the game when we need to.

[MirceaKitsune 213]

7 hours ago, STRUNK said:

@MirceaKitsune

I had sort of the same question about changing the size of AI models. This was the answer:

 

Ah. Why would you need to downscale the model in Blender though? It should be simple to just give any entity a different size! Might not be worth the effort in this case, even if I could probably do it that feels overkill... I was hoping to play with the idea using just simple def edits. Maybe I'll try giving an AI the same scale parameter used to resize func_static meshes, curious what that would do.

[demagogue 1242]

If it's any consolation, it's a very old complaint. IIRC there's a reason why it hasn't been fixed, it's more complicated than you'd think, since it's been brought up a lot.

[MirceaKitsune 213]

18 hours ago, demagogue said:

If it's any consolation, it's a very old complaint. IIRC there's a reason why it hasn't been fixed, it's more complicated than you'd think, since it's been brought up a lot.

Character rescaling? I'm assuming it might require some changes to the AI system, since the bounding box and similar modifications could break pathfinding and more. Oh... and joint attachments, not sure how keys attached to the hips and such would behave. Down-scaling an animated model should otherwise work I imagine, but probably not the rest.

[MirceaKitsune 213]

Okay, I remember now: There's oddly enough no proper way to change the scale of entities. You do it from the rotation field which I hear breaks stuff in general. Very odd design choice when idTech4 was created, using rotation to define scale and only having that work on static entities.

[grayman 2959]

You can use the DR model scaler to create new versions of modeled entities.

I don’t know if it will work with AI.

Don’t  use the ‘rotation’  spawnarg to change size.

No longer legal.

[MirceaKitsune 213]

Alright, onto a new question. I was going to make an unique thread for this one as it's a bit more complicated, but I seem to have some stuff figured out and only need help with the last part now.

I'm looking into how to define an electrical light that flashes and flickers ambientally. The light source itself is no problem: I can create either a plain light entity or an atdm:static_electric_light_nomodel_lit (this works better for my use case) and with the following properties I can customize it to get precisely the desired result:

light_center 0 0 0
light_radius 128 128 128
s_looping 1
s_shader light_flicker_104
texture lights/biground1_squarelamp_snd
_color 0 1 0

But now comes the complicated part: I want to create the light surface out of brushes. You can think of them as the filament of the bulb, their purpose to provide a full bright texture synced with the light source. The brushes are converted to an entity (eg: func_static); How to make the faces appear fully bright, have the same color as the light, and flicker or turn off with it?

First thing first: What texture do I even give the lit face(s) of the brush so it becomes a light surface? I noticed you can hack by giving your brush a texture from "light/", however the texture browser doesn't normally let you browse there when texturing geometry so it's probably not normal. There isn't a fitting texture there anyway, as all light textures are squares or circles fading toward the edge, what I need is a fully white texture which ideally has some spots like a neon.

Once I were to solve that, the second and last question comes: How do I connect this brush entity to the light entity, so that it copies its color as well as the texture intensity while flickering with the light source? Would a simple "bind" do, or perhaps a "def_attach"? It should be noted that ideally, this is a light the player can turn off and the AI should notice it's out... therefore the brush texture also needs to respect that and become black if the light source has been triggered off.

One last note: I tried to do everything in one entity, by converting my brushes to a func_static then changing the classname to light. However this seems to break stuff: Even after a dmap the brushes are moved and distorted, light entities clearly don't like being given a model. Thus I'll probably need two entities in the end (the brushes func_static and the light source) with the light source telling the brushes how to colorize their light faces.

Edited November 9 by MirceaKitsune

[peter_spy 1500]

Usually the least convoluted workflow is to a) model a lamp, b) use an emissive texture for the lightbulb part (with blend add stage), c) create entity class for a light source, d) extend it with a class with the lamp model. Typically I prefer to keep models and light sources separate, to have greater freedom of light placement, but there are situations when light source + model entity can be useful too.

[Dragofer 1287]

The process peter_spy describes is mainly suited for making a lamp with a flame, since it doesn't let the light affect the lamp model too much.

For a flickering electrical light, you'll need to start with a light entity and change its model spawnarg to your lamp or filament model, change its texture spawnarg to one that ends in _snd, assign a flickering soundshader, and inherit from one of the existing sound-emitting electrical lamps.

I doubt you can assign a brush as a model, so you'll have to export it as one first. The surface textures need to be a texture that uses colorme. You'll probably also need to define new skins to override the inherited ones.

Since you can only assign a light one model, it'd be much more convenient to combine the lamp and filament into one model.

[peter_spy 1500]

Actually, for a lamp with a flame you'll need a particle emitter and all the stuff that goes along with it You also assumed that he wants to sync the lamp flicker with a sound shader, which can be done and works pretty well, but it's not a necessary thing, since it adds another layer of complexity. For starters, you can just create a light table that will flicker in any way you want, and use it both in light and model shader.

Edited November 10 by peter_spy

[Dragofer 1287]

1 hour ago, peter_spy said:

Actually, for a lamp with a flame you'll need a particle emitter and all the stuff that goes along with it

The standard way to make a flame light is to assign the flame particle as the light's model. This takes up the light's model slot, so you have to connect it to the lamp via def_attach which means the light's colour won't affect the lamp's colour. It also means you can't easily edit the light's properties in DR, so def_attach is only really used for lights that need a particle.

 

1 hour ago, peter_spy said:

You also assumed that he wants to sync the lamp flicker with a sound shader

His desired result contains a flickering sound shader, so that was my assumption yes, though I skimmed through the not too concise post.

 

1 hour ago, peter_spy said:

For starters, you can just create a light table that will flicker in any way you want, and use it both in light and model shader.

Creating new versions of materials which use tables would let him avoid exporting his brush as a model, but last I checked there weren't any tables made for electrical lights. I got pretty good results in my map using the thunderstorm tables, but that was for very dysfunctional lamps. Creating a light table from scratch seems a bit much since you'd have to define intensity frame-by-frame, while you could just sync it to one of the flickering sound shaders. Can set volume to -60 if you don't want to hear the sound.

 

Tbh I think a lot of Mircea's problems could be solved by exporting that brush as a model first before dropping it into an existing flickering electrical lamp. Might need to set up lit and unlit skins too.

[peter_spy 1500]

23 minutes ago, Dragofer said:

His desired result contains a flickering sound shader, so that was my assumption yes, though I skimmed through this not too concise post so I might've missed some finer points.

Ah, didn't see it, the dark theme is awful with that code snippets section. It shows black font against dark bg. 

 

23 minutes ago, Dragofer said:

Creating a light table from scratch seems a bit much since you'd have to define intensity frame-by-frame, while you could just sync it to one of the flickering sound shaders. Can set volume to -60 if you don't want to hear the sound.

That's not true, actually. By default, table, when used with time keyword, spans across one second; you can add as few or as many values there as you want. The table interpolates between them by default, but if you want a square wave sort of response, you have to use snap keyword inside the table. You can also increase or shorten that initial time span with simple math operators like * or /.

Edited November 10 by peter_spy

[Dragofer 1287]

19 minutes ago, peter_spy said:

That's not true, actually. By default, table, when used with time keyword, spans across one second; you can add as few or as many values there as you want. The table interpolates between them by default, but if you want a square wave sort of response, you have to use snap keyword inside the table. You can also increase or shorten that initial time span with simple math operators like * or /.

Ah, then it's not wholly as laborious as I remembered, though still there are plenty of numbers between 0 and 1 involved. Almost all of the existing tables are geared towards flickering candle light (more like pulsating tbh), so if some tables for electrical flickers were made that could be a useful addition i.e. for making lit windows for industrial buildings.

[peter_spy 1500]

Yeah, I prefer pulse lights, mostly because they're easier on the eyes, and inserting like 4-5 values there to interpolate is just fine.

Flickering with the sound file instead of time value is probably okay for decorative reasons here and there.

If you'd want to make this more gameplay-oriented thing, like a light that flickers and switches off for a while, so the player can pass an otherwise lit area, that might either require a time-based snap table, or a custom sound file with proper silence intervals. I'd probably experiment with a table first and make the sound after gameplay tests.

Edited November 10 by peter_spy

[MirceaKitsune 213]

Yes, that is correct: This isn't a flame light, it's an electric light. No particles and the light will flicker ambientally. I already have the light source entity which works perfectly, buzz sound and the light flickering with its intensity and all... the main issue is the light surface being synced with it at all times.

So is it official that I have to export the model to ASE to make this possible? No way to make my brushes func_static or another entity then have the flickering light translate its intensity to its texture? Because I really preferred it this way for my use case, I plan on directly using brushes and patches which I'd rather not convert to a mesh.

Also where do I find a material ending in _snd useful for a light surface? I'm only aware of the ones in "lights/" but those are intended as projector textures for light sources and not textures to be put on surfaces directly.