[Builder Blocks: An item matching in-world minigame]

On 8/7/2021 at 4:57 PM, MirceaKitsune said:

I'm hoping the gui / def / script at least can be included for 2.10, this would be a fun minigame to have available for mappers by default.

It's an interesting idea and impressive that you got it to work, but we're kind of split on this for a couple of reasons:

- as you say, an arcade game is somewhat questionable in a steampunk universe. I can definitely imagine a situation or two where it would seem fitting, such as the recreational area of an Inventor Guild compound, but those are somewhat unique scenarios.

- testing is another matter. It's a technically complex asset, and as you've said it's crashed a few times. I think it'd be best if it featured in an FM first, since you'd have a good amount of players with a variety of PCs and approaches try it out. It should also result in feedback on how a minigame like this can be integrated into stealth gameplay.

[Newbie DarkRadiant Questions]

There's an excess comma at the end of the key name in the "used_by" spawnarg. Maybe that's what tripped up the door script for both keys.

Also, it might be worth making the 2 keys stackable with inv_stackable 1, since they're identical. Might need to change the used_by spawnargs to point to the inv_names in that case.

[hide_distance broken again?]

@peter_spy Nice, and yes I can confirm that an arrow shot ingame into a LOD object stays where it's meant to be. Looks like this is an issue that happens at map start on LOD objects that start hidden.

[Fan Mission: One Step Too Far, by Dragofer (2014/08/04)]

I've been playing with the thought of finally providing a much needed sequel for this mission and realised that this mission, being my first and released 7 years ago, can be rough around the edges. So I've now brought this mission into a more sequel-worthy state with these changes:

• enhancements to visuals to make the mission look better all around
• new readables to build out the storytelling, both on the ship and the landing area
• some voiced lines have been contributed by Narrator and Goldwell to help set the mood
• collision has been overhauled throughout the ship, so that it's much less likely to get stuck
• more space in the captain's area for AIs and stealth, as well as a generally cleaner pathing implementation
• the main cutscene has been shortened and better lit, while all other fades to black have been cut
• a new loading screen by the painter Ivan Aivazovsky, to replace the slightly bland TDM-made arctic scene
• the option to set LOD Detail in the graphics settings if maximum performance is needed when outdoors
• myriad other tweaks, such as smooth fading out for triggered ambient sounds and some gimmicks around clocks and compasses aboard the ship

Quite a bit has been touched, so it'd be appreciated if one or two people could give this a try on the betatesting forums and post back if there's something that seemed odd, before I upload the new version to the official mirrors.

The mission's length is still the same, since these changes already took longer than expected. My plan is to focus fully on my two WIP missions from here onwards, then ideally return to One Step Too Far with a small sequel (as suggested by Amadeus it could be called Two Steps Too Far).

[hide_distance broken again?]

5 hours ago, kingsal said:

That shouldn't be happening. Out of curiosity does the model or its LOD  have a collision mesh? This won't happen to moveables  AFIK since their collisions meshes are kept. 

This was just some plain func_static wooden beams made out of patches, with a 'stuck' version of a broadhead arrow lodged in one of them. Only the beams had any kind of LOD, hide_distance, enabled.

Stuck arrows probably shouldn't be moveables anyway.

[Playertools:holywater -- how to apply that entitydef to custom model?]

You could just create a holy water potion in your map and change its "model" spawnarg to your custom model. The more sophisticated way would be to create a new entityDef that inherits from the original potion entity but specifies a different model. Either of those are how customisations like yours are usually done.

Note that if the model should be for a moveable like a potion, then it needs a collision mesh. This is a very simplistic shape that can be part of the model - you could look at the existing holywater's collision mesh to see how it's done.

[Colored flame lights]

1 hour ago, MirceaKitsune said:

Only part I may disagree on is that someone forgetting the _color spawnarg on a torch should keep us from properly implementing this:

It's basically the policy of the team with regards to making changes to assets used in existing missions. You may argue that the likelihood of a negative effect may not be too high or too severe, but if one adopts this approach, then over the years the integrity of released missions would gradually degrade. In this case you'd have areas that may not be lit like the author intended since he never had a chance to look at what the lights are like with the _color spawnargs in action, which has visual + gameplay consequences. In the worst case the colours may be completely wrong.

