OrbWeaver

This actually came up in a earlier discussion about Greebo's new favourites browser. Since the favourites browser can contain things other than textures (although I don't know if this is active in the released builds) there is an open question about how things like models could actually be inserted from the favourites list rather than the right-click menu. I actually like the idea of drag-and-drop asset insertion, although it would probably require some fiddly coding under the hood since DR's selection system is somewhat complicated. Even better would be if models could be shown on a 2D g

I definitely wouldn't vote for a custom implementation of the notebook control, but there are a couple of other options: Only use icons for the tabs, at all times. This would require very clear and obvious icons (which work in both light and dark themes), and still might be less useable for new users who don't know what each icon means. A hack whereby we dynamically set the style to show or hide text, based on the current overall size of the dialog. This wouldn't be ideal because we'd have to basically guess the size threshold for hiding the text, and this might not be the same o

Tears of St Lucia — no helmeted or lamp-carrying guards as far as I recall, easy to blackjack most of them. Working out how to safely get into the church can be something of a puzzle though, which you may or may not enjoy. In the North (William Steele 1) — well-designed mansion interior, I don't remember any helmets or lamps, although there are quite a lot of guards in total.

This sounds like something a Python script ought to be able to do. Either it could create a series of individual patches with matching texture coordinates, or it could displace a single large patch in a stair-stepped shape.

I suppose you can say they are in the same world, but not necessarily the same series — in the same way that Fantastic Beasts is part of the Harry Potter universe but not part of the main Harry Potter storyline.

I guess you're misreading the Wiki description for Braeden Church, which says: This means "Braeden Church is not part of any series". It is not referring to In The North, which certainly is part of the William Steele series and is listed in the downloader along with all of the other WS missions.

Aren't all the William Steele missions prefixed with "WS1:", "WS2:" etc? Try scrolling down to the missions which start with W.

If a model is out of view it will be culled anyway. There's no benefit in trying to use portals to do "manual view-frustum culling" when the engine already has automatic view-frustum culling to do the same job. If the idea with that screenshot is to make a huge horizontal portal flush with the top of the selected box, I struggle to see any viewpoint from which such a portal would provide any culling whatsoever. But perhaps testing with r_showPortals and r_showTris would prove me wrong.

You need to consider the sightlines and work out exactly what is going to be culled by each portal you propose to add. Will there be any vantage points from which your proposed portals will actually close, or at least substantially reduce what is seen through them? If not, then your portals are worthless. Portals are not go-faster stripes. You can't just dump them haphazardly into your map and expect to see performance improvements just because "I have lots of portals now". They need to serve a specific, technical purpose in restricting visible geometry.

I haven't seen any suggestions that NPCs specifically will have their own colour. It wouldn't serve any purpose — everyone can tell the difference between an NPC and a junk object. The only suggestions for colour coding have been loot vs other objects, and so far this has been nothing more than discussion, with no actual implementation as far as I know. Of course all the colours will be customisable, but it might take the form of cvars rather than explicit menu items.

Interesting to learn that TAA applies a jitter. Reading about TAA and its focus on motion I could never understand why TAA looks so good in Elder Scrolls Online even when I wasn't moving, but I guessed it must be doing some kind of "simulated motion" when the player is standing still. At work I implemented a basic jitter-based antialiasing for our spline rendering years ago (four samples for every frame in a fixed pattern), but never really thought of it as "TAA" — perhaps we should advertise it as such. Personally I wouldn't choose to use FXAA but I have no objection to it being availabl

Although I didn't implement the search by entity number feature, I'm 99% sure it has nothing to do with comments in the map file, since these comments will be lost as soon as the map is read into DR's internal data structures. There is no way to have "duplicate" entity numbers because there are no entity numbers: the "number" is just an emergent property of having a list of entities in memory¹ which can be counted in order, and it's impossible to have two different entities at the same position in the list. The name clash problem you describe is indeed a valid concern, although it sounds

I don't think entities currently have ID numbers — at least not explicit numbers written into the file. There is a comment written into the map file e.g. "// entity 24" but comments aren't part of the parsing operation. The entity number is therefore derived from the position of each entity in the file relative to other entities. Merging and collaboration does raise the issue of whether there should be unique entity identifiers, though. If mapper A edits a spawnarg on the 10th entity, then mapper B adds 15 new entities and tries to merge mapper A's work, is there a danger that the merge m

It sounds to me like the precision is acceptable. We're not using these rotations for motion tracking or precision engineering, it's mainly for rotating models (most likely in steps of 15 or even 45 degrees). I presume most mappers won't notice if their 15° rotation is actually 15.02°. The reason we use doubles everywhere is because when we tried floats, we started seeing inaccuracies in brush coordinates. When brushes are a long way from the origin and have a bunch of cumulative operations done to them (splitting, edge dragging etc), the combined error in the face coordinates starts to a

Well, the good news is that this turned out to be really easy to set up. It's one line of CMake which Just Works, although I wrapped in a CMAKE_VERSION check to make sure the build won't break for those who don't have CMake >= 3.16. The not so good news is that this only seems to shave about 5 seconds off the compile time, from 3:44 down to 3:39. Perhaps it delivers more benefit when you're doing an incremental re-compilation after some code change.