Newbie DarkRadiant Questions

[MirceaKitsune]

22 hours ago, Geep said:

@MirceaKitsune, instead of relying on sintable and an algorithm, you might consider just creating your own table of settings, which you could manually massage until you're happy. For instance, in tdm_ai_steambots.mtr, Baddcog defined a table manually:

table lanternbot_flicker_high { { 0.9, 0.8, 1, 1, 1, 1, 1, 1, 1, 0.8, 1, 0.9, 0.8, 1, 0.9, 0.9, 0.85, 0.9 } }

which was then invoked in that file as "lanternbot_flicker_high[time]" in combination with other parms to set red, green, blue.

For your case, if it was me doing it, I'd define separate tables for R, G, B, maybe with a change every half hour of simulated time (e.g., 48 values per table). You'd still have to do some calculation to normalize the time before indexing the table.

Thanks, that's very helpful! For some reason I thought those tables were hardcoded functions in the engine or some fancy script, didn't realize how easy it was to make your own. Definitely should be using that, very easy to achieve this way

[Geep]

Glad it helps. Yeah, I wasn't sure about how "sintable" was implemented either. So on speculation that it wasn't done by the engine (in which case anyone would be able make a table), I did a file search for that term, and the hits included the "table" usage in an mtr file. Then I searched "table" itself in .mtr files to find Baddcog's non-sintable example. And riffed from there.

[datiswous]

See some info here: https://iddevnet.dhewm3.org/doom3/materials.html

[Geep]

@datiswous, I didn't realize that linear interpolation between table elements would happen by default. Nice.

[datiswous]

For what it's worth, a while back I figured out how to make my own light table:

That topic falls in the category of learning things in non-logical order (which I'm doing all the time).

[cvlw]

Hello again.

I want to teleport a ragdoll to a point in the air and fall horizontally, face down and to land face down.

I have the ragdoll entity defined to flop face down at map start in a hidden area.  When I trigger the atdm:teleport, the ragdoll is teleported standing up and falls feet first, no guarantee to land face down.

Is there a way to keep the ragdoll "lying face down" at teleport?

Thanks.

Clint

[Dragofer]

2 hours ago, cvlw said:

Hello again.

I want to teleport a ragdoll to a point in the air and fall horizontally, face down and to land face down.

I have the ragdoll entity defined to flop face down at map start in a hidden area.  When I trigger the atdm:teleport, the ragdoll is teleported standing up and falls feet first, no guarantee to land face down.

Is there a way to keep the ragdoll "lying face down" at teleport?

Thanks.

Clint

Should the player be there when the ragdoll falls? If not, you can unhide an invisible ragdoll that already lies in the correct position:

1) Create a ragdoll entity in DR

2) Start the map in TDM and place the ragdoll how you want it to be.

3) Use the saveRagdolls console command. This generates a new .map file in your base install maps folder, where the ragdoll has a bunch of new spawnargs that make it spawn in that exact position.

4) I don't think it's 100% safe to override your .map file with the generated .map, so the best is to open another instance of DR, open that new .map, copy-paste the ragdoll to your original .map, copy-paste the new spawnargs to your original ragdoll and get rid of the other ragdoll again.

5) Set the "hide" "1" spawnarg on your ragdoll. When you want the ragdoll to show up, trigger the ragdoll (or use show() in a script). Alternatively it may also work to set "skin" "invisible" and change that to "visible".

[MirceaKitsune]

I have a more conventional question myself for a change. I'm working with the building modules which are very awesome and helpful. I'm trying to understand how I can use them in ways that play nicely with vis portals and the need to isolate large areas. I want to know to what extent it's considered safe to put a roof model inside a brush block textured with textures/smf/portal_sky in hopes that it will always show properly when seen from below.

The issue is you typically want the brushes of your your buildings to be blocks stretching up to the ceiling, so you can put portal surfaces in between them without any leaks. However the roof model is triangular now square. For this reason I initially went with making the brush a triangle in its shape with the tip edge stretching up to the ceiling, but of course this only lets me draw a portal across the axis where the triangle touches the world roof.

