Search the Community

I posted last night, IE lockedup when I was almost done, arghh... let's see if I can remember what I posted: I'll let you guys worry about pathfinding, ect... -------------------------------------------------- Rat Mouth - Attacking rats I think an opening mouth would look best. But you are right, player might barely see it, unless maybe a rat was attacking a guard. I still think 2-3 small attacker would be cool, but do realize the prob is not polys (maybe 600 each) but the AI computations. The reason I'd like to do a mouth for them all (IF we want a mouth on large rat) is that it'll only increase polys by 30-50. Reasonable since it's only at -500 polys now. If I gav all rats a mouth I wouldn't have to re-rig for a lartger version, which would also mean reanimate. Adding verts and polys messes up the order and count and bone attachments. But if you guys are fine with NO mouths on any of them that's perfectly fine by me. I still have some touch ups to do so there's time to decide. I might like to start rigging by next weekend. ------------------------------------ I will put the rats into ambient_animals But I think if we do a large attacking rat it should probably be in monsters (help the author defferentiate between a standard rat and a monster rat) ------------------------------------- As far as AI scripting goes this is what I think we should do: Very Ambient Creature: base creautre scripts. these are ravens, butterflies, dragonflies, snails. Animated but don't attack, not even aware of player. All they do is patrol, whether on ground or air (I'm not sure how flying creatures play into simplicity) Ambient Creatures: rats, same as above BUT they are aware of player and will flee. possibly frogs. I'd like to do a bullfrog at some point. Big fat slimy bullfrog, not T2 chicken leg frogs. (This might be an after release thing, but would be cool to have some kindof base scripting to use) Not so Ambient creatures: Attacking rats, possibly exploding frogs. Can patrol, CAN detect player. Can attack. But very basic, they see polayer they charge, that's it. No figuring out what they should say/whatever. Just patrol/attack. --------------------- probably all creatures should die. with instecs death very low priority. If a snail is hit with sword and doesn't die no biggie. But if a racne is shot with arrow it should die, same with all rats. They will have AF's anyway, and a death anim is quick and easy. It would suck if a rat got shot and just kept trolling.

Ah, I thought that was familiar, and that you'd be the guy to remember the reason behind it. Well that's cool if something can be done about it. I assume the reference would just be copied in a different way or whatever.

I'm sure people will want to fire their bow while on a rope as well...that's not a compelling reason to allow it IMO. I don't have any strong arguments for NOT allowing it, however. Only that it's more work and inconsistent with other animated activities.

I agree it's mostly eye candy and shouldn't be a high priority, but it can't hurt to have more interaction possibilities. Now that we have the procedure down, it should literally take 10 minutes to do an AF with a single simple constraint. If we have a sign model already, there's really no reason not to make an AF version as well. It takes far longer to model and texture stuff than it does to set up a simple AF for it.

they are virtually the same object. one is fixed that's all. But I can only export as .ase. I don't see a reason not to get rid of the bad one. Even ifwe converted it to lwo we'd still have the same prob if we deleted the ase. We just need to get rid of one before the issues grow further, since the lwo is currently the messed up one it would make sense just to delete it. I'm not sure what the mappers have been using. But this was done and I did request someone delete the original long before any of these screens with signs in em. Either way, shouldn't be hard for mappers just to replace the few sign mounts they are using if they are the wrong ones. Not like they have to rebuild anything. Just a quick drop n swap.

It's been in game for some time, though it doesn't spin. Frankly, I think having it spin is virtually pointless, and possible even a bad idea. It would be like bookshelves where every book is frobbable--it doesn't add anything to gameplay and can actually make the player aware of other limits to their ability to interact with the world that they wouldn't otherwise notice--it's like the "ugly friend" syndrom in reverse. I'd like to make sure we don't get too carried away with animated objects. Neither a spinning globe nor a sign that reacts to arrows add anything to gameplay--it's just eye candy. And unlike other types of pure eye-candy (like light-beams or nice textures) they're going to have no impact at all if the player doesn't actively use them. Players aren't going to spin a globe or shoot a sign with an arrow for any reason other than "to see what happens". After the initial, "neat, it moves" that'll be it. I'm not saying we shouldn't make any AF objects--I think a swinging bucket might be useful for some kind of mousetrap-style contraption. But if we're still seriously looking at a beta-release at the end of 2008 (less than a year and a half away), then we shouldn't get too carried away when there are lots of regular models that need to be done.

