OrbWeaver

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 like Greebo has a solution in hand. ¹ Technically it's a tree, but a very shallow one where most entities are direct children of the root node, stored in a simple linear list.

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 might apply the spawnarg change onto the wrong entity (because the ordering in the map file isn't guaranteed to be stable)? Perhaps it will be necessary to add a UUID into each created entity so that it is always clear what the target of a merge operation should be. EDIT: Never mind, entities have unique names, so the above ought to be a non-issue (and I assume the current merge algorithm is already using names to match entities). But UUIDs might be an option if collaborating mappers want to edit their entity names for organisational purposes, and still have merged spawnargs apply correctly.

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 add up, perhaps even to the point where it can generate map leaks.

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.

We don't currently have PCH at all on Linux, although in theory it should be possible with CMake 3.16 (which has a new directive specifically to support it).

That is actually impressively fast. I think it might even be faster than my Linux build. My guess is that confusion probably arises from two things: CPU time versus physical time — 600s could be 100s on 6 processor cores in parallel. Overlapping parallel processes incorrectly interpreted as being summed together — a 600s process feeding data into a 500s process might result in a a wall time of 600s rather than 1100s.

Fair enough. Thanks for going to the trouble of producing the analysis. Presumably the problem is the complexity of the templates, rather than the mere existence of templates? After all our original Vector classes were already templated on the element type, although we only ever instantiated them with <double>. Eigen's templates are considerably more complicated with their MatrixBase, DenseBase and other helper parent classes. It's odd that there isn't a way to tell the compiler "instantiate this complex template once, then use it everywhere else as a simple inlined class". I'm pretty sure that once all the helper templates are processed, the Eigen code must reduce to the same sequence of basic multiplications; you'd think there would be a way to get to the end point without having to deal with the semantics of template parsing each and every time (which is what I assume causes slow compilation). I suppose this would trade compilation speed for application speed (since you'd need actual function calls instead of inlined code for even simple operations) so would probably be a pessimisation from the user perspective.

