Dragofer

@stgatilovMaybe there could be a way for the tdm_installer to recognise and leave custom .pk4 addons alone? Maybe via naming convention?

I don't know myself, I'm only responding to the bug report I saw in this thread. You could check on your location_settings entity whether the same music has been specified in multiple snd_ spawnargs. There should only be one snd_ spawnarg per music on the location_settings entity, and all info_location entities that should play the same music should use the same snd in their "ambient" spawnarg.

I believe there is no relationship between kcghost's addon and mine. His works by replacing the loot counter inventory item and scriptobject to show stealth statistics. The GUI update in 2.10 only concerns the menu interfaces, so it's not clear to me why this shouldn't work. The problem of no loading progress often happens when loading a save that's based on a different version of the game, which most likely includes any change in the .pk4 addons you have installed.

Alright, try renaming both copies of the file from z_nofog.prt to a_nofog.prt.

@GadavreUntil you get this new variable you could use this customised particle file to make the most common fog particles invisible. z_nofog.prt You have to be logged in to download it. (edit: should be renamed to a_nofog.prt) To use it, close TDM and create a folder called "particles" in your "darkmod" folder and put this file inside it. Result: darkmod/particles/z_nofog.prt. Some FMs like The Black Mage have custom versions of fog particles, which means this file might not work 100%. So you can create a folder called "particles" in the fm's folder and put a copy of the file inside it. Result: darkmod/fms/black_mage/particles/z_nofog.prt.

@NeonsStyleThis is probably because of how the ambients for the locations have been set up. The correct way is to set each ambient once on the location_settings entity (i.e. "snd_streets" "city_night04_loop"), then let location entities share that same snd (so spawnarg "ambient" "snd_streets"). The randomly stopping music happens when you define the same music multiple times on the location settings entity (i.e. "snd_street1" "city_night04_loop", "snd_street2" "city_night04_loop" etc.) and give each location one of these snd's. The location system thinks each location uses different music so it restarts.

I've noticed that I can see the edges of light volumes as sparkly lines now - this is taken from a recent test map: And this is m y darkmod.cfg (pretty much the one that the tdm_installer.exe gives me after updating to beta02): Darkmod.cfg

That objective should tick off, silently and invisibly in your case, if you enter Marlow's 2-floor study - but I think the underlying problem is just that the mission success logic seems to be more complicated than it needs to be and can therefore break if things are done in certain orders. It's definitely something for an update. I'm afraid in this case I can't offer anything else than entering "tdm_end_mission" into the console when you're standing at the exit location to get a proper mission ending statistics screen.

The "here is my way out" voiceover is a self-contained event triggered when walking near the exit location that only counts how many objectives you've completed before deciding whether to play the voiceover or not, so it seems unlikely this is the cause. According to the objective logic, you need to complete the following objectives to complete the mission:

Xrays + mirrors don't seem to work well together yet, though experimentation may yield interesting results and maybe support could be added if it's considered an interesting combination by mappers. From a performance perspective it seems unsensible to attempt this though, since the xray system adds a 2nd model and the mirror doubles everything, ending up at 4 models. But it depends on what you do with the system: if all you do is change some decorative models you probably wouldn't notice a difference, but you would notice it if you converted your entire city map into an undead necropolis through xray vision and threw in a mirror with realtime reflections.

Ah yes, we had problems with the numbered camera materials used by this test FM some time ago, so I commented them out in order to not impede the initial beta release. Problem is, the test FM doesn't have its own copy of the materials, so it's now missing them. I very much believe duzenko managed to fix the numbered camera materials before the initial beta release, so you should be able to just drop this .mtr file into your install. Also, they'll be included with the next beta version again. tdm_camera.mtr

Since the wiki articles are now both done this thread can be unhidden. Enjoy!

It should give mappers some more freedom with lighting their map without punishing the players for it. It's of course a delicate balance, mappers shouldn't go too far with this so that the mismatch between lighting and lightgem becomes obvious.

Unless the Doors wiki article says otherwise, I don't think you can change the center of rotation on an .lwo/.ase model. It'd be advisable to export the brushes (or re-export the model) by placing them near the DR grid origin such that DR's 0,0,0 is where you want the model origin to be and unchecking 'Center objects at 0,0,0 origin'.

This thread is for discussion and feedback on the xray feature, which has been developed further for 2.10 and is now considered feature rich enough to be publicised and wikified with X-Rays and X-Rays in GUIs. See below for the main wiki article's introductory section: As well as some screenshots from the demonstration map found in the main wiki article: (Note that various assets mentioned in the article are currently only available in the demo map and will become part of the second 2.10 beta build).

I wouldn't be surprised if most of the heaviest FMs have plenty of potential for being trimmed down to a smaller archive size. Mappers who've been around for a while tend to have ever growing suites of their own custom assets which they drop in at the start of each of their WIPs, and I doubt everyone goes through them at the end of the mapping process to check which ones aren't used or have meanwhile been added to core assets. This is probably especially true in FMs that contain hundreds of custom assets, since they can only be checked by hand at present. In any case, we're fortunate to have considerable reserves both in storage space and bandwidth for FMs, so I don't think there's a real need for mappers to go out of their way to trim down their FMs (like we did with TPW, which was in a way treated as a challenge). Low-hanging fruit should in my opinion still be plucked, and as Orbweaver says, abnormal file sizes can be indicators of underlying problems that should be addressed.