1 hour ago, MirceaKitsune said:

As for brightness, isn't it possible to adjust it from the color? So if you want a blue light that's as bright as possible that's "_color 0 0.5 1" but if you want half the brightness you can set that to "_color 0 0.25 0.5" instead. I love the appearance in that screenshot still, that feels very right and pleasant to me!

Yes, but if you want to use 1 spawnarg for both the flame and the light, then the light would become too dim. Colourable particles need to be calibrated so that they look right at a normal light intensity.

1 hour ago, MirceaKitsune said:

What if we simply don't enable that on the default light entities but configure them so they're compatible with it?

The problem is that a light fixture consists not just of the entity defs, but also materials, models, particles and skins. Changing them, i.e. by making particle and glow maps black & white, has a high chance of breaking custom light fixtures that relied on the original version of some of those assets, i.e. by causing them to appear bright white because the mapper didn't foresee a need to apply a matching _color spawnarg. This can be avoided by creating separate versions of those assets.

[(POLL) Normalised texel-scale when applying new textures?]

For me the problem is mainly that when drawing new brushes, the apparent scale of the texture is heavily influenced by the image resolution. To show this, I've shown in the screen below how large a newly drawn brush needs to be to accommodate 1 tile of 2 different textures when I have "Default Scale" set to 0.500 in the Surface Inspector:

The texture on the left is 1024x512 pixels (textures/darkmod/plaster/plaster_leaking), on the right is 2048x1024 pixels (textures/darkmod/sliptip/plaster/plaster_old_stained).

I think both textures should be treated the same regardless of image resolution. Basically I think what I want is a setting that 1 image tile = 128 units, which would result in always drawing wall brushes like on the left. Such a setting could be problematic, however, if

• the texture is designed for very small objects, such as a piece of paper, which should certainly not be 128 units tall. But the current implementation also gets this completely wrong.
• the texture isn't a square. With these wall textures it's obvious we want them to be 256x128 units, but what if it's a very long, slim piece of wall trim? That should ideally be something like 128x16 units, not 1024x128 units. Can't really see a way to distinguish between such textures.

 

Generally the problem seems to be only when drawing new brushes. If I replace the texture of the left brush with that of the right brush by right-clicking the material in the Media browser > "Apply to selection" (not with the MMB), then it's a 1:1 replacement that looks correctly scaled.

[Colored flame lights]

11 hours ago, MirceaKitsune said:

Once the change you mentioned is ready, setting the color on a torch will automatically colorize its light, correct?

Indeed, this new segment in ::init of the tdm_light_holder scriptobject applies the _color of the parent entity to everything bound to it, if the spawnarg "propagate_color" is set to "1":

    if ( getKey("propagate_color") == "1" )
    {
        vector col = getVectorKey("_color");
    
        for (ind = 0; ind < numBindChildren(); ind++)
        {
            child = getBindChild(ind);
            if( child )
            {
                child.setColor(col_x, col_y, col_z);
                child.setKey("_color",col);
            }
        }
    }

I would only apply this script to new entities with the propagate_color spawnarg, and only make the new entities recolourable, for a number of reasons:

1. There are bound to be a lot of light holders across TDM's missions that have leftover _color spawnargs from when the mapper was trying to work out how to recolour the def_attached lights. If this starts to take effect, it may unpredictably change how those missions look or play.
2. The _color spawnarg isn't fully as realistic as having a pre-coloured particle image, in part because of the additive effect. You can see here how at default particle settings, this blue-coloured flame is incredibly bright. Recolourable particles will therefore need fewer than the default 12 cards to still look reasonably realistic. From a visual perspective it'd be ideal if we had one duplication of our light entities per pre-set colour, but this would be extremely cluttered. I think we can justify 2 sets of entities: standard flames and recolourable flames.

Generally we're quite stringent about avoiding changes to existing assets that could alter or break released missions, preferring to create new entities. Being able to recolour any standard light with a single spawnarg would be great, rather than using a separate set of entities, but it'd have far-reaching effects for TDM's missions.

[Newbie DarkRadiant Questions]

19 minutes ago, Geep said:

Could someone point me to the sound shader and/or ogg file that has the sound of a fly circling over a chamberpot? I know I've seen this in FMs in the past, but can't seem find it.

