Dragofer

There is a bugfix after beta5 for new security cameras always reacting to AIs that are on hostile teams (i.e. zombies) regardless of the new seeAI spawnarg. Security cameras in existing missions shouldn't be affected at all by this bug anyway. Apart from that security cameras are more or less locked in for 2.10.

Yes, as well as a way to encourage players to try the game mode (how many people would have semi-iron manned Hazard Pay of their own volition?) and a way for mappers to know that (most) players will be playing by those rules on that difficulty. Like how a mapper knows the player will have limited equipment during the early phase of a jail-break mission.

It's a choice that players voluntarily subject themselves to by selecting that difficulty before starting the mission. The team has no plans to get rid of manual saving, and the missions can be played with regular saving on other difficulties. It's a way to force themselves to deal with the consequences of getting busted or missing a shot without having to resist the temptation of that quick-reload hotkey. It's been described by several players who have played Hazard Pay as increasing adrenaline in tense situations. Kind of like bungee jumping, which is for those who get a kick out of it and no one else is going to be forced to do it.

This part has me thinking there's a misunderstanding. FMs that offer "save room" modes will also offer regular modes with unrestricted saving that you can choose instead. Is your argument that you only want to play a mission on Expert difficulty, which is probably going to be the difficulty that would have the restricted saves? The technical implementation of new gameplay modes can probably be improved so that it doesn't need to use up a difficulty slot. As for mapper time investment - some players enjoy this mode, and some more players would enjoy this mode but might just never try it without a mission that's designed for it. I think it's good to cater to a variety of playstyles in the mission catalogue. Thief FMs intentionally change up gameplay all the time.

That's probably the result of LOD for lights being fixed in 2.10. Kyyrma probably attempted to apply LOD to these lights, found it didnt work, and left the spawnargs on them.

@AluminumHastewell, you did learn all that in missions without save restrictions and can now apply that, in a pinch, to help you get through survival FMs like highest-difficulty Hazard Pay. I think the main problem here is that you risk up to an hour of progress. If it were more like 10 minutes I think the outlook would be somewhat different. For a veteran player that loss shouldn't happen too often, while still having to be mindful of the possible consequences of your choices.

This is my approach to arbitrary restrictions too. They often feel to me like a quick & dirty shortcut to having multiple difficulty levels without putting effort into organically making the mission harder by changing how it's designed. That said, I think for a horror survival mission like Hazard Pay there is a believable justification to restrict saves, just as there is a believable justification to start a jail break mission without your blackjack. It's an intentionally designed gameplay experience to make you feel at risk, cautious and plan for what to do if things go wrong. As peter_spy says, there are whole games designed around this kind of gameplay. For a regular mansion heist save restrictions would feel artificial, but for a survival mission it's a part of the experience that the mission has been designed for. And as said, if players don't feel up to it they can choose a different mode. My regrets are that this takes up one of the difficulty slots, so one potentially can't have expert-level mission design without save restrictions, as well as my earlier points about unfair deaths and losing progress if you run out of RL time for your session before you make it to the next save room.

Personally I think objective types that typically fail a mission instantly like no kills or no knockouts can be disabled relatively safely. But as kingsal says it's possible that authors foresaw something else to happen than the mission failing when such objectives are failed, so you'd have to identify what the consequences of failing the objective are. This could be done by checking for the Mandatory flag and checking whether the mission has specified custom mission failure logic that includes these objectives. For disabling loot objectives I would lower the loot requirement to a symbolic amount like 1, just so that any associated events can still fire. Regarding the save restrictions, I think having a console-based cheat for them would make sense just like we have for god mode, notarget, noclip. It's on us if we use cheats irresponsibly (i.e. playing the whole mission with notarget enabled), but cheats do have their place and would in this case allow to experience Hazard Pay's expert-level AI placements etc. without having to make enough time IRL to make it to the next save room.

I fixed that the first time around by reducing the size / mins / maxs spawnargs of the bat to fit inside the maximum bounds allowed for that aas type. You can see the max bounds allowed by looking at the aas entities in the Create Entity menu.

Thats probably the problem. Did you restart TDM or reloadDecls after changing that to aas96?

Note that the security cameras in those missions should still have the old, simpler behaviour, so i.e. no tracking of the player.

Did you try deleting the .aas96 file from the maps folder and then dmapping again?

We do have a func_beam entity which has been used for a tripwire entity to trigger a mine. Problem is, I couldn't get the func_beam to work well (probably very limited or got broken as TDM developed) and the tripwire is excluded from release, most likely due to too many problems.

