Dragofer

I don't think you can create brushes on the fly because dmap is needed to give them their collisions.

I believe there's no way to control a func_mover without using a script. Doors have the advantage of having an inbuilt response to frobs and triggers. If you can script, then func_movers are the more elegant option. In this case their advantage would be that you can more easily make it a single-use thing.

Ignoring is somewhat inadequate as you still see other members engaging in a discussion with the problematic user, and as Wellingtoncrab says such discussions displace all other content within that channel. Moderation is also imperfect as being unpleasant to engage with is not in itself banworthy, so there is nothing more to do if such people return to their old behaviour after a moderator had a talk with them, except live with it or move away. I'd be more willing to deal with it if it felt like there were more on-topic discussion, i.e. thoughts about recently played fan missions or mappers showcasing their progress, rather than a stream of consciousness about a meta topic that may or not have to do with TDM. I guess the forums already serve the desired purpose, or they just compartmentalise discussions better.

Yeah, I quit the official Discord after someone intensively argued with me that we shouldn't credit Grayman for Seeking Lady Leicester (but Black Mage was fine?). A few other mappers have left too after similar episodes.

Btw, last time I talked to Flood he said he wanted to step away from this task and is glad for the team to take over. The abandoned missions repo has also been moved to TDM's SVN server. I suppose any team member who manages FM uploads can also accept newly abandoned missions.

Could it be your map is leaking and therefore not generating physics for new geometry? If you use "testmap" instead of "dmap" + "map" it will load the map even if dmap failed.

After a brief delay version 2 of the mission is now up for grabs from the downloader and from Google Drive. The above post does still hold true for the most part, all-round polishing what was already there of this first mission of mine. Retaken screenshots can be obtained here: Google Drive. Thanks go out to the betatesters of round 2: JackFarmer, joebarnin, The Black Arrow, datiswous, Acolytesix

Hm, he's meant to continue talking after the placement is complete and the objective ticks off.

Thanks for giving it a playthrough and leaving the detailed feedback. Regarding your supposed glitch, it's actually an intended feature to ensure the player stays inside the room while the NPC is talking to him to avoid missing cues and not seeing why the objectives were updated. The barrier should be gone afterwards.

This would also have the advantage that the foglight wont be contributing to an extra rendering pass of everything it touches in the map, even if its transparency were ultra high. IIRC a foglight added 1000+ drawcalls to the Perilous Refuge harbour scene.

On a separate note, does the stealth score behave as expected now? 2.11 had some fixes regarding detections by guards in dark places and civilians.

Your approach is basically how I did it with the custom AI alert behaviour in Iris. You can only steer AIs while they're unalerted, so my script would tell them to approach the source of the commotion. Once they come close enough to see the problem, TDM's stock AI routines would take care of the rest.

As the file name implies it's for v2.07, which was the last TDM version before a hook for custom user addons was added. It therefore overwrites the main TDM script file with a version from 2.07, which means several newer missions won't work anymore. It looks like I made an updated version that should be compatible with all 2.08+ TDM versions, as per datiswous' post. Practically it's an inventory item that triggers a GUI message popup whenever you activate it in your inventory.

Yes. You would modify the function that gets called when the player frobs a teledoor to offer the player a GUI selection, wait for his input and then update the entity variable for which teledoor it's paired to, before the teleportation begins.

The way Id do it is sys.VecToAngles( point2 - point1 ); That gets you a set of angles from 0 to 360 - if you need their overall magnitude you could use sys.vecLength( angles ); Alternatively you can convert them with sys.angToForward( angles ); if you only need the angle on the horizontal plane. You can also use anglemod180( angles ); to convert angles to the range -180 to +180. I believe that function only lets you do 1 angle at a time. @thebighwere you able to get persistantargs to work? @MirceaKitsuneI think you'd be better off respawning an AI with the desired properties. I highly doubt TDM allows you to alter an AI to that extent.

Secrets only get shown in the stats screen if the FM uses the official system. Before that was introduced a lot of FMs used a selfmade system.

Yes, overwriting individual core entities with custom .def files in an FM archive is now uncomplicated after the overwrite rules were changed in a recent TDM version. The FM will be isolated from any future changes to the player entity, however - even if they may be rare.

You can always add it via script, but itll be too late because the spawn frame code events have already happened. i.e. the lantern won't be part of the weapon index. This is a generic def file for player-related entities. If you overwrite a core def file you have to include everything, otherwise those entities will be missing from the game.

Adding that def_weapon spawnarg is indeed the only change made for this lantern. In fact the file is outdated because it doesnt have the bobbing spawnargs that were added in a recent TDM version. It doesnt look like there's a way to replace this via script, currently. Player.cpp does various stuff with the def_weapon spawnargs in the spawn frame, including setting up a weapon index. There's also stuff that seems to be called after map start like idPlayer::UpdateWeapon which reads out def_weapon spawnargs, so any dynamic approach should include appending a def_weapon spawnarg for the lantern to the player entity. All in all, adding custom weapons is quite limited. Besides the requirement of the above core file overwrite, we only have 2 extra hotkey slots for custom weapons with no way to set them via the menu. In a previous dev discussion it was decided that we already have too many hotkeys so some alternative approach should be tried i.e. a weapon wheel like in Dishonored.

This is true, but the fact is that the viewmodel only consists of a bare arm (animated model), with something bound to it (static model). The depth hack only applies to the arm model itself. If you want to stop the lantern clipping through walls you have to make a new version of the animated arm model that has the lantern integrated into it.

Thanks for asking, Ive figured it out in SLL for making those self-fading readable items. I think it was a matter of setting the colours in the GUI stages in a certain way.

Are you sure that's the materials' names? Usually materials that use textures from the props folder dont have paths in their names. You can look them up in the DR media browser or in the model chooser for that model.

I think setSpawnArg is intended for setting spawnargs on entities that you're going to spawn. You can use it on sys followed by sys.spawn()

The most likely cause imo is that the objects are further from the map origin, the larger coordinates leading to minor rounding errors.

The family portraits were generated using AI by Wellingtoncrab, using ingame screenshots of the characters as a starting point. It took a lot of iteration to get the appearance shown in the portraits.