Leaderboard

Hidden Hands: The Lost Citadel ============================================================== Title: Hidden Hands: The Lost Citadel Filename : hhtlc.pk4 Authors: Jack Farmer with Amadeus & Joebarnin Date of release: 18.09.2020 Latest version: 5 (released June 2021) EFX: Yes ============================================================== Hidden Hands series: I - Initiation II - Vitalic Fever III - The Lost Citadel ============================================================== Available via the Dark Mod Mission Downloader (Version 4) ============================================================== Jack Farmer: Mapping & drafts Amadeus: Editing and revising of all texts for readables, narration and dialogues, testing of gameplay and gameplay mechanics, all alpha testing & performance optimization joebarnin: Beta testing lead, debugging and debugging reports Beta testers: Krilmar Joebarnin Cambridge Spy manzanita-crow Shadow Voice actors: New Horizon: The educated Builder & Brother Gilbert (Briefing video) Goldchocobo: The naive Builder, guard (A union of its own) Jedi_Wannabe: Two guards (Of monsters and master guards) AndrosTheOxen: Jonus, guard (A union of its own) Boy Lag: Guard (Evolution of the peasants) Malasdair: Narrator (Briefing video & in game comments) Special thanks to: - Springheel, Sotha, and Fidcal for the tutorials - VanishedOne, HMart, Destined, Grayman, Joebarnin, Dragofer, demagogue, AluminumHaste, STRUNK, Geep and ERH+ for patiently answering my questions and solving in-game issues - All voice actors & beta testers for their great support - All others not mentioned here who answered my questions in the Newbie thread or via PM Pilfered items: - Setup for the main menu animation originally developed by Goldwell for "Snowed Inn" - Portal sky with trees originally developed and arranged by Dragofer for "Down By The Riverside" - Selected cliff sections originally developed and arranged by Dragofer for "A Perilous Refuge" - The scary, red-eyed Builder ghosts that have been originally developed by Bienie for "Longhorn Lodge" - Floating boat set-up originally developed by Bikerdude for one of his missions Contributors from the Inventor's Guild: - STRUNK created a prefab (S.T.A.R.S) used for various puzzles and mechanical items, he also helped with models - Dragofer supplied the experimental func_mover entity (modified by STRUNK to fit the mission purposes) - Joebarnin provided the script alteration for the mechanical locks - Grayman adjusted the switch/door mechanics for all sliding doors and fixed several AI problems Additional ambient sounds by gigagooga All other new ambient tracks and sound effects produced and mixed by Jack Farmer Explosion sound taken from freesound.org produced by tommccann Drowning man sound taken from freesound.org produced by muses202 Engine room machine sound taken from freesound.org produced by Astounded Electric zap taken from freesound.org produced by Joel_Audio Briefing video by SirSmokeALot "Walk On Roses" (title screen reprise) RC Deickler - Drums & loops R. Recum - Keyboards gigagooga - Additional ambient outtakes This mission is dedicated to all past & present Dark Mod and Dark Radiant contributors - thank you for all of your hard work over the years. ============================================================= Listen to another crazy inventor and learn more about his sick brain! Marvel at the latest inventions from the Inventors Guild! Sneak through long forgotten ruins and face (yes. I know, once again) the unspeakable evil! Show the undead that the living are not to be trifled with! Solve puzzles the complexity of which would even melt the brains of Nobel Prize winners!

I can confirm that trigger_multiple brushes stop firing triggers if an AI stands still within them. So I see 3 options: Report this for 2.09 so it hopefully gets fixed, or keep both mechanisms so we have both motion sensors and presence sensors. Develop a different presence mechanism that doesn't (wholly) rely on trigger brushes Turn this into a feature and rename to "motion lamp" instead of "presence lamp". Change the script so the lamp only responds to player movements that exceed a certain velocity.

I was able to assemble a satisfactory 1x fan unit (except for outer skin); I replaced the stock fan+motor with a separate stock motor & scaled-up fan, that better fills the duct.

Right: that's basically what I did as well. If the AI stood still for long enough the timer would run out and the AI would be plunged into darkness. If memory serves, the last time I mentioned this you suggested using a different set-up with a modified AI scriptobject.

Let me know if there is any problem with this version, it runs flawlessly here but i cannot account for every PC out there. Things that work for one person have a tendency of breaking for another so i need input if anything behaves odd.

It's good, it's good. Ah, it isn't "Sistema fognario" but "Rete - network - fognaria" or more directly "fogne" (the sewers)