For some reason throwing only works when you're holding the handle, not sure why. It also throws WAY too far, because our throwing force was calibrated for throwing around 200 kg crates. We'll have to update those forces as we update the masses. Rotating shouldn't be that hard to code, I just have to decide which body to rotate about for small AFs like this (maybe the most massive one?), and make sure the constraints don't fight the rotation in a bad way. Dragging the bucket around is lagging behind more than it should be. When the only AFs were bodies, I had put in a general AF damping number for extra damping, but this should really be a per-entity spawnarg, not an overall variable. In terms of tweaking the AF, what I've been doing is starting with a sensible mass for the whole thing using the TotalMass variable. Then I set all the densities to 1 as a first guess, and use af_showmass cvar to check it out ingame, make sure no body part is too light (significantly under 1.0). Then I adjust the constraint frictions, setting them fairly low until it starts moving like you'd expect, but not so low that it's unstable. After that first guess, I go thru and tweak the densities and frictions as needed to make it stable. The contact friction of the body itself is also critical, if those are too high, the bodies will get stuck when they're trying to slide against the floor, and it will come to rest too early. Too low and the whole thing will slide across the floor too easily.

There's no reason it has to be linear though. Just the simple act of putting in somewhat realistic architecture, like a mansion with 5 different entrances, makes it a lot less linear. One of my gripes with TDS was they never had a well-developed perimeter area, where you could scope out several possible entrances an pick one you thought was best (like First City Bank & Trust). The only TDS mission that came close to that sort of freedom was Overlook Mansion. The rest were all pretty much a closed in court yard and maybe two doors going inside at most.

Okay, I tweaked it up. There was an extra constraint you didn't need in there binding it to the world, which is why you couldn't drag it anywhere. Set the mass to a semi-realistic 10 kg, and tweaked the friction. Also, I renamed atdm:phys_bucket to atdm:env_bucket to be consistent with the rest of the ragdolls, rather than start a new group with just the bucket in it. It's pretty cool, you can choose between holding it by the handle or by the bucket based on which your view-center is closer to when you frob (maybe at some point we should make a system for showing you which AF body you're frobbing before you frob it, if that's even possible. Something like a subtle secondary hilight around the particular body). The grabber currently won't let you rotate this, and it's also applying the dead body drag force to all AF's, meaning the drag is artificially high on this bucket. Also, for some reason when you are grabbing on to part of an AF, you seem to be able to exert less force on the entire AF the lower the mass of the thing you're grabbing is. Not sure why. Could be that the grabber is only calculating the desired acceleration based on that particular body, neglecting that the rest of the AF is connected to it. I had to scale up the mass of the handle a bit artificially to make this work. Anyway, that's why we're doing this test, to iron out these issues.

I did try an alphaTest 0.5, but it didn't have any effect I could see. Adding "translucent" didn't seem to effect anything either. I'm not sure what you mean by this. I tried a few different images, and the black boxes seem to follow the shape of the object in the image for some reason.