I think some more context is needed here. Is the build noticeably slow (in terms of wall clock time), and impacting development, or is this purely a theoretical concern based on profiling data? Assuming that the data correctly identifies Eigen template compilation as being slow, does this affect all kinds of change, or does the slowdown only happen when you change something fundamental like the Matrix4 header? I'd be perfectly happy to use pre-compiled headers to avoid compilation cost (especially with the maths classes which don't change very much), but I have no experience with this technique (I think it's largely a Windows thing).

Probably — I imagine many video playback applications are using textures around that size. But it would need testing of course.

Note that non-power-of-two and non-square are two different things. In general it's never really been a problem (AFAIK) to have non-square textures that use powers of two for each side (e.g. 1024x512, 256x8 etc), and you might well find that you can fit your textures into this scheme. There's also a difference between non-power-of-two and not-a-multiple-of-anything-sane — you can probably get away with 768x768 (not a power of two, but still a multiple of 256) but I really wouldn't try 757x343 or something weird like that. In any case, if DR is showing a black texture and there is definitely nothing wrong with the material def or texture itself, that should be reported as a bug I think. If the GPU supports it then DR should too.

Is it really possible to break existing missions just by providing higher-res replacements of existing textures which are otherwise identical in terms of pattern and appearance? I suppose there might be problems if an artist has done something really weird like zooming into particular pixels to colour part of a model, but that seems an unlikely use case. Increasing asset resolution seems like the sort of safe change that the mod team should be able to make without much objection. The danger of having separate versions (other than a slight increase in total mod size) is that mappers might not notice or realise that there are specific "HD" versions that they need to select, and inadvertently release a new map using needlessly low-res textures.

Perhaps a dumb question, but what is your Quick Load key actually bound to? Is it possible it has been bound to something non-standard (like Left Click) which is being pressed when you start a mission normally?

I think the junk objects problem will be largely solved once the new frobbing physics is implemented, so you can actually pick up junk and put it down quietly (just as you could in real life) without alerting every guard in a 50 foot radius. One thing that would potentially even more useful than highlighting loot objects, would be using the highlight to distinguish between "about to pick up something" and "already holding something". To me it seems that the current interface makes no distinction between these two states, so I don't know if I'm actually holding the candle until I rotate the view and see if it moves with me.

Just to be clear: you're going through the New Mission process, past Objectives, Briefing, Purchase Equipment etc, to start a completely new mission, and then the game is complaining about loading a savegame?

The reason ID worked around the Carmarck's Reverse patent is very specific: when you make a GPL release, the license requires that you grant a patent license for any patent which might cover the code. Since this was a known patent which was not owned by ID, they could not legally grant this license, and therefore had to remove the patented algorithm from the code before making the GPL release. I don't think they were particularly worried about being sued by Creative, otherwise they would have removed it from their closed-source code long before the GPL release (or maybe they negotiated a commercial license with Creative, which covered the commercial Doom 3 but not any subsequent GPL releases). Note that some people have said that the Creative patent is actually invalid, and as far as I know it has never actually been taken to court, so this whole thing is something of a theoretical risk (a bit like open-source implementations of FAT which are widely used despite possibly infringing patents by Microsoft).

The GitHub repository is Greebo's, the GitLab one is mine. Code is synchronised between the two sporadically (usually after a release or one of us implements a significant change), while at other times the code may diverge.

That's amazing. It seems we were only discussing this a couple of weeks ago, and I assumed that graphical map diffs would be the most complex and difficult feature which would probably never see the light of day... but you managed to implement it anyway.

I don't like the idea of bolding everything, it will just make everything look really loud and in your face. Bold should be used for occasional highlights, not as the default text style.

Thanks for locating the relevant code. I fixed it not by choosing a standard colour but by defaulting to no colour at all, which seems to use the default theme-appropriate colour just like the fixed entity property list.

We don't have full control over asset design (even if all core assets were made consistent, mappers can produce their own custom loot, and frequently do). We do have almost full control over the UI. Therefore, "compensating for [inconsistent] asset design with the UI" is exactly what is needed to solve this problem. This actually adds even more weight to the idea that the frob highlight should not vary on a map-by-map basis.

It's not as simple as that. Players' preferences matter too. Should a player with colour blindness be forced to have a frob highlight they can barely see because a mapper thought that a particular colour looked better? And if the frob UI can be configured by the mapper, why not other UI settings too? Perhaps a mapper thinks that their map looks better with bloom enabled, and all players should be forced to have bloom (after all, this is clearly an artistic element of the map)? What about gamma? Can a mapper insist on a super-low brightness setting because they think their map looks artistically better in almost complete darkness? Clearly there is a line to be drawn between UI elements which should be under the mapper's control and those which should be left to the player. We can disagree about exactly where that line should be, but I don't think it's very helpful to boil it down to some simplistic morality play about mappers' "artistic choices" being "restricted". I meant the majority of the people who had expressed an opinion in the internal discussion thread. Others are of course free to speak up if that is not an accurate assessment of the situation. There's also the implementation to consider — even if everybody were to agree that some frob highlight customisation should be possible by the mapper, this should not derail the plans to remove the material stage based implementation which is a horrific hack designed for the closed-source engine and no longer makes sense with a fully open-source codebase.

Because the majority opinion amongst the team is that the frob highlight is an aspect of the UI, not the world, and should therefore be customisable by the player (for accessibility and personal preference reasons) but not by the mapper. Just as mappers can't override the screen resolution or force you to play with uncapped FPS.

Exactly this. The visibility of the frob highlight has absolutely nothing to do with the light falling on the player (as reported by the light gem) and everything to do with the light falling on the frobbable object. In order for this approach to work you'd need to measure the rendered brightness of the frobbed object before deciding whether to use a bright or a dark highlight. I don't know how feasible or performant this would be in modern OpenGL, but it definitely sounds hacky. I also don't think it would be terribly intuitive for users — never before has an object become darker to indicate that it can be interacted with.

The trick is to focus on how you ask. If you go in all guns blazing, with something like "Your code is obviously wrong and does not use variable X where it clearly should be" you're likely to piss people off (even if you're correct). However, nobody (reasonable) will be offended if you ask an honest question in a polite way, e.g. "I am trying to adapt this code for another game but I'm confused about the correct usage of variable X, which I can't find in the code. Is this no longer required?". It's quite possible that there is a good reason for the code to be written in the apparently "wrong" way, but if not, your asking about it might prompt the developers to notice the mistake without it seeming like you're calling them incompetent.

I don't think anyone is suggesting that music recordings don't have copyright. This is a thread for "Dark Mod inspiration", not freely reusable assets.