Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16735
  • Joined

  • Days Won

    51

Everything posted by greebo

  1. No harmful behaviour here, it's just a formatting issue, the underlying value doesn't differ. The difference between 2.14 and 3.0 is the fmtlib version DR is using. It appears that the fmtlib update to version 8.1.1 introduced a change in formatting behaviour when omitting the format specifier. Explicitly setting the format specifier to "g" removes the rounding of the rightmost digits: fmt::format("{0:g}", value)
  2. Maybe this is a good time to revisit the rest of the log file too. Do you care to you double check what other entries there are that might not be useful from your point of view? I might have been missing a lot of them over the past years.
  3. I added a link to your PPA to the website. It usually takes some time for the debian package to appear.
  4. I think the overlay system was designed to work with the player entity (HUD, effects, etc.), hence the name. It was implemented on the generic entity level, so it replaced the older system for all the entities. That's what I could figure out in the little time; it has been ages since I've touched that code and if I recall correctly, I didn't implement it myself, maybe it's been Ishtvan. I think, yes, since the "gui", "gui2", "gui3" spawnargs are processed before any script or game code has a chance to load any additional GUIs and reserve these [1..3] handles. A workaround to not hardcoding the handle might be 1) use the script loop you wrote to find out what handle it has been assigned or 2) load the GUI by the script itself using me.setGui("guis/test.gui") and store the handle somewhere (either a script object field or the "me" func_static entity). I know how you feel, weird GUI syntax is weird. I remember having my own fill of figuring out the GUI quirks back when we didn't have any sources to check. The GUI parser also chokes if no onTime block is present after the "float vis" declaration (without semicolon), claims about running into "unexpected end of file". It seems almost everybody hates working with GUIs, but after you've sunk in you'll find can do a lot and there are some really powerful features in there. The logging only works for the main menu GUI, which I assume is where you got that part from. The main menu GUI has special support in the C++ code, in idGameLocal::HandleMainMenuCommand or something like that. IIRC this method was the only place I could connect to the main menu GUI and implement things like the Mission Download GUI (in the days of closed source). set cmd "log" was one of the crucial things I needed for debugging stuff. You can look at the main menu to learn, but some things cannot be applied to regular player or entity GUIs, especially the set "cmd" trickery.
  5. Ok, if I understood your use case correctly, this should do the trick: Change the GUI to look like this: windowDef test { rect 0, 0, 640, 480 backcolor 0,1,0,1 visible "gui::is_visible" notime 0 } The visible property is now bound to the is_visible GUI state variable. Which is "0" by default, so the green window starts out hidden. Change your script to toggle the visibility by inverting the state flag: void onFrob(entity me) { sys.println("frobbed"); // Invert the is_visible variable that is bound // to the visible property of the test window me.setGuiInt(1, "is_visible", 1 - me.getGuiInt(1, "is_visible")); // Note: The first argument "1" refers to the first entity GUI // as defined by the "gui" "guis/test.gui" spawnarg } Does this help?
  6. @GeepIf you care to create a small PK4 for me with that particular set up, I'll have a look.
  7. DarkRadiant 3.0.0 is ready for download. It took a while, but DarkRadiant 3.0.0 is finally available. Most of the time has been spent on improving DarkRadiant's renderer, which now features shadow mapping support of up to 6 lights. It's still not matching the engine's output (especially in terms of performance), but it should be faster and much more helpful than it was before. The effort that has been put into the renderer rewrite plus the bigger changes in the previous few releases make the jump to the next major version feel more than justified. Besides of that, a lot of non-renderer issues have been resolved in this release too, next to some fine usability improvements. For more things that have changed or fixed, see the list below. Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.0.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! And I'll gladly repeat myself, by thanking all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. Changes since 2.14.0 Feature: Realtime shadow mode Feature: Allow way to hide some entities in Create Entity list Feature: MD5 Animation Viewer: show current frame & total frames Feature: MD5 Animation Viewer: jump to frame Feature: DarkRadiant warns about missing .darkradiant file on load Feature: Ability to center 3D camera on selected entity Feature: Cut functionality to complement copy and paste Feature: Save user settings by application version Fixed: Free Rotation not working anymore, can only rotate along 3 axes Fixed: DR crash with combination of mouse buttons pressed Fixed: Git Sync Exception: too many redirects or authentication replays Fixed: Missing brushes when opening alphalabs1 from vanilla Doom 3 PK4s Fixed: Selected Skin not showing in ModelSelector Fixed: Reload Defs takes longer every time Fixed: ForceShadows materials are not casting shadows Fixed: Objective GUI doesn't display properly in some places Fixed: Crash on loading certain maps Fixed: Vertex colours do not show on models in lighting mode Fixed: Entity inspector shows inherited spawnargs of previous selection Fixed: DR overwrite order for defs is different from TDM's Fixed: X/Y and Camera View bindings don't save properly Fixed: Material Preview rendering Fixed: "Replace Selection with exported Model" sets classname to "func_static". Fixed: Map -> Edit Package Info (darkmod.txt)... crashes DarkRadiant Fixed: Rotating a func_static result to random stretch textures Fixed: DR crashes when syncing with remote Git repository Fixed: Switching visibility of Github repo from public to private causes crash Fixed: Dockable window layout doesn't save new floating XY views Fixed: "Choose skin..." button on custom model spawnargs shows skins for main model spawnarg Fixed: Entity inspector considers inherited colors black Fixed: ReloadDefs moves def_attached light crystals to entity origin Fixed: Option to filter skins out of search results in the Choose Model dialogue Fixed: .lin files can't be opened if different case than .map name Fixed: Model chooser radio box selection issue Fixed: Changing multiple lights between omni/projected resets colours to black Improvement: Allow absolute paths for snapshots Improvement: Light diamonds and Speaker radii are transparent Improvement: Unify Declaration Parsers Improvement: Add "Create Particle" to right-click orthoview drop-down menu Improvement: Revisit Interaction Shader to get closer to the TDM looks Improvement: Entity inspector should recognise spawnargs beginning with "sprS_" as def spawnargs Improvement: UI for worldspawn-to-entity conversion Improvement: classname field should always be read-only, to force use of the "Choose entity class" button Coding: Update solution and build dependencies to Visual Studio 2022 The list of changes can be found on the our bugtracker changelog. Have fun mapping!
  8. I'll probably be going to release 3.0.0 in the next few days, unless someone has noticed anything that might stop that train. Thanks a lot for testing the new release, folks, this is invaluable and makes DR better for everybody.
  9. Not so sure how much work AA would be to implement, but you can dock off the camera window and move/resize it for your needs. Does this help?
  10. New version 3.0.0pre8 is available in the first post. Fixed the misaligned entity box, and patch vertices can be snapped again.
  11. I can confirm the problem, it's a regression. I'll look into it.
  12. Yes, I'm aware of that. It might not make it into the first 3.0.0 release, I'm afraid.
  13. A new build is available, links and changelog can be found in the first post.
  14. Oh man. Can you share that map with me, and does it happen every time?
  15. I'm not familiar with this bug. Can anyone confirm this behaviour?
  16. New pre6 release is available in the first post. The playerstart visibility is fixed, and I could finally resolve that bug causing the weirdly stretched geometry in the render views.
  17. I can't reproduce this. I'm using the portable version linked in the first post to make sure my local build is not different than the uploads, but the player start is not disappearing. I run DarkRadiant.exe, right-click to create a player start, and it's there. Pointfiles are working too for me. Can anyone try this and provide more feedback, please? @Frost_Salamander Is this something that is only happening in pre5, or are earlier pre-release builds affected too? Link to pre4 portable, just in case: https://drive.google.com/file/d/11WJIyLq8LOB2RqF0daH8HidBpytYJtcs/view?usp=sharing
  18. Yes, I've noticed those too, but couldn't pinpoint it yet. Information about reproduction would be appreciated, I'd like to fix that as well. There must be one sequence of entity selection operations that triggers this, and which I obviously haven't covered in the unit tests.
  19. Next build (pre5) is available in the first post. This should be better now, I reduced the frame buffer count from 3 to 1. I'll get back to this in case the front end render pass is ever going to be multi-threaded, but for now it's safe. This new build has reduced map loading times (by 10-20%) and front-end render times (by another 10%). I still haven't been able to track down the geometry issues (stray diagonal lines messing up the view). They can appear right after map loading as well as in the middle of editing - I'm grateful for any insight on how this can be reproduced. I had it happen on me, but I couldn't find the reason so far.
  20. DR is using triple frame buffers, and this is indeed quite expensive. I'll try to see if this can be reduced without compromising performance. It was set up this way to be able to support threaded rendering, but as there's no threading yet in the renderer, I might as well get rid of the triple buffer, and reduce it to one. This should save a few GB of system memory in large maps.
  21. I think this must be DR's current limitation to 6 shadowcasting lights. If more than 6 lights are shadowcasting in a view, DR will choose the 6 nearest lights. I assume when changing the camera angle, a nearer light comes into the view and another one stops casting shadows. I can either try to get more lights to cast shadows, with some rearrangement of the shadow map texture, or try to choose the 6 lights in a better way. Can you maybe share the map and camera position of those screens? I'd like to check these out. Not broken, just not supported yet. There are quite a few renderer features that haven't made it into DR yet. Maybe next release, it all comes down to free time and motivation.
  22. New pre4 build is available in the first post, with more fixes to the things mentioned in this thread.
  23. I could reproduce that problem now, with my Github account. I'll see what I can do to fix it. Entry: https://bugs.thedarkmod.com/view.php?id=5947
  24. I have to test this on another machine some time, one that doesn't have credentials saved at all, to have any chance of seeing what's going on. Obviously there is something saved in the credstore, DR is retrieving non-empty strings for username/password, otherwise the message wouldn't be there.
×
×
  • Create New...