PranQster

Suddenly tonight, the ragdoll started falling through the elevator entity. I'm not sure what happened but I can't get the ragdoll to float now. (I had moved it a little ways from where I had created it). Fixed. I needed to revert the elevator to worldspawn, convert it back to an elevator, and re-bind it to the mover_bobbing. Until I did that, the ragdoll kept falling through.

Ok. I'll check it out and see if there is anything to add. A boat bobbing on waves is easy. I'll make some prefabs and post here, but I did the following: For a regular existing boat model to bob, etc. This will rotate, bob, and undulate at the same time: Put an existing boat model in the map at its initial position in the water. Create a nodraw textured small brush, I use 4x4x4, and change it into a 'atdm:mover_door'. I set the following properties: 'auto_close_time' '.15' 'auto_open_time' '.15' 'frobable' '0' 'grabable' '0' 'locked' '' 'move_time' '1' 'pickable' '0' 'rotate' '0 .35 0' 'snd_close' 'nosound' 'snd_open' 'nosound' 'stop_when_blocked' '0' 'used_by' '-' Do the same method for creating an 'func_pendulum' with the following: 'bind' 'atdm_mover_door_5' (obviously, use the name of the mover_door created in the previous step) 'phase' '2' (OPTIONAL: best to use 'phase' if there are more than one pendulum in the same area and you want them to be out of sync from each other) 'speed' '4' (The lower the value for speed, the less the pendulum will swing) And one more little cube to become an 'func_bobbing': 'bind' 'func_pendulum_1' (your pendulum name) 'height' '.225' (play with this for how choppy the water is, along 'speed' value) 'speed' '1' Place the 'func_bobbing' and 'func_pendulum' in the center of the boat, at the water line. I placed the mover_door at the shore, where I attached a rope from dock to boat. The mover_door was placed at origin of rope at the dock. This will make the boat rotate in more of an arc in the water. If you want the boat to rotate more in place, put the mover_door under the boat. Bind the boat to the func_bobbing You should end up with the following binding: boat > bobbing > pendulum > door (rotator) Alternatively, the door entity could be a sliding type to move the boat across the water. Or the func_pendulum could be bound to a mover on a spline to make the boat go wherever you want. I'll attach my custom 'elevator' boat which an AI can stand upon and ride around. Attached. AI can ride in the boat_elevator_03.pfb while standing, but sitting will interfere with the entities moving the boat, causing the boat to randomly come to a dead stop. If an AI is positioned between the seats and given two path corners, stacked directly above him, each with a path_turn and a path_sit, then he can be made to sit on each seat in the boat. All of these path entities were bound to the boat so they aren't left behind when the boat moves. The AI will just turn in place and sit down. Adjust the AI sitting slide distance to get him over the seats and bind some cushions to the boat seats so he doesn't sit in mid air. I have not yet succeeded in making an AI do regular pathfinding on the boat. I tried to get him to walk from stern to bow and sit on each bench, facing forward. Can't make him move an inch. I even tried an aas_obstacle entity, as found in the 3-floor elevator, but can't get the AI to find a path. I'll make one more prefab including the movers, etc. already bound to the boat.... And now attached as boat_elevator_ahoymatey_01. Maybe someone can figure out how to make an AI path find whole being dragged around by a mover. In the meantime I'll test with a basic boat with no movers. If I can get AI to pathfind onto a static boat, then portals can be used to replace the AI with one with no paths, and the static boat with a moving one. The moving boat can take that AI to the other side of the river/dock, etc. where another set of portals places a static boat and AI with pathfinding in the new area. Better yet, perhaps only the boat itself needs the portal. AI pathfinds onto static boat at dock (no bobbing), triggers timer when entering boat and then portal when AI in position AI gets path_wait with time set for the time of the boat ride Boat replaced via portal with bobbing boat on a mover Bobbing boat moves to other side of the river, carrying the patiently waiting AI AI presence triggers portal to replace boat with no movers AI path_wait times out and sends AI on path on new side of river This should allow AI to pathfind to a boat, embark, ride, disembark, and continue to pathfind (apparently). boat_elevator_03.pfb boat_elevator_03.zip boat_elevator_ahoymatey_01.pfb boat_elevator_ahoymatey_01.zip

Ahoy Matey! Eventually, the mover_sliding entity stops working when the AI is sitting, but if the AI is standing then the boat will move back and forth without issue. No audio due to TDM alsa audio not linking properly into pulseaudio output. So OBS gets no audio even though my speakers do

A city map will be my next challenge after I finish my big outdoor map. Having lived my entire life in places where the oldest buildings date to the mid 1800s, I have absolutely zero real world experience being among medieval architecture. It's a lot easier to modify a big patch into a lumpy stone cliff than to make a good looking building.