I've got such a speaker underneath the northwestern external stairs on the ship in Perilous Refuge - can't checl that myself atm.

[hide_distance broken again?]

Seems odd that a visual performance optimisation makes the entities become nonsolid. I've got an arrow stuck in some LOD-enabled wooden beams and when the player is over 1500 units away the arrow drops to the floor. The same could happen to i.e. a readable resting on a LOD-enabled crate, causing the readable to go unnoticed.

Surely we'd want LOD to use a hide method that doesn't switch off solidity?

[hide_distance broken again?]

20 hours ago, peter_spy said:

That's a good practical example you can analyze. If it isn't too much to ask, you can try taking stats screnshots from the same spot and camera angle with:

1) both light and objects visible

2) light entity hidden and objects visible

3) light visible and objects hidden

4) all hidden

The biggest stat difference will be between 1 and 4 obviously, but you should observe much bigger performance gain between 1 and 3, than from 1 and 2 or 3 and 4.

My results are as follows, with "objects" being 2 packages, 1 crate, 1 tub, all set to noshadows at this distance. The light itself is shadowcasting, since as far as I'm aware there's no noshadows_lod for lights:

[drawcalls, tris, shadowtris, VBO]
1) objects + light
	1346 	252195	28600	223559
2) objects
	1329	249083	28398	220649
3) light
	1321	248285	28600	219649
4) -
	1309	245915	28398	217481

