[Beta testing 2.11]

2 hours ago, Araneidae said:

Blast it, thought we'd fixed this!  I'm quite high up and some distance from the guard.

It looks like another stealth score bug. What I've fixed so far was:

- fully alerted civilians not adding to stealth score because the m_ignorePlayer flag is never cleared for non-combatants

- seenTime is not increased for AIs chasing the player in full darkness because they literally can't see the player, they're only using the tactile sense

Your new case is notable for the vertical difference between you and the AI, and the fact that -if I interpret what you wrote right - the AI never fully detects the player, even after the score is wiped.

Did you expect the AI to fully detect you in that position? Do you have getViewPos (console command) coordinates for that location?

[Noisemaker arrows and AI Hearing]

I also find broadheads and thrown moveables quite impotent for distracting AIs - unless they go right past the AI's heads the response isn't much more than a "huh", on "challenging" hearing. They sure made a racket in Thief.

[Newbie DarkRadiant Questions]

I vaguely remember a spawnarg in the func_animate entityDef that might be useful. Otherwise an approach is to copy the idle .md5animation and replace its 1 frame (joint origins and angles) with the desired frame from the desired anim. You'll need to add that anim to the model's modelDef (or just overwrite an existing .md5animation).

[Newbie DarkRadiant Questions]

1 hour ago, joebarnin said:

Intentional, or bug?

This is a bug that was fixed in 2.11.

[Abandoned Works]

I've added my old 2015-2016 WIP Of Brambles and Thorns to the abandoned repo. It's a large mansion mission set in the woods, suitable for a spooky or detective story, a faithful recreation of the real-life luxury hotel "Halcyon Hall"/posh girls' school "Bennett College", at least with regards to the exterior. You can find lots of historic material on the internet and drone-recorded videos of the whole exterior on Youtube.

Architecture is mostly done and some sparse interiors exist. There used to be more interiors, but they were lost during an incorrect backup overwrite - screenshots of some of those interiors can be found in #2 to #10 of this album and in the .pk4's screenshot folder (which is the reason why I personally have little motivation to recreate them, rather than working on my new & original WIPs). There are also some old versions of my custom assets - would be better to switch to the improved versions available in core assets.

This FM would be suggested for someone with intermediate mapping experience due to its large size.

[[2.11] OBJ model format]

I've opened a ticket to ask for .obj model render support to be added to DR so this can catch on better. Support for a universal model format is very significant when obtaining models from online repositories.

On 10/23/2022 at 8:39 PM, stgatilov said:

Should we support referencing part of OBJ file as model in TDM map? Is it common to export several LODs into one OBJ?

I'm not sure - the ideal would be if models automatically switched to LOD versions if any are available, and if the stages are in the same file this would be easier to achieve. But I think it's still going to require entityDefs with hand-calibrated distance values.

Could still be convenient, the same way how having the shadowmesh and collisionmesh in the same model file is more convenient than having a _cm file somewhere nearby.

[Tools and plugins for modeling & animating]

I've recently searched the internet with the aim of finding importers and exporters for all model formats used by TDM, both for older and newer versions of Blender and any other common modelling apps. Here's the result:

As a precaution I've made a backup of these importers and exporters on TDM's FTP server in case these links go dead. I won't provide download links to them here so we don't compete with the authors' links, but if at some point in the future someone isn't able to model something for TDM because the right import/export scripts don't exist anymore they can contact a team member. If the original authors want their work removed from this backup they can post here, send a PM to a team member or write an email to the address found at the bottom of this page: https://www.thedarkmod.com/team/

ASE

• Blender 2.80+: Orbweaver and chedap's importers and exporters for ASE & LWO, should be regularly updated (ASE importer only imports geometry, no materials or UVs) Link
• Blender 2.79b: Orbweaver and chedap's exporters for ASE & LWO Link
• Blender 2.79b: JediAcademy importers and exporters for ASE & MD3: Link
• Blender 2.76b: JediAcademy importers and exporters for ASE & MD3: unknown
• Blender 2.76b: Motorsep's updated importer for ASE (download link access has been restricted): Link

LWO

• Blender 2.80+: Orbweaver's importers and exporters for ASE & LWO, should be regularly updated (2.79b scripts no longer available): Link
• Blender 2.80+: douglaskastle's importer for LWO: Link
• Blender 2.79b: ken9's importer for LWO: can't find the link anymore, used to be on Blenderartists.org

MD5

