Leaderboard

I got a pre-release build to share, in case somebody wants to tinker with the current state a bit. I probably won't be able to work on it for a few days, so I might as well get some feedback in the meantime. Don't use this for your productive mapping work, it's probably full of glitches and crashes. The Material Editor can be found in the "Entity" menu for the moment being. DarkRadiant 2.12.0pre1 portable x64: https://drive.google.com/file/d/14Q9d1N7iuv1g8EquSb7IlF5zhCpYn6j9/view?usp=sharing

https://www.gog.com/giveaway/claim Got a hit, let's see what it was. https://www.gog.com/game/xiii https://en.wikipedia.org/wiki/XIII_(2003_video_game)

DR calculates and processing bounding boxes internally and they are pretty simple to render, so I don't think it would be all the difficult to allow visualisation of model bounding boxes if enough people felt it would be useful. We'd probably want to check how the game calculates them to make sure we were generating them with the same size (i.e. if there is an internal margin making the AABB slightly larger than the true model bounds).

Used to have an old Asus with a Phenom II and a Radeon HD6950 and 8GB RAM on some old 60Hz monitor Now I'm running a Legion5 with a Ryzen7 3700X and a GeForce GTX 1660 Super and 16GB RAM on a curved 144Hz monitor It's really nothing special by today's standards but all I've wanted to play the past ten years was TDM so I can thankfully crank shit up without slowdowns and running around my WIP actually got me randy. Felt like a brand new game! (new S.T.A.L.K.E.R. Anomaly 1.5.1 with some new modpacks was super sexy too) Now I can let my kid destroy the old PC with Roblox all he wants and I don't have to worry about losing my precious work. Oh, and DR runs soooo much better too, I expect my mapping workflow to dramatically speed up, so maybe after six months of radio silence on my beta, I can finally have something to show.

I personally like a somewhat more open ended "resolution" to things. Especially horror. The more clearly or concrete you understand something, the less you fear it. The choice of taking or leaving the primary loot, the thing you came here for in the first place, was a really nice touch. Especially in a Thief type of game. I think this mission did just enough setting up of expectations only to turn the tables on you in the end. For example... I felt the story, the history of the stone and the events that happened with the family, was implied enough in the various readables scattered about. I like the very simple "Forgive me..." note in particular. Where it is placed and its obvious implications really set an ominous tone. Its clear from the start that nothing good happened here.

It might be possibe that if the key is not picked up early, it may get kicked around and lost. To try and avoid that issue I wanted the player to pick up that key early. The body should be one of the main things in the hall that draws attention to the player, so providing the player wants to look at the readable they should easily notice the key sitting on top. I tried to stop as many out of bounds areas as I could although I didn't extensively check every part of the map. Getting out of bounds can be fun for the player in a way. Have a look at a lot of AAA games where speed runners just destroy entire missions by completing the whole map out of bounds. I didn't intend for there to be a resolution to what's going on. I understand some people like to have the story wrapped up nicely. I did hint as to what might have happened to some of the family in the note located in the upper sewer maintenance room (after you climb the ladder). I've found that whenever I watch a good horror movie, most of the time the ending disappoints when everything is explained and there is no mystery after it finishes. I went for a more blair witch style where you are left in the dark as to what is going on.

When using modules the wall segments are normally either patches or a brush with all sides caulked except the one facing inside the room. In regards to the 8+8 I mean that the wall surface is 8 doom units away from a larger grids line, but I do not seal each room with its own caulk shell. I place the modules and add the caulk afterwards, which, if in between two adjacenting rooms is usually an 16 doom units thick brush. It can happen that if added afterwards there are two brushes. It doesn't make a difference for caulk walls, though, so you can do it both ways or as it suits the situation. Check out the threads dealing with modular building techniques as well as information that can be found via google on that matter. There is plenty of information on that matter available. Creating angled brushes works imho best by either clipping them or by dragging the vertices in suitable place. Especially for sealing geometry it is important to have the vertices on grid. If the modules are of cosmetic nature and the windows are not openable, it is no issue for them to clip into the sealing geometry if the latter is textured with caulk. Caulk doesn't get rendered and will not occlude the model as long as some part of the model is inside the pvs.

CPU: Intel Core i5-4570S 2.9 Ghz RAM: 8 GB Video Card: GeForce RTX 3060, 12 GB OS: Manjaro Linux xfce edition Load game from ssd

been a while since i toyed with the source code but yeah it did do something in the past as well but maybe not what you would expect. The problem with it in stock doom3 was that even though it removed microstutter it also caused things to go out of sync, sound etc... also it made the game run way to fast as the original code was built around a capped tic of 62.5 (old quake 3 limit actually). This caused the game to actually run at 59 fps and not 60 which many people noticed after mucking about with this variable. In fact even after setting com_fixedtic if you used a framerate limiter to limit it to 60 fps with com_fixedtic on it would cause microstutter if you lowered it one frame more to 59 :). The code was fixed in darkmod and i been working on getting it ported back to doom3 but im mostly retired these days so it is slow going.

