Search the Community

I hope I'm not proposing some unfeasible idea that was already imagined before, this stuff is fun to discuss so no loss still. Riding the wave of recent optimizations, I keep thinking what more could be done to reach a round 144 FPS compatible with today's monitors. An intriguing optimization came to mind which I felt I have to share: Could we gain something if we had distance-based LOD for entity updates, encompassing everything visual from models to lights? How it would work: New settings allow you to set a start distance, end distance, and minimum rate. The further an entity gets the lower its individual update rate, slowly decreasing from updating each frame (start distance and closer) to updating at the minimum rate (end distance and further). This means any visual change is preformed with frame skips on any entity: For models such as characters animations are updated at the lower rate, for lights it means shadows are recalculated less often... even changes in the position and rotation of an entity may follow it for consistency, this would especially benefit lights with a moving origin like fireplaces or torches held by guards which recalculate per-frame. Reasoning: Light recalculation even animated models or individual particles can be significant contributors to performance drain. We know the further something is from the camera the less detail it requires, this is why we have a level-of-detail system with lower-polygon LOD models for characters and even mapmodels. Thus we can go even further and extend the concept to visual updates; Similar to how you don't care if a far away guard has a low-poly helmet you won't notice, you won't care if that guard is being animated at 30 FPS out of your maximum of 60, nor if the shadow of a small distant light is being updated at 15 FPS when an AI passes in front of it. This is especially useful if you own a 144 Hz monitor and expect 144 FPS: I want to see a character in front of me move at 144 FPS, but may not even notice if a guard far away is animating at 60 FPS... I want the shadows of the light from the nearby torch to animate smoothly, but can care less if a lamp meters away updates its shadows at 30 FPS instead. The question is if this is easy to implement in a way that offers the full benefit. If we use GPU skinning for instance, the graphics card should be told to animate the model at a lower FPS in order to actually preserve cycles... does OpenGL (and in the future Vulkan) let us do this per individual model? I know the engine has control over light recalculations which would probably yield the biggest benefit. Might add more points later as to not make the post too big, for now what are your thoughts?

A few additions and observations: We may get even better results using not just distance but also the entity's size, given the rate should probably depend on how much the entity is covering your view at that moment. As this shouldn't need much accuracy we can just throw in the average bounding-box size as an offset to distance to estimate the entity's total screen space. A small candle can decrease its update rate even closer to the camera, while a larger torch will retain a slightly higher rate for longer. To prevent noticeable sudden changes, the way LOD models can be seen snapping between states in their case, the effect can be applied gradually without artificial steps given it's just a number and may take any value. It might be best to have a multiplier acting on top of the player's maximum or average FPS: If your top is 60 FPS, the lowest update rate beyond the maximum distance would be 30 FPS for a 0.5 minimum setting... along the way one entity may be 0.9 meaning it ticks at 54 FPS, a further one 0.75 meaning 45 FPS, etc. Internally there should probably be different settings for model animations and lights: A low FPS may be obvious on AI or moving objects so you probably don't want to go lower than half the max (eg: 30 FPS for 60 Hz)... for lights the effect can be more aggressive on soft shadows without noticeable ugliness (eg: 15 FPS for 60 Hz). In the menu this can probably be tied to the existing LOD option which can control both model and frameskip LOD's.

