Jump to content
The Dark Mod Forums

Dragofer

Development Role
  • Posts

    2626
  • Joined

  • Last visited

  • Days Won

    157

Posts posted by Dragofer

  1. @JackFarmer
    I can't comment on any 

    Spoiler

    submarines,

    you might be thinking of one of the excellent models created by ERH+?

    54 minutes ago, MirceaKitsune said:

    I kind of forgot the command used to check performance. My other excuse is that I allowed myself to forget because I was afraid of what I might see if I used them :D

    In your defence, cabalistic says drawcalls aren't as important as they used to be.

    • Like 1
  2. @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?

  3. 4 hours ago, nbohr1more said:

    Does the "forceHighQuality" material keyword still work? If so, that should be usable to force menu's etc to bypass compression.

    Yes, it works here.

    1 hour ago, duzenko said:

    I think it's good that users have a choice here. Would anyone prefer hi-quality GUI backdrops over in-game stutter and freezes? It's not just VRAM issue, but also system RAM/pagefile too.

    Your particular .tga might not make a difference, but there could be dozens in other maps.

    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?

  4. On 6/26/2021 at 9:58 AM, stgatilov said:
    1. I don't understand what's in the images that you posted. I see gray rectangle in the second one, and gray rectangle with some outlines in the first one.
    2. Almost surely this is the problem of DXT compression in OpenGL driver, since you provide non-DXT data, and engine uploads it as DXT. It is possible that the problem does not happen on drivers of other vendors. You can workaround it by forcing high quality in material, or providing DXT-compressed DDS (it should work).
    3. It can be related to the problem with DXT compression on AMD that you had before you turned image_useTexStorage off.

     

    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.

    46 minutes ago, OrbWeaver said:

    I don't think there's any bug here. DXT is a cheap and cheerful texture compression algorithm that works OK for most images if you don't look too closely, but it doesn't handle smooth gradients very well. If you want a large and smooth background image filling the whole screen, you need to disable DXT compression.

    Setting image_useCompression to 0 will work for you (although it will disable compression for all images, so might increase GPU memory usage), but it won't help other users if you are using this image as part of a released mission. If you are planning to release this image and you want it to look good for everybody, you probably need the forceHighQuality material keyword.

    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.

     

  5. 1 hour ago, MirceaKitsune said:

    Objectives are meant to appear to the player, using a hidden objective just for a trigger feels like an ugly hack to compensate for a missing implementation.

    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.

  6. 56 minutes ago, MirceaKitsune said:

    Hmmm, I see what you mean. I could do that but it feels kinda wrong: Objectives are meant to appear to the player, using a hidden objective just for a trigger feels like an ugly hack to compensate for a missing implementation. If nothing else works I can do that I guess, I will consider if I can make that work in some form.

    Can it be confirmed however that there's currently no other way? More specifically, that notes cannot trigger targets upon being read, and objectives are the only thing that can scan whether a readable was accessed and target something based on that? If yes I at least know my options for sure. Also I'll probably make a report regarding this limitation, the next TDM release could use a proper trigger for readables from what I'm seeing.

    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”.

    • Like 1
  7. 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.

  8. 6 hours ago, stgatilov said:

    Parchments are not included into backgrounds.

    Just saying because when I uncommented the custom_title section and changed the image path the parchment was gone.

    6 hours ago, stgatilov said:

    Usually when someone overrides main menu background, they do the same for difficulty selection and shop too.

    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").

    • Like 1
  9. 38 minutes ago, stgatilov said:

    All effects?

    I thought about having single macro like MM_BACKGROUNDS_ALL instead of many individual ones, but should it replace background on success and failure screens too?

    And if not, then how should it be called to avoid confusion?
    Maybe something like MM_BACKGROUNDS_META_ALLBEFOREGAME ?

    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.

    51 minutes ago, stgatilov said:

    File mainmenu_background_custom.gui already contains a stub of GUI window:

    Ah right, my TDM install's gui .pk4 doesn't contain this file so I was deriving it from mainmenu_background.gui

  10. 3 hours ago, stgatilov said:

    It is deprecated, and will be removed soon.

    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.

  11. 46 minutes ago, duzenko said:

    1. What is your image_compression cvar?

    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.

     

    52 minutes ago, duzenko said:

    2. Tried it in the .dds format?

    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.

    • Like 1
  12. 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:

    image.png.e15fbe3c104b09193595a5d3158c3879.png

    Compared to a screenshot of the same area in GIMP:

    image.png.ec7c0e43d7a4066194ceff7e004f59eb.png

     

  13. 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.
  14. 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").

  15. @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.

    • Like 1
  16. 2 hours ago, Geep said:

    3) Ramps of solid nodraw, which some prefabs have, to also ease player movement

    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.

    • Like 2
  17. @MirceaKitsuneAIs are not able to walk on top of entities unless there's something worldspawn (i.e. monsterclip) at most 30 units beneath the surface. So for those stairs you'll need to put in MC ramps for the steps and big MC blocks reaching up to the landings.

    You'd want to MC the large majority of solid entities. Things like doorframes don't need it because they hardly stick out from the worldspawn walls and the AI's collisionmeshes aren't as wide as their AAS, but railings definitely, not least to protect AIs from falling off the stairs if they start running.

    MC and worldspawn basically says where an AI may or may not go. If you tell an AI it can go to a space that's already occupied by a solid object, they have a good chance to get stuck on it.

    • Like 1
  18. @MirceaKitsuneAIs can easily walk over things like plates and bottles lying on the floor, and they can automatically maneuver around moveables. Anything else has significant potential to hobble/teleport or even permanently snag AIs if a bit of it is sticking out of the MC. The good thing is you don't need to MC individual models, you can MC them as groups.

    You can see how I do MC in Perilous Refuge, such as in the warehouse:

    image.thumb.png.b5e0bb365ecc192dc5cd2dfe09d0c3c3.png

    Basically the MC is drawn from floor to ceiling so that you don't have unnecessary pathing islands on top of them. Once you have the first brush in place, you can just copy it and adjust its dimensions on a 1 or 2 unit grid. The smallest gap or nook an AI get into is 33 units. Stair steps can be done simply as ramps.

    If done well enough, the FM will thank you for it by not having severe pathing issues.

    • Like 2
  19. 5 hours ago, MirceaKitsune said:

    As I might be needing this to do some testing I figured I'd ask: Is there by chance a console command that can be used to trigger an entity on the map? So if for example I type "thetriggercommand trigger_relay_1" that relay fires as if triggered by a trigger_multiple entity for instance. Never heard of one but the team is intuitive so I imagine it might be there! It would be useful to test some effects before I have their proper triggers in place.

    It'd be new to me, but maybe you can write your own general-purpose script and call it from the console? So

    void trigger_entity(entity e)
    {
    	sys.trigger(e);
    }

    And call it from the console with:

    script trigger_entity($trigger_relay_1);

    Would be interesting whether something like this works.
    Note that once you call a script from the console, you can no longer save and load in that session.

     

    @datiswous The startpack sounds like it'd still be relevant today, basically containing all those premade entities to use.

    Another option you have is to use the mapper_tools prefabs, which are similar but less substantial in giving the mapper an array of things he might need.

    • Like 2
×
×
  • Create New...