Dragofer

@JackFarmer Turns out you can just put in another line in the darkmod.txt: Title: Hidden Hands The Lost Citadel The 2nd line only gets shown in one place as far as I could see: Currently Installed Mission.

@JackFarmer Behind Closed Doors does this, maybe you'd like to take a closer look at its darkmod.txt? darkmod.txt

@NeonsStyle 2 things to look into: to be on the safe side, I'd change the names of the normalmaps so that they end in _local instead of _n. Don't forget to update the material with the new names. surftype15 shouldn't be in quotation marks Also, these files don't happen to be stored in a dds folder? If they're .tga they don't belong there.

Many thanks once again for the considerable amount of fixes and improvements!

It's a good deal more expansive than BCD, so much so that it's taken some effort to get the engine to compile it. A lot of people have had their hands in this FM over the years, with Bikerdude and Shadowhide contributing a huge chunk of those manhours.

@Atheran welcome back, and you sure sound a lot more knowledgeable than me about modelling now. For me modelling is just part of my toolset as an FM author for getting things done, alongside sound/image editing and scripting, so I'm glad to see a (newly baked) specialist in this field returning to the forums. Regarding the tools, Lightwave isn't obligatory. Arcturus and I use Blender, while I know others use/used 3dsmax, softimage and wings3d. As long as it produces .lwo or .ase models it's all good.

Pretty much since bikerdude posted that invitation for public testing we've been working without interruptions (6200 Discord messages to date) on getting the mission into a polished state. Betatesting has been on hold while everything from the briefing to voiceovers, conversations, readables, main story, scripting and balancing was getting revised or implemented. That's all virtually done now, so at the moment we're making quite a unique bonus area (mostly it's bikerdude building and myself scripting) before we resume betatesting, which will be announced by a post in this forum. The mission has really undergone a metamorphosis since the last test build and I'm looking forward to seeing it happen.

BCD uses a very outdated version of my first oil lamp, so apart from a visual similarity it has nothing in common with the lamps pack I committed to TDM recently (in terms of names of skins / defs / models), except for a material which was already present in earlier TDM versions. This blackness looks like it can't find the skin anymore. Might have something to do with the fact that the model path contains a hyphen (/non-extinguishable/) and that recently all stock skin definitions were updated to put model paths into quotation marks to avoid problems with such characters?

In Down by the Riverside I've used monsterclip brushes converted to func_mover to push AIs sitting inside or on a carriage. Should be possible to make the boat move at least on the horizontal plane, if not vertically / rotate. AI can't be bound, they'll disappear at map start.