Here's the DR 2.14.0pre2 build for every interested mapper to test. This release focused on DarkRadiant's texturing abilities, the Texture Tool and some of the Surface Inspector algorithms have been completely rewritten. A new model importer UI has been added with the ability to convert FBX models into a format compatible to the game (it can also convert LWO, ASE and OBJ models). The EntityInspector can now deal with more than one selected entities, showing the shared key values in the list. Copy/Paste Textures across angled faces: Texture Tool Rotate Tool (use "R" hotkey to switch) Surface Inspector Harmonise Scale / Linked Scaling Surface Inspector Normalise EntityInspector Multi-Selection Support For more things that have changed or fixed, see the list below. Download Windows Portable x64: https://drive.google.com/file/d/1-wqcqnlz8KOYpts-ap8x313yVaiQm87l/view?usp=sharing Download Windows Installer x64: https://drive.google.com/file/d/1-pSE-517B7Y-T3-VonNv4zLzUMgr-fXt/view?usp=sharing Linux folks need to compile this stuff from source, instructions for various distributions are on the wiki. If you happen to run into a crash, please record a crashdump: How to record a crashdump Changes since 2.13.0 can be seen on the Bugtracker changelog, here's the summary: #5746: Feature: Texture Tool Improvements #5776: Feature: Texture Tool: Add Manipulation Panel to shift/scale/rotate selection #5613: Feature: Show shared keyvalues when multiple entities are selected #5738: Feature: Texture Browser Filter: match multiple words (using 'AND' logic) #5728: Feature: Skin Chooser shows materials of the model #5774: Feature: Surface Inspector: Add buttons to harmonise Horizontal and Vertical scale values #5771: Feature: Improved pasting textures to angled faces sharing an edge #5753: Feature: XY view zoom is centered at cursor #5748: Feature: Texture Tool: Constrain operations to axes by holding down Shift #5128: Feature: Texture Tools: rotate function #5731: Feature: Texture Tool: UI contrast #5721: Feature: Model Conversion UI #5722: Feature: Add FBX model importer #5712: Feature: add IQM format support into lib/picomodel #5705: Improvement: "Replace Selection with exported Model" preserves spawnargs #5659: Improvement: automatically reload exported models #5745: Improvement: Search function: don't start searching while still typing #5791: Improvement: MediaBrowser toolbar: clear filter text when texture is selected through MMB or Texture Browser #5788: Improvement: Merge "Create player start" and "Move player start" options #5785: Improvement: Patch Texture Rotation should take aspect ratio into account #5733: Improvement: Texture Tool: use aspect ratio of material #5740: Improvement: Step-rotating textures through the Surface Inspector should be using the center as pivot #5775: Improvement: Surface Inspector: Option to change horizontal and vertical scale values proportionally #5633: Improvement: Apply textures to surfaces using "normalized" scaling. #5547: Improvement: Normalise button brings texture coordinates closer to 0,0 #2272: Improvement: Prevent Texture Tool "face jump" on rescaling textures #5735: Improvement: Move modifier hints out of the status bar #5767: Improvement: Flip Texture: Prevent huge face UV coordinate translations #5752: Improvement: Double click on list elements should auto-close dialogs #5749: Improvement: Texture Tool: Select items by clicking the UV space they cover #5750: Improvement: Texture Tool: Grid lines are getting too dense when zooming out a lot #5732: Improvement: Texture Tool: intercept keystrokes for grid resizing & snap to grid #5734: Tweak: Surface Inspector vertical shift / vertical scale arrows #5706: Tweak: Surface Inspector's minimum width is too large #5741: Improvement: Model Exporter: warn if Output Format and extension in File Path don't match #5711: Improvement: Change Quake3 map exporter to write "legacy" brush syntax #5710: Fixed: Q3 Legacy BrushDef parser sometime produce some wrong texture rotation #5687: Fixed: "Replace Selection with exported Model" assigns result to Default layer #5408: Fixed: All scene graphs connect to the same undo system, causing interference #5790: Fixed: Remove Floating Layout #5783: Fixed: EntityInspector allows to set an entity's name to an empty value #5723: Fixed: modelDefs folder starts expanded after changing selection #5736: Fixed: Particle Editor: wireframe does not render #4584: Fixed: Drag-select while in texture tool window gets stuck. #5770: Fixed: Some brushes change shape or disappear when rotated or duplicated #5747: Fixed: Texture Tool: drag operation doesn't capture the mouse #5754: Fixed: Ctrl-S does not work when focus is on inputs #5729: Fixed: Autosave filename unhelpfully overwrites 'save copy as' filename #5725: Fixed: Merge Maps: can't hide changed entities/primitives #5708: Fixed: Merge Maps: can't center orthoview/camera on changed entities #5709: Fixed: Merge Maps UI remains if DR is closed while a merge is in progress #5707: Fixed: Merge Maps: "Details" text doesn't use full width of window #5704: Fixed: Brushes colour schemes not saving #5702: Fixed: Fit Texture fields do not allow values below 1.0 #5713: Fixed: PatchDefExporter: do not write trailing white space after shader name #5717: Fixed: LWO2 Model Exporter doesn't write vertex colours #5588: Coding: Separate UI-related and core module interface headers #5780: Coding: Remove IDialogManager references from Map module #5778: Coding: Solution / Build Dependencies Update Changes since 2.14.0pre1 #5810: Fixed: Objective components not correctly renumbered after removing a component #5801: Fixed: Applying a skin to a model entity no longer works under 2.14pre1 #5813: Fixed: Spawnarg types and tooltips not reliably inherited in entityDefs #5814: Feature: Spawnarg type icon not shown for inherited properties #5808: Fixed: Crash when saving map or prefab without a file extension #5807: Fixed: Texture Tool crashes when creating a new brush #5797: Fixed: "Texture tool" grid cannot decrease under 1 #5799: Fixed: Texture Tool: dragged vertices snap to grid even though it's switched off #5800: Fixed: Sound chooser not pre-selecting the inherited value of snd_* keys of an entity #5794: Fixed: User Guide (Local) doesn't work #5792: XY View zooming behaviour improved (if not fixed) Refresh icons for axis flip buttons Separate SurfaceInspector scale rows from other property rows Restore GL_LINEAR_MIPMAP_LINEAR texture filtering Thanks for testing, as always!