The problems might not be as hard as you described them, but at least pathfinding and sound propagation would suffer. However, you don't seal a cross-shaped corridor by creating a brush hollowed room around all of it. The brushes form the walls of the corridor. So if that is made out of models, you basically place caulk brushes right behind the walls. Also, using hollowed out rooms is only one way of building levels. I haven't build like that for years now. If you use world geometry mainly for sealing and culling purposes, you can create the walls as well as the ceilings and floors seperately once you need them, as they can be very rough (in terms of grid size) and therefore are unlikely to cause issues. Most of the time when I helped other mappers fixing their maps the root source of leaks (also internal ones) was, that they either created their sealing geometry on small grid sizes (the smaller the grid size, the smaller the gaps can be, and the more likely you'll going to overlook them) or that they used the hollowed out way of building and later on changed something, shifting a brush or resizing it in a way that cause a leak. This is especially bad if the leak created is internal, because it will take ages to even find out that there is an issue, not to mention the time it takes to find it. A good advice imho is to keep the detailing geometry and the one used for sealing as seperate from each other as possible. Make the detailing stuff out of models or stuff converted to func_static. Note that you can export func_statics as models which will help performance if reused (a copy of a func_static is handled as a seperate model, two instances of a model are not). And use caulk and portal_sky brushes, created on large grid sizes (8+) and axis-aligned if possible, for the sealing. This will spare you most of the headaches.

Lots of great looking screenshots this year! Mine is still very much a WIP, but I've got AI routes and main lighting generally where I want them and now I'm doing initial detail passes. I'm trying to focus on the areas I expect to be the most performance-intensive first, to minimize any fundamental rework I might have to do. I do need to set this aside for a little while in order to focus on some other projects though, so this is also a self-reminder to pick it back up in June To everyone else, keep up the great work!

The Johannes-Burock caves from the abandoned works thread are fully integrated into "Hidden Hands: The Anomaly" (changed the title, this one is much better fitting). The cave geometry has been preserved (only the outdoor area had to be removed), I even let in a sound effect from Johannes because it adds perfectly to the new ambient sound. Seemed to be a really nice place, but now nobody wants to go there anymore...and the guy lying next to his shovel is not a drunk for a change!

I don't think we need any of this, we already have TDM with much better graphics than Thief and very close gameplay!

Here's an alternative approach: https://drive.google.com/open?id=1wHJGv1txRJrpcYnqR94BL3_kBRsVAn1n The difference here is that instead of generating a cubemap, you have a single texture with the front wall in the center and the sides/ceiling/floor in perspective: I feel like this will be easier for a mapper to make, either in-game or from an external source. For this one I took a 1024x1024 envshot from roughly where the window would sit (I didn't try to be too precise), and kept only the _forward texture. I brought that into Gimp and scaled it so that the front wall was a centered 256x256 square in the middle of the 512x512 texture (use the same ratio at any size). It doesn't matter if you end up with overhang on the edges of the image that get cropped off, but conversely you don't want to end up with empty space. The new shader will follow the same pattern of perspective and slide around the UVs according to your position. My problem at the moment is that it only works if you're facing one direction. I'm not sure what coordinate space all the incoming parameters are in and how to transform them into a space relative to each face. Can someone help out here? I think the fragment shader is correct and the vertex shader is wrong. Once that works, I think we could add back in the room scaling parameters too. For reference, I tried to follow the approach here: https://github.com/OBKF/Fake-Interior-Shader-for-GodotEngine. I took out the reflect() in the vertex shader because it was messing things up and that's where I think there's a clash in coordinate spaces or I was failing to normalize things properly. For those casually curious what this looks like, the github link has a sample video of this in Godot, you can see his input textures and the ability to scale the depth.

Because I'm a programmer and I'll go to any length working on cool things that help me avoid tedious/repetitive work! A case could be made that once you've built up a handful of cubemaps, placing prefab windows with this material becomes a piece of cake. Relative to a plane with an interior map, a physical cubicle clutters up the map and is a lot harder to move around once you make it. Although, realistically this is something you'd do as a final detail pass after your map's layout and major details are all totally done. There was some interest in trying this in conjunction with a visportal that you close from a distance and display an interior map impostor at the same location. This might be hard to get lined up correctly. Honestly though, you're probably right. The real work is in making the cubemap and having to make actual room geometry as well shouldn't be a deal-breaker in terms of mapper effort or performance. That said... Maybe you could repurpose the side of the cubemap that you never see as the alpha plane and use the 4th value of the vertexParm to choose its depth within the room. Also, I tried your example and the room is currently tipped on its side... nice work though! And maybe a better compromise on mapper effort and complexity would be to use a single parallax plane instead of the whole cubemapped room. It won't look as believable when you get up close, but you could also have it fade to the window texture or something else to simulate fresnel at a sharp viewing angle where the effect breaks down.

i get these emails, but I don't have a webcam, so they are obviously not recording anything, the way they know you read the email is usually a white dot hosted on a hacked website that is in the email the software on the hacked website knows when the image has been accessed, but not by who, if you've got your email set to block images, then the dot in the email doesn't work.