stgatilov

You can set value 144 via console. but I don't think it will give you 144 FPS. There is some place in the main loop, which ensure that at least 1000 / 144 milliseconds have passed since last time we have been here. The real FPS is usually lower than this cap.

Maybe this FM hits some sort of memory limit, like VBO size of buffer mapping size. And the driver starts to do stupid things like reuploading stuff much more times to make it work. If this FM has places with LOD models, maybe check if setting minimum LOD quality vs maximum one helps.

beta209-03 is available. Changelog is provided in its usual place. Use tdm_installer to get the new version, and don't forget to check "Get custom version". In a very rare case if you managed to download beta209-03 yesterday, please run tdm_installer and update to beta209-03 once again. It was a bit different yesterday Note that the new beta contains a lot of new assets and asset fixes. It would be great if mappers check them out

Please try setting "r_gpuBufferNonpersistentUpdateMode 1" along with "r_usePersistentMapping 1" and check if it becomes any better. UPDATE: And of course with "r_useNewBackend 1".

The tdm_update was trying to detect TDM or DR among processes and give warning. Perhaps I should port this thing to tdm_installer.

Please attach your config. I cannot reproduce this problem with mine.

Or maybe config reset does miracles...

How can I trigger the video sequence? I couldn't find the painting. If you know where it is, run "getviewpos" while being there, and copy the coordinates here.

Could you explain how to reproduce the issue? At least post the coordinates of the main objective. I'm flying around the map, but can't find it...

"seeStakeout" is the name of the two scripting functions in this FM. They print message to console (without EOL), and soon after that the game crashes for you. Is it true that you use TDM 2.08 version?

I would say if DR monitors assets, it should monitor all of them: both core assets and FM assets. I'd definitely skip monitoring files inside zips, since it is a very different story. But if there are some unpacked core assets, it would be better to monitor them too (at least TDM devs would be happy). DarkRadiant should have the set of paths where assets are searched for, the most correct approach would be to monitor them all. As for monitoring too many files. I used watchdog module in Python, it watched over 20K core assets without any problem on Windows. Perhaps it depends on which OS API is used by the library of choice. I hope you do use some third-party library for watching over files, don't you? Speaking of preferences, I would prefer having one checkbox per type of assets. This way we can avoid arguing over what should and what should not be reloaded automatically. As for TDM game and game connection. The best approach would be to automatically reload assets in TDM when they are reloaded by DR if game is currently connected. Implementation-wise, DR functions for assets reloading should emit events like "I have just reloaded skins". The game connection should subscribe to these events when it gets enabled, and unsubscribe when it gets disabled. On such event, it should execute reloadSkins or reloadDecls or whatever other console command. P.S. I must warn that my opinion is hardly decisive: I'm neither DR developer nor a mapper.

Another alternative is to move this tweaking to def/script area. It can work like this. 1) If entity has spawnarg "hr_respawn_all" "1", then any modification to this entity leads to its respawn. This setting would be useful for static entities, which don't move around and don't have any sort of memory (func_static, func_emitter, func_speaker, ...). Respawning them is always a good idea, since the fresh entity is indistinguishable from the old one anyway. 2) If entity has spawnarg "hr_respawn__s_shader" "1", then modification of "s_shader" spawnarg leads to entity respawn. This can be added to base classes for spawnargs which are known to require respawn. The obvious downside is that there would be much more spawnargs like this. Also, I guess spawnargs like "hr_respawn_prefix__set " "1" are needed in order to respawn when "set XXX on YYY" is modified. 3) If entity is not respawned, then I can call method "on_hot_reload" on entity's script object (if it exists). In addition to direct modification of origin, rotation, and ordinary model and skin. Hopefully, someone can write this method for TDM lights with their _lit/_extinguished properties, so that they could be updated without respawn. Perhaps it could be added to AIs too.

I'm looking at various complicated cases when mapper has to manually respawn entity in order to update some spawnargs. For instance, various light properties depending on lit/extunguished, LOD settings. Right now the implementation has hardcoded blacklist of spawnargs. If any of them is changed, then the entity is respawned afresh. If none of them are changed, then some fixed updates are performed directly. Currently the following direct updates are supported: "origin", "rotation", "model", "skin", and some light properties. The funny fact is that there is myriad of spawnargs which are not handled properly and which are not yet in the blacklist; changing these don't work currently. On the other hand, respawning the entity manually solves the problem perfectly in most cases. I wonder if I should replace blacklist with whitelist. I.e. respawn any modified entity, unless all the modified spawnargs are the ones which can be handled directly (listed above).