For taking a screenshot of an item to use as an HUD icon, sometimes it's easier to do that in DR (e.g., in the head model view), where you have better shot control than in TDM, even if the lighting is a bit unrealistic. Fakey lighting for an icon is often not a problem.

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

@Fidcal I know where you're coming from. GPT-4's continuity can sometimes falter over long stretches of text. However, I've found that there are ways to guide the model to maintain a more consistent narrative. I've not yet tried fully giving GPT-4 the free reins to write its own long format fiction, but I co-wrote a short story with GPT-4 that worked really well. I provided an outline, and we worked on the text piece by piece. In the end, approximately two-thirds of the text was GPT-4's original work. The story was well received by my writing group, showing that GPT-4 can indeed be a valuable contributor in creative endeavors. Building on my previously described experiments, I also ran GPT-4 through an entire fantasy campaign that eventually got so long the ChatGPT interface stopped working. It did forget certain details along the way, but (because the game master+player dynamic let me give constant reinforcement) it never lost the plot or the essential personality of its character (Thrumm Stoneshield: a dwarven barbarian goat herder who found a magic ring, fought a necromancer, and became temporary king of the Iron Home Dwarves). For maintaining the story's coherence, I've found it helpful to have GPT-4 first list out the themes of the story and generate an outline. From there, I have it produce the story piece by piece, while periodically reminding the model of its themes and outlines. This seems to help the AI stay focused and maintain better continuity. Examples: The adventure of Thrumm Stoneshield part 1: https://chat.openai.com/share/b77439c1-596a-4050-a018-b33fce5948ef Short story writing experiment: https://chat.openai.com/share/1c20988d-349d-4901-b300-25ce17658b5d

Evening Would anyone be able to make a hanging version of the following model..? - models/darkmod/lights/non-extinguishable/standing_lantern02_large.lwo many thanks. b.

if toned down slightly, that could be a mural of some sort, nice! By the way, while I was experimenting with current paintings-as-loot entity system, I noticed a couple of things. It seems like it always needs a second model for an empty frame entityDef. You can't use the base model with "stolen" skin. Examples from Loot entityDef seem to confirm that. The second model can even use different skin, but you can't use the same model for base painting and empty frame, by just switching skins. It's a bit of resource waste, two models instead of one, but ideally both solutions could be supported, IMO.

