stgatilov

I have an idea of adding TDM connection management to DarkRadiant. The plan is to combine it with TDM hot reload features later. Here is a brief list of features: start/connect to TDM, stop TDM dmap/start current map camera DR to TDM synchronization showing selected entities/brushes in TDM update entities in TDM immediately after they get changed in DR ("hot reload") The idea is to use new automation framework to send commands from DR to TDM. It already supports running console commands, moving player, clicking GUI elements. The core of automation framework is socket-based network protocol. TDM engine listens on a socket, receives some commands and sends back responses. There are also Python scripts which can send automation requests to TDM and provide some high-level API. The Python code is currently located in TDM assets repo in devel/auto. For what I see, any feature in DR can be implemented in three places: core (C++, all games) plugin (C++, TDM-specific) scripts (Python embedded) Initially I thought I would try to use automation as Python scripts, but there some problems with this approach. The DR scripting API is not suitable for running persistent Python tasks. Mainly, there are no events, and no way for Python script to live long and react to events. Since automation is only implemented in new versions of TDM, it should not go into core. So I imagine the best idea would be to create a new TDM-only plugin. Even if automation will be in C++ plugin, it would be helpful to use automation Python scripts. I have seen at least two problems with it: Embedded Python is 3.6, while my code has strict type annotations, and use some feature of 3.7. Don't remember which, but the line from __future__ import annotations does not work in 3.6. Embedded Python has socket.pyc, but does not have _socket.pyd, making it unable to interact with sockets. On the other hand, I can copy/paste automation message framing from TDM code, then somehow hack process creation/destruction in C++, and live without Python. I wonder if there are any issues or limitations with plugins. Can they listen to events or execute some code regularly? Do they have access to underlying data? Can they have their own GUI elements, like windows, buttons, menus, etc?

Because nobody knows them?... At least not good enough to post them officially.

What about points 4 and 5?

I had thoughts about providing FMs in the same installer the same way. If I add it in future, it definitely won't have any fancy features like showing descriptions, screenshots, etc. The only possible reason to download FMs in tdm_installer is the ability to preserve older version of FMs. Suppose that FM was working in TDM 2.08, but was updated for 2.09, and the updated version stopped working in 2.08. It is all written in tdm_installer.ini. There is a related checkbox "Don't download config" or something like that. One important exception: every official version must be present on TDM server (which is hardcoded in exe). If someone wants to use it for his own stuff, he will have to fork and rebuild the installer. I think that's the verification procedure that you already complained about Yes, downloads are not preserved right now.

Meanwhile, a new version of installer is ready. Now user can optionally delete darkmod.cfg and create desktop shortcut after install. It is astonishing how a simple problem of creating shortcut takes half a day to implement

It does not make sense until tdm_installer becomes official and tdm_update bites dust. Because dev builds are only available in tdm_installer. Filebrowser and alert message are going to be pain. Because right now I spawn them all with simple C functions. Yes, I have noticed it too. It is especially bad on fresh install. Downloading is already over, files are verified to match checksums. Architecturally, it is part of "downloading" task, but progress ratio is measured by downloaded bytes, so it stays 100%.

New dev build of TDM published in tdm_installer. Changelog provided here.

Published a new version of tdm_installer. The GUI is reworked completely. Everything has less size, sizes are more or less like my OS windows have. Reverted to default font size. Colors tweaked a bit to remind how my Windows 10 looks. That's not the default of FLTK, but looks more like modern GUIs look. Unfortunately, alerts and file browser now look a bit different than everything else I did not add any hover actions for now. @freyk, @New Horizon, please say what you think about new GUI style.

Do I understand it right that you change key bindings in game menu, then exit the game. And when you launch it again, the keybindings are back to original values? If yes, could you please: find line seta logFile "0" in darkmod.cfg and change it to seta logFile "1" save file DarkmodKeybinds.cfg before launch launch TDM and change key bindings in it, then exit save file DarkmodKeybinds.cfg now and compare it to the original one check that the file DarkmodKeybinds.cfg is allowed to be written by everyone find file qconsole.log in fms directory (in subdirectory of the currently installed FM) and attach it here

