PranQster

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?

Scratch that last post claim of 1 week. Time flies faster than I realize. Also, I have a few more ideas which I feel need to be incorporated into version 5. I also need to experiment with the elevator call positions a bit more. AI are sometimes hesitant to step onto the platform after having called the elevator to their floor. Since I will be re-doing the cave at the beginning of the map, it would be a good time to re-do the cliff walls as well. The player will require more hiding places in the outdoor area, due to changes with the way things are illuminated. Some creative landscaping is due to accommodate this.

FYI, everyone, I'm likely about 1 week (yeah, right) away from Siege Shop v. 5.0 (Beta). This will be the biggest re-design since v. 3, and the final version of the mission (sans bug fixes for future TDM releases). I just need to make a new cave area for the player to pass through, finalize some lights, adjust some AI paths, and finish modifying/decorating about 3 or 4 rooms. I also have some fancy furniture which needs to be replaced with some rougher furniture. Readables will then be given a once-over and it will be ready to release for Beta testing.

I have so many missions to catch up on, I can't decide which to play first. These reviews will help.

'bureau_door_frob_controlD2' is the name. Yes, the frob control makes the items frobable when the door is open and not when closed. The door itself was clipping the frob control brush, causing the door to become unfrobbable when it was closed. So if the key wasn't grabbed while the door was initially open, it can't be retrieved. All oil lamps have been replaced, but not all with lights which can be extinguished. That may change, but some parts of this map will be easier while other parts will be more difficult.

Allow me to re-post what I already posted. That part about the door becoming non-frobable applies to all contents of the desk as well. It has been fixed. This fix will be in the next release, which will be relatively soon.

I don't know. I've never used any such command.

I'll check into all of this. I'm likely a week away from having a beta ready, so all of this will be addressed soon.

One of my AI bashed his head last night on the elevator which was never broken. It was one of those cases which I need to address where an AI leaves a path network and then chooses to immediately re-enter it. This AI, the cook, came down the elevator and stepped off, turned around, and stepped on the elevator again. Then he activated the switch for the upper floor before he had even walked all the way onto the elevator. (Maybe...I might be mistaken...) This caused him to bash himself upon the upper frame of the entrance to the elevator. I guess he learned his lesson, because he turned around again and stepped off the elevator and continued on his normal path on the lower floor. I guess he gave up on the second floor with a raging headache.

Ahhh! But of course! I did make changes to the bookshelves, replacing simple shelves with full bookcases. And I have been lazy and right-clicking on models and choosing to surround with m/c. I have not been extending those to the ceiling, though I had when originally making siege. Thank you in advance. I'm sure that's it... about to find out. And thank you after having fixed the problem. I will be much more careful with m/c in the future. Now I can get back to making it look better. This would also explain why AI have sometimes been hesitant to exit the elevator platform.

Interesting. I think I'll delete the new doors and block off the ends of the new hallway with solid brushwork and see if the bottom stop works again.