Here's the pre-release build 3.0.0pre8, we're getting closer to the finish line. It's about time for a new major release - not just because of the changes of this build, but for all the improvements made over the last few releases. I'm going to need your help stabilising this release, with all the renderer changes things are bound to require a few tweaks. Most time since 2.14 has been spent on the renderer, which should now be faster in regular (non-lit) render mode. Lit render mode is probably not going to be faster, but at least more accurate. You can activate Shadow Mapping, and the interaction shader code has been ported over from TDM to produce the same look as the game. Starting with this release, the user settings will be saved separately for each DR version, meaning that this release won't mess with the settings of the previous versions, including keyboard shortcuts, colours, last used maps, etc. DR will try to import and use any settings of previous releases, but it won't change them. For more things that have changed or fixed, see the list below. Download Windows Portable x64: https://drive.google.com/file/d/121ibqqYMKqRqjcQ1zS0HtM4JO0ADrgRo/view?usp=sharing Download Windows Installer x64: https://drive.google.com/file/d/1209hG92chVzqOc-iaFDzJ0cBfQucDad8/view?usp=sharing Linux folks need to compile this stuff from source, instructions for various distributions are on the wiki. If you happen to run into a crash, please record a crashdump: How to record a crashdump Changes since 2.14.0 can be seen on the Bugtracker changelog, here's the summary: #5787: Feature: Add "Create Particle" to right-click orthoview drop-down menu #219: Feature: Shadow mapping support #5761: Feature: Cut functionality to complement copy and paste #5757: Feature: Ability to center 3D camera on selected entity #5927: Feature: Save user settings by application version #5848: Feature: MD5 Animation Viewer: show current frame & total frames #5849: Feature: MD5 Animation Viewer: jump to frame #5905: Improvement: Safeguard warning against Loss of Layering #5872: Improvement: Option to filter skins out of search results in the Choose Model dialogue #5909: Improvement: Revisit Interaction Shader to get closer to the TDM looks #5822: Improvement: UI tweaks for worldspawn-to-entity conversion #5873: Improvement: Entity inspector should recognise spawnargs beginning with "sprS_" as def spawnargs #5825: Improvement: Allow absolute paths for snapshots #5910: Improvement: Entity Inspector: classname field should always be read-only, to force use of the "Choose entity class" button #5925: Fixed: Objective GUI doesn't display properly in some places #5919: Fixed: Crash on loading certain maps #5829: Fixed: Entity inspector shows inherited spawnargs of previous selection #5853: Fixed: DR overwrite order for defs is different from TDM's #5897: Fixed: X/Y and Camera View bindings don't save properly #5858: Fixed: "Replace Selection with exported Model" sets classname to "func_static". #5864: Fixed: Map -> Edit Package Info (darkmod.txt)... crashes DarkRadiant #5846: Fixed: Rotating a func_static result to random stretch textures #5840: Fixed: DR crashes when syncing with remote Git repository #5847: Fixed: Switching visibility of Github repo from public to private causes crash #5841: Fixed: Dockable window layout doesn't save new floating XY views #5844: Fixed: "Choose skin..." button on custom model spawnargs shows skins for main model spawnarg #5826: Fixed: Entity inspector considers inherited colors black #5885: Fixed: ReloadDefs moves def_attached light crystals to entity origin #5901: Fixed: .lin files can't be opened if different case than .map name #5884: Fixed: Model chooser radio box selection issue #5836: Fixed: Changing multiple lights between omni/projected resets colours to black Changes since 3.0.0pre1 #5934: Selection overlay is z-fighting on patches #5932: ForceShadows materials are not casting shadows #5933: Moving brushes doesn't update the scene in lit render mode Changes since 3.0.0pre2 #5941: Selected Skin not showing in ModelSelector #5935: Defs takes longer every time #5939: Texture tool Free rotation not showing anymore #5940: Light diamond frequently disappears on colour change until it's moved again #5938: Additive blend stages over black diffusemap are z-fighting #5936: Ambient lights don't render properly in lighting preview mode Changes since 3.0.0pre3 #5949: Fixed: DR crash with combination of mouse buttons pressed #5948: Fixed: Manipulation Vertex Dots are hard to see #5947: Fixed: Git Sync Exception: too many redirects or authentication replays #5907: Feature: Allow way to hide some entities in Create Entity list #5946: Improvement: Speaker radii should be transparent #5945: Improvement: Light diamonds should be transparent again #5937: Fixed: Sound radius spheres don't always update #5943: Fixed: Brush manipulation is laggy in huge maps #5942: Fixed: Missing brushes when opening alphalabs1 from vanilla Doom 3 PK4s Changes since 3.0.0pre4 Reduced Frame Buffer Count from 3 to 1, this should reduce RAM consumption a lot #5953: Wireframe object drawing order is changing between sessions #5951: "Hide Deselected" is slowed when there's a lot of patches present in the scene #5950: Visibility checks are slowing down front-end render pass Changes since 3.0.0pre5 #5955 + #5956: Fixed: Player start entity is invisible in 3.0.0pre5 #5959: Geometry Corruption / weird diagonal lines messing up the view Changes since 3.0.0pre6 #5966: Light entity radious colour changes as you pan the camera around. #5964: Cannot manipulate func_emitter after creation #5965: Resizing light entites via light_radius in property inspector broken #5963: More Geometry Corruption in Camera View (Lighting Mode) #5960: Crash in MD5 model viewer Changes since 3.0.0pre7 #5968: origin of player start entity misaligned #5969: Cannot snap selected patch vertices to grid Thanks for testing, as always!