If this happens only on Painter's Wife, then I would appreciate if you share the savegame. If you can load it by starting new game first, then it is indeed not the problem with format, but something else.

I have fixed the problem in svn revs 8866-8867. The fix will be in 2.09 and in the next dev build. By the way, I really like how this FM works! I only got to the manor. Because when I reached it and looked over the maps.... well, I hope I'll have time to finish it one day But before that it was pretty cool and refreshing, especially the realms system, the shovel, and many conversations Obviously, the authors have decent programming skills So many nontrivial scripts in the FM!

You can read full explanation in the issue 5302. Meanwhile, could you please report if the workaround works for you?

A stupid question: do you always load some sort of savegame? If yes, could you also give the savegame? UPDATE: The mechanics of the last crash is that some script function calls getCurInvItemName, but player's inventory has no items in current category #str_02389 (Lockpicks). So InventoryCursor()->GetCurrentItem() returns NULL pointer, and final GetName() crashes. UPDATE2: As for workaround, try to hit "Clear Inventory" key before doing whatever causes the crash for you. This key is unmapped by default.

New version is published. Now when you install some version, installer saves the set of files this version contains in a file. When you install different version later, it deletes all those files of the old version. This won't change much if you install official versions, aside from minor details like alsoft.ini being removed when downgrading to 2.06 or earlier. But it changes things if you install unofficial versions (like VR version) which add their own files. Such custom files will now be deleted when you decide to install back an official version. By the way, the VR version can be now installed in tdm_installer like this: Check "Get Custom Version" on first page and click next. Copy/paste this to "Custom manifest URL": http://darkmod.taaaki.za.net/zipsync/VR/209a1/manifest.iniz Choose release208 in GUI tree --- that is the base version. Continue as usual. Also, I will post some sort of changelog for dev. versions in this thread. New dev build will appear soon. Next I will look into GUI style issues (make it look more familiar) and documentation of the whole system on wiki.

If you are caught in such situation, you can temporarily rollback to 2.07 using tdm_installer, finish all your progress with old savegames, them update back to 2.08 and start new missions there.

The log does not contain anything when the problem happens: the engine just starts shutting down. Strange. Let's do it this way then. 1) Download debug information here. Get thedarkmod.x64.debug.7z and unpack it into TDM directory. 2) Run gdb ./thedarkmod.x64. It should load debug symbols from the downloaded file. 3) Enter command: b idGameLocal::MapShutdown (creates breakpoint at game end) 4) Enter command: run (start game) 5) Reproduce your problem until breakpoint gets triggered. 6) Enter command: generate-core-file (save core dump) 7) Zip the core dump and share at google drive or something. Yes, the core dump is huge, but you can remove it shortly after the problem is analyzed. UPDATE: If breakpoints triggers before you get to the problem (e.g. on initial map load), then enter continue in gdb. UPDATE: I enabled access to everyone by the link. Somehow, that was usually the default, but recently it has changed and I forgot it.

Memory leak is not the reason for crash. I think the best idea would be to record a crash dump (I guess in linux it is called core dump). Here are some instructions. While assets SVN contains debug info for all Windows releases, I also have debug info for Linux build of 2.08 locally, so I can inspect the state at the monent of crash.

I think it should choose "ALSA default": it looks like the best default and comes first in the list. Why it doesn't work --- that' probably question to ALSA configuration.