Anyone got some experience with modifying the strength of gravity in part of a map? The TDM Script Reference only has enableGravity() and disableGravity(). I was thinking of adapting the slow-fall potion script, but it seems to use SDK-level coding (which I can't access in scripts) and it wouldn't affect moveables. I heard that some Doom 3 branches have a so-called Volume_gravity entity that modifies gravity within its volume by a vector (so it could even change the direction of gravity), but we don't seem to have any entities with "gravity" in their names in TDM.

Alright, looks like I found the solution: besides patches and func_emitters there exists a 3rd method for generating particles: func_smoke entities. Like scripts, they produce particles that exist in the world independently of any entity, so they'll stay where they were made regardless of where the func_smoke goes afterwards. Based on preliminary tests it seems to do what I need perfectly. Wiki: World Particle System

I'd like to get this kind of wisp ingame: Putting a glowing ball on a spline was straightforward enough, but I haven't been able to get it to leave a trail of particles along its path. My 2 first attempts went like this: Make an additional func_emitter for the trail particle and bind it to the spline's mover -> the trail particle spins insanely fast. This is an old & frequently encountered bug when binding particles to something. Make an additional light which has the trail particle as its model and bind it to the spline's mover -> the trail particle always maintains its starting orientation and doesn't leave a trail. Then I found out that the fire elemental leaves a particle trail like in the screenshot. But it looks like this was a very custom solution: the elemental doesn't def_attach its trail particle, tdm_elemental_smoke.prt, but rather has these 2 spawnargs that only seem to work on the elemental: "smokeParticleSystem1" "tdm_elemental_smoke-body" "smokeParticleSystem2" "tdm_elemental_smoke-body" Maybe there's some way to adapt these "smokeParticleSystems" to non-AI entities like a light or func_emitter? Or another approach altogether?

You can have either a cutscene in which you direct AIs to do various things while the player's watching them through a moving camera entity (wiki), or have a video texture or GUI showing a video file (wiki). In the case of the latter you might still want to immobilise the player using the first method.

@grayman alright, I isolated the cause of the bug that a sitting AI briefly stands up and sits back down after a conversation finishes: it only occurs if the path_sit node is his final path node. Adding a path_waitfortrigger after the path_sit fixed it. Will look into a bug report. @Geep yes, just like that.

@grayman thanks for clearing up the status of path_talk. I'm already using a 1-line conversation to get an AI to say something to the player a few seconds after map start. The problem is that the AI should sit at map start, so what happens is: Map loads. AI sits down (screen slowly fades in from black to conceal the animation) AI says a line When he's done talking, AI stands back up, then sits down again. I'm assuming it's because the conversation starts while the AI is still finding the most comfortable position on his chair, so I'll probably have to delay the conversation even more. A path_talk would've been a nice solution for a snappier start.

Anyone got experience with the path_talk entity? I'd like to use this instead of a conversation to get an AI to say a line, but neither the entity description nor the inherited properties suggest how to use the entity. @Geep looks impressive, sure went all the way with that bobbing entity. Maybe you'd like to open an own thread for it?

Alright, how about doing it the old way with 'sort 101' in the material?

Good thing that 2.08 comes with the new drawSortOffset spawnarg to adjust the drawing priority of post-processed/transparent surfaces, without having to clone & edit the materials involved. The starting sort value for transparent materials is typically 100.

@Spooks I just checked Down by the Riverside in the 2.08 beta and wasn't able to find anything wrong with my custom lamps. Might be what you're seeing is related to the other issues in that post, or how the wisps in mission 2 showed up as black boxes on your end?

Thanks, that sounds very useful. I wasn't aware of them because they weren't listed under "func_mover" in the TDM Script Reference. That should make life much easier if SIG_MOVER_POS1 etc. work for non-binary movers too.

Something to really watch out for here is that sys.waitFor() or sys.waitFor(self) don't work in scriptobjects. So if you just use sys.wait(x) it won't care if the mover gets delayed because it was blocked and it can get thrown off course. The way I solved it was to compare current position with target position every 0.1s in a looping script. If both are identical, the mover has arrived and can start moving back. I also compared current position : previous position to detect when the mover was blocked in order to pause movement sound.

If you only want to reload spawnargs you can use getKey at the start of every movement. So: while(m_bobbing) { m_time = getFloatKey("time"); m_translate = getFloatKey("translate"); time(m_time); //how long the movement should take move(m_translate); sys.wait(m_time); //wait for the movement to finish before repeating this block of script. sys.waitFor(self) doesn't work in scriptobjects } I wouldn't advise that, func_mover comes with plenty of inbuilt features like being interruptable, pushing/damaging things etc.

@Geep instead of triggering the whole entity, you could maybe get by just by re-calling the objectfunction if condition x (m_bobbing) is true. void scriptobjectname::bob() { move up wait move down wait if(m_bobbing){thread bob();} } Or use a while(condition_x) to only repeat movement for as long as condition x is true. void scriptobjectname::bob() { while(m_bobbing) { move up wait move down wait } } And condition x could be toggled like this. This should get called when the func_bobbing is triggered(/frobbed). void scriptobjectname::toggle_bob() { if(m_bobbing) //if m_bobbing == 1 {m_bobbing = 0;} else {m_bobbing = 1;} }

I recently opened 0005176 because I found it annoying that whenever I open a map my shader clipboard is set to "_default", which means when I draw a brush or paste onto a brush/patch it'll have that "Shader not Found" texture. Especially because _default uses a very peculiar texture scale, so when you replace _default with a normal TDM texture the scale will be off. I asked that DR remembers which shader was in the clipboard from the last DR session, to which @greebo asked the question: I figured that each map should remember its own last shader, as that should make resuming work easier, i.e. trimming a facade with a particular stone texture or laying out a dirt path. For brand new maps which never had a shader in the clipboard before, I'd see 2 options: Let them use the last shader from the most recently saved map. Keep using _default as the first texture in brand new maps, but change the inherent scale of _default so it can be swapped for a real texture with ease (meaning the scale of the real texture will be Natural 0.500). Personally I think this is a slightly cleaner approach so I'd prefer this one a bit.

That's weird, my DR (v2.7) doesn't produce the hard blocky surfaces I'm seeing in your spice grinder. Btw, try looking at this: https://wiki.thedarkmod.com/index.php?title=Text_Decals_for_Signs_etc.