I agree with your observation in the main post, and admit it's a sin even I understandably commit: The DarkRadiant GUI didn't make it clear which models have a LOD, you'd have to check and find out for yourself... even then you aren't encouraged to do so right away as it requires going through the trouble of setting LOD spawnargs manually. My suggestion: Maybe don't combine the models and entities menus, they seem better as separate things and mixing them might clutter everything and make it harder to browse. But the model screen could hide LOD models from the browser, and instead automatically set LOD spawnargs to models that have them when inserted on the map. We could leave it func_static but add the "model_lod_*" and "lod_*_distance" arguments... I'd even consider a default "hide_distance" for all models based on their bounding box size. Those should be settings you can disable like "Surround with monsterclip brush" which is currently the only option in the model chooser, we could maybe offer a multiplier offsetting how aggressive the LOD settings are based on the model scale. If not the simple and perhaps ideal solution is having a default entity for every model that has a LOD: Some trees for instance have them, a few other items too... not everything does though. I checked out the new "Related entity classes" menu and that seems good enough to me; I'd add a checkbox to automatically insert the first entry if one is detected, the menu might be lost on some mappers in all the GUI detail. But to be useful I think more models should be given entities.

So I have been going through my city WIP converting FuncStatics into .LWO models using the new export menu Greebo added - Main Menu>File>Export Selected as Model - But then I discovered I could select normal FS and .LWO models and export them all as a single model So it them occurred to me I should be able to do the same thing with existing core mod models - https://www.youtube.com/watch?v=Ar5jP3XqOwM&

Seems to confirm: https://bugs.thedarkmod.com/view.php?id=5718 does it happen in the latest dev build: https://forums.thedarkmod.com/index.php?/topic/20824-public-access-to-development-versions/

Yes it could but wouldn't using the skin system be better for that? I know that using the colored system, permits to do variable colors very easily, good for carpets, flags, cloth, etc and also only have a single material, but if your idea is to make more varied looking characters, with a single model, I think the skin system is better, it means more materials need to be created but it also means more flexibility and power. The skin system is very powerful, was designed exactly to make different material variations for a single model and it does way more than just swap colors, you can have characters that look somewhat different geometrically, by hiding or showing hidden peace's on a model, etc. On a animal for example you can have a model with fur and another without it by just hiding the fur geometry, or one with a collar on his neck and another without it, without swapping models, just the skin.

xash3d a half-life clone engine was also based on darkplaces though on a much much older version than what is currently up for grabs. had they used the newer engine then xash would be close to source engine levels of photorealism but the newer engine sources are pretty hard to work with if you are not into toying with the darkplaces source code regularily mostly because the code no longer resemble the quake source code anymore. It was also the first quake engine to support portal culling though not the first to support real time lighting and bumpmapping that honor goes to tenebrae, havoc did catch on quickly though and his implementation was far superior to the tenebrae model which used hacked entity lights (sprites basically). darkplaces uses rtlight a variant of the old lighting tool from quake supporting real time light sources, quake itself does not however support realtime lighting so the lightsources are parsed from an external rtlight file containing the positions of lightsources in the map if you dont have these it can approximate the lightsources much the same way as tenebrae did but it is very very VERY slow, in mods it can be compiled into the map. it also supports bsp2 a new map format allowing much more complex levels and a skeletal model format instead of the blocky mdl1 format. havoc has not had much time to do work on darkplaces in later years (works for ID software now) and got married some years back to one of the other devs from the now defunct inside3d where i used to frequent, but i heard she would probably take up work on it again shortly. Would be rather cool to see where that might lead having worked with the ID dev'ils she might actually make an engine that becomes a serious contender to them heres a shot from quake 1 with all the mod bells and whistles on skeletal models real time lights hd textures you name it it is probably there.