Could you please install some 32-bit trash and check whether 32-bit build works properly without setting device explicitly? I find it amusing that it works properly in 32-bit build. It seems to be normal, but completely pointless. It is entirely precise and completely useless information, just like in an anecdote about programmers. Here is discussion about this, which says this weirdness exists for compatibility with old Creative's implementation. Look at the code: //gets list of all available devices --- their names are printed to console as "found device ..." const char *devs = alcGetString(NULL, ALC_ALL_DEVICES_SPECIFIER); //opens default device in OpenAL --- that's what happens if you don't set s_device openalDevice = alcOpenDevice(NULL); //gets the name of device --- that's what is printed to console as "using ..." alcGetString(openalDevice, ALC_DEVICE_SPECIFIER); It sounds obvious that querying the name of particular device and getting the names of all devices should return the same names. But it does not , because the function which queries the name of the device was in core OpenAL and was useless, and the function to get the list of all devices was added later as OpenAL extension specifically to cope with this problem. As far as I see, I cannot get the detailed name of an opened OpenAL device. But it looks like I can query ALC_DEFAULT_ALL_DEVICES_SPECIFIER to get the name of default device (i.e. the one which gets opened by alcOpenDevice(NULL)). This way I can probably print the proper name to TDM console

Setup OpenAL device and context OpenAL: found device 'ALSA Default' OpenAL: found device 'HDA ATI HDMI, HDMI 0 (CARD=HDMI,DEV=3)' OpenAL: found device 'HDA ATI HDMI, HDMI 1 (CARD=HDMI,DEV=7)' OpenAL: found device 'HDA ATI HDMI, HDMI 2 (CARD=HDMI,DEV=8)' OpenAL: found device 'HDA ATI HDMI, HDMI 3 (CARD=HDMI,DEV=9)' OpenAL: found device 'HDA ATI HDMI, HDMI 4 (CARD=HDMI,DEV=10)' OpenAL: found device 'HDA ATI HDMI, HDMI 5 (CARD=HDMI,DEV=11)' OpenAL: found device 'Loopback, Loopback PCM (CARD=Loopback,DEV=0)' OpenAL: found device 'Loopback, Loopback PCM (CARD=Loopback,DEV=1)' OpenAL: found device 'HD-Audio Generic, ALC1220 Analog (CARD=Generic,DEV=0)' OpenAL: found device 'HD-Audio Generic, ALC1220 Digital (CARD=Generic,DEV=1)' OpenAL: using 'OpenAL Soft' Hmm... it lists many devices, but then chooses device with name OpenAL Soft, which does not even exist in its list Could you please find the line in darkmod.cfg: seta s_device "default" And replace it with: seta s_device "ALSA Default" Also try all the other names listed in console excerpt. P.S. Actually, PranQster suggest the same.

The logs look strange. Different errors everywhere, abrupt end of file in different places, etc. I guess I better won't read them. Could you please check two custom binaries downloaded from here ?

Radeon HD 4000 series, just like in the other thread with same problem. Among extensions, I find it strange that GL_ARB_texture_swizzle is not supported --- it has become core feature of OpenGL 3.3, which this video card should support. Although the game should run without it: I verified the code, and even tried to run 2.08 with marking all the same extensions as disabled in debugger. Could you please follow these instructions and record a trace? Please use the script that I have attached. Note that if the game closes by itself and the trace is less than 1 MB, than it would be useless. apitrace_record.cmd

I have published a new version with one major new feature: custom manifest URL is working. However, we don't have any custom versions to test it yet... maybe we'll try it on VR build I can say that: I used some nonstandard buttons (as I described why above) I used font larger than default Perhaps some widgets are larger than they usually are, which also looks unfamiliar. I'm going to rework GUI style. Share a link of the video if you liked it, I'll look through it too.

As a minor note, tdm_installer will soon allow publishing user-made versions --- that's what "Custom Manifest URL" is for. It is not implemented yet, but soon will be. I'm not sure if it would be easier than simple posting exe + shaders directory though.

Not possible, except if someone wants to rewrite the whole GUI part from scratch. I will try to improve the look, but it will never look exactly as native Windows GUI. They are needed for beta testing a new release. After the release is out, they are left for historical purposes. They don't eat much space anyway. The only dev build currently available is newer than release208. I have just renamed its folder from 208 to 209. By the way, dev build name is composed from two svn revision numbers. They don't want, they just have a habit.