grayman

Just to be clear: 'angle' and 'speed' are set on the func_pendulum, not the model.

I have swinging signs in Cleighmoor. Place the func_pendulum (a 2x2x2 nodraw-textured brush) on the axis of rotation of the model, bind the model to it, and give it these spawnargs: angle (angle of the axis of rotation - this is right angles to the swing direction) speed (how far it swings) One sign swings in the NW<->SE direction. The func_pendulum has: angle = 45 speed = 3 Another sign swings EW. Its func_pendulum has: angle = 90 speed = 3 Both signs are func_static models.

Biker's going to be working on a Tatev Monastery mission. You should contact him about providing pictures. Thanks!

"Flip" is fine.

@Serpentine, I have a small nit that you could fix if it makes sense to you. The "mirror X", "mirror Y", and "mirror Z" buttons misrepresent what happens when you use them. Instead of mirroring across the X, Y, and Z axes respectively, they mirror along the axis. For example, given an XY plane, mirroring across the Y axis (which is what is suggested both by the term and by the Y|Y icon) is supposed to change point [x,y] to [-x,y] but what it does is change it to [x,-y], which is in reality a mirror across the X axis. Ditto in the XZ and YZ planes. Fids and I debated this a while back and the conclusion was that mappers had learned what the button was doing even if it was doing the wrong thing, so why change anything? But with new icons, at least there's the opportunity to represent what's really happening instead of what's supposed to happen. Thanks.

I can't help with the HTTPS question, but that remark above caught my eye. Could it be a date problem? The server stopped responding Jan 1.

I believe the game successfully rotates idBounds when it rotates func_statics at spawn time. When I was working with the rat improvements, I was also able to repair some existing debugging drawing boxes to represent a rotated bounding box.

Where is it defined that AI bounding boxes are cylinders? I see a comment in SysCvar.cpp about treating the player's bounding "box" as a cylinder, but nothing about AI bounding boxes.

Thanks! I was looking for a model for a future William Steele mission, and this one fits the bill.

This picture was on the cover of a catalogue I recently received. I thought it would make an interesting mission, but the catalogue doesn't say where the building is. I investigated the photographer and the site where they got the picture, but couldn't find the original. Does anyone recognize this place? Thanks.

Something else to consider is to change the horse's bounding box as it travels. The idea is to give the horse a rectangular bounding box that matches his footprint depending on whether he's traveling (mainly) N/S or E/W. In between, when he's roughly at a 45 degree angle in any direction, you give him a square bounding box. These changes keep him from sticking his head into walls and/or having too large a box width-wise. I don't know if TDM can handle non-square bounding boxes, though. The code might make assumptions about the box being square. This would also be good for the Belcher (or whatever we're calling it), since he's also longer than he is wide.

I put the horse on patrol for the first time. He looks great, but he has problems at path_corners, since he does a simple "spin in place" rotation when he reaches the path_corner. What he needs is some prediction code that lets him walk an arc that will gracefully take him from the current path to the next. I did some work on a shark years ago to fix the same problem. Is anyone planning to do this, or was the horse only meant to stand in one place and look good?

I don't know anything about what's going on here, but from looking at the code, it looks like there are tests for huge translations of clip models. Translations are done to answer proximity or pathing questions. A huge translation is defined as one where the translation distance > 4096. In the code just prior to where your error message is written to the console, there's an assertion statement that's commented out. It looks like at one point the coders were using this assertion to raise a red flag if any huge translations were attempted. Someone with more history with this will have to provide an answer. Or ... if you don't get a timely response, you could PM me the map with steps on how to reproduce this, and I'll look at what's going on when this occurs.

The Noblewoman's left footstep sound is out of sync with her walking animation. Her foot comes down and the sound occurs later. I assume the sound is requested by a frame in the animation, so AFAIK this frame number just needs to be changed. Even if you're not watching her, you don't hear evenly-spaced steps.

Getting better all the time.

Ok, I'll take the normal PM route, then. Thanks.

Heh. These are changes to reduce the number of times AI get stuck on func_statics, walls, each other, etc. It also includes changes to keep rats from getting stuck.

I'd like to set up a beta test for the upcoming movement changes. Can I do that in the "FM Beta" forum? It looks like I can just start a new thread, but how do I invite people? I'd have to solicit outside the Forum, then get those interested invited.

If one is created I shall fill it with pages upon pages concerning my adventures with <rant>health insurance</rant>. Just sayin'.

It's immediately to the left of the 1 key.

Holy Moly, that's a lot of chairs! Nice work.

I just watched the noblewoman walk for the first time. The back hem of her dress should stay close to the ground. There's no reason I can see for it to flip up at all, unless her backmost heel sticks out. As it is now, it looks like she's got a tail wagging around in there. She is a very regal-looking lady. Nice job. The commoner wench's dress looks good. There's a tiny flip, but it looks natural.

Good, glad it helped. Looking forward to the mission.

The first map is all zeros. I couldn't open it in a text editor, so I tried a hex editor. All zeros. Nothing at all. Sorry.

I looked at the second map first. It's corrupted. It looks like an extra block of data was added to the end of the file. A number of entities, starting with #250 appear well after entity #655. There's garbage in between. I cut off the garbage and the extra entities and the map loads fine in DR. It won't build w/dmap because it appears the entire map is open to the void (no enclosing walls). I hope that's what you expect. You can find the edited map here: http://www.mediafire.com/?nog61oaij65dleb along with an extra *.txt file showing the extra entities that I cut off, in case they're important in some way. Note that the last of these entities is cut off mid-line. Hope that helps. I'll look at the first map now.