• Maya: idTech and greebo importers for MD5: Link
• 3DSMax: Berserker importer and exporter for MD5: Link
• Blender 2.80: KozGit importers and exporters for MD5: Link
• Blender 2.79b: Nemyax importers and exporters for MD5, made for 2.66 and still works for 2.79b: Link
• Blender 2.72: RPGista's guide for MD5: Link
• Blender 2.66: Sotha's guide for MD5 (access to the link for Arcturus' rig has been restricted): Link

MD3

• Blender 2.79b: JediAcademy importers and exporters for ASE & MD3: Link

[2022 "Horror for Christmas" Contest]

2 hours ago, nbohr1more said:

Because no entrants made it this year, all eligible FM authors will be visited by the ghosts of darkmod past, present, and future.

The spookiest outcome of all!

Not if they can use TDM 2.11 dev work as an excuse and never formally announced their participation...

[2022 "Horror for Christmas" Contest]

That's easy, just ask a bunch of devs to upload their test maps and work from there.

9 hours ago, datiswous said:

I personally haven't started because of a lack of clear idea of a story and location (I have some rough ideas).

I actually had an idea for a contest where the community submits mission ideas and the best ones get distributed randomly among the contest participants.

[2022 "Horror for Christmas" Contest]

4 hours ago, Daft Mugi said:

I don't know. That mission with the lady stuck in a large wooden box with a single light and a thief to test how her scare factor ranks is quite horrific.

Not really, I think it was horrific for the AI more than anything else. Well, maybe a small segment of the playerbase enjoys spooking our AIs.

[Any way to toggle creep? Instead of holding down Ctrl?]

That should already be possible to enable in the settings, i.e. under "movement".

[Beta testing 2.11]

Alright, looks like this fixes it: clearing ignorePlayer when the AI enters the fleeing state:

[Beta testing 2.11]

Thanks - looks like if you alert civilians anything less than suddenly they get into a pre-combat state for one frame where the ignorePlayer flag gets enabled, so my check for the "fleeing" state comes too late. It should be solvable by instead checking whether the AI is at all capable of fighting.

[Augmented Reality on Dark mod?]

Any first post advertising a link is highly suspicious.

[Beta testing 2.11]

Any success with testing the stealth score fixes? I believe @Daft Mugiand @Araneidaewere interested in testing them.

[Beta testing 2.11]

23 hours ago, datiswous said:

Where is this for?

Btw. there is an ambiant world light prefab and an atdm:ambient_world entity. Do these have different use cases?

There is a mapper_tools prefab folder that contains prefabs meant to make it easy to start a new mission or test map. The ambient_world light included in those prefabs was relatively small and I often ended up resizing it massively.

[Peek through (almost) every door]

The dimensions shouldnt contain a component that's 0 for a 3D object. The mistake is probably how dimensions is calculated: shouldn't do maxs + mins, but maxs - mins.

[Peek through (almost) every door]

1 hour ago, snatcher said:

the flame gets placed in the exact same pos no matter where I look the door from

This is expected, the peek begins from the door center and goes outwards 90° from the door surface. The player view angles are only used to determine whether the peek goes forwards or backwards ("flipped").

1 hour ago, snatcher said:

peekVector and playerViewVector almost the same? No: (1, -0, -0) vs (-0.01, -1, 0)

So this suggests there's a problem with how either peekVector and/or playerViewVector get calculated. playerViewVector is much simpler and uses premade functions, so it's more likely the peekVector is at fault.

You'll need to place debug lines to check the variables that are involved in its calculation, starting with "dimensions". Every time a variable gets changed you need to print its new value.

[Peek through (almost) every door]

1 hour ago, snatcher said:

	sys.println("normalized peekVector: " + peekVector);
	sys.println("normalized playerViewVector: " + playerViewVector);
	sys.println("normalized delta: " + delta);
	sys.println("magnitude of delta: " + magnitude);

Yeah, I wrote these debug lines so that the script tells you what it's calculating. Please read the console output to check that the values are as expected:

2 hours ago, Dragofer said:

If you look into the direction you'd expect the peek to go, is:

1) peekVector and playerViewVector almost the same?

2) delta and magnitude of delta almost 0?

3) peekVector doesn't get flipped?

Repeat with various other player view directions.

[Peek through (almost) every door]

19 minutes ago, snatcher said:

Aren't we missing somewhere in peekVector the current angle of the door? Vector dimensions is always the same therefore the starting values of peekVector are always the same (for a same door).

Yeah, it looks like that line was deleted. It should be rotated before it gets normalized.

In any case, the script isnt done yet. So far you know the center of the door and the direction you need to peek into. At this point it'd be wise to check the console output of the debug lines (sys.println...) to make sure the script is doing what you expect it to before adding more to the script. If you look into the direction you'd expect the peek to go, is:

