Newbie DarkRadiant Questions

[Frost_Salamander]

I'm trying to set up something with a func_pendulum.  Totally guessing, and so far I've got:

• created a long, narrow invisible brush and converted to func_pendulum
• bound it to a model
• moved the origin so it swings from the top

All that works, but is it correct, and how do I change the frequency and distance?  All I could find on the the Wiki is this:

"Pendulums always swing north / south on unrotated models. Add an angles field to the model to allow rotation in other directions. Pendulum frequency is a physical constant based on the length of the beam and gravity."

So:

• Do I just make it longer to slow it down? 
• I only want to it swing a very small distance - is it possible to change that?
• the 'angles' field - is that just a spawnarg on the model I've bound, or the func_portal?

[Dragofer]

IIRC the spawnargs for a func_pendulum are freq and speed, though "speed" effectively also acts as the swing angle (because the time period is already determined by freq).

Angles is just a generic spawnarg that describes how an entity is rotated on the horizontal plane.

Btw, the idea with binding a func_pendulum to a rotated model is to change the direction in which it swings. While the idea with binding a model to a func_pendulum, instead of making the model itself a func_pendulum, is to allow the model to swing from a different origin than its own.

[Obsttorte]

Re @peter_spy

1.) is definetely true (as written in my post, maybe I was a bit unclear).

2.) sounds odd. I noticed when working with caulk sky in the past that the sky stopped rendering when there was no visportal textured surface in the currently rendered area (noticeable as the caulked surfaces suddenly turned from skybox to black). There have been adjustments made both to the vp's as to the way portal skies are rendered if I am not mistaken, so maybe something changed along those. Haven't touched DarkRadiand in a while (except for setting up scripts or custom objects, but no real mapping).

Re @Frost_Salamander

The behaviour of a pendulum is depending on one value only. This could be the swing speed at the lowest point, the altitude of the swing or the largest angle. More then one is not possible. freq and speed as suggested by Dragofer to belong to each other, so specifying one should make the other redudant. I don't know which one gets the higher priority, though. Angle is used to change the swing direction.

BTW.: If you want to create a swinging hanging cagelamp or oil lamp binding it to a func_pendulum bound to another func_pendulum swinging into another direction at a different altitude/frequency gives you a nice effect. Just don't use too many of them in a scene as they eat performance.

 

If you want more control over the movement you would need to use a func_mover and script the behaviour. This is only required if you need something very specific.

[peter_spy]

14 hours ago, Obsttorte said:

2.) sounds odd. I noticed when working with caulk sky in the past that the sky stopped rendering when there was no visportal textured surface in the currently rendered area (noticeable as the caulked surfaces suddenly turned from skybox to black). There have been adjustments made both to the vp's as to the way portal skies are rendered if I am not mistaken, so maybe something changed along those. Haven't touched DarkRadiand in a while (except for setting up scripts or custom objects, but no real mapping).

I'm still on 2.08, so maybe that has changed, but:

The portalsky surface is behind the visportal that is closed, but look at the stats.

[Obsttorte]

With "behind the visportal" I guess you mean to the right?! I don't know for sure what "views" is counting, though. I would have to repeat my caulk sky test to see whether something has changed ... and I would need another screenshot from the very same scene but with the visportal on the right open, so I can compare the stats. This way I can only guess what's on.

[peter_spy]

Views is usually set at 3, if you have a regular scene without stuff like mirrors and such. This is the scene with second visportal open:

Now the second visportal is opened and "skybox" is visible. Note that number of views and texture memory used hasn't changed, so it was used by the skybox all along.

[Obsttorte]

@peter_spy I can reproduce your observations. I've taken a look at the code and there is a check for whether a portal skybox needs rendering, so in theory the rendering should be skipped if it is not within the current pvs. Either something is wrong with that code or the statistics console output is wrong or our interpretation of said values.

Disabling portalsky via console reduces the view to 4. However, maybe the view count is just the amount of potential views (like reserved viewports) and not those actually rendered. I see whether I can make the skybox a bit more performance hungry to see whether it gets disabled if out of view or not.

 

EDIT: Visportals indeed seem to not have the desired effect, independent from whether the old or new skybox method is used (according to the console description of g_enablePortalSky). Furthermore, I've placed several ai and tons of light in the skybox, so lots of shadows are casted on the floor of the skybox room. This causes the framerate to drop when I look downwards (at the floor, where there is no skybox material, not even behind walls etc...), whereas the performance improves when looking upwards (at the skybox!!!).

 

Although we rarely have stuff placed at the bottom of the skyboxes I think this is unintentional, and the functions for checking whether rendering of the skybox is needed are broken.

 

On the good side: caulk sky still seems to work.

[peter_spy]

Good thing that most maps run fairly well then, as this went unnoticed for quite some time, I think.

Still, the easy workaround for that would be either using doors or using proximity-triggered visportals. Try to place a func_portal so it touches the visportal for the visleaf where portalsky material is located, then set up dist_check_period and portal_dist values. That should do the trick.

[Obsttorte]

Does anybody know how to compare strings in guis? Or how to find out whether a string is empty? Somehow I neither get it to work nor can I find anything useful on this in the web or the code. The latter implies that it should work, but it doesn't Frustrating.

[Dragofer]