I don't think it's negative - you did post a large figure for your first FM's size, which inevitably triggered comments on why it might be so big and how to reduce it. Everyone has their own way of delivering such remarks. 445 MBs compressed is on the large end, but we've had several FMs that were in that size range for whatever reason (long videos, many custom assets). I think as long as you devote some attention and effort to the matter, then such a file size won't be a problem.

I don't think you can compress env images as .dds, it hasn't worked for me in the past.

I don't think it's this black and white. The process you describe is the technically correct way to do modelling, but TDM has a long history of mappers making models "on the fly" in DR using brushes and patches at a level of detail that may not seem out of place when seen together with TDM's other models, and without much of a technical difference compared to if that model had been made in Blender. I myself have made detailed ships (as seen in Perilous Refuge), quite a few furniture pieces (of which most are in core assets) as well as the stagecoach and lamp models back in 2016 (which are also in core assets). Usually I passed them through Blender for some touching up, but DR on its own can produce quite useable results. The main problem imo with using DR to make models is that it takes a lot of time, so it'd be very much adviseable to use skins or to use DR's model exporter to add new geometry to an existing model. For example for your good-looking new type of standing oil lamp, I'd just have drawn a glass patch around the top of an existing standing oil lamp and exported them both together as a new model. It can also get problematic if you try to add really small details, i.e. I remember shading issues when I tried to make small desk oil lamps where I sometimes had to drop down to a grid size of 0.125. Generally one should primarily use patches wherever reasonable, since as you say brushes don't have smooth shading. Performance-wise I have a feeling that leaving big complex models as brushes and patches without turning them into .lwo or .ase models using DR's exporter is disadvantageous, but I haven't confirmed that yet. @geegeeOne thing to consider is that your figure of 1.7 GB is probably in its uncompressed state, which isn't how you're going to distribute the mission, so I'd look at how much it weighs as a .zip. Map files and .ase models are text-based, so they compress really well - IIRC they'll be only 8% or so of the original size. I guess you also have .bak files and autosaves in your maps folder, maybe also a snapshots folder? The weight of the .proc and .map files themselves does seem abnormal. Have you converted your brush-and-patch remakes as models or left them as is? No, it's not known - a lot of models were added by a lot of people as many as 10 years ago, and our contribution tracking wasn't as robust back then. I myself have contributed i.e. the oil desk lamp and desk02/desk03 series and the miniature ship models.

Damn, how does this break down by folder / asset type? Stuff like .tga diffuses and speculars can be compressed into .dds, for example.

I think this is mixing up 2 different things: - Under the current system mappers are obliged to add the above blocks of code to every material if it should ever frob highlight. Not only does this clutter material files and deter mappers from learning the material system because of the unnecessary apparent complexity, it's also occasionally forgotten by mappers, and not every mapper is able to troubleshoot why his objects don't highlight if these blocks are missing. These 2 blocks should at the very least be simplified into a single line (which solves some of the problems above) or else be handled automatically (which solves all of the above problems). Handling highlighting automatically without manually adding code to each materials is one of 2 things being done here - the other thing is to add a frob outline. - The new automatic highlighting, however, has problems with transparent textures, since different transparent textures have different needs for frob highlighting, and an automatic system has difficulties applying the correct solution in each situation, potentially causing errors like shown above by wellingtoncrab. One of the only safe solutions for transparent textures may be to not highlight them at all and rely on the outline instead.

The old 2.09 security camera had a fairly simple movement model, simply fetching the spawnargs for sweepAngle and the sweep duration, then adding a gradually growing fraction of the sweepAngle to the starting angles, multiplied by -1 if negativeSweep is true for that sweep. I could imagine that there's sometimes a problem with setting the initial value for negativeSweep based on the value of the sweepAngle spawnarg. The 2.10+ security camera still makes use of sweepAngle and negativeSweep, so I wouldn't exclude it still happens there, but altogether the movement code has changed a lot to allow the camera to horizontally and vertically track the player's position and later return to the closest sweep position. negativeSweep is now calculated every time the camera initiates a rotation, based on the sign of - in most cases - the shorter route towards the targeted position. In exchange, the two ends of the regular sweep are calculated and stored at spawn based on current angle + sweepAngle, so negativeSweep no longer plays a role for setting the camera's sweep range. It'd be interesting to know if any of your beta testers happen to be using 2.10 builds, and also how the room fares for you yourself if you were to use a 2.10 build yourself. Its release shouldn't be that long off in any case.

@JackFarmerI think you need to use a different script event to switch it back on. The torch is a model entity that spawns a light at map start, and I believe On is designed to be called directly on the light entity itself. It should be enough just to sys.trigger the torch, which would cause its tdm_light_holder scriptobject to switch the light on. Might want to find another way though if theres a risk the player mightve relit that torch with a fire arrow or candle. IIRC there are also S/R events for switching extinguishable lights on, but they too might be designed to be used on the light entity directly. For 2) the problem seems familiar, youre probably not the first to have it. Will have to think on it.

It should be as simple as unchecking the tickbox "Mandatory" for those objectives in the Objectives Editor. If you really wanted to avoid DR you could even do it by opening the map in a text editor and changing the right lines. Alternatively it might be possible to make a script addon that automatically detects the map's objectives entity and sets the objectives to non-mandatory. Would have to be careful it doesn't break missions, though, if they combine no-kill requirements and other tasks into the same objectives.

@bwyanThanks! I was wondering, if you delete the silver platters and add back one or all mirrors, do the mirrors work again in post-9232 dev builds? Could be you cant have both at once.