It would be easier to just make the whole building a sky cube, put the module parts on its surface, then stick the roof inside and leave only the front sticking out. This seems to work in practice: If any part of the model is outside of the brush, the entire model appears to be rendered accordingly. But is this a safe practice to rely on? Should you intentionally allow large models to go through brushes like that? Can you officially rely on caulk and portal skies not to mask models that go into them or break their lighting? Here's a mockup screenshot to show what I mean and how I'd want to do it in the future:

[Frost_Salamander]

1 hour ago, MirceaKitsune said:

I have a more conventional question myself for a change. I'm working with the building modules which are very awesome and helpful. I'm trying to understand how I can use them in ways that play nicely with vis portals and the need to isolate large areas. I want to know to what extent it's considered safe to put a roof model inside a brush block textured with textures/smf/portal_sky in hopes that it will always show properly when seen from below.

The issue is you typically want the brushes of your your buildings to be blocks stretching up to the ceiling, so you can put portal surfaces in between them without any leaks. However the roof model is triangular now square. For this reason I initially went with making the brush a triangle in its shape with the tip edge stretching up to the ceiling, but of course this only lets me draw a portal across the axis where the triangle touches the world roof.

It would be easier to just make the whole building a sky cube, put the module parts on its surface, then stick the roof inside and leave only the front sticking out. This seems to work in practice: If any part of the model is outside of the brush, the entire model appears to be rendered accordingly. But is this a safe practice to rely on? Should you intentionally allow large models to go through brushes like that? Can you officially rely on caulk and portal skies not to mask models that go into them or break their lighting? Here's a mockup screenshot to show what I mean and how I'd want to do it in the future:

Yes models (func_statics) can safely be embedded in brushes.  In your case, the brush touching that roof doesn't need to be portal_sky, just use caulk.  You only need to make one surface in the rendered area use portal_sky - the easiest is to just put in on the ceiling.  Most of this is covered here: https://wiki.thedarkmod.com/index.php?title=Caulk

[MirceaKitsune]

16 hours ago, Frost_Salamander said:

Yes models (func_statics) can safely be embedded in brushes.  In your case, the brush touching that roof doesn't need to be portal_sky, just use caulk.  You only need to make one surface in the rendered area use portal_sky - the easiest is to just put in on the ceiling.  Most of this is covered here: https://wiki.thedarkmod.com/index.php?title=Caulk

Thanks. And that's correct: portal_sky may cause cutting and the sky showing through or a black rectangle rendering instead, using caulk seems to be safer and not do that however.

 

[Geep]

On 12/14/2022 at 3:04 PM, cvlw said:

Hello again.

I want to teleport a ragdoll to a point in the air and fall horizontally, face down and to land face down.

I have the ragdoll entity defined to flop face down at map start in a hidden area.  When I trigger the atdm:teleport, the ragdoll is teleported standing up and falls feet first, no guarantee to land face down.

Is there a way to keep the ragdoll "lying face down" at teleport?

Thanks.

Clint

If the player does need to see the ragdoll drop, here's what I might try (no guarantees):

- Put a hidden door in the ceiling and place the prone ragdoll atop it. Arrange to trigger open the door.

- Or use an upward force field to pin the ragdoll to the ceiling. Arrange to trigger the turn-off of the field.

[cvlw]

Thanks for the ideas Dragofer, Geep.

The player is actually tossing the body as mentioned in some prior posts of mine... still working on that vision.  So, the player will likely see it.

I am finding I can do almost entirely what I envision by creating the ragdoll, horizontal and face down, above the "landing" spot and cvar hide=1.   At my controlled moment, I  "target" it to bring it into view, drop it, and teleport out the original body.  Additionally, I have the nodrop=1 on it which gives it a T-pose that looks strikingly natural when landed.

This eliminates the usual random-ish tumble from a tossed body and allows controlling of the process.

So far it seems promising except for differing orientations at the moment of body swap.

So, I think I am getting closer.

Clint

[Dragofer]

Why do you swap the body?

[cvlw]

On 12/16/2022 at 11:48 AM, Dragofer said:

Why do you swap the body?

I am interested in positioning how a body lands.  Maybe have it fall into a box, land on a dais, or become impaled on a spike or fence post.

I have been experimenting with the player tossing a body and controlling how it falls and lands.  The AI entity, when KO/dead, falls and lands in random ways that can't seem to be controlled.  The ragdoll replacement entity looks to be more controllable in that respect.

 

