Leaderboard

I threw together a really basic proof-of concept: https://streamable.com/9m9vgd None of the options in the dialog are actually hooked up yet, but it's just a matter of adding the math for them. The actual brush creation seems to be working ok (although I had to get a little creative with the scripting to do it, which I should probably improve in the DR source code itself).

Hey guys, I am also coming from Thief and working with marbleman to specify the ghost rules for TDM. I played it a bit some years back, but have recently picked it up again. I agree alert levels are more difficult to detect, and guards are much tougher to fool up close. Probably due to settings needing to be on hardcore. The biggest problem I found so far is enemy reactions aren't consistent. They pivot their heads randomly and when they do, it actually changes their viewing angle. So you could be lucky sneaking through a room if the guard doesnt turn his head. This never happens in Thief. A good example is if you're crouched behind a counter and stand up visible in a guard's periphery. Suddenly after 2 seconds he alerts, then you reload and next time it might take 6 seconds. In Thief it's always instant or not at all. It will take a bit to get used to, but I dont think it will be difficult to specify in the rules. As for the question about keys made and dropped off for you, these could probably be brought along and not returned for Supreme. If you make a key in a foundry or something, then you are not supposed to drop it back, because this will actually leave evidence instead of removing it. A key left for you by an accomplice would be a similar situation.

One more pre-release build available in the first post, before 2.13.0 will be posted on the website. I've finished the first implementation of a three-way map merge, allowing to incorporate changes from another map into the active one - by specifying the base version both maps have been started from. This way all the changes that have been made to the loaded map will stay intact, and only the actual changes made to the other map will be applied to this one. Just a quick textual description, before any tutorial is going to be posted eventually. Let's say mapper A takes the map M1 and works on the harbour section of the mission, then saves it as M2. Mapper B took the same map M1 and added a house in a different section of the mission, saving it as M3. When merging M3 into M2, only the house from M3 will be imported into the active M2 map. Including layer changes and selection groups. In case both mappers manipulated the same section of the map, the merger will still try to incorporate the changes, unless there's no reasonable way to do so - in this case the conflicting elements will be highlighted in the map and the mapper is asked to resolve it. By default, no conflicting change will be imported, unless the mapper chooses "Accept this change". The whole thing is meant to form the algorithmic base for adding version control support to DR, most likely in the form of a Git plugin. This is something that has to be discussed though, feel free to share your thoughts.

For those of you who haven't seen it yet, Boy Lag has started playing through all of the WS missions and is currently playing WS 3. I think Boy Lag found the right words to describe the situation.

Nicely done. I have lamps in 2 WIPs that could certainly use this effect. Thanks!