IMO evidence points more into the direction that free will is just an illusion IMO. After all, we are made of physical stuff. Physcial stuff is goverened by physical laws, which are not free at all. There is no reason why we should assume something like a soul, so free will would also be just an emergent behaviour of complex information processing and interaction. I don't see how free will would be working because of the many constraints anybody constantly has to live with. Even though some decisions, may seem quite arbitrary and free (like deciding to make suicide) I still believe that such a decision is not completely free, because it stems from the complex analysis thats going on before the actual decision. Nobody denies that decisions doesn't have to be rational from any point of view, only from the persons own perpspective. Nobody gets up in the morning and decides to make suicide (I'm just using this as an example, because suicide may look as a perfect example of free will). The decision is based on the previous experience, and the persons assesment what the best course of action would be to resolve the problems. As a matter of fact, suicide can even happen on the cell level, so we can also see there, that such a "decision" is not a real example for free will at all, even though it may seem so.

I'm not ignoring the facts of the situation - I'm looking straight at them. Snape had a tough childhood with strict parents. I don't see how that can be accepted as a reason for siding with a mass murderer. The central premise of this argument is that Snape showed 'considerable strength of character not to become completely evil' - I'm just arguing that this isn't true. He showed considerable weakness of character in siding with Voldemort in the first place, even more in sticking with him when he showed his hand as a mass murderer. The Germans were completely vilified by British propaganda during both world wars. Your argument does not stand up, because every one in Germany was subject to the same propaganda but responded in different ways. Some chose to become Nazi guards, others didn't, some fled, some stayed to fight the Nazis from within. These different choices show that different people of different character can respond differently whatever their background. The 'hypodermic needle model' for propaganda is much too simplistic. People do have a choice in the way they act and to blame it on propaganda or their past for their choices is just an abdication of responsibility on their part.

Hey guys, I've been wondering if anyone is going to model the city where Garrett lives in TDM. I mean take the various drawn maps of the city from Thief I and II and the playable levels that show parts of it, plus the maps and levels from Thief III and recreate the entire city in TDM. This would include the Hammerite cathedrals, various inn's, the docks, the Keeper compound, locations of alleys, shops, local fences, Garrett's apartment, the Thieves' Highway, etc., the whole thing as one continuous level. If one is careful about the layout of the streets and such, so as to keep how much you could see of the city at any one time to a manageable amount, this would keep the polygon count of what is visible within reason. Would it be possible to do this in the DOOM III engine without the need for portals like they used in Thief III? Instead of FM authors having to reinvent the wheel every time they want to have a Thief mission take place either in part or in whole in the city and massively duplicate each others efforts endlessly, there would be a master reference level of the city modeled with a high degree of accuracy that could be used in any TDM Thief fan mission. Either as a base of operations for parts of the mission or campaign to which they could add in a portal which takes the player to some location on the outskirts of the town, or as the location of a main mission or campaign which takes place entirely in the city itself. The city would have convenient dead-end alleys and such where any FM author could easily add in portals if they want to that could serve to simulate roads which take the players out of the city to other nearby locales for part of their adventures before they return. This would greatly simplify the creation of FM's, as there would an excellent foundation which any FM could build on or use as is. After all, the city is large and there are many adventures that await within it's sizable confines.

You're right; any new purchasable entity would need an inventory icon as well. In a pinch, the mapper could use the same image for both. Well, that settles it then. I think I'll go ahead with 2d images for the purchase menu unless anyone can think of a compelling reason not to.

Me too, I'm not trying to put down the Gimp. The main reason I tried Gimp was for Texturizer, but it couldn't do anything larger than a postage stamp without crashing, so I gave up on it. (a way around MDI mode sure would be nice... I'm sure that must exist??)

Aww, but I loved the time travel sequence in book 3. I think the reason (or excuse, if you like) JKR can get away with time travel is that changing the past is so dangerous that nobody dares to attempt it. That, and the entire stock of Time Turners was smashed (though admittedly this is a weak argument since they could presumably just build more, assuming they know how). That's an easy one. It's because there are souls in the HP universe, and these souls are not made from the same fundamental stuff as matter. You can turn an apple into an orange, but you can't give it life. (Inferi don't count since they're not actually alive; they're just magically animated corpses.) I'm sure one can sit back and poke holes in the fabric of the HP universe all day long if one chooses, but ultimately I don't see the point except to demonstrate how smarter-than-thou one is. It's a work of fiction set in a world containing magic, and as such some suspension of disbelief is required. For the most part I think JKR manages to dodge around the plot holes at least as well as most authors do. If you don't like 'em, don't read 'em; meanwhile I'll be enjoying myself despite any apparent logical contradictions.

Just download it via bittorrent. I did and it works fine. Much bettern than with that crap Steam. I usally download all my games or get a crack for it, and play these. I hate to have to put the disc inside. I also ran my Doom 3 as the pirated version, until Id removed the CD check, but this was simply because I checked it out before I got the delivery and didn't bother to reinstall. Pirated games are much easier to handle. I put them on my external harddisc, and let them sit there until I have time to play them. The original boxes stay in my shelf, because I like to to have them but I don't want to spoil them. I once had a disc which got scratched in the drive for some reason (Diablo 2) and some others were scratched because my kids don't really take care much.

What's wrong with one folder for textures? I think it makes life easier - there's just one path to all models' textures, so you can't make any mistakes. And it's not like models folders - mappers don't go there looking for anything. And if they want a particular texture for some reason they can easily find it by name.

Actually triangles, but double-sided polys sounds even better. I'm liking the alpha trick the more I think about it, too. I got it. Actually, you said what I meant. I didn't mean to say that merely turning the squares into triangles will make it smoother, since the squares are already planar. I just meant it will give me the opportunity to turn the triangles to follow the curve better, since triangulating them will give me twice the polys to work with in matching the curve. Actually, that raises a question I had. Does the engine care just about how many polys you have per se, or how much is planar? Because I could turn that front surface into a bunch of triangles, or the squares on the back, but it's still all on the same plane. Does it even matter that it's planar though? One reason I ask is, e.g., if I'm going to have to add a bunch of triangles anyway, should I take advantage of that and make the back smoother by tilting them, or is it still better to keep the present configuration with the bigger planar surfaces and leave the triangles as they would be after I trianglate all those squares?

Gotcha. The front surface of my lute is actually one very big 37-sided polygon! (Or was until I added that hole.) I already read about triangulating the 4+ ones, so it's no problem. And as the back is all squares, turning all that into triangles will at least give it a smoother contour. It should add about 100 polys, but hopefully I'm still under 600. Well, I finally got the outside border drawn in. Need to clean it up a bit, then I can just cut it out with the lasso for that alpha channel trick. For some reason, it took me for freaking ever to get that border lined up properly -- it does not look nearly as impressive as the effort I put into it! But it looks nice, I think; anyway, it looks bad without it. Tomorrow I'll clean it up, add a bump map for it, and then do the hole, and it will also take a while, but at least it's smaller. Then I have a surprise I want to try out.

I knew there would be some more bugs. Thanks for spotting them! They (and a bunch of another ones...) are fixed and commited to SVN. Editor images of inscriptions are ugly (just white and black texture) but that's because some material keywords are not recognized by DR. Oh, I wish I had somebody to do all that dirty job... I wonder how much more I could do if I didn't have to export my models and textures to engine - just focus on next modelling job... Graveyard models share one and the same texture (excluding insrciptions). Something like this: Horizontal surfaces (and sloping ones) are UV mapped in the left-upper corner, vertical ones - the rest of the texture. That horizontal white strip in the middle is for beveled edges. Some models still need corrections - I'll do them, as soon as I get my Max working again... BTW - some normal map tip: if you ever want to make a snowy version of your texture with normal maps, representing some vertical surface (stone wall, texture), do the following to get a piece of snow on every bump: - in Photoshop (or other program) choose a layer with normal map. - go to Channels - choose Green channel, select it and copy - paste as a layer, desaturate it (if for some reason it's not) - invert it - now you have white light coming from the top side - we're close to snow effect... - now you can tweak it changing brightness, contrast, levels or selecting colours etc. to get only the whitest pixels - this will look like snow on the bumps. Or at least it's a good base for manual painting snow.

