Jump to content
The Dark Mod Forums

Leaderboard

Popular Content

Showing content with the highest reputation on 12/30/20 in Posts

  1. Metro Last Light free on GOG www.gog.com/giveaway/claim
    2 points
  2. @stgatilovWhat do you think about having the hot reload also reload models, materials, skins, scripts, etc when the same is done in DR?
    2 points
  3. I've got a proof-of-concept of this working in DarkRadiant right now. I'm not sure it would be as easy to do directly in TDM due to cross-platform stuff that wxWidgets takes care of in DR. Having this feature combined with the hot-reload, though, would provide the same end result as long as DR was running to relay the reload command.
    1 point
  4. Please add a bugtracker item for me. When textures are made bindless, texture parameters can no longer be changed for those textures. Changing AF or other parameters with bindless may require recreating the textures.
    1 point
  5. @jonri @peter_spy @stgatilov I could see auto updating models and textures, but I would be cautious about auto updating definition files and scripts without user confirmation. There might be cases where the author needs to touch a few different files before reloading the definition in game or simply wants to save their progress while writing a script. When hotReloading this stuff, the engine might grab incomplete data an cause errors while the user isnt looking. For instance you bind an object to an AI in a def file, but you havent created that object yet- the engine will try to grab a null entity and possibly crash in some cases.
    1 point
  6. Regarding "reload map" vs "update map". I guess "reload map" mode can be removed from GUI, leaving only the "update map"... if "update map" works well enough and nobody sees any reason to retain the other mode. For debugging purposes, I can always save map in DR and execute "reloadMap" in TDM console. As for "always sync" vs "sync now" in "update map" mode, I think both are useful.
    1 point
  7. @stgatilovYeah I was thinking maybe we could pop the dmap warnings into the DR console? That might be too much though and flood it. Maybe just a log file for now and then later we can do something fancier? It would be nice to get some kind of confirmation the dmap finished. I personally don’t use the DR console, but maybe this would get me into the habit of checking it as I’m sure there’s useful info there. Some of the reasons I find myself constantly dmapping: - Tweaking monster clip brushes to allow the AI to continue their patrols. - Tweaking textures! This is hands down the most tedious thing. Having to dmap and reload just to see texture changes is very time consuming. Workflow is typically: - Launch TDM and DR - Do a fresh dmap and move my cameras to where I want to work - Tweak texture in DR - Dmap, wait, load map, move back to troubled area in TDM - Do this over and over again...
    1 point
  8. Sounds like what you want is exactly what's implemented, except that it's currently a menu item rather than a button. Again, that's complicating things by introducing a need for DR to "take orders" from another process and trigger UI changes that don't correspond to keyboard or mouse events from the user (and might conflict with those events). It's much safer and simpler to have the currently implementation whereby the trigger to synchronise locations comes from DR menu/button events rather than commands from inside the game.
    1 point
  9. To me, the main justification for TDM => DR camera sync would be for pinpointing locations where things go wrong in order to fix them. For instance you find a place where you've got z-fighting, or an AI is getting stuck on an object, and you want to jump to it in DR. As this is a more occasional thing, this would bring me back to wanting a button for it instead of it enabled all the time. Alternatively, we could have a keybinding in TDM to push the location back to DR (or rather queue the location and have DR poll for updates to the value). And maybe instead of moving the camera in DR when this happens, use the location value to draw a "breadcrumb" in DR (maybe have it look similar to a player start entity but make it easy to find).
    1 point
  10. The underlying code only checks when DR camera moves, and continuously enforces same location into TDM (with some inevitable delay). Two-way sync would be hard to implement and more error prone. To be honest, I consider any type of two-way since with great care and distrust. I once had such "sync" software clear my mobile instead of backing it up, so I prefer to have direction explicit Yes, exactly. Constant sync from DR to TDM seems like a perfect thing when you are mapping in DR, and use TDM merely to see the same scene there. I was considering it to become the main mode of operation. The backsync (from TDM to DR) might be useful when you are testing something. E.g. you tweak some runtime settings which are not immediately visible without player interaction. Or you simply test the game by playing it. At some moment you see a problem in-game and want to quickly fix it in DR before continuing playing. And that's when you click on "sync back", do the quick fix, then switch to TDM again. So it might be useful in a rare case when you dove into TDM and ran too much away in there. I ditched the idea of continuous sync from TDM to DR, because I believed it was not necessary, and would only complicate things. I don't like most of the names proposed here for camera sync, but I must admit my names are not better either As long as everyone is OK with the idea that continuous sync from TDM to DR is not needed, I would suggest name like "Camera sync" for the main mode, with a more weird "Find player" or "move camera to player" button, if simple "sync back" is not clear enough. Another question is notarget/noclip. Right now enabling camera sync mode automatically enables notarget, noclip, and god. Without any of them, free flying on DR camera would end badly in TDM, so they are pretty essential. Is there any real need to configure these modes? By the way, when camera sync is disabled, none are the settings are restored back. That's not very nice and assumes that user either knows how to disable them or simply does not care because uses TDM for visual preview only.
    1 point
  11. At the risk of introducing another alternative, why not combine both and have two-way sync? If you move in DR, it updates in TDM. If you move in TDM, it updates in DR. If you want to be in two different places, you turn off the sync. I agree, but due to the above I see this as 2 toggle buttons: Sync Camera and Sync Entities. Both of these toggle the continuous updates, no instant update buttons. In my use of the reloadMap command so far, there are some things hot reload (at least currently) doesn't deal with, that restarting the map does. So, this gives us 1 more toggle button: restart map on save. No need for the instant button, since you have to save first for it to be useful anyways. The same logic as restarting the map should apply here, if it wasn't for performance. Perhaps we start with a manual dmap button, and if we get an incremental dmap someday, we can switch over to a "dmap on save" toggle button or better yet fold it into the "restart map on save" button. This gives us a total of 4 buttons - distilling each row from the mockup into only one element. Based on which buttons are toggled/pressed, we should be able to enable the Game Connection without a dedicated button. When any toggle is turned on or the dmap button is pressed, enable the connection. When they're all off, disable the connection. If we can really boil it down to just four buttons, I'd personally lean towards putting them on the toolbar above the 3D view in DR. It's got some empty space and toolbars are well suited for both toggle and normal buttons.
    1 point
  12. Undervolting might be as important as the temperature. Don't overvolt, do undervolt and underclock.
    1 point
  13. Alright, thanks for testing. And thanks to @lowenz to find the relevant clue I'll ensure we add proper detection for 64 bit support so that it isn't enabled on systems that don't support it.
    1 point
  14. Fantastic! This works!! The in-game gamma adjustment preview works now as well (this got turned off a release or two ago).
    1 point
  15. @Araneidae You could try to change the color precision to 32 bits (either in the menu or by setting `r_fboColorBits 32` via the console or in your darkmod.cfg. Perhaps we don't have proper detection for 64 bit color buffer support right now, and that messes things up if your card doesn't actually support is, as lowenz's post suggests? Although I wouldn't really understand how disabling tonemapping could influence this, but who knows...
    1 point
×
×
  • Create New...