Dragofer

I'm thinking the advanced options would still be in action with their current values, just that the controls are not visible to the user. This sounds like a good idea to me, wouldn't want to alter or break special materials that the mapper is inspecting for guidance in creating his own version. But this is a question of necessary time investment to implement vs. number of special materials that need special attention. It's one of the things planned for 2.10, but until then frob stages will be necessary and not all mappers may upgrade immediately i.e. because of technical issues, so there might still be some value in being able to quickly add frob stages. There will also no doubt be many material frob stages floating about in custom texture packs long after 2.10 is out.

On the other hand, security cameras are basically like AIs that are non-KOable, non-killable (without loud and expensive arrows) and never leave their area. Also, I can imagine that security cameras will see a lot of use simply in restricting the player's mobility around the mission, as we saw in the bank in Thief 2, not only to guard the most important locations. I could therefore imagine them becoming cumbersome to deal with if the only available methods were fire arrows or the power switch (possibly guarded by keys and codes). It is also the mapper's responsibility to balance them well, but I think it'd make the mapper's life easier if there were some more methods available - but not as abundant and effective as water arrows. Flashbombs could have more uses, anyway - they're currently no good for anything else than escaping or fighting undead. Having this already enabled is preferrable since only a subset of mappers is able to use S/R and scripting effectively, and such behaviour should be fairly consistent across most of TDM's FMs for cameras of the same genus.

I'm leaning towards making flashbombs, but not water arrows, a means of temporarily disabling a security camera. They're less abundant and more valuable, so this should justify being able to get past a stationary camera, which might after all be guarding a very sensitive location. Breaching that location once might render the camera irrelevant for the rest of the mission, so it should be an exceptional act to disable it and not something as common as dousing a flame.

I'm very much looking forward to the material editor as I think it would open up a lot of the material system's potential to mappers. It'd be a major improvement over how I imagine most mappers to interact with the materials system, which is to copy an existing material, update the image paths and maybe copy-paste in something one has found in another material. I think the main purpose of the editor is to 1) show what options are available, 2) apply them so that the mapper doesn’t have to worry about syntax. In an ideal world it’d also show an accurate preview, but I still think this is of secondary importance given the difficulty of replicating TDM’s rendering in DR and the existence of the new TDM<>DR connection feature. For mappers it’d arguably be even more realistic to view their custom materials ingame in the actual map. But for strict non-mappers there should be at least some preview support. Maybe some “basic” or “common” settings can be identified, like diffusemap & normalmap. These are settings that are shown in “basic” mode and that the DR renderer should be able to portray.

Done here https://forums.thedarkmod.com/index.php?/topic/16091-fan-mission-breaking-out-the-fence-17032014-by-kyyrma/&do=findComment&comment=457768 I've only changed the entity that removes the lockpicks, I could not at all say for sure whether it was also safe to permanently delete the AIs. It appears they are sometimes teleported (back in?) to locations in the playable map area.

The mission has been reuploaded with a small fix for the lag that begins after lockpicks are picked up - the downloader should offer to update the FM. Please let us know if there are still problems in this vein with the FM. @kyyrma

You can actually disable the offset behaviour on an individual basis by doing the clone while you're in 'R'otate mode. I actually almost always clone like this because I want to move the clone in a different direction and sometimes only on one axis. As Jonri says, most of the time cloning works without problems, but it's a definitely a boon to be able to track down the cases where it goes wrong.

I think I'd tend towards Thief's approach of making security cameras quite sturdy so that the player either has to invest high-value arrows or find a way to switch them off. Fire arrows are underused in TDM imo. Water arrows are rather abundant in relation to security cameras, so I think they should only temporarily disable them, as a potential extra feature in TDM. The idea with making the lens vulnerable to broadhead arrows is interesting, but broadheads come so cheap that the lens would have to be quite hard to hit, which would be frustrating in a similar way to how the blackjack is hard to use reliably for some people. Also, the old security camera has 2 huge lenses, so that would be quite trivial there. Regarding technically modifying vulnerability to various weapons, I can give the security camera an own ::Damage method that is passed the reference to the inflicting entity (broadhead, sword etc.), so that's not a problem. The main thing is to come up with a "damage_mult" spawnarg system that lets the mapper tweak these vulnerabilities. Also, a damage threshold isn't currently an option because fire arrow splash damage does less damage than a broadhead, but I think that was because the security camera until now used the base idEntity::Damage method, which discards some of the information from the incoming hit (i.e damageScale) and simply just reads the damageDef. I think a threshold isn't really needed anyway if you can use damage_mult spawnargs - the only thing I'm using a damage threshold for is to decide whether or not to flinderize a dead security camera. And yeah, this is all customisable, we're talking about establishing the standard TDM behaviour here. I'm all for making a turret, btw, especially if someone has a good model and projectiles to work with - but one thing at a time.

I think we should establish a convention for how security cameras can be disabled, damaged and destroyed. My proposal for the default behaviour would be the following: - fire arrows: 2 indirect hits would break it, 1 direct hit would obliterate (flinderize) it - water arrows: switch the camera off for 10-15s and make it spark. Let 3 shots permanently disable it so it can't be switched back on. - sword & broadhead arrows do no damage by default. A stretch goal would be to let a precise shot at the lens make it blind. - blackjacks do no damage (they don't seem to damage anything anyway)

