PranQster

Whoa. The in-game downloader should not have version 5 yet. It's only been linked directly to three players. Besides, version 5 is about 30 megabytes and version 4 was about 15. But If you want to see version 5, I'll happily send you my next build with no beta-test strings attached The fish were definitely fixed earlier this year. I had several dozen models which I had scaled 'the old way', before having knowledge of the DR model scale tool, despite it being right there on the toolbar. But then again, I spent quite a while away from DR and many things had changed since I had built siegeshop 3 and 4.

You're testing for me, so I'll test for you

I updated siegeshop earlier this year to correct that. There are no more improperly scaled models in siegeshop. If the current one in the mission downloader still has bad rotations, then wait a few days for siegeshop v.5 which has proper models and much more.

Siege Shop 5 link sent to thebigh and wesp5 I'll open a beta forum thread if need be, otherwise I'll just take feedback through messages.

All that came before was me modifying my tutorial map over and over. Now the mission has a more tangible beginning and feels much more complete.

Ok I'll get back to everyone in the next few days.

I'm looking for two or three players to test siegeshop v.5 lowenz has helped a lot during the big update, but at least two others should test it apart from us... just in case.

Next time I'm in the 'shop, I'll test that and see how my system behaves.

There is a light at the end of the tunnel. No train detected. This update is nearly finished. This will feel like a much more thorough mission than before. I have a little more spit and polish to do inside the building and a little more decorating outside. Then comes a re-vamp of the readables. After that is just finishing details such as the splash screen gui stuff. There will be a whole new outdoor start area. There will be two paths out of the cave. There will be some new, unique things (or so I hope). Some previously broken things, such as frob control boxes, were fixed. Massive re-decoration was done. The fortress is a darker, dirtier place from top to bottom. It also looks much more lived-in now. The Siege Shop is now an equal opportunity employer. A few more employees were hired to manage the new area. The elevators were removed due to lack of maintenance. That, and the officers were getting lazy. The generator was upgraded, despite the removal of the elevators. The storm outside has worsened quite a lot. Be careful out there... Several more things moving on splines. It seems we're not limited to two or three anymore. The most graphically violent feature in the dungeon has been moved to a more humorous location. You might see a rat or four. You might see a horse or three. You might see some things with eight legs. I think I'll be asking for two or three testers quite soon.

Hmm... this looks a little familiar Are you only getting the frame rate drop after having loaded a savegame? Or any time you access the menu, as though it toggles each time?

Almost done. I have a few things to decide upon; a new route for the player to take...maybe. Maybe not. I did just get rid of the 3-floor elevator as well. There were too many issues and I was spending too much time working on it. It looks much better with stairs now. Stairs also open many more possible AI paths. I need to go over the readables too. This is a pain because the readables editor lets me create new readables (apending the siegeshop.xd file), but it does not allow me to save changes to those readables unless I change the readable definition name. DR seems to think the readable has been loaded from an pk4. Anyway, I have a workaround which does the trick, but it's still a pain in the ass. Right now, things are looking pretty good, but I mostly want to tweak the readables and the AI paths. Some animations I chose are not working well for some AI. A little more work (or a lot) is still to be done on the cave near the start. I'll probably re-do the rock wall surrounding the balloon area. I'll add some bushes here and there and some hiding places.

Aah. Sorry I never got back to that. Glad you fixed it on your own.

This would be handy to have a button in DR linked to the TDM executable, and feed it the parameters for running dmap and loading the map. On the flip-side, it's also pretty easy to make a desktop shorcut/application launcher which does this. But it would be handy for DR to apply the map path/name so the user doesn't have to edit the shortcut every time they want to dmap a different mission.

Tip o-the-day for these problems. Keep a text editor or desktop sticky notes widget open and paste the text there first (unformatted, if given the option when pasting), then re-copy to paste to forums.

There's not a lot of info on this error out there, but from what I could find it's likely to do with either openal itself, or with glibc. This one related to openal: https://github.com/unrealarena/unrealarena/issues/30 And this one related to glibc: https://developer.blender.org/T49208 These are from around 2015/2016, so I don't think they'll help much.

Good to hear. My very limited experience with ardour was with ALSA and I did not have a good time trying to set up my inputs and outputs. I have yet to link ardour with jack, but hope for a better experience. As for jack itself, I've used it to link qsynth and some guitar software and in that regard it has gotten much better in recent years. Also, if getting jack running with qjackctl does not work, then try with 'cadence', and it's tools 'catia' or 'claudia'. Sometimes cadence can do a better job of initial jack configuration, and then either cadence or qjackctl can be used. I prefer Cadence because it's graphical tools for linking the audio devices is much more intuitive than what qjackctl has.

Is it possible that when s_device "default" is set, that it is looking for 'CARD=0,DEV=0'? I'm asking because I'm not a programmer and have no idea how a lot of this works. If that is the case, then maybe when s_device "default" is set it doesn't look for 'CARD=Generic,DEV=0'?

