MirceaKitsune

Giving this a try now. So far I completed the first level. I found it rather frustrating and not as engaging as the previous parts in this series: The layout felt like an endless maze of basements and rooms, very repetitive and easy to get lost in. Then I noticed this is one of the rare campaigns for TDM, with 5 levels in total. Now I'm excited to see the other ones!

I'd have to minimize my setup, working on a few things at the moment. Can anyone currently working on a map give this a try considering it's such a simple one? If you already have an AI going through a door at all, just temporarily set the "drunk" flag on them and see what they do: If you get the same result it's a generic bug that's easy to reproduce, if not it's something more specific and I'll need to dig the exact circumstances. Hopefully it's the former, especially since I got the result in two different areas with two separate AI.

Dev snapshot. Semi-latest: My main internet connection is still down until we get it repaired, I can't transfer a lot of data on mobile so I haven't updated to the latest one yet. To my knowledge nothing in the last snapshot changed that would affect this so latest development makes sense. Printed version is #10890. Let me know if others can reproduce this or I need to try compiling my own test map. The steps are simple: Have a set of path_corner entities going through an unlocked door, put an AI with the "drunk 1" spawnarg on. For me the AI crosses fine without drunk mode on, but will just sit in front of the door forever after opening it otherwise. Slightly modified screenshot for emphasis.

I noticed two things that look like they might be bugs in TDM, figured I'd ask first to be sure. Firstly is it normal that you need to set the sit_down_angle spawnarg on every path_sit to make the AI face the way of the chair when navigating to one and sitting on it? I thought just changing the angle of the path_sit entity would be enough. I also noticed AI with the drunk spawnarg can't walk through doors: They're able to open a door, but then proceed to stand in front of it and never move from that spot.

Noted and will be giving that a try, cheers! Had another question in mind: Is it possible to turn off a readable by triggering it, essentially create a readable that works like a light and can be turned off? This means its text disappears when its disabled until it's triggered back on again. I guess I could set it not frobable when disabled, but its world GUI would still display the text... perhaps changing skins could solve that as well, is that the right way or is a better approach possible?

Better version of the banner horse with banners on the sides.

r_showSkel worked and gave me the info I needed. Here's a few images of the result...

Based on feedback after my above post, I decided to turn this FM into a festive map where the action takes place during a holiday. It was a good chance to experiment with a fun concept: Having banners and lights attached to horses. One horse carries a large banner that sways in the wind, the other a lantern that sings and blinks with the music (default music box audio). Must say it's quite fun to watch them parading the streets this way!

Thanks! I'll give those a try. md5mesh / md5anim are text based, but of course you can't tell which bone goes where if they aren't named... the console command sounds best.

The elevator isn't using a projected light, light just shines through the glass naturally. For those kinds of windows, I guess breaking it should turn off the light or change it into a full white light to indicate light shining through naturally. Which reminds me: If a func_fracture targets another entity, will it trigger those when broken? Could be useful for things like alarms. Other question, since the md5 animation viewer in DarkRadiant doesn't list armature bones unfortunately: What is the name of the back bone for the horse? I might be turning my recent FM into a festive map, thought of having a horse with a banner attached to their back parading around.

Got around to it just now. Another good experimental FM with an unique design! Makes me wish we had a proper facility module, these kinds of layouts can really go places.

I really wish this and other FM series were turned into actual campaigns, or rather given separate versions in this form without breaking their existing parts. The multi-level system was barely ever used, I believe only one or two actual campaigns were ever released. I think those tend to have more continuity than separately releasing each FM in parts, especially with things like returning between levels to find what changed and do new things.

That's amazing, thanks: I'll give it a try and see how the prefab elevator does it to double-check. For breakable windows, I can confirm they work well for a horizontal panel you can break to enter buildings through the ceiling. My little church shall be using that as one point of entry. Speaking of elevators, I went ahead and made the windows for my elevator breakable too. Not sure how much sense it makes and if it looks too weird but I'll take it. func_fracture seems to handle itself nicely when bound to other entities.

I always use the latest dev snapshot from the installer now. Thus I couldn't compare it with the release, only noticed the starting area was very slow. I presume it's an issue with newer TDM versions in that case, or the fact I use Linux and the amdgpu driver? Others reported it first though so I wasn't the only one who saw it, only popped to mind now that others mentioned it.

I set it up and it works wonderfully! I'm actually not encountering any issue with func_frature on either a plane or brush, it just works without even having to change anything beyond the health spawnarg! Had some fun with it already and might use this in even more places. And it automatically handles sound occlusion if placed over a visportal! You hear outside sounds muffled until you break the glass, then you can hear them loudly which is quite awesome

Sounds like a good opportunity to replay this sometime. I can confirm performance was very slow in the starting area, particularly when looking toward the buildings from the peer when you can see a lot at once: I thought this is because it's very open and visportals can't hide much, didn't think about the water shader. Reflective water using the mirror setting creates an extra render which has a huge performance impact, it looks beautiful but sadly a less accurate cubemap may be the better choice at times with current capabilities.

Yes, that was the one and what I'm looking for, thanks! Hope a wiki page can be made with details on setting it up so others have the knowledge handy. I also can't find details on how to make AI ride a multistate elevator using the default entities to move between floors. Do I simply put a path_corner at the floor position of the elevator at each location, tie them together, and TDM automatically knows how to make the AI frob the right button and use the elevator?

I played a tiny FM a few months ago which had destructible glass. You could actually hack away at different parts and it broke in pieces based on where you hit: Was quite amazed TDM had something of this detail implemented. However I never found instructions on how to do it yourself.

There's a little something I couldn't help thinking about.

I might want to play this one again since it sounds like I missed a lot of things. Might even give the other difficulty levels a try. I remember being left with one question I never asked...

A question for the more immediate time: Is there a tutorial on how to setup dynamic breakable glass? There doesn't appear to be a page on the wiki about it. Also on making AI use and ride an elevator. I made elevators in the past but never had a character use them, I've seen it done in other FM's but no idea how to do it right.

New idea I'm working on. Does this look good to everyone else?

I have an interesting question: Do we have a setting to not render a model if its origin point isn't located in an open visportal, even if its bounding box intersects a room the player can see? If not can you associate the visibility of an entity with a particular info_location so it only renders in that area? The reason why I ask: The building modules are pretty terrific visually speaking, but were made with some design issues when it comes to origin points and proportions. Often times you'll have an interior module poking outside, or oppositely an exterior module poking the interior of a room. You usually can't see them but the model is still loaded which will may decrease performance. It might improve FPS with the modules if interior and exterior walls can be bound to only render inside or outside, being completely derendered when the room they're bound to isn't open.