Dragofer

The LOD system doesn't seem to support toggling lights, at least that's what came of an earlier discussion on Discord. Even if it did, the best you could probably do with lights is setting them to noshadows after a certain distance, but you can just as well set that on the models being lit up by the light. Switching the light itself off would probably require very long distances, since something like a streetlamp emits a lot of light that'll make the LOD very obvious. Really, the best thing you can do for performance is preventing such long sight lines in the first place by designing your architecture such that it naturally obstructs them. Not only does this perform far better, it also feels realistic in the sense of a medieval city where everyone builds wherever they can get a few bricks in, and it should make for more interesting gameplay when the player can navigate through and around buildings (like Life of the Party) rather than walking on level ground most of the time. Melan has made an interesting guide on how to quickly layout and build convoluted city streets in his behind the scenes thread for Talbot 3: Fiasco at Fauchard Street, maybe you'll find it helpful?

I mean it became literally less than 1 fps whenever I had a large speaker (i.e. wind) crossing such visportal boxes, so it's an engine bug. I think it's still working out for you because you might be using only smaller speakers, but it might be there's a different cause. Maybe @stgatilov has some input on what might be going wrong here?

[quote] I remember someone expressing interest in how I create what I called "virtual cubes" out of vis portals, to have open outdoor areas be more performance efficient. Figured I'd share this screenshot which exemplifies a part of it. I tested this setup and can confirm it to work well: As long as the edges of portals touch accordingly you can connect them together. I haven't testing T junctures (the edge of a portal laying across the face of another portal) since that seemed inefficient, currently I divide across intersections to create two portals in this scenario... if the engine tolerates T shapes I might unify some of them to make the calculation even more simple for the computer. [/quote] [Continued from the "So what are you working on thread"] How does it work when you have speakers crossing such visportal cubes? My fps hits absolute rock bottom when TDM calculates sound propagation across them. Also, if you don't mind I'd move this visportal discussion to the newbie questions thread.

@JackFarmer Ah, that little thing - I was reminded of it when I saw your cool submarine in The Lost Citadel. Who knows, maybe people will see it in a FM one day?

@MirceaKitsune I just remembered that ai_see is only for lights. AI_USE is a string spawnarg that tells AI what kind of item something is, i.e. a door or a suspicious weapon. If the spawnarg is - it's invisible to them. You can find all the AI_USE possibilities in one of the ai scripts or maybe the wiki.

@MirceaKitsune Either wipe the AI_SEE spawnarg on the ragdoll or deactivate the visual stim it emits. Both should be reversible ingame.

@JackFarmer I can't comment on any you might be thinking of one of the excellent models created by ERH+? In your defence, cabalistic says drawcalls aren't as important as they used to be.

@MirceaKitsune TDM natively supports debriefing videos, but I've never noticed it mentioning text. It should in any case be possible to modify the "next" button on the success screen to show a briefing slide instead of returning to the main menu, but I doubt you can do that without modifying "forbidden" .gui files. It'd be something to suggest to @stgatilov for his menu GUIs rework. GUI scripting also allows some very basic conditional checks, i.e. what mission is active. Maybe you can check objective states or properties on ingame entities, but I can only go as far as saying that you could use notepad++ to search through all the .gui files to find existing examples of checks. Maybe you can find how the gui decides to mark objective checkboxes?

Yes, it works here. Mappers do have that choice already, and that's when they provide either .tga or .dds images. But it gets overruled by default when the .tga's are compressed to .dds at runtime. As cabalistic says this is slow for loading and driver-dependent, and mappers might not be aware it's happening. Maybe it's still considered a poor decision for mappers to use many custom .tga's, but maybe once we have pre-compressed normalmaps there'd be enough budget left to allow any .tga's to remain as they are by default?

1. I’m only showing a section of the sky in this thread in order not to spoiler. 2/3. Yes, I tried opening the same FM with a .tga background on my Intel GPU PC and the compression artefacts are less severe. The quality is like when I use a .dds image. The real problem I believe is that I’m giving the game a .tga image in hopes of optimal quality, but it automatically gets compressed at startup. On my AMD GPU the result happens to be even worse than when I use a .dds image. I suppose you can work around it by making a material with forceHighQuality, but it doesn’t make sense to me that TDM compresses my .tga images. If I wanted that I’d use .dds images.

No shame in using hidden objectives to achieve scripted effects. The objective editor is like a visual scripting editor that’s often considerably easier to use than scripting by hand or setting up cascades of entities carrying script functions.

Looking at an immobile entity in DR shows that its frob_action_script is readable_immobile_frob, which notepad++ says can be found in tdm_readables.script. One of the member functions there is handleCloseEvent(). This function calls another function that triggers the entitiy specified in the spawnarg "trigger_on_close", every time it's closed. For TDM as a whole, it’s a matter of someone setting aside the time to make sure that all spawnargs that are implemented in the scripts and source code are also documented in the entityDef so they show up in DR. Or at least tracks them somewhere, like a general bugtracker ticket of “undocumented spawnargs”.

It doesn't have to be a painting, there are other ways to include a tribute. For example, Geep created a character inspired by grayman, and you could create an ingame location with a sword stuck in something. Regarding Zerg Rush's painting, it's not sufficient to modify a copyrighted work to make it your own. You really need to check what the author says about how you may use it.