I had tried "ALSA Default", with no luck, when I was trying to fix the same issue. I'm pretty sure the device listed as DEV=0 is what is needed, but not the one listed as Loopback. I'm 99% positive that using the following will fix this issue. If not, then try the loopback device.: seta s_device "HD-Audio Generic, ALC1220 Analog (CARD=Generic,DEV=0)" Here's what my condump looks like for openal. Notice the addition of "(ACTIVE)" once the device is working: ----- Initializing OpenAL ----- Setup OpenAL device and context OpenAL: found device 'ALSA Default' OpenAL: found device 'HDA NVidia, HDMI 0 (CARD=NVidia,DEV=3)' OpenAL: found device 'HDA NVidia, HDMI 1 (CARD=NVidia,DEV=7)' OpenAL: found device 'HDA NVidia, HDMI 2 (CARD=NVidia,DEV=8)' OpenAL: found device 'HDA NVidia, HDMI 3 (CARD=NVidia,DEV=9)' OpenAL: found device 'HDA NVidia, HDMI 4 (CARD=NVidia,DEV=10)' OpenAL: found device 'HDA NVidia, HDMI 5 (CARD=NVidia,DEV=11)' OpenAL: found device 'HDA NVidia, HDMI 6 (CARD=NVidia,DEV=12)' OpenAL: found device 'HD-Audio Generic, ALC1220 Analog (CARD=Generic,DEV=0)' (A CTIVE) OpenAL: found device 'HD-Audio Generic, ALC1220 Digital (CARD=Generic,DEV=1)' OpenAL: using 'OpenAL Soft' OpenAL: HRTF is available OpenAL vendor: OpenAL Community OpenAL renderer: OpenAL Soft OpenAL version: 1.1 ALSOFT 1.19.1 OpenAL: found EFX extension OpenAL: HRTF is enabled (reason: 1 = ALC_HRTF_ENABLED_SOFT) OpenAL: found 256 hardware voices ----- Initializing OpenGL ----- And, yes, it is normal for it to say it is using OpenAL Soft.

Throughout the years I have had both the absolute best and absolute worst experiences with audio in Linux. Making sure the user has been added to the proper user groups ('audio' and 'realtime') is important for some audio software to work properly. Right now my biggest complaints are with the problem this thread is about (our devices not being seen as 'default'), and with various programs requiring different audio systems. Audio production can be a challenge, with some software requiring JACK, others want ALSA, others PulseAudio, portaudio, oss, etc.. Fortunately, most of this software uses JACK and that has gotten much better over the years. I used to have to restart the machine to get pulseaudio working again after having used JACK, also to get JACK running again. Now things tend to switch back to pulse properly and have no troubles re-starting JACK. But it's still a pain sometimes.

Have you tried setting this in darkmod.cfg in place of 'seta s_device "default"'? I have the same named audio device and had to set the following manually: seta s_device "HD-Audio Generic, ALC1220 Analog (CARD=Generic,DEV=0)" If that gives you audio, it's through ALSA and will not share with pulseaudio but for one active output. In other words (especially for those mapping with DR), while running TDM audio output will be only from TDM. So you can't test speakers in DR if TDM was run first. Also, if DR is run first and audio is played there, then TDM will have no audio output until after DR has been closed.

After having broken the elevator, and having fixed it again, it's having some issues again. AI sometimes get stuck entering or exiting the elevator. This is not related to pathfinding or m/c issues. When that was happening, the AI would go through their path motions even though they couldn't reach them. What is happening now is AI simply not loading onto or off of the elevator, thus not continuing with their path. The player can help by calling the elevator to another floor, causing the AI to re-call the elevator and continue on their merry way. It seems that the more elevators and mover_multistate platforms are in the map, the worse the behavior gets (nope, that wasn't it), and I added another mover_multistate to the mission, not even near the existing paths of the AI or elevators. This was first another func_elevator, but the AI all had immediate problems loading onto the existing elevators. When this new thing was changed to a mover_multistate, the AI started using the elevators in a more reliable manner. But they still sometimes get stuck. EDIT: Progress is being made with the elevator. I have edited the Y and Z origin values for the multistate position entities and the elevator is working much better. I think I got the Z values set fine, but the Ys need some fine tuning. On the last build I did not see any issues with AI using the elevator. So: I will make a copy of the mission and experiment with redesigning it with only one 3-floor elevator, preferably near t he middle of the building. I'll delete the elevators at the west and east ends and try the central elevator only. The balloon was always an 'atdm:mover_multistate', and now is a new item I added which I am not willing to remove. So... the elevator likely needs to be moved. I can't release the map with the AI getting confused over whose turn it is to press a button or step onto/off-of a platform. EDIT: I did remove the 2-floor elevator in favor of stairs, despite having made improvements to the 3-floor elevator.

I put quirky little things all over the place. Thanks for the encouragement Since I'm in the process of a final major update of the mission's aesthetics, I'll be sure to put some more little things here and there.

How about 2021? Likely early in the year or late 2020.

Keep my "Pagan Tree Village" listed, please. That is in semi-active development, and will be fully active upon the (yes, FINAL) release of Siege Shop 5.0.

How about a main forum topic for "TDM in the news", where a pinned thread for PCGamer could exist alongside other threads for media coverage?