Very unlikely. But when you delete/respawn entity, its sound remains (that's default behavior when deleting entity). I'll make sure sound is stopped when entity is deleted via hot reload. I'll force respawn if any spawnarg starting form "s_" has changed. Along with sound stopping fix, it solves the problem. The harder problem is with lights. They have some stuff with "lit", "extinguished", "unlit", etc. suffixes, and script code which switches between them. I'm not yet certain how to deal with them.

Technically, it is possible to ask OpenGL after FBO creation if FBO indeed has the desired format. But I'm not sure if it is worth the trouble, and if it would help at all. Also, I'm not sure about the referenced news article: will this bug be fixed soon by driver update?

I think we can add a GUI button which would start or restart map in TDM. It can be used for many different features already proposed. I think there should also be a "dmap" checkbox near the button. I see it working the following way: If TDM is already connected, then execute "getviewpos" to learn current coordinates and disconnect. Save the map in DR if it has local modifications. If there is no TDM with automation ON, then start new one. Connect to TDM instance with automation ON. Select the current FM(project) if it does not match yet (extend automation: learn the current FM). Run dmap if the "dmap" checkbox is enabled. If there is an error, then stop completely. Start the map. If camera sync was enabled initially, then enable it again (turning noclip/god/notarget ON). If the player position was saved, then "setviewpos" to it. If various other modes (i.e. map update) were on, then enable them back too. I think it should cover the features like "start TDM automatically", "restart map", and "dmap map". P.S. @OrbWeaver, I guess we need to search for yet another library, this time similar to Python's subprocess. I have written various process-starting C++ code with WinAPI in the past, and don't want to go through it again

Yes, respawn should serve as a way to "force" full update. Could you please report precisely cases which don't work, so that I could probably adjust builtin rules in future? It is pretty hard to understand when something is changed from within TDM. For example, in order to set god mode ON, "god" command is executed, then the console message is read, and if it says "god mode OFF", then "god" command is executed again. There is no direct way to learn if god mode is ON, and although it is possible to add a specific automation command for this, I'd better avoid it. And it is even harder to learn when god mode changes: I believe current architecture is like HTTP, i.e. TDM cannot send stuff when it wants to, it only responds to requests sent from DR. I think it would be better to add a way to "restart FM", and make it disable/enable camera sync automatically.

It exists in some sense for 2 years already. But without proper release scheme (neither part of TDM not part of DR) and requiring Python to be installed. I use it most of the time to edit shaders, and it supports models and materials just as easily.

If it runs once on trigger, you can probably respawn the trigger, and run it again.

I guess @kingsal means changing textures on brushes. Right now hot reload cannot do it, so dmap + restart is needed. To be honest, tweaking monsterclip is a way much harder task among these two...

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.

Report it here. You can always restart the map by going to TDM, hitting Esc and Restart Mission. I don't like the idea of creating a DR button for everything which mapper might ever need. Better cover something which is either not possible to do manually in TDM, or something which is done too often to bother. Reloading map afresh currently does not sound like this.

Note: just like the "Launch the map in TDM" feature, dmapping from DR is not implemented yet. It is of course perfectly OK to discuss them now, but for the first time it's GUI will probably be missing/hidden. I think right now mappers want "Launch map in TDM" quite a lot. As for dmapping, I recall such ideas too. The thing is: running dmap from DR is trivial. But fetching warnings and errors back to DR is more questionable. I can fetch back all the console messages which happened during dmap as one huge text, but not sure what to do with it then. Perform text-based filtering for warnings and errors in DR? Some warnings have additional text printed afterwards, and users won't see it unless they switch to TDM console and manually scroll to it. Also, could you write the "workflow" (sorry for this word again) when you have to dmap repeatedly? I had an rather complicated idea about limited hotreload for brushes, and had very faint idea for making dmap incremental...

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.

I tried to merge only those GUI changes which "surely won't break anything". The big story (about expanding supported ways of customization and removing unsupported from FMs) lives in its own branch, and is delayed for 2.10. So if something broken, it is unintentional. On the other hand, the state of menu GUI is such that touching it slightly in one place often leads to many unrelated things broken, so no surprise I tried it in 2.08: I see snow animation, but the music is default one. I think the proper way was and still is uncommenting these lines: // Uncomment this to override the default menu music //#undef MM_MENU_SOUND_CMD //#define MM_MENU_SOUND_CMD "music tdm_mainmenu_background_music;" // Uncomment this to override the default in-game menu music //#undef MM_INGAME_MENU_SOUND_CMD //#define MM_INGAME_MENU_SOUND_CMD "music tdm_objectives;" In Snowed Inn, these lines are commented...