Go for it. I also suggest trying different shapes for the cage, experiment. But my example is a good starting place. I tried it with monsterclip and it works. The ragdoll respects the static entity as long as it is an elevator! On a related note (using elevators to place AI where they normally won't stay): What does not yet work (as seen by me) is to convert a model, ie. the rowboat, into an elevator and have an AI sit in it (without using a separate elevator). The AI just falls through the boat, probably already having clipped the collision model. I suspect the AI might be able to be placed high above the boat, but would likely end up levitating above the boat due to the boat having a big rectangular collision model. But, putting a little elevator "cage" in the boat for an AI to sit upon does work. Then comes the issue of making the boat bob and such. If the AI is standing in the boat, the boat bobs, rotates, etc with all of its movers, unhindered. If the AI is sitting, the movement is intermittent and often stops for long periods of time. Since I'm currently working on siegeshop yet again, I think I will temporarily add an AI which does nothing but ride elevators. I'll put a chair in an elevator and have him sit on it when riding to see if elevator movement is impeded. DOH! The rowboat is such a simple model. Why don't I simply re-create it with brushwork and convert that to an elevator? Haha! A little project for later today. A basic small rowboat was created out of patches and made intro an elevator. So far tests with an standing AI look pretty good. A sitting AI looks even better until the movers for the boat stop moving. The AI needs to be a bit more stable, so I will make a flat bottom on the inside of the boat. It needs that anyway to hide the water in the hull. Sitting AI still interfere with the movers the boat is bound too, but I almost have a fisherman standing up which moves smoothly with the boat.

Well. Everything just came to a screeching halt. I had done a bunch of work AFTER fixing rotation on many entities. Then when testing the map last night I decided to operate the drawbridge.That's when I discovered that the various chain segments which rotate and translate as the drawbridge lowers are now not rotating and transforming to where they need to be. So I will have to open a backup version of the map and copy the rotation values back to the many chain segments. A future TDM release might break the drawbridge, but for now it requires those bad rotation values to function. AHA! Those weren't the chains I fixed rotation on. Instead, the chains had become un-bound from the drawbridge due to two entities changing names. I have two metal rings on the drawbridge which the chains are bound to. They were both replaced with properly scaled models, so their names had changed and I had failed to update the binding of the chains. Drawbridge fixed. All is well.

Lol. Not gonna happen. The one time I had it in there was a happy accident. But it was a pain to try to get a proper sized unit of grass. I'll think about it.

All badly rotated entities were either fixed or replaced. So the next released version will be compliant with future releases of TDM. Next I will go through the map and adjust all the lights to look good with 2.08. Then comes a new start area, outdoors, before the cave. Perhaps it will feature a bit of hide & seek with some patrols on a road. I'd also like to do more integration of the human-built structure with the cave system. And I'll be changing the entire second floor textures and decor to be a less fancy upgrade from the other floors.

I haven't tried TDM on a laptop with an external monitor. Nor have I tried borderless fullscreen, though that seems to be windows only. In my case I also have 0 experience with wayland as it does not yet work with nvidia. However I will try to test this when I can, though I seriously doubt the laptop I have will even run TDM.

I'll never be done with this map. "WARNING:Detected 114 func_static-s with bad rotation:" Hehe. I have some work cut out for me. ... So, I'm going through siegeshop one room at a time and checking all entities which have been rotated and possibly re-scaled via rotation. I am finding many entities which have only ever been rotated by 90 degrees on any axis, but having crazy looking rotation values. These are items which have not been re-scaled and only rotated. As an example, I have above the cook stove, 'models/darkmod/mechanical/pipes/steam_pipe02_bend2.lwo'. The current one has a rotation value of '-4.21469e-08 -1 0 4.21469e-08 -1.77636e-15 -1 1 -4.2147e-08 4.21469e-08'. I delete that rotation and then give the pipe 90 degree rotations on X and Y, ending up with rotation value '0 -1 0 0 0 -1 1 0 0'. The pipe ends up the exact size and position as before. I have no idea how those other rotation values had ended up like that. 85 to go, down from 114. About 1/3 of what I fixed so far were entities that I had simply rotated but not scaled.

Ok. I never knew there was such a feature. Thank you.

Ok. Thanks. I already know of a few models which didn't exist when I started some maps, and do exist now (such as hanging coil of rope). So I'll work on replacing such entities.

Is it possible to suppress warnings on static_entities which have a "bad rotation matrix"? I often re-size models on at least one axis by modifying the rotation values, so I end up seeing a lot of these errors when doing dmap.

I did that, more or less. I made some extra little walls and dividers to keep the ragdoll from sliding off. See the video I posted. I'll make a screenshot in DR of the little cage and post it here. The ragdoll has been made stable. The little cage/sled is made of tdm_nodraw_solid_liquid right now. I'll test it with monsterclip, which will probably work since the ragdoll will likely see the elevator as solid no matter how it is textured. Then the player won't hit any invisible obstructions if the ragdoll is grabbable. I'm thinking of trying a trigger system set below the surface of the water in a well, or something similar. The goal would be to have the player drop a KO'd AI or other (named) ragdoll down the well. The dropped AI would likely not be positioned on an existing elevator/cage properly, so it will need replacing with a ragdoll in the proper position (which would be in another room already loaded on the cage). The named AI would immediately sink and hit the trigger, which would activate portals to replace the dropped AI with the ragdoll & elevator platform. That would then be moved slowly to the surface, followed by rotation and bobbing. Nice thing is that the elevator system itself does not need setting up, just the basic elevator entity bound to a standard mover.

I had a thought when considering the use of an elevator. Ragdolls can be placed upon an elevator and moved around. So I made a small brush textured with tdm_nodraw_solid_liquid (lol) and made it into a func_mover_elevator. I placed that under a ragdoll at water surface. With no movement of the platform, the ragdoll just stays in place. Arms, legs, and head can all droop if the entity is shaped properly. I then bound the invisible elevator platform to a func_bobbing and that to a func_rotating entity. That worked rather well and the ragdoll bobs and rotates in the water with limbs dangling. Due to the bobbing and rotating, the ragdoll eventually slides off the platform (currently a rectangle from neck to waist and shoulder to shoulder). But it doesn't shake and twitch like other disturbed ragdolls sometimes do. If I can get the platform shaped just right, then ragdolls can be floated with bobbing and rotation, etc. And yes, that is a spider walking on the wall at the left edge, just above the brick. Here's a video taken after modifying the sled .

Repaired in siegeshop by switching to a different particle. Several of the water splash particles do this, including the ones starting with 'tdm_'. I switched to a large steam particle instead. OMG I hope I put it in the .pk4 Time to repack and update the link. And I have been delayed by a suddenly misbehaving ragdoll in the dungeon. That guy stayed put for years, lol. The .pk4 linked in my FM post now has the steam particle added. I'll have to run it to check the ragdoll.

Will do. I'll check for the best place.

That was fun setting up. Not difficult, just some tinkering to get the rain the proper height. This years big update of siegeshop added rain splash to the crates and benches on the roof. I'm planning one more update after TDM 2.08 is released, mostly to expand the mission start area. That area will be outdoors, before the cave, so it will have rain there as well.

Thanks. I'll try it. I did try making a savegame, shortly after which (about 1 minute) there was a standoff between one AI exiting and another trying to enter the elevator. I loaded that savegame and moved near the elevator and saved again. But this time the AI behaved as they should.

A tiny update today. A water splash particle was fixed for TDM 2.08 and some improper and redundant visportals were removed. The link in the original post has been updated.

It's also quite possible that this behavior has always been there, but the RIT networks make it so rare for this to occur that I simply never saw it happen before. It just happened to be with my first run with 2.08 that I saw it happen twice. I just saved the map in DR 2.80 and dmap'd in 2.08 and so far only see issues with a watersplash particle. No conflicts yet witnessed at the elevators. If I see two AI heading for the same elevator I will make a savegame.

For those who experience low FPS, or FPS synced to vertical refresh even when set not to, try the following. Before launching TDM for the first time after logging in to your DM of choice, run nvidiasettings and select 'OpenGL Settings'. Move the slider for 'Image Settings' to any position (& back again if you want). Mine is normally set for 'High Quality', but if I move it to any other setting and back again, TDM then starts with full frame rate. I used to have to launch TDM multiple times, over and over, until I got full frame rate. Now it works properly every time as long as I make that adjustment before first launching. This has annoyed me for freaking years. It's the only game I've seen do so, though I haven't launched old doom3 in a long time.

DR, now 2.8.0, built properly for me with lib64wxgtku 3.1 in Mageia 8/Cauldron. I had major UI issues when having built with 3.0

No, I didn't think of it. It would be so random that I'd need to wait for it to occur, then make a savegame while the standoff is happening. Would that work?

Elevator use seems to have issues in 2.08 I just dmap'd and loaded up siegeshop last night to check with 2.08 compatibility. Aside from a water splash particle I need to replace, I found that when two AI try to use an elevator at the same time, they come to a standoff at the call buttons. The AI just sit there doing nothing. I need to use one of the call buttons to move the elevator. Then one of the AI will finally decide to use it and everyone gets to pathing again. To clarify, I saw this happen twice, and at each of two elevators. In both situations, the AI trying to use the elevators were on different floors from one another.