31 minutes ago, Obsttorte said:

Does anybody know how to compare strings in guis? Or how to find out whether a string is empty? Somehow I neither get it to work nor can I find anything useful on this in the web or the code. The latter implies that it should work, but it doesn't Frustrating.

The best I can offer is this expression I used in Down by the Riverside's campaign briefing:

if ("gui::CurrentMission" == 1)

The value for CurrentMission seems to come from player.cpp and Game_local.cpp:

gui->SetStateInt("CurrentMission", missionNum);

SetStateInt is defined in UserInterface.cpp. There one also finds GetStateString and SetStateString.

[Obsttorte]

9 hours ago, Dragofer said:

The best I can offer is this expression I used in Down by the Riverside's campaign briefing

Yeah, but that isn't a string but an integer. From what I can see in the source code strings should be doable, too, and somehow I think I even did that in the past. But either I am mistaken or I use the wrong syntax. However, there is no logical reason why a comparision between strings should not be doable.

[Dragofer]

8 minutes ago, Obsttorte said:

Yeah, but that isn't a string but an integer. From what I can see in the source code strings should be doable, too, and somehow I think I even did that in the past. But either I am mistaken or I use the wrong syntax. However, there is no logical reason why a comparision between strings should not be doable.

Was just to show how the syntax is for an integer, and that the code should also be able to do a string check in that kind of expression, given the string functions neighbouring the int functions in the code.

I've done a search of the .gui files and noticed that there are few expressions where both sides of the equals sign are in double quotation marks:

 

The bottom result seems to check for an empty string, the top results seem to refer to "0" as a string and the music check is probably with strings too. The modes are probably just integers.

[Obsttorte]

These are all integers except the last expression, which is exactly the syntax I am using and it is not working. The difference for the last instance, though, is that $gui::title is a spawnarg.

[Dragofer]

Seems odd that the top results check for "0" instead of 0 like most other integer checks.

Anyway, that's all there is for " == " in the core and FM .gui files. Maybe there's a reason why there's no (non-spawnarg) string-checking in the whole of TDM, such as that it doesn't work.

Or the string syntax is just completely different from what we expect, but that spawnarg string check suggests otherwise.

[Obsttorte]

Nevermind, it is not that important. Thanks anyways.

[HMart]

I saw this in the Doom 3 main menu.

onTime 0 {
	if ( "SGC1Title::text" "!=" "" ) {
		...
	} else {
		...
	}
}

so perhaps if("string" "==" "string")   may work, try it.

Edited February 28, 2021 by HMart

[Obsttorte]

This definetely goes into the right direction. Unfortunately, "==" always returns true and "!=" always returns false, no matter the content of the string. Guess I am still doing something wrong.

Thanks thus far.

[Geep]

FYI. I've added a new section to the Doors wiki article, "Initially Blocking a Door - Partially or Fully", that summarizes the recent discussion here about that.

[grayman]

Why does the “==“ bit have quotes?

[HMart]

9 hours ago, grayman said:

Why does the “==“ bit have quotes?

I really don't know for sure but maybe, because every text in a GUI, including the gui keywords, are seen by the c++ gui parser has strings and making them enclosed in quotes, perhaps helps the gui parser?  For example I've seen in Doom 3 gui's  floats defined has:

float somefloat 0

float "somefloat" "0"
 

both versions work but the bellow one could be "safer" to parse? I really don't know, this does shows that the gui scripting language is not very strict. 

[Geep]

I've been trying without success to get a standing AI to deliver a Conversation Talk with a steady gaze, without moving the head around. My experiments to overlap a Talk with a PlayAnim that points to an anim def with "no_random_headturning" haven't been fruitful.

Tried the "Turn Towards" and "Look at" commands too. Head still shifting.

Ideas?

Edited March 11, 2021 by Geep

[JackFarmer]

3 hours ago, Geep said:

I've been trying without success to get a standing AI to deliver a Conversation Talk with a steady gaze, without moving the head around. My experiments to overlap a Talk with a PlayAnim that points to an anim def with "no_random_headturning" haven't been fruitful.

Tried the "Turn Towards" and "Look at" commands too. Head still shifting.

Ideas?

Something like that:

https://streamable.com/3qndys

If so, then check the setup in Vitalic Fever.

[Geep]

@JackFarmer, if you look at that video closely, you will see the guards heads (and shoulders) are constantly rotating slowly from side to side. That's what I need to stop... or at least keep the eyes pointed in exactly one direction.

The head movement is fine for casual chit-chat, less so for vital high-drama engagement.

[JackFarmer]

11 minutes ago, Geep said:

@JackFarmer, if you look at that video closely, you will see the guards heads (and shoulders) are constantly rotating slowly from side to side. That's what I need to stop... or at least keep the eyes pointed in exactly one direction.

The head movement is fine for casual chit-chat, less so for vital high-drama engagement.

You have two characters in your conversation which shall look each other strictly in the eyes during the conversation?

[Geep]

It's a video cutscene. So the single AI character is looking directly at the player, whose viewpoint is being screen-captured. I can move the player, but not in a fast, fluid way to compensate for AI gaze shifts. And the gaze shifts makes the AI seem "shifty", not the effect I want.

If there's no TDM solution, I'll have to use choppy editing, not ideal.