On thinking about this further, the light-penetrating the current modules is probably not a real problem, given that these modules assume the mapper will provide their own shell (architectural enclosure). From my perspective, for an alternative set with external skins, an implementation with two-sided, light-blocking patches would be much preferable to shell modules, that would require additional mapper attention to matching and alignment. (Shells for some of your S-shaped could be challenge for you to make too.) As for my immediate needs, external skins for these would help: - single horizontal duct - horizontal right-angle connector - complex generator unit I've also tried the closed 3-unit fan (which as you know as a fan model at one end, a different fan texture at the other), but it is unsatisfactory. Due to the integral (non-removable) grate over the only entrance, in the side of the central duct, you can't really poke your head in to see the fans at either end... so what's the point? A variant that might be useful would be a 1x unit with fan model and light... A shelled version could have an exterior end-cap texture suggesting the fan within; or maybe spinning fan blades would cast a rotating shadow through a transparent end-cap grill. (I'll try cobbling such up with the existing assets.)

There's a 2.08-related texturing problem with a lamp model used in this FM:

The new HotReload feature by stgatilov in this latest build is a big one for any mappers. Now you no longer need to reload the whole map in TDM if you changed an entity's properties in DR (origin, model, light colour/radius, skin etc.), simply save in DR and enter reloadMap into TDM's console and the changes take effect ingame. This should save a lot of time in things like getting the lighting right, well worth getting if you're a mapper. Even easier is to bind this to a hotkey by typing the following into the console (in this case binding to j): bind "j" "reloadMap"

Well well well. I don't know which of those settings made the difference (r_glCoreProfile is set to 2, by the way), but it seems to work properly now. Do you want me to try recreating the problem to determine which setting was important, or shall I just take this as a win? I've attached the console log file, there are quite a lot of warnings on loading, but maybe this is normal? Otherwise looks ok to me. For this log I just started the map, let the conversation finish, saved the game, checked the menu screen was working, climbed up towards the generator and onto the open window ... and fell to the ground while trying to enter the window! Looking forward to playing this properly at the right time. I'll also attach my .cfg file, but there's nothing interesting there, I reset it. darkmod.log Darkmod.cfg P.S. What do those .cfg settings mean and do? I couldn't find anything relevant with a quick use of google. P.P.S. Thank you for the help!

Amusing for an italian like me to play a FM with all those (pseudo)italian (sur)names

"extinguished" is for flames (candles, torches, fireplaces etc...), electric lights use "start_off" (you cannot extinguish an electric light ) As VanishedOne stated the respective entity probably needs to use the tdm_light_holder scriptobject you could change the frobability via the generator. So the switch that turns on the generator also changes the frobability of the secret button, which starts unfrobable. Use a target_setfrobable entity for that purpose (that's thesame entity used on footlockers etc... to change the frobability of the items inside, check the respective prefabs to see how it works and you can read up here )

@VanishedOneThat's indeed the case. Note that Dragofer doesn't directly triggers the light via the trigger_multiple, but instead uses it to reset a timer that turns the light off once it ran out.

New dev build dev15987-8910 of the game published.

I downloaded the save, thank you! The problem with elementals comes back. Now it is caused by killing an elemental which was put on a list of "registered users" for a door. Opening the door afterwards causes a null pointer crash. @kin, I'm afraid you have to noclip past this door, but if some other door crashes on open, just do the same. I don't expect any problems further in game: only the doors analyzed by elementals are affected.

Last release before i start changing things, get HPL1Engine-sources-02-08-2020.7z from same url as the engine. Changes: All libraries beside newton and anglescript have been updated to latest. Fixed a few memory leaks in source. Removed old project files (no longer possible to build it with the old compilers anyway). Added HPL tools to main solution and added a readme on how to use them. Build instructions: open HPL.sln in msvc 2017 and select if you want a debug or release build, hit build and profit . If you want the mapper tools theres a folder named tools in the workspace, it does not get built by default but even if you have not built HPL1 yet it will build the dependencies automatically. Select each tool in the workspace and hit build. If you want to mod for penumbra you need to open hplhelper.exe and execute the tools from there, it reads the material.cfg file at startup to get the correct location of of game materials. You can then do a few things like seing how your model / map / particle etc. would look in game (yah it is pretty basic). There are a few editors for hudobjects maps and particles but they only have the most basic functionality, atleast you can see if things will look right.

When I tried to make Lost City lamps with trigger_inactivity, I found it worked for the player but the trigger_multiple would repeatedly trigger its target with an AI inside it only if the AI was pathing, not if it was standing still. Have you found differently?

From a glance at one of the lantern entity classes, it doesn't use a scriptobject (which would read the "extinguished" spawnarg). You could try giving it "scriptobject" "tdm_light_holder". If that fails you could investigate the def_attached light entity if there is one (as an actual light it should respect "start_off" even if you can't get "extinguished" working on it or its holder). I'm looking at atdm:moveable_lantern_bullseye, which actually attaches light_lantern_bullseye_spotlight_unlit by default.