The steps for non MD5 models are relatively simple: create a model and make sure it is all in a single layer (when exporting) be mindful of the scale diference between the 3d tool and the game, one way to see the scale needed, is to create a cube in DR export has obj and import in blender. make sure the model is made of triangles no quads (you can work in quads then triangulate at export) uvmap the model and make sure the uv's fall within the 0/1 window and don't overlap create a diffuse texture (colors only no shading) create a normal map create a specular map (you can put color on it) create or edit a .mtr material file and define your model material there. make sure the material name, for the model surfaces, in blender, is the name of the material you have created inside the .mtr file if you want to create, a shadow mesh or a collision mesh make sure the surfaces/models lay in the same layer as the main model (they overlap it) apply to each model the invisible "texture/common/collision" or "texture/common/shadow" material names depending on the model function you want (for collision models if making a physics enabled model a 'movable' in idtech 4 parlance, make sure the collision proxy has no more than 16 faces) export as a single .ASE or .LWO hope I didn't forget anything.

TTLG? That's Through the Looking Glass Forums. A looking glass fan community. Has been around for a long, long time. https://www.ttlg.com/forums/

Thanks... that's awesome, will gladly keep it in mind. Can't avoid needing a custom script but I cannot complain: I'll likely write a custom map entity for this, can use it to do both storing and triggering based on circumstance. Since I already asked, I kinda had a part two to my question: Is it possible to change AI definitions in realtime, so for minor changes you don't need to register a different AI altogether? Namely the model, skin, head definition, and voice; Can a script replace them? For the body model / skin I think that would work like on func_static, but def_head and def_vocal_set are probably read once on map load and not updated in realtime. It would also break precaching and cause a jitter. Problem is that if I leave the unused AI in a hidden box on the map, it's still loaded in memory and thinks thus wasting CPU. Can I at least delete an entity I don't want safely? The difficulty filter does that, entities not corresponding to a given difficulty are erased... this however is likely decided during loading which wouldn't work here.

I'm new to modeling in Dark Radiant (using Blender), and having some noob issues. I've exported the model as .ase, model appears as it should but has no texture present. I modified the BITMAP margin in the .ase to the path of the texture (ie: //base\models\darkmod\props\textures\*texture name*). I've browsed countless times through the wiki re-reading everything concerning this general issue with no luck. What other steps am I missing for the texture to show up in the model? Any help will be greatly appreciated!

https://github.com/HansKristian-Work/vkd3d-proton/tags <- directx 12 wrapper for dxvk https://github.com/doitsujin/dxvk/tags <- directx to vulkan wrappers D3D 9 to 11 eg. dxvk if you want to try it with horizon zero dawn you need to copy out dxcompiler.dll from Tools\ShaderCompiler\PC\1.0.2595\x64 and bink2w64.dll from Tools\bin and place them next to HorizonZeroDawn.exe. then copy over dxgi.dll from dxvk and d3d12.dll from vkd3d and place them next to it to. now fire up the game and let the shaders recompile -> profit.

I just read@motorsep Discovered that you are able to create a brush, then select it and right click "create light". Now you have a light that ha the radius of the former brush. Just read it on discord and thought it may be of use for some people in the forums here too.

Humans use semantic information to modulate pacing and pitch over sentences and even entire paragraphs. Having a language model like ChatGPT detect the semantic "features" of the text and feeding them as additional input into the speech synthesis model might reduce the amount of markup significantly or even eliminate the need for the common case where the speaker's emotional state is rather neutral and the meaning of the message matches the actual text. That might be a pretty intuitive way to provide additional emotional context that can't be derived from the text alone - like the state of the speaker (exhausted, happy...) or subtext (sarcastic, ironic, bragging, threatening). But just slapping an emoticon in front of some parts of the text might also work good enough when combined with a language model trained to detect them. I'm excited to see, which path speech synthesis will go. Pretty sure, results will become indistinguishable from professional voice-acting in the next few years.

Thanks for the update Greebo! I did send you a message on discord back in the end of December about a rather annoying bug which I don't seem to see is fixed in the list. And it's quite frustrating to deal with. So the arrow that goes between targeted entities doesn't render correctly when updated to a different entity. The spawn arg updates but not in the orthoview. It's easy to replicate though. Drop in two models and create a trigger once. Set the trigger once to be targeted to model 1. Then duplicate the trigger once and change it's target from model 1 to model 2 and the arrow doesn't update but the spawnarg does. For example it looks like this: In order to get it to display correctly I have to hide the entity it's targeting, and then reshow it which causes it to update to the proper view like this:

I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs. Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.