Fps: always 60 (didn't uncap)

So the single light causes 12-17 drawcalls, while the group of 4 objects causes 20-25 drawcalls, depending on the extent of light interactions. A small difference in any case when it comes to LOD, but every bit counts, and this almost invisible light is ca. 1% of the drawcalls in that scene.

[hide_distance broken again?]

1 hour ago, peter_spy said:

And in your example, you could simply hide stuff these lanterns light

I hide most of the stuff up there already, but I do still want the lanterns themselves to be visible from a distance, since their purpose is to eventually attract the player's attention to this part of the map, despite their small size, thanks to their surfaces' high luminosity and their swinging motion. (They're quite far away - and .jpg compression makes this worse - because of how huge the geography is, but that's a misjudged scale problem common in first missions). As you can see the illumination itself is almost invisible.

The cost of the light is probably very small, but probably no less than that of the crates and packages on that platform. If, as duzenko's earlier post suggests, hide_distance for lights is pretty much implemented already, it can just as well be used.

[hide_distance broken again?]

I've got some lanterns near the top of a mountain in a large outdoor scene. When you look up at them from the foot of the mountain it's almost impossible to see what they light up, given their surroundings. With the way how the mountain path is made, you have to get quite close before you can properly see what these lanterns illuminate. For this scene an option to switch off those lights beyond x distance could be used.

Yeah, hide_distance for lights has strict limitations because in most cases the switch is glaringly obvious, but it's still a tool in the toolbox that has situations where it's suitable. Another such situation could be lights inside an apartment that has an open window to the streets, where you know it's not possible to get a clear view inside from further than x units.

@peter_spyWith modern workflows, you probably mean an alternative implementation of the LOD system compared to what TDM has?

[Convert normal maps to RGTC?]

15 hours ago, nbohr1more said:

Can you try the latest SVN? Orbweaver commited a fixed BC5 loader

I can now confirm that on my Intel UHD machine, the BC5 normalmap shows up ingame and without artefacts. And the "bindless handle" console error no longer shows up.

My cvars are r_useBindlessTextures 1 and image_useNormalCompression 1.

[Colored flame lights]

We've just talked about adding these coloured lights: we'd probably add a set of colorme lights that allow the mapper to easily set their desired hue, saturation and intensity.

For one, this is because it became clear everyone has their own opinion of what these settings should be. For the other, this minimises the number of entity duplications in the Lights folder compared to having multiple preset colours for each light.

Kingsal offered to pick up this .pk4 and look into making it become core-ready in accordance with these specifications.

Btw, is it intentional you've also recoloured the deprecated entities? Those should probably not be shown anymore in DR by default.

[So, what are you working on right now?]

@kin
NHAT v4 is in the beta testing forums right now, so it should be fairly soon. Could maybe do with another tester there, though.

[Default grass particles ignore lighting and appear fully bright]

Looks like it uses the .tga image directly, without putting it in a material. You can simply create a material for your FM by copy-pasting an existing decal material and changing its paths. It would actually be quite helpful, because then a team member can transfer your fix to the core asset base.

The bugtracker is definitely the best way of tracking asset issues like this.

[Assets with invalid data]

@MirceaKitsune
There's quite a few tickets that list a number of asset issues and get expanded upon as their author finds more - no need to have 1 issue per ticket in such a case.

[Assets with invalid data]

Stuff like this really needs to be tracked in the bugtracker.

[Ability to select all entities with the same model]

1 hour ago, MirceaKitsune said:

I need to do this right now

An immediate band-aid would be to create a filter that looks for that model and use the right-click menu to "Select by filter". I have a "search" filter that I edit whenever I need to look for a specific thing.

Maybe a search mask would be the most flexible solution. Get prompted with a dialogue for "spawnarg" and "value" and it selects all entities that match this.

[Convert normal maps to RGTC?]

On 7/27/2021 at 10:05 PM, nbohr1more said:

WOO!!!

@Dragofer can you test BC5 normal maps again?

I've:

• Updated my SVN for assets and source code, compiled the latest source code
• Removed the normalmap from my SVN install for one of those textures
• Exported that normalmap as a BC5 .dds with mipmaps in GIMP
• Placed that .dds normalmap in the corresponding dds/ folder
• Loaded OGDA's demomap

The console tells me that TDM failed to get a bindless texture handle on that normalmap There's no normalmap effect visible ingame.

[Newbie DarkRadiant Questions]

@joebarnin
Maybe you can spawn a new rope at the same location and rotation? Possibly a stuck rope arrow and/or the rope arrow result entity. Otherwise it'd have to be that the script waits for the player to get off the rope.

For fixing this, it should be possible to either expose the detach functions to scripting or call them from teleportation functions.

@MirceaKitsune
The only thing I can suggest is to look at all the spawnargs, I have no experience making animals that are like humans. Search cooldown timers for a fact have a lot of spawnargs governing them. And maybe you need to set some kind of rank so other AIs know what to greet them as.

[Newbie DarkRadiant Questions]

@joebarnin I think you'll need to clear immobilisation flags from the player - MirceaKitsune's recent arcade machine posted to the Art Assets thread has a script that works with these flags.

scriptEvent void setImmobilization(string source, float type);

    Used to set immobilization from a source. Warning: Not a finalized version. It's subject to change, so use it at your own risk.)

    Spawnclasses responding to this event: idPlayer

Btw, this is how the player is detached from a ladder in the engine (Physics_Player.cpp):

Spoiler

/*
============
idPhysics_Player::ClimbDetach
============
*/
void idPhysics_Player::ClimbDetach( bool bStepUp ) 
{
	m_bOnClimb = false;
	m_ClimbingOnEnt = NULL;
	m_bClimbDetachThisFrame = true;

	static_cast<idPlayer *>(self)->SetImmobilization("ClimbMove", 0);

	current.velocity += m_RefEntVelocity;

	// switch movement modes to the appropriate one
	if( bStepUp )
	{
		// Step up at the top of a ladder
		idVec3 ClimbNormXY = m_vClimbNormal - (gravityNormal * m_vClimbNormal) * gravityNormal;
		ClimbNormXY.Normalize();
		current.velocity += -ClimbNormXY * LADDER_TOPVELOCITY;
		idPhysics_Player::SlideMove( false, true, false, true );
	}
	else if ( waterLevel > WATERLEVEL_FEET ) 
	{
		WaterMove();
	}
	else 
	{
		AirMove();
	}

	SetNextAttachTime(gameLocal.time + cv_tdm_reattach_delay.GetFloat());

}

 

Yeah I think it's a bug that teleportation doesn't automatically do this. It could be worth a ticket.

[Builder Blocks: An item matching in-world minigame]

@MirceaKitsune
To me the 2 GUIs look the same - same format, and both just a tad too short. Can't you just increase the vertical size of that GUI window?

Debugging crashes is worlds easier when you can build yourself a debug build, showing which entity and which function was the problem. It's pretty easy to install, pretty easy to compile a new build (open the code in Microsoft Visual Studio, select "Debug with Inlines" from a dropdown list and press F7) and would probably have a high payoff for someone scripting as much as you do:

TDM Compilation Guide