nbohr1more

yes

Added a note to this wiki: https://wiki.thedarkmod.com/index.php?title=GUI_Scripting_Language#The_Basics_for_Mappers

Thanks! I am guessing that other fixes need to be done to "Shadows of Northdale: Act 1" ( launches to a black screen ) ?

That blueprint looks like an image rather than a 3D file format? If so, mappers can use the background image feature to trace the geometry in brush / patch form: http://orbweaver.gitlab.io/DarkRadiant/#_adding_a_background_image That said, the is probably a good AI tool that can convert blueprints to geometry formats such as ASE or OBJ

Could be something funky going on with our implicit RGTC compression. We use a Microsoft BC format for pre-compressed normals but our on-the-fly encoder is supposed to use standard OpenGL tangent space normals. I wonder if the work to fix BC loading had some unintended effect on uncompressed loading? Maybe @orbweaver can be convinced to take a 2nd look?

In our SVN under the devel folder we have a font source sub-folder. Do we know for sure that these are all newer?

Arrows are a core part of TDM. They should be moved to C++ and have dedicated Cvars for both players and mission authors. Plan: 1) Implement Arrows in C++ ( evaluate changing some old defaults ) 2) Make associated Cvars "non-archived" 3) Mappers add mission.cfg to enforce their customizations 4) Players can alter mission.cfg to their preference Along the way, reduce some of the performance impact of the weapon script constantly invoking "raise torso" and other nonsense due to using scripts rather than C++ https://bugs.thedarkmod.com/view.php?id=4203

2.12 we introduced the mission.cfg We just need to ensure that the cvars revert when switching missions.

Early TDM 15yr anniversary contest entry?

The Megatextures concept predates idSoftware. It even predates hardware accelerated 3D in consumer graphics. The problem it solves is managing image diversity. It is well suited to photogrammetry where almost nothing is repeated \ tiled. It is not well suited to human texture artists because even the most perfectionist ones are going to use some sort of template that they repeat and thus it is a waste to store the resultant work as unique pixels rather than tiles.

Rage didn’t have terrible loading times but people complained that it took awhile for the texture fidelity to catch up. Doom 2016 tried to fix that by front loading more but they went overboard with that.

I think that this discussion is probably similar to discussions that idSoftware themselves had about the challenges of texture storage in engines that heavily rely on Normal Maps for real-time lighting. The conclusion was Megatextures ( later known as partially resident textures ) but the suggestion was a little too ahead of its time. Heck, early Megatexture games would probably benefit from detail textures more than idTech4 because they capped the pixel density to allow larger map-sized textures. Many modern games have caught up and use partially resident textures but do so in a more conservative way thus making them part of a hierarchy of texture usage methods that includes texture atlases and traditional tiled textures.

The translation pack for The Outpost is now essentially the same as the one at Darkfate.org. I'll probably do this for most of the old dormant missions.