Newbie DarkRadiant Questions

[Frost_Salamander]

11 minutes ago, joebarnin said:

I've seen a technique for doing this, in The Painter's Wife. I borrowed the code myself for a WIP. The technique is basically to override the  multistateposition object (defined in tdm_movers.script) and implement the onMultiStateMoverLeave method, which stops the elevator before it gets going, tries to close the door(s), and then starts up the elevator again. The code is something like this:

void multistateposition::onMultiStateMoverLeaveEffector(entity mover)
{
	door.setFrobable(0);

	if (door.IsOpen())
	{
		door.Close();
		tdm_elevator elev;
		elev=mover;
		sys.waitFrame();
		elev.stopMoving();

		while(door.IsOpen()) 		//wait for door to close
		{
			sys.waitFrame();
		}

		elev.activate(elev.lastTriggeredBy);	//once door has closed, set the elevator in motion once more
		door.Lock();
	}

	else
	{
		door.Lock();
	}
}

Take a look at that FM to see how it's done.

ah nice - I've already overridden that script object for a different purpose (but for the arrive event). Thanks!

[cvlw]

Hello TDM crew.

I am wondering how to address the situation JackFarmer noted here:

JackFarmer question on particle dripping through brush

I wish to have a simple drip particle.  However the drips fall through brushes and modules.  I am not {yet} ready to edit particles.

Is there any way to stop particles with a brush or such?

Thanks

Clint

 

[datiswous]

Hi, ultra newbie question here:

If I make a visportal and I stick it in an opening in a wall, but the direct surroundings, which touch the visportal are an entity, does this work for sealing? Or does the visportal have to be set toward a brush to work?

And I guess for patches the same?

[Frost_Salamander]

4 minutes ago, datiswous said:

Hi, ultra newbie question here:

If I make a visportal and I stick it in an opening in a wall, but the direct surroundings, which touch the visportal are an entity, does this work for sealing? Or does the visportal have to be set toward a brush to work?

And I guess for patches the same?

The face of the visportal with the 'Vis Portal' texture must be touching a brush on all sides.  Entities and patches don't seal.

[Geep]

@Frost_Salamander got the main facts about visportals exactly right, but of course there is more to know, particularly about debugging them. If need be, see https://wiki.thedarkmod.com/index.php?title=Visportals

[JackFarmer]

On 10/31/2022 at 5:24 AM, cvlw said:

Hello TDM crew.

I am wondering how to address the situation JackFarmer noted here:

JackFarmer question on particle dripping through brush

I wish to have a simple drip particle.  However the drips fall through brushes and modules.  I am not {yet} ready to edit particles.

Is there any way to stop particles with a brush or such?

Thanks

Clint

 

If my recollection is correct, then @Dragoferhinted that it probably could be done with some sort of periodical checking of the distance between the droplet and the brush; a non-trivial scripting task for a newbie I suppose.

It surely is way easier to learn particle editing. If you need help on how to do it, just ask here.

[Dragofer]

The easiest way is to make a custom particle that has a much shorter lifespan so it stops before passing through the brush (requires trial and error with the duration setting in the particle editor). You can use the console command reloaddecls to quickly reload a particle ingame after a change in the DR particle editor.

The other way is more complex to setup and only really needed if you want to make a rainy map. You need a custom version of the particle with specific keywords and settings and then compile your map in a special way that generates 2D textures representing your mission, like for this ship stern section:

The textures are colour-coded to represent how high the obstacles are, and automatically sets the lifespan of particles above it to stop just before hitting that obstacle.

https://wiki.thedarkmod.com/index.php?title=Particle_collisions_and_cutoff

[cvlw]

Ah, thanks JackFarmer, Dragofer.  I will get to particle customizations, as they say... "soon!"

Very much appreciated.

Clint

 

[cvlw]

Hello again.

When I use r_showprimitives 1 and con_noprint 0 the values show on the game screen.  However, they quite often print so fast that they blur together and I cant tell what the values are.

I have tried messing with con_speed and con_notifytime values to no effect.