The Painter’s Wife v1.2 is ready for beta testing! Compared to previous versions, this is a more modest update: One of the main features is that the FM archive has been cleaned up thoroughly, resulting in a much lighter mission that now weighs in at just 160 MB without compromising on content. The level has been tweaked and polished all over the place with an aim to improving lighting and performance. In particular the secret chapel is worth another look. The console has been used to track down numerous bugs that went undiscovered until now, in addition to some “regular” bugs that were reported. As always, a handful new locations have been added, such as a tiny roof garden on Kings St. Also note that the loot in the secret spider cave counts as the 14th secret now. A more detailed changelog can be viewed here: Anyone who’s interested in trying this out would be very welcome to do so by downloading from this link: Google Drive For providing feedback, please use the FM’s betatesting server on Discord (channel beta-v1-2-b1) or send me PMs on these forums.

Seems odd that the top results check for "0" instead of 0 like most other integer checks. Anyway, that's all there is for " == " in the core and FM .gui files. Maybe there's a reason why there's no (non-spawnarg) string-checking in the whole of TDM, such as that it doesn't work. Or the string syntax is just completely different from what we expect, but that spawnarg string check suggests otherwise.

Was just to show how the syntax is for an integer, and that the code should also be able to do a string check in that kind of expression, given the string functions neighbouring the int functions in the code. I've done a search of the .gui files and noticed that there are few expressions where both sides of the equals sign are in double quotation marks: The bottom result seems to check for an empty string, the top results seem to refer to "0" as a string and the music check is probably with strings too. The modes are probably just integers.

The best I can offer is this expression I used in Down by the Riverside's campaign briefing: if ("gui::CurrentMission" == 1) The value for CurrentMission seems to come from player.cpp and Game_local.cpp: gui->SetStateInt("CurrentMission", missionNum); SetStateInt is defined in UserInterface.cpp. There one also finds GetStateString and SetStateString.

It's not possible to change the files of an FM while you're doing a playthrough of it, some changes will have no effect while others will cause savegames to break.

IIRC the spawnargs for a func_pendulum are freq and speed, though "speed" effectively also acts as the swing angle (because the time period is already determined by freq). Angles is just a generic spawnarg that describes how an entity is rotated on the horizontal plane. Btw, the idea with binding a func_pendulum to a rotated model is to change the direction in which it swings. While the idea with binding a model to a func_pendulum, instead of making the model itself a func_pendulum, is to allow the model to swing from a different origin than its own.

@Araneidae Odd, seems that the map didn't compile properly in that version, thanks for the heads up. I'll have to make a new .pk4 from the latest build.

It's possible that the AI re-reads the spawnargs for what doors it's allowed to open. You could try adding a frob Response to the key (Entity -> Stim/Response... -> Response) with an effect that sets the canUnlock spawnarg on that AI to -. In my experience the skybox is only rendered when the player can see an area containing a portal_sky surface, you can see this when standing in a caulk-textured room and opening a door to a portal_sky-textured room. I don't know how GPU memory is handled, though.

Those look like leftover spawnargs from a door, not something a func_pendulum would have. You could just use s_shader, that always plays.

Just to be sure, are you trying to load an old savegame with the new FM files? And how far does the loading bar get?

@johlkien Good to hear that your integrated GPU also benefited massively from that cvar when it comes to loading times. What you could also try is the 140 MB version of The Painter's Wife (aka v1.2, not official yet). It should be almost exactly the same content, just that the archive has been cleaned up and what's left has been compressed or fixed by taking advantage of some recent DarkRadiant fixes. Loading times are probably a bit longer because of the extra compression, but maybe the FM performs better because in some regards there's less to hold in memory. You'd have to make a new save, though.

iddevnet.com has gone down at long last, so anyone wanting to learn about the FX system has the following options until we have our own documentation: Use the Wayback Machine: https://web.archive.org/web/20200613234848/https://www.iddevnet.com/doom3/ Download the website as a .zip from moddb: https://www.moddb.com/downloads/iddevnet-archive Download the website as a .zip from the TDM server: http://ftp.thedarkmod.com/backup/iddevnet.zip

@sohda@DestinedWhat I meant was to open the .map in notepad, find the entity with "name" "atdm_teleport_10" and change its "classname" from "atdm:teleport" to "func_remove" so that the entity performs a removal instead of a teleportation when triggered. There's no need to change the scripting.

@johlkien Regarding loading times, I have a PC in a similar situation as yours (onboard graphics, loading times longer in 2.09) and found that I could get much faster loading times by applying this with the console: image_useNormalCompression 0 This stops your PC from compressing normalmaps during loading. In theory this should lower your fps if you run out of graphics memory to store all those huge normalmaps, but I didn't notice a difference, only much better loading times.

@VanishedOne An alternative that I just found is this zip of the website on https://www.moddb.com/downloads/iddevnet-archive Now also from the TDM server: http://ftp.thedarkmod.com/backup/iddevnet.zip

Generally speaking the FM often uses teleportation entities to "remove" entities by bringing somewhere where they can't be seen anymore, i.e. teleporting AIs behind a house outside of the map boundaries. It'd probably be worth for kyyrma to switch all those teleporters to func_remove, too, so that removed AIs no longer contribute to processing load.