[datiswous]

On 12/16/2022 at 6:44 PM, cvlw said:

The player is actually tossing the body

If the player tosses the body face-up, how can it end up face-down? Especially during the swap it might look unrealistic.

 

Edit:

On 12/16/2022 at 6:44 PM, cvlw said:

So far it seems promising except for differing orientations at the moment of body swap.

Sorry, I didn't read this part. I cannot delete my post.

Edited December 19, 2022 by datiswous

[Geep]

Maybe you could hide the body swap in a momentary puff of smoke, as "dust" kicked up by the hard landing.

That probably wouldn't work if the body gets impaled on landing. Might need an explosion of blood instead... is that FX available? Dunno.

Edited December 19, 2022 by Geep

[cvlw]

6 hours ago, Geep said:

Maybe you could hide the body swap in a momentary puff of smoke

...

I was toying around with my current build and did just that and it is looking great [in my inexperienced opinion!].

The ragdoll is set right above the landing {hide=0, solid=0, frobable=0, nodrop=0}.  The objective location triggers a relay that teleports the boxes out, triggers the crashing sounds, triggers the  mine_cloud.prt particles which nicely hides all the magic in smoky clouds, triggers the ragdoll, and triggers a SEED with wood debris to show.   It looks just like the body falls and smashes the boxes in faux real-time.  Even if the player jumps down with the body, it is all nicely camouflaged.

The ragdoll is not kicked around by aggravated AI like I was dealing with in previous posts.  The SEED is solid=0.  So, none of the final objects are in the way.

This is all turning out nicely and has been a great experience making a fun effect.

I will save the dropping of bodies on spikes for some other entirely wholesome mapping effort.

Clint

 

 

[Frost_Salamander]

I'm getting a lot of this type of thing with visportals in my current WIP.  Is this a known issue, or due to some graphics setting/problem?  This is 2.10 still.

 

[AluminumHaste]

Can't tell what it is

Can you use lower FOV to take the screenshot so it's zoomed in?

[Frost_Salamander]

26 minutes ago, AluminumHaste said:

Can't tell what it is

Can you use lower FOV to take the screenshot so it's zoomed in?

sorry it's hard to notice, they only appear when you are a good distance away and at a certain angle.  It's just little artifacts around the edges of the portal.  At some point over the last few days these started appearing.  Here's another one zoomed in a bit:

 

 

[AluminumHaste]

Sorry if dumb question, if you go into DarkRadiant, select the visportal and snap to grid, does that help?

[Frost_Salamander]

1 hour ago, AluminumHaste said:

Sorry if dumb question, if you go into DarkRadiant, select the visportal and snap to grid, does that help?

nah.  I mean they are all grid-aligned anyways.  Regardless I tried it and it didn't do anything.  I'm hoping this is something to do with my local machine or something.  I guess we'll find out sooner or later.

[Geep]

On 12/19/2022 at 9:56 PM, cvlw said:

... triggers the crashing sounds, ...

You could have the loud sound cause a screen shake, too, to further stir the pot.

[joebarnin]

I have a trigger_multiple, and I want to be notified whenever the player is within it. The trigger_multiple targets an atdm:target_callscriptfunction. I also set wait=1 on the trigger. When the player is within the trigger area, the script gets called once a second. This happens if the player is moving or stationary. So everything is working great.

 

I also want to be notified if any other AI is within the trigger area. So I added the anyTouch=1 spawnarg. Now, when a guard walks into the trigger, the script function gets called. As long as he's moving, it gets called (once a second). But as soon as he stops, the script is no longer called (I assume becase the trigger is no longer firing). This is true if he is just standing there, or is stationary because of a path_wait.

 

Summary: a trigger_multiple will fire each time the player is within the trigger. But a trigger_multiple with anyTouch=1 will only fire for other AIs if the AI is moving. If the AI is stationary, the trigger no longer fires.

 

Intentional, or bug?

[Geep]

I don't really know, but I'd guess it was unintentional, and just the byproduct of some optimization to save CPU cycles when an AI is idle. Maybe that's a good thing sometimes, and a new feature request might be to have some way to indicate whether or not to do firing with an inactive AI?