TDM has envshot already, which will create a 6 sided box images, front, back, left, right, top, bottom.

@duzenko @stgatilov Is there a chance you could help him? As for the picture and the red headlight AIs:

Hm, for a conscious design choice I've seen them implemented really badly way too often. It depends on the particular game, of course. I don't mind checkpoints in many games, but particularly in the stealth genre, they tend to ruin the fun for me. The most striking impact I observed in the Splinter Cell series. Whereas in the first three games, I really enjoyed going for a stealthy approach, I absolutely hated it and felt punished for it in the later games, and the difference is exactly quick saves vs. checkpoints. In the first games, I could quick save whenever I wanted - and it was incredibly fast, both the saving and the loading. And as such, I felt more inspired to try and take some risks, and if I did get caught, I didn't lose much progress and could just try something else. In the later games, however, getting caught means being reset to the last checkpoint, and if you are taking a stealthy and cautious approach through the level, that means easily replaying your last 5-10 mins. And nothing, absolutely nothing, infuriates me more than replaying the same part of the game over again that I just went through, particularly if my mistake came later. And that led to me very quickly abandoning the stealth approach, because it felt way too punishing. Playing the levels action-style also meant you went much quicker from checkpoint to checkpoint, so less time lost if I die. But playing the games action-style also diminished my enjoyment of the games immensely, and so this is at least one example where my enjoyment greatly suffered from checkpoints...

Sorry for resurrecting an old thread, but I thought this might interest a few people (I accidentally applied the wrong normal map to the floor, so ignore those artefacts you may see.) This works by means of a new custom shader, which I've attached to this post. I don't know if it'll land in the upcoming 2.08 release, but you could also bundle the shader with your map, and it should even work in 2.07. How to use it? Well, it's admittedly not super user-friendly. You'll need the regular cubemap capture as before. But in addition you'll also need the world position from where the cubemap capture was taken, and you need to specify an axis-aligned bounding box that approximates the captured geometry in the cubemap. This means that this technique works best in rectangular-shaped areas (like in Epifire's test map from this video), and that rectangular shape should be axis-aligned. You can of course still define an axis-aligned bounding box for non-rectangular or rotated geometry, but it'll probably not look as good. Since there's currently no support from DR or the game to get those parameters, you'll have to measure those three positions yourself (cubemap capture position and AABB min and max corners), either in DR or in the game with noclip and getviewpos. They don't have to be exact, but it'll look better if they are not totally off. Now, in your material, you'll need to replace the default cubemap reflection stage, i.e. this part: { blend gl_dst_alpha, gl_one cameraCubeMap env/cubetest texgen reflect } Replace it with the following: { blend gl_dst_alpha, gl_one program parallaxCubeReflect vertexParm 0 0, 40, 100, 0 // cubemap capture position vertexParm 1 -130, -240, 0, 0 // proxy AABB min vertexParm 2 130, 320, 200, 0 // proxy AABB max fragmentMap 0 cameraCubeMap env/cubetest // reflection cube map fragmentMap 1 _flat // normal map } vertexParm 0,1,2 are the cubemap capture position and the AABB min and max corners in world space, respectively. fragmentMap 0 is the actual captured cubemap, and fragmentMap 1 is the normal map for your surface (or '_flat', if you don't want one). parallax_cubemap_shader.7z

Something a bit like this, perhaps? Translating the shader over into a proof-of-concept wasn't bad at all. Here's what we'd have to figure out: How to get this in-game. At the moment I'm using the techniques from this thread:It's only running properly with the special build from there. If custom shaders are going to remain a more experimental thing in 2.08, this might become something to spend some time and make well-rounded enough for general inclusion in the following release. What is the best way to supply textures to the shader. It would be neat if a mapper could build some rooms and take envshots of them, and use those as an input. We could get fancy and randomize which walls to use within a room, or get even fancier and have detail layers on top of the walls. Also have a mid-plane with alpha cut-outs for more depth... How to set the size of the rooms. Right now it's hard-coded, and the repeating nature works better for skyscrapers than strewn-about buildings. You wouldn't want a wall running down the middle of your window, so we'll have to work around that. What do to about lighting. I'm drawing the shader itself full-bright as lights shining on its surface would ruin the effect. That's unavoidable, the question is how to achieve lighting within the fake rooms. The original code simulates a light within each room (which I didn't port over), but I'm leaning towards keeping it simple and relying on the envshots having pre-baked lighting in them. I haven't thought through the implications either way when it comes to normal/specular maps. How to put a window in front of this. Should we leave it as-is and rely on the mapper to put a transparent material in front with their desired effect? I'm leaning towards that in order to keep things flexible, but I haven't tried it yet. I'm fairly busy the rest of the week but I think this is really cool and plan to keep working on it. I'd welcome any input from others with more experience.