Baddcog, I see you added a new folder in the kitchen section for food. I can see the logic behind that move, but it creates problems when we already have food in the main kitchen folder. If we move them, it breaks existing maps. If we don't move them, it creates confusion when mappers look for food models. I'd rather not create new sub-categories inside existing folders unless there's a pressing reason. In this case, I think it's pretty intuitive to look for food in the "kitchen" folder. I'm interested in hearing how other people feel about it, however.

Usually models tend to look best with textures designed specifically for them. So in that respect I think it's fine to have a tex for each model. On the other hand, if there are alot of good base textures alot can be done with them to good end results. I have reused a few where I could, unfortunately most of the textures are intended for a certain object and hard to use on others. The 'magic ball lamp' I made uses the anvil diffuse and the gold plate and a tomb stone normal for details. It actually turned out pretty good I think but I had to pick through the textures quite a bit to find things that would work. This is the main reason I like one folder for textures, searching for things by shape, details, things I can rob for another object. However, once these folders are changed I will just have a seperate texture directory with all of the tex in one folder for this purpose. This was fairly common with T2 also. There was no need to unpack the textures really, but it was nice if you used them to model. The main prob I've noticed with reusing, mix and matching diffuse and normal maps is that in the object veiwer they show the 'missing shader' blue. Giving the objects an unfinished look. I think I mentioned this at one point as something that needed to be fixed if possible in model veiwer.

I used to use some plugin (maybe it was the one Baddcoq mentioned above) but I meant just using some image viewer (like Irfan View). ------ I'd be against any subfolders. It makes things unclear. I don't even see the reason to keep architecture and weapons textures separately except for the fact that they're already separate and it's better not too mess to much. That's good idea. My ship textures are all tileable so they can be used with brushes and patches. That will encourage modelers (including me... ) to reuse more our existing textures instead of creating new ones, where the benefit of unique texture is very small. Somehow I'm worried that we're going too easy with models textures.

The reason I used this method, was due to all the constant errors we were having with models appearing black, because material files and file paths were constantly not being correctly matched. We originally stored all the textures for a model, 'within' the models folder. Whenever you moved the model...the textures would be broken. With the current implimentation...you can move the model, and it will not break the textures. I also chose this method because it followed the T1/2 way of doing things for models, and it seemed to work fine there. Not saying it's the best way, but it is I think a good step would be to try and name the textures similarly to the model they are being used by. This won't work in all cases, but I think it could help. We could potentially make a few extra folders to help lower the quanity to search through. As long as the textures are stored 'outside' of the model folder...the models could still be rearranged later, without breaking the texture paths. darkmod/models/furniture/textures darkmod/models/architecture/textures darkmod/models/junk/textures darkmod/models/paintings/textures darkmod/models/shared/textures - for textures that are used on more than one model. I wouldn't want to break it into too many, as it would make such a reorg a hassle...but this would keep it fairly close to the original.