It's a mechanic thats only enabled on the higher or highest difficulties. It's only a problem if you want to play on Expert difficulty. Goldwell's way of handling that was to only have 2 difficulties (normal & expert) and use the 3rd slot for a save-room version of expert. Regarding the merits of the feature, I think there is something worth addressing: its just so easy to quicksave before every turn, and quickload as soon as someone sees you. I think people are missing out on a good chunk of the thrill and features that the gameplay could offer because of abuse of quicksave. Problems with restricting saves: - unfair-feeling situations like failing to jump onto something (especially because of physics issues) and thus falling to death. Anything that could cause instant death should probably be implemented very cautiously. - not being able to end the session when it suits you, possibly losing a good chunk of progress if something in RL comes up. Probably should offer more, rather than fewer save opportunities - and allow to use previous save rooms without penalty in case those are closer. - restricting saves is an arbitrary restriction like "No killing" that players could just as well impose on themselves. This feature is only needed for those who want to play without saving so often but dont have the discipline to stick to it / or who would never try it out in the first place. We should probably also offer some kind of cvar to disable the saving restrictions, no questions asked.

Editor tooltips are defined separately from the values for the spawnargs. For example: Tooltips are inherited in the same way as the values, so if an entityDef doesn't override them then they'll be used from the inherited entity. The fact that you dont see the tooltip might be because of a bug in DR 2.14 with inherited spawnargs that causes, among other things, the tooltips to not be shown on inherited spawnargs.

Yeah please use spoilers in order to avoid spoilering people who haven't found the things you have found, especially the 2nd half of the mission. You can put something in spoilers by clicking on the eye symbol, at the top of the text box. Re: blow torch - I think that's a question from the Hazard Pay mission by Kingsal. Re: where that leads to:

The dev builds are older than the beta builds - you need to download the latest build from the "beta" category in the installer. The script error happens if the TDM .exe doesn't contain certain script events ( so, outdated ).

@madtaffer By the way, please use spoilers for that part of the mission at least for now.

Could be you still have a leftover .aas96 in the maps folder.

The goals of the contest are unchanged (connect to other FMs and use new core features), its just about making sure the reward for using new features doesnt weigh more than the voting. Its also not the first time it was mentioned. And I'm a little surprised that most of us don't seem to really care about the contest aspect. I don't really mind since I generally prefer collaboration over competition, but I was around to see the Vertical (2010), Beginner (2012) and Halloween (2015) Contests and it felt to me like most participants were in it to win it. Ofc the outcome was only symbolic (i.e. no rewards except a title below the avatar) but I think people just enjoyed the good-spirited competition aspect and the voting at the end was an important part of that experience. Well, maybe that's just not feasible here with several of the participants dropping out and an uneven playing field overall in terms of mapping experience (12 years after TDM's release), number of authors and prior work on the FMs. Yeah 30% of the score sounds alright. My feedback would be that it's quite easy to max out the reward since you only need 2 features and 1 asset (i.e. volumetrics, secret tracking and a cabinet1-type furniture piece). Could reward use of more features by giving fewer points per feature, i.e. 2x and 1/2.

Animal patrol causes them to randomly path around in a 240 unit radius, ignoring actual path nodes. Its intentional. Btw, you can put a tick in "Show help" atop the Entity Inspector in DR to show editor tooltips for spawnargs that have them.

We should also reconsider how the scoring system will work for this contest. Realistically we might have around 30 voters per FM, so if we dole out 2-6 additional perfect votes per new core feature or asset used the contest will be primarily decided by the length of the feature list, not the quality of the FM. The way contests usually handle this is to reflect in the voting criteria how well the FM adhered to the contest theme. Either as a separate voting category or rolled into one of the existing categories like "Gameplay" (i.e. use of new features) or "Story" (i.e. connection to other FMs). In this case we will need to agree on a wording for how voters should vote in each of the voting categories (Gameplay, Appearance, Story and maybe Contest Theme). This is complicated by the fact that most voters probably won't know whether a feature is newly added to core or they just didnt come across it before in the FMs they played. We might still want to reward a small(!) bonus per new core feature to guarantee at least some recognition for the effort and risk of implementing these new features.

I think having the deadline be the 2.10 release date would also be a viable option, and it would make sense to extend the deadline if 2 out of 6 contest FMs (by goldwell and jonri) won't make it for RL reasons. This would of course require an expected 2.10 release date to be set. Note that the team recently agreed to wait with the 2.10 release until some time after the contest FMs have been released to see what bug reports appear when a wider circle of players has access to them. Regarding fairness - the contest rules IIRC didn't mention that authors couldn't team up or had to start from scratch, so we have 1 multi-author FM and 1 FM that was already in the works long before the contest. I think it would be good sportsmanship for those 2 FMs to adhere to the original 28th deadline as closely as they can - but ultimately we want to have polished FMs that enrich TDM, so maybe those FM authors should just list what they did after the 28th so voters can take it into account if they wish to. I believe this is mainly the video briefing for the former FM and my reworking of the "Hitman" script as well as bug fixes for the latter FM. By the way, I'm now also listed as an author for the FM started by Amadeus and Bikerdude since I've contributed substantially to its development by way of my offer to assist all contest participants with implementing new features and solving problems they run into.

It should definitely be in 2.10b5, which came out quite recently and is available from the installer like all other beta builds.