1) peekVector and playerViewVector almost the same?

2) delta and magnitude of delta almost 0?

3) peekVector doesn't get flipped?

Repeat with various other player view directions.

Regarding the current end of the script, you can't use angToForward on peekVector because it's already a vector, not angles. You'll have to multiply the peekVector by half the door thickness (smallest component of "dimension") and add that to the door center so that the peekOrigin is on the surface of the door, not inside. Then you need to convert the peekVector to peekAngles and make $player1 look in that direction during the peek.

Note that in DoomScript vectors and angles are both treated as "vector" variables.

[Peek through (almost) every door]

1 hour ago, snatcher said:

Are you suggesting to rewrite the previous steps?

Yeah, like this it becomes clearer what the variables represent. Note that peekVector should be created empty, so just “vector peekVector;”.

To better visualise what “dimensions”, smallest component and “peekVector” actually represent, here’s an illustration of a door.

Regarding comparing orientations, it occurred to me that once you normalize a vector its length will always become exactly 1, so you can’t use the length for checking whether the player view difference is too large. What should actually be done is normalize both the peekVector and the player’s forward view vector (use angToForward on player view angles), then subtract the vectors from each other and get the length of the result. If the vectors were identical (player looks in the same direction as the peekVector) the length is 0, while if the vectors were opposite (180° difference) the length is 2, and if perpendicular (90° difference) the length is 1.

vector playerViewVector = sys.angToForward($player1.getViewAngles());

peekVector = sys.vecNormalize(peekVector);
playerViewVector = sys.vecNormalize(playerViewVector);
vector delta = playerViewVector – peekVector;
float magnitude = sys.vecLength(delta);

sys.println(“normalized peekVector: “ + peekVector );
sys.println(“normalized playerViewVector: “ + playerViewVector );
sys.println(“normalized delta: “ + delta );
sys.println(”magnitude of delta: “ + magnitude );

if( magnitude > 1)
{
	peekVector = -peekVector;
	sys.println(“inverting peekVector”);
}

[Peek through (almost) every door]

3 hours ago, snatcher said:

A last resort worth mentioning is to allow peeking only when a door is in closed position. Not only we eliminate from the equation weird player angles but it would also get rid of any potential clipping when a door, in example, is fully open but tightly close to a wall.

I don't think this is going to let you use traces: the door surface may be uneven, so that the detected surface normal is different from the actual door surface normal. Another possible flaw is hitting the frame or handle. Using the direction of the shortest side of the door as the peek direction should be more reliable, but it won't work if the door was created diagonally. I think that's rare, though.

Regarding what you've written so far, it looks good. I'd suggest adding comments to better indicate what's going on and changing some variable names:

- "smallest" should be "dimensions"

- "newVector" should be "peekVector". It can be created directly below "vector dimensions", then have either its x, y or z value changed to the corresponding value of "dimensions".

 

For comparing orientations, one approach that should work is to convert the difference into a normalized vector and get its magnitude from 0 to 1, where 0 means no difference (same direction), 1 should mean maximum difference (opposite direction, 180° turn) and 0.5 should mean half difference (90° turn). You will actually need to keep peekVector as a vector and convert the player view angles into a forward vector with angToForward, input the difference into vecNormalize and use vecLength to get the magnitude of the normalized vector.

When working with such calculations it's wise to insert debug lines like below so that you know what your script is doing and what numbers it's working with:

sys.println( "peekVector is now: " + peekVector );

[Peek through (almost) every door]

The trace might hit the side of the door or other things. You can identify the desired peek axis by adding getMins() and getMaxs() to get the total size vector of the door, then check whether the x, y or z component is smallest (absolute size). You can access the components of a vector variable like this (it gets considered as a float):

vector newVector = '100 20 60';

if( newVector_x > 100 ) ....

Make a new vector with only that component and rotate it by the current door angles. Convert this vector into angles and compare it with the player's view direction angles: if the difference is more than 90° the peek needs to go in the opposite direction.

[[Bug] Player Message stale first frame]

Sure, here's a slightly more advanced test map:

1. frobbing the func_static box on the left triggers an invisible func_static with a "gui" spawnarg pointing to the default message gui. Frobbing this a lot causes the blank parchment to flash in sometimes.
2. frobbing the 2 books each triggers 2 different message entities which also have a "gui" spawnarg. You see a parchment with text on it but sometimes also a blank parchment if you frob rapidly.

gui.map

[Beta testing 2.11]

Lots of new assets added in this one, and a fix to A New Job for a bug that made it unfinishable if you guessed/knew the safe combination, without searching the lord's room.