Just saying because when I uncommented the custom_title section and changed the image path the parchment was gone. My reasoning for that suggestion was that I think there are 2 kinds of backgrounds: scenes that look good when they occupy the left half of the screen in the main menu, like in the Hidden Hands series, but not so good if most of the screen is covered by i.e. a shop. more uniform backgrounds i.e. blue fog like in the Shadows of Northdale series which is good at bordering any menu. I think having a choice between 2 basic macros depending on what type of background the mapper has, where 1 macro only affects menus with enough screen space to show a scene and the other macro affects all menus, would be suitable. A further comment is that mainmenu_background_custom.gui should have a description of how to uncomment the windowDef, especially since a different comment system is used here (setting "#if 0" to "#if 1").

I think the most common usage would be: - custom background for the main menu (pregame and ingame) and its submenus: Load/Save, Settings, Select Mission. - stock background for everything else: TDM credits, anything after Start Mission (briefing, objectives, shop), success/failure screens and so on The 2nd macro could assign the custom background image to everything. Also, I think the parchment overlays should be kept by default. If a mapper is engaged enough to draw a new menu box they'd probably want to use the more advanced method. Ah right, my TDM install's gui .pk4 doesn't contain this file so I was deriving it from mainmenu_background.gui

This would be a shame, I think the GUI customisation system would profit from a simple & easy way to just drop in a custom background image that instantly replaces all of the stock menu effects in one go. The new menu customisation system looks like it's very powerful for advanced effects and complete control, but could be tricky for a mapper who's not familiar with the GUI system and only wants to make a simple change like this. In this case he'd have to find out that you can't use a custom background image directly but need to make a GUI material with an appropriate blend mode (ok, seems this is not the case, but it seemed necessary after inspecting the stock menu), a GUI window containing this material with an appropriate rect size, and replace all the stock windows of every state with this new window. I think this is a system for advanced users.

It's maybe a bit buried in my last post, but setting seta image_useCompression 0 actually cures the problem: no more compression artefacts.

With a currently .tga background and default darkmod.cfg cvars from updating to the main menu beta: Can't see an image_compression cvar in my darkmod.cfg, and the console doesn't seem to know it. My other seemingly compression-related cvars are: seta s_decompressionLimit "6" > seems to be something for audio files (max uncompressed sample length), so I didn't experiment with it seta image_usePrecompressedTextures "1" > setting this to 0 has no effect on the background and turns pretty much everything else into black rectangles/screens seta image_useNormalCompression "1" > setting this to 0 has no effect seta image_useAllFormats "1" > setting this to 0 has no effect seta image_useCompression "1" > setting this to 0 cures the problem. As sharp as ingame. Yes, I tried it in .tga, .dds and .jpg and made sure I didn't have both a .tga and a .dds in valid locations simultaneously.

For some reason, my custom main menu background image has huge compression artefacts when seen in the TDM menu. I took it from an ingame location using TDM's F12 screenshotting tool, then opened it in GIMP and exported as either .tga or .dds. Also tried .jpg. If I open one of my .jpg briefing images from the internet in GIMP and convert it to .tga, that's perfectly sharp in the TDM menu. Definitely quite weird, since I've seen plenty other missions with reasonably sharp ingame screenshots, and my screenshot looks good while it's still in GIMP. AMD driver issue? This is a screenshot of the foggy sky in the TDM menu, which should be completely uniform: Compared to a screenshot of the same area in GIMP:

Some experiences I made trying to replace the stock background with a custom background image for the first time: It seems there are 2 ways to achieve this: making custom background window defs (line 61) or applying custom title graphics (line 300). I found the background windowDefs method first since it's higher up, so tried that first. This method is more complex, considering the setup that's required outside of the custom_defs file, so it should probably be shown after the custom_title method. There was also trial and error with modifying the windowDefs, so it'd be useful if the GUIs automatically reloaded themselves when you switch between states, if performance allows, so that it gets easier to try out changes without restarting TDM. Then I tried the custom_title method, which is much simpler but has some downsides: The menu parchment gets replaced too - can't see a way to change only the background, which is what I think most people who would use this simpler method want. When the player clicks into another menu, i.e. Options, the background is the default one again.

Found an edge case: When multiple things (i.e. doors) have a common bind parent (i.e. a carriage), they all highlight together even though they don't have any direct relationship to each other. Maybe common highlighting should only be for entities that are bound to each other? Sometimes you need to bind doors to something, for example if you want them to move on a rotated axis or if you're making a vehicle. This happens in a test map I posted to the dev forums today ("Fog obscures transparent textures").

An encounter with some rather unsavoury types is taking shape...

Internally the downloader can only work with integers, so v1.1 = v2 and v1.2 (current) = v3. If the archive is 175 MB instead of 500+ it's the current version.

@MirceaKitsune func_statics are entities, so there's no distinction there. AIs can only walk on anything that's an entity if there's some kind of solid worldspawn brushes reasonably close to the surface, i.e. MC or nodrawsolid or a solid visible texture. Brushes converted to func_static will be counted as entities. RIT is basically so that you place central nodes (usually a path_wait with wait 0 and wait_max 0) that target multiple different nodes in a room representing various activities i.e. sit in a chair, look at a painting, warm hands at a fireplace. This means whenever the AI goes into that room it does something different, usually, from the last time so that they appear more human.

Definitely this if the player is having trouble navigating the stairs or other map features, though for the player it's easier to have steps than a ramp: players need that for actual physics, while AIs only need MC ramps to tell them they're allowed to go there. Simply encase each step in a brush that reaches down to the step below. You can keep the nodrawsolid steps as worldspawn, then you won't need to MC the steps anymore.