Is there a way to somehow slow down the text printing from these commands?

Thanks

Clint

[Frost_Salamander]

Does anyone know what this means (from DMAP output):

EarCutter: no more ears after 6/8 iterations (zone 162.592 x 7.939)  

Is it bad?  It's not a warning, just informational it seems.  I have a feeling it's something to do with some irregular worldspawn shapes, which I have but try to minimise.  Also is there a way to track down what that 'zone' is?

[JackFarmer]

On 11/4/2022 at 11:24 PM, cvlw said:

Ah, thanks JackFarmer, Dragofer.  I will get to particle customizations, as they say... "soon!"

Very much appreciated.

Clint

 

If you take a screenshot (F12),  you should get a still looking like this:

 

[datiswous]

How do I make ai nonsolid? Setting solid: 0 in DR doesn't work

Edited November 23, 2022 by datiswous

[JackFarmer]

On 11/22/2022 at 1:30 PM, datiswous said:

How do I make ai nonsolid? Setting solid: 0 in DR doesn't work

I am not sure that's possible at all. @Dragofer?

[Dragofer]

You can give them a skin with nonsolid materials, which makes arrows go through them but I think they'll still be solid to the player himself. I recall experimenting to try to achieve a completely nonsolid AI but without success. There are also dedicated script functions for solidity of AIs and moveables (becomeNonSolid() and becomeSolid()), not sure if I tried them myself. For 2.10 I also added a new script function setSolid(float solidity).

[datiswous]

Ah ok that's a shame. I was trying to create an x-ray screen which makes an ai visible, but which is not visible and nonsolid when you walk around the screen. I also had an issue with the head not becoming fully invisible, but that's something else.

[MirceaKitsune]

What is the correct way to make an AI that starts sleeping on a chair? I enabled both "sitting" and "sleeping" on the entity, but that only causes the character to be sitting without also being asleep.

[Frost_Salamander]

2 minutes ago, MirceaKitsune said:

What is the correct way to make an AI that starts sleeping on a chair? I enabled both "sitting" and "sleeping" on the entity, but that only causes the character to be sitting without also being asleep.

See here (v2.06 or later version): https://wiki.thedarkmod.com/index.php?title=Sleeping_AI#Sleeping_While_Sitting

There are a couple of methods there - note the 'NOTE' at the bottom regarding the behaviour if the AI wakes up - because of that I would recommend the path nodes option.

[MirceaKitsune]

10 hours ago, Frost_Salamander said:

See here (v2.06 or later version): https://wiki.thedarkmod.com/index.php?title=Sleeping_AI#Sleeping_While_Sitting

There are a couple of methods there - note the 'NOTE' at the bottom regarding the behaviour if the AI wakes up - because of that I would recommend the path nodes option.

Thanks. My mistake was setting both sitting and sleeping, only sleeping must be turned on... then of course "sleep_location 2" also has to be set. No paths needed this way if you don't want the AI to wake up at times.

Stuck on another one now: How do you make a walking AI occasionally sit at a desk and write? I've seen it done in several FM's but never had to do it till now.

Edited November 27, 2022 by MirceaKitsune

[Dragofer]

7 hours ago, MirceaKitsune said:

No paths needed this way if you don't want the AI to wake up at times.

I think the problem is more that if the AI gets alerted and woken by a loud noise they won't know how to get back to the bed if there are no paths.

 

For a writing AI: you can find a working path setup in the starting area of WS1: In the North.

[MirceaKitsune]

10 hours ago, Dragofer said:

I think the problem is more that if the AI gets alerted and woken by a loud noise they won't know how to get back to the bed if there are no paths.

 

For a writing AI: you can find a working path setup in the starting area of WS1: In the North.

Managed to solve part of the problem but not quite. Even the AI Sitting Behavior doc doesn't quite explain it it.

