Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Posts

    6740
  • Joined

  • Last visited

  • Days Won

    231

Everything posted by stgatilov

  1. I'm pretty sure this would turn into simple "frob hold delay" slider if this approach is taken as default.
  2. It's a bit too late, the builds are long under these names in tdm_installer. And given that you have already asked me to change "long-click" to "hold frob" or "frob hold", I think tagging with names will help us to avoid confusion. Even if something is developed by several people, but there is usually one "champion" who is kinda responsible for the whole thing But in general I agree, I don't like attaching names e.g. to changelog.
  3. I can add test-frob-daftmugi2. But could you please attach source patch?
  4. There are two ways to change frob controls proposed for TDM 2.12. Both approaches have test builds, which you can install in tdm_installer. Just set "Get custom version" on the first page, then choose either test-frob-daftmugi2 or test-frob-stgatilov there. The goal of this voting is to quantify current opinion about these ways. ATTENTION: Please vote only if you have installed and tried both test builds! Note also, that only one controls scheme will survive. Even if there is a switch in a test build, it will not be supported and will naturally die out. The approaches are also described and discussed in their threads: daftmugi approach (aka "hold-frob"): stgatilov approach (aka "double-click"):
  5. I'm strongly against this idea, at least until we have automatic box size and are sure fonts are not too different. Right now allowing choice between several fonts will mean that some subtitles won't fit with one fonts, the others won't fit with other fonts.
  6. I think php links are for the "mission database" on TDM website. You can go there and browse released missions without downloading TDM. If not, then php is just some remnant of the past I would say: better use XML links.
  7. There was an in-game button to delete a mission. It was removed because mappers sometimes accidentally clicked it for their WIP missions, which resulted in removing months of their work. Since the feature itself is not much needed anyway, we removed it. In principle, you can simply delete the fms/qwerty directory manually. One possible issue is that a record in missions.tdminfo will remain. Maybe it will be deleted on next TDM start (there is some kind of cleanup), maybe not --- then it will retain some info when you reinstall the mission back.
  8. The description of missions on server is located here: http://missions.thedarkmod.com/available_missions.xml (cvar tdm_mission_list_urls). Every mission has "id" field, you can put it into template to see details: http://missions.thedarkmod.com/get_mission_details.php?id=25 (cvar cv_tdm_mission_details_url) And from this XML you can put screenshot path into yet another URL to download screenshot: http://missions.thedarkmod.com/screenshots/25_builders_blocks_0.jpg (cvar tdm_mission_screenshot_url) These are cvars in engine: idCVar cv_tdm_mission_list_urls("tdm_mission_list_urls", "http://missions.thedarkmod.com/get_available_missions.php;http://missions.thedarkmod.com/available_missions.xml", CVAR_GAME, "The URLs to check for the mission list XML." ); idCVar cv_tdm_mission_details_url("tdm_mission_details_url", "http://missions.thedarkmod.com/get_mission_details.php?id=%d", CVAR_GAME, "The URLs to check for the mission details XML." ); idCVar cv_tdm_mission_screenshot_url("tdm_mission_screenshot_url", "http://missions.thedarkmod.com/%s", CVAR_GAME, "The URL template to download the mission screenshots." ); This interface for missions database has not changed in ages. Everything else is kinda additional/unofficial information. Maybe we'll add it to "details" XML in future, maybe not. Parsing wiki page is a bad idea for a normal application. But I think someone else did it in order to create a website with the list of missions.
  9. This is certainly a different issue. It renders bright lines along scissor rectangle of some visportal area (happens near visportals). It might be the same as 4660, but much more likely to appear after the optimizations. UPDATE: No, they are not related. I'll soon commit a fix for this scissor issue, and those two issues from 4660 still happen. In fact this problem is clearly distinguished by the fact that bright lines are always horizontal or vertical (go along light scissor rectangle), and they move as player moves even if light + shadow casters are still. UPDATE: Hopefully fixed in svn rev 10463.
  10. It is possible to add: Entity spawnarg --- means that this entity should casts shadow even if it's beyond walls according to area/portals. Worldspawn spawnarg --- same meaning as p.1, but applies to all entities in the map. This is OK if the mission is rather up-to-date. The older missions (like before 2.08 maybe) were compiled with older dmap. While I tried to add some compatibility cvar for dmap, it is still likely that fresh dmap will behave differently. You'll have to test the whole map thoroughly, and probably fix dmap-related issues everywhere. On the other hand, adding spawnarg is risk-free, since it does not require fresh dmap. Yes, the major part of the problem is that these caulky walls don't manifest any issues until you carry a light source into specific position. The original game would be buggy only if simple static light is in that position, which is much easier to test. Maybe filter away entities in DarkRadiant and look for visible caulk. I think mappers put caulk on surely-invisible part as an optimization, since otherwise this brush surface would actually be rendered (although only to depth buffer, which is cheap). But some of these surfaces should cast shadow, so it is no clear which can be replaced with caulk and which not. My suggestion is: Create a dedicated thread regarding light/shadow issues. Move the messages from this thread into it too. Analyze cases one by one. It can easily happen that some issues are caused by other things. Decide what to do when we have enough info.
  11. You can probably write a new one, and use it in your readables. If you override existing one, the next change in core will break your mission. The only question is: is there any hardcoded stuff in C++ connected to readables?
  12. This would be almost the same as "disable new optimizations completely". Perhaps first see how many missions are broken.
  13. I wrote about it here: https://bugs.thedarkmod.com/view.php?id=5172#c16126 This is broken by my shadows optimization. Basically, this map breaks Doom 3 assumptions by replacing some parts of world geometry in the doorway with caulk. No idea how to fix it in engine (aside from disabling all the optimizations). UPDATE: We had a major performance issue with shadows. Imagine we have a small fully closed house with a light source inside it. The light has huge light radius, which covers a lot of stuff outdoors. Previously, all that stuff did cast shadows, despite everyone agrees it is not necessary. This is no longer the case: the latest dev build won't cast shadows for the entities outdoors. Now imagine that part of the wall of the house is replaced with caulk. The engine still thinks it is a solid wall because it's fully enclosed with opaque surfaces, so it drops shadows of outdoors entities. But outdoor objects might get lit. This map does the same.
  14. I guess I'll copy my answer too. I think all these use cases are blocked by the fact the TDM core readable scripts don't support them. If you want to use TDM's readable code, then you have to respect its boundaries/interface. If it does not normally support something, then you can't do it while using them, regardless of what features GUI scripting or game scripting supports. On the other hand, let's suppose someone is willing to implement a fully custom GUI + script, without support --- i.e. no readable.guicode, no xdata, etc. In this case, he needs to put control logic somewhere. Putting it both in GUI code and game scripts would generate confusion, bugs, and maybe even race conditions. Putting it only on GUI side is bad simply because GUI scripting is bad. The only viable solution is to put all the logic into game script. But if all the logic is in game script, then GUI does not need the runScript command. It should only set some of its own gui variables as "requests", so that later the game script could detect these requests and process them. At least that's how TDM core readable support works.
  15. My idea is that the game engine chooses box size automatically. It means that someone (e.g. me) will have to see where to take width calculate from in the C++ code, and add corresponding logic to subtitle integration code. It's not like we run some script once and then live with hardcoded settings in .subs files forever.
  16. I don't like variable-sized subtitles in general, especially if people can set width at will. If we know speech subtitles are not going to be large, then we can make them always less wide. Although I'm not certain we can know it in advance. Maybe we'd better implement some automatic size adjustment for subtitles in the future? If the subtitle fits one line, then show it on one line. After that, check 3 tiers of width and show the minimum one that is OK. Of course, top-middle point of the subtitle box is always at the same location, even if the box is smaller.
  17. There was an idea to add two features to GUI scripts (6164). The first one is runScript command, which allows GUI script to call a function from game script. Interestingly, this feature is already supported in the GUI engine, but the game code only processes this command when the player clicks left mouse button on the GUI (i.e. usually it works in onAction handler, but not in namedEvent or onTime handlers). Obviously, ID initially did not envision runScript as a global feature which works the same way everywhere, their idea was that it is context-sensitive, and whoever calls the GUI code can then pull the commands generated by the call and do whatever he wants with them. I'm not sure I really want to change this architecture... Anyway: what are the possible use cases for runScript command? The second feature is namedEvent command, which simply generates/calls a named event with specified name on the whole UI, which can be then handled by matching onNamedEvent handlers. However, this command can be implemented in several ways: Whenever namedEvent command is executed, the named event is processed immediately. The rest of the script (after namedEvent command) is continued only after generated named event is fully processed. Whenever namedEvent command is executed, named event is put into some kind of queue, then the current script continues to execute. The generated named event is executed at some moment later, but surely on the current frame. The point 2 can be further differentiated on the exact order when generated named events are processed. So the first approach is how functions normally behave in normal imperative languages, with a real call stack. The second approach is delayed execution, like what we currently do with "resetTime X; -> X::onTime 0 {...}" combo (at least everywhere in the main menu GUI). My worry with the first approach is that it is an major change for GUI engine with no past experience, and it will probably not match well with the long-established GUI wierdness (I mean e.g. the wierdness that all expressions in GUI script are executed before the script commands start executing). And it would work different both from the "resetTime + onTime 0" combo. On the other hand, the callGui in game scripts do execute named event immediately. And I must admit nested GUI calls could be used to reduce the issues from the GUI weirdness mentioned above. Also, this command exists in Quake 4, but I'm not sure how exactly it works. And it's probably good idea to make TDM work the same way.
  18. Oh sorry! When I started, I tried to find the prototype, but did not find it. So you suggest to reduce the width of subtitles? How can you even do it globally? Where would you place all the text? Having different width depending on verbosity... that's something to think about. I bet most people would actually care about story subtitles anyway, both players and mappers. Maybe it would be OK to have smaller size for speech only.
  19. I make automation script which draws bow for 0.1-0.85 seconds (with 0.05 sec increments) every 3 seconds. The SVN version does not crash. Perhaps I should take your config file and retry on 2.11. Also: do you have any mods installed?
  20. I have implemented your idea: The volume-to-alpha thing is a bit weird since it does not take volume of the sample into account (hopefully improved in the future). And perhaps someone would replace images (I'm not an artist, you know). But it works and looks nice
  21. I think people will have way more misclicks with single-click vs long-click prototype: you don't even need a second press to do the wrong action. And increasing the duration threshold to reduce this chance will also increase delay of single-click actions, which is hard to notice on 200 ms.
×
×
  • Create New...