The problem is if the AI sits at an angle. For instance you set "sit_down_angle 90" on your path_sit: The AI spins in place after sitting, but if you trigger a path_wait or path_anim after that, he instantly spins back before playing the animation. Apparently path_sit treats any path following it as the AI having finished sitting, the angle only sticks if you set "wait" and "wait_max" directly on the path_sit.... if you do that however you can't have your custom idle animation.

Does path_sit allow you to override the anim directly? As a workaround which will work as intended, you can set a couple of spawnargs on the AI itself, exemplified by the beggar prefab... problem then is the AI will play the page turning animation wherever it sits rather than just at the desk, I don't have him sitting elsewhere but this still feels wrong.

idle_animations_interval 2555
idle_animations_sitting idle_sit_turnpage
replace_anim_idle_sit idle_sit_turnpage

 

Edited November 27, 2022 by MirceaKitsune

[Dragofer]

1 hour ago, MirceaKitsune said:

The problem is if the AI sits at an angle. For instance you set "sit_down_angle 90" on your path_sit: The AI spins in place after sitting, but if you trigger a path_wait or path_anim after that, he instantly spins back before playing the animation.

The issue is probably that the "angle" spawnarg of the path_wait/path_anim doesn't match the "sit_down_angle" spawnarg of the path_sit. In that case the AI will spin towards the new angle.

[MirceaKitsune]

1 hour ago, Dragofer said:

The issue is probably that the "angle" spawnarg of the path_wait/path_anim doesn't match the "sit_down_angle" spawnarg of the path_sit. In that case the AI will spin towards the new angle.

That's necessary, I want the spinning in this case: The AI sits on a chair in front of a desk, they can't normally walk in between them so it needs to sit from the right side of the chair then rotate in place. The issue is that the AI doesn't spin back when standing up, but does so when playing the book flip animation which is too early.

[cvlw]

Hello TDMers.

This is, hopefully. a quick TDM mapping "fundamentals" question.  I apologize if this has been asked in the past.  I wasn't finding this searching the forum.

Consider a mapping task that can be achieved either in scripting or with DR objects:

Is there any benefit to one over the other such as performance?  Does it matter if the end result is a map that works?

As I venture forth in mapping, I am often overwhelmed by the objects in DR.  Scripting seems to get me what I envision faster.  The script concepts feel easier to search for on the wiki, too.

I hope to do things right and avoid painting myself into a corner by doing things wrong.

I appreciate the advice/opinions.

Clint

 

[Frost_Salamander]

3 hours ago, cvlw said:

Hello TDMers.

This is, hopefully. a quick TDM mapping "fundamentals" question.  I apologize if this has been asked in the past.  I wasn't finding this searching the forum.

Consider a mapping task that can be achieved either in scripting or with DR objects:

Is there any benefit to one over the other such as performance?  Does it matter if the end result is a map that works?

As I venture forth in mapping, I am often overwhelmed by the objects in DR.  Scripting seems to get me what I envision faster.  The script concepts feel easier to search for on the wiki, too.

I hope to do things right and avoid painting myself into a corner by doing things wrong.

I appreciate the advice/opinions.

Clint

 

My advice would be to use the 'objects' if you can achieve what you want with those.  Reasons being:

• you're not reinventing the wheel
• saves time
• they've been tested
• I don't know about the performance part, but I would assume performance was something that was considered when they were designed/implemented.

Having said that, they obviously don't cover every situation so in those cases script away.   I gravitate towards scripting as well because I used to be a programmer (and still sort of am to some extent).  I've also used them when the native TDM stuff doesn't quite work as expected (bugs, poor documentation or just me being dumb).  But a couple of times I've realised that I can do what I want without scripts and have reverted to using native TDM objects instead.  Also, if the scripts get complicated, they require a lot of testing which you may or may not feel like doing.

So in summary, my approach is to use the native tools first and keep the scripts in your back pocket for when they are really needed.

[HMart]

To add to frost_salamander reply about performance, game objects/entities, created by native c++ code and used in editor, through the entity definitions func_* whatever, imo should be faster than a custom pure script based object, for the simple reason that like I mentioned, they are made/call directly from a c++ based class, and c++ is objectively faster than DoomScript.