Search the Community

No - I only want them in the editor. What I mean is if I have an actual item - any item - in the map whether it be a brush, an entity, a model, that exists on the grid, a wall, a door, anything, then I might for some reason occasionally want to add a comment to appear in its properties. This can already be done with any entity. A worldspawn brush needs converting to an entity first. The item has a purpose; the comment just makes a remark concerning the item it is placed upon. So on an oddly-placed cupboard I might add: Comment DO NOT MOVE BECAUSE... Your idea of a func_group entity presumably means create a new separate item in the map with a comment - a stand-alone comment with no other purpose than to be a comment. So that might be used with for example: Comment REMEMBER TO ADD STATUE X HERE WHEN AVAILABLE.

I still can't relate to that though. I purposefully don't look at severe car crashes too carefully in case I see something that's going to stick in my head for the rest of my life for no reason. Once I had one happen right next to me and I was horrified by the fact that I had to keep my eyes on all the cars involved in case I had to take evasive action, regardless of what I saw. Fortunately no one was really hurt more than shock and a few scratches.

You can just add a comment property to any entity so if it does not want to be a static or anything else for some reason, and if func_group is otherwise passive then it works fine on that. Though on mine a func_group is rendered invisible in the grid as black and I can't see how to change it. Just done a search for func_group and it seems it is nothing in the game at all so it is not of any use for this. The purpose of the comment (for me anyway) is to comment on a real item in the game not just a lone comment on the grid that isn't a part of the actual game.

Are you synced with the latest revision on SVN? I recently fixed a bug causing the light falloff textures not being found, so that might be the reason. If you're synced, there is something else amiss. I will check out your ZIP.

That's probably the reason, why.

Status crimes are a bad idea! You're a dirty drug user ... you didn't do drugs, we just picked you up for loitering, but off to jail with you anyway. You're gay; we'd never prosecute straight sodomy, but for you ... off to jail with you. Atheist, Nazi, Communist, gang member ... you say? Off with his head. You're rich and can't sympathize with the hard knocks of poor people, and get way too many privileges in life ... of to jail with you to compensate, nevermind that your offense isn't a jail-able one. All of these things can be terrific symbols of justice (if you like the outcome), but are themselves injustice. If a normal person would not get jail, any person should not get jail under the same circumstances, esp not because of their status. The more I look at this, the more I see a sheriff's office that would not imprison someone for this offense being under tremendous public pressure to "do something", so tries the next best alternative ... just let her sit at home; everybody wins. She shouldn't be in jail anyway. But at least this will appease the public looking for rich blood to spill. You're all a bunch of sick-o Robespierre's just happy to see her suffer for no better reason than its own sake -- always pushing aside the fact that her offense wasn't actually drunk driving, just speeding on a suspended license, the kind of thing the cops always just fine people for ... unless they're rich. Just think of the alternative? Everybody sits around and agrees with each other? How dull!! Anyway, I'm just stirring the pot with this post to help make your point. It's not actually that big of a deal to me; she can sit on her hands for just 3 more weeks to pay for the sins of the rich. And she did do something personally stupid. So there you go.

In the Thief world. Oddity is sort of like Karras but a lil dictatorish and i'm a bit like Garrett. However I kinda support this bann that game is violent for no other reason. Too violent. AO only is the way to go.

Pfff... you're as bad as the religious nitwits you claim to loathe. Violence comes naturally to animals and there's nothing wrong with enjoying it. Of course it can't be allowed in real life but if you can simulate it what exactly is the harm? Is this forum as an 'argument simulator' a bad thing just because you wouldn't be as rude as you are to people here in real life? In fact the whole reason people enjoy violent games and films is that they can get their animal urges out of their system so they don't feel inclined to do it in real life. So in a way playing violent games probably makes you less violent. How come Japan has less censorship... yet almost no crime? Compare that to very religious ststes in America where they suppress everything and the murder rate goes through the roof.

It's up to the Concerned Parents to decide what gets banned: statistics, reason or anything else don't enter into consideration. In this case, a Concerned Parent has decided that the Manhunt game killed her son, even though (1) the police stated that robbery was the actual motive, and (2) it was the VICTIM, not the killer, who owned a copy of the game. All it will take is one death that is blamed on football by the affected Concerned Parent, and ministers or other authorities will start scrambling to find something that needs to be banned in response.

Well, the reason I was using attack in the first place for alert response is that is the only option I was aware of to use to make him alert. I'm just trying to test him, test anims, make him react how he needs to. As far as playin one sound over and over, not a prob. It's just a whistle. right now it sounds messed up 'cause he's using a guards voice. Maybe the coders can make the sound not stop or overlap. Maybe there is another code for alert response. Either way that's a one line edit in the def file that can be changed when needed. The standing on a crate thing, well, that hadn't occured to me as a problem. But like I said, I don't want him to just stand there aiming at the player, I want him to play an anim. If it has to be something other than attack and it needs coded fine. Like I said in an earlier post I thought using attack would be easier than new code... I guess I'll have to put a bystander in game and see what reaction I get, But I have a feeling they will just stand there which is not what the bot needs to do. I did increase the melee range to a more realistic distance though, I think that works fine. I'm sure the same system can be used with a new code set-up. There's got to be a limit though, if he's 100 feet away I think that is too far to 'spot' the player. I think there is a communication gap too. I feel like I post stuff and it only gets half read, then 3 people respond, then I have to repost what I posted above. No biggie, I don't always catch what everyone else posts either. I asked you guys to look at his current state, you didn't say you did so I thought maybe you were thinking back to his previous state. But an example is the post I made about the bot being able to see to an extent. I know we had talked about him not being able to see, only hear. And hear very well. But I thought about it and thought it might be odd to the player if they are standing right in front of him and he doesn't even know it. The point IS to have him light up the area, but more than that to light up the PLAYER. But if he can only find player if player makes noise, then the player could just stand in the middle of the hall and watch the bot pass by as the player is brightly lit, dumb little bot just keeps going. This would seem VERY odd to me and I'm sure odd to any player who was in that situation. So the bot DOES need some vision, even if it is a very small radius in front of him. I explained that before but got no response. But then in your last post Spring you say "if the bot spots the player". So in one sentence you tell me he can't see and in another you say he can? @ Crispy: I know you guys are handling the coding, that's cool, I don't even want to think about going there. But I do need to be somewhat concerned about it due to the fact I'm trying to make things work within the code, or need to make you guys aware of code I need to make something work. I'm not going to ride you on it and say I need this and I need it now. But if I don't let you know that something is wrong with his behavior you guys might not realize it, I'm just trying to stay on the same page.

I agree. I also don't consider drunk driving as trivial, especially if it happens multiple times. The only reason why it may seem trivial right now is because apparently nothing fatal happened. Would you still call it trivial if she had killed somebody? It's not as if this is not something unheard of.

That's the reason why they did it. If nobody had notice it, she would have been faster out than you can say "Take that money"

It deffinately needs the attack anim. Probably easier than renaming/coding "alert state anim" which is basically what I'm using it for. Basically the 'attack_anim' has the bot getting agitated. He doesn't attack so much as lets the player know he's pissed, this is also what sounds his voice (which works btw), I am working on his actual voice. If you haven't checked the progress of him in the last week run test_baddcog.map again. SVN is current with what I have finished so far including half the new AF file which is better than before too. The reason I would like to keep the earphone moving in most anims is that it's his job to search by listening. So if walk anim is playing he hasn't been alerted yet, but still needs to be listening around him. Otherwise it'll seem like he's only listening straight in front of him as he patrols. However the search_anim will not have ear animations, so when he becomes alert and starts to search the game should make him "listen" (look really since that's his 'head') towards the sound. So I am looking foward to having the search anim instituted to see how that works. I was thinking of making a death anim. mainly so I can have him collapse, maybe make a death cry and have one long stream of steam escape like his soul is floating away. I'll export an Af pose in the state of collapse. That stuff will be less than 175k. He's got a light attached, however the lantern light texture doesn't seem to be working. It did on a mock-up with an unattached light. Not sure if he will need the turn anims, guess that depends on how they are coded. He turns now, his legs are moving since he does it when his walk anim is running. Give me your opinion after you look at him again. He turns fairly fast so it's hard to even notice if his legs slide. Of course I haven't set him on patrol and watched him turn during patrol, mainly when he's searching for a noise arrow or me.

Well, I for one believe you when you say you aren't maliciously spamming (seems an awful attempt if you were); you pretty clearly want to post pictures of random stuff you like for us ... for whatever reason. But anyway, we don't see a compass. We see a magazine cover. Maybe the cache to your computer still puts up the compass picture? But you need to double check the link's web address and edit it so we see what you're talking about.

I've spent an hour trying to do something that has been absolutely effortless in the past. I was trying to separate the parchment on the objectives.gui into a separate image, so I could apply the swirling background texture to it. For some reason, however, I can't seem to apply any graphic to the gui without a pale grey border appearing around it. I've had no trouble adding graphics with transparencies before while working on the failure and success screens, so I can't figure out what's going on. Even a simple black box gives me a grey border.

I kept thinking about this bcause I forgot some detail. Now I remembered it. Th reason why we need to parse the material files is, because we not only replace the textures with new directory and names. We also want to change the material name itself, which means that I must parse the material file, because I need to create a new name for the entry as well. For example: arch_brick01 { stone qer_editorimage textures/darkmod/mansion/wall/manwbrick01.tga diffusemap textures/darkmod/mansion/wall/manwbrick01.tga //specularmap textures/darkmod/mansion/wall/manwbrick01_s.tga bumpmap textures/darkmod/mansion/wall/manwbrick01_local.tga { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white.tga rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map textures/darkmod/mansion/wall/manwbrick01.tga rgb 0.15 * parm11 } } will become something like this: textures/darkmod/stone/tiling/stone_brick_001 { stone qer_editorimage textures/darkmod/stone/tiling/stone_brick_001.tga diffusemap textures/darkmod/stone/tiling/stone_brick_001.tga //specularmap textures/darkmod/stone/tiling/stone_brick_001_s.tga bumpmap textures/darkmod/stone/tiling/stone_brick_001_local.tga { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white.tga rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map textures/darkmod/mansion/wall/manwbrick01.tga rgb 0.15 * parm11 } } Which means that not only the filepath is replaced, but also the materialname. So I have to write a parser that can parse such an entry and copy over all the lines from within a single definition (which is the problematic part) and replace the filename (which is the easy part), because only the affected materials should be replaced in the mtr file.

That's an interesting site. I think the general lesson is to just have a reason why you make certain choices over others, which reasons fit into a more general pattern your idea you are working with, so all the features fit together according to that general idea. And then it offers loads of time-tested ideas to start with. I think it's more of a starting place, to get you thinking in terms of patterns and ideas than an "answer" site, per se, but that's more because I've always thought of decorating to be an expression of personal style, informed by good, time-tested sense. (I'm a real sucker for the Home & Garden Channel shows on interior design, actually ... and often try out ideas in dromed). I had problems with the things you were talking about for a long time when I first started using dromed ... I noticed I got a feel for proportions the more I played around with it and I gave myself some simple rules to play with, looking at real world first (doors open from the lesser space into the greater, so from hallways into rooms, except the front door opens in). On proportions, I tend to work in multiples of four and eight. This started from the way textures work in Thief, they tend to divide by 4 and 8, so you want your heights to tend to be some multiple of four; 4 for reliefs, 8 to 10 for small/normal rooms - 8 for the wall and maybe 2 for a border; 12 for larger rooms, relief + wall; etc. And that naturally fed into the way I did horizontal space as well. Then I just sort of figured out my own rules as I went along, and my own sense of style. The tips I read about in magazines and on shows added fuel to my thinking, though. I also just walked around my rooms a lot, in any conceivable way from different angles, as people might actually walk in (thieves running and guards running after them), or just to see how things looked from every angle, so that I placed rugs and furniture and doors in places that made the movement natural to the gameplay and the "look" of it look good from anywhere. One thing to emphasize, as I've been implying, some of the design in a game engine is, in addition to the things that that site focuses on, somewhat uniquely driven by the way gameplay and assets work in the game/engine, such as the way texture space is set or the way a Thief/guards would want to move through a house, etc. The thinking is similar, but some considerations and the "economy" of it can be different. E.g., you don't have to literally worry about a budget and physics in buying/using assets in-game, you only have to worry about it insofar as it looks about right (a peasant would only have about enough money to do this, and the physics generally wouldn't agree with a stone ceiling, but in the margins of fashionable textures and load bearing walls you can push the boundaries in-game more than IRL). But on the other hand, you have to be much more concerned in-game with overusing stock assets (or the work you have to put in to make new assets) and you do have an effective economy for architecture in terms of polygons, etc. Anyway, this site adds a lot more food for thought and considerations that a builder will want to pay attention to. Thanks. Edit: And as I look more into this site, there is a lot of great tips in here. And it is very well organized, almost like a basic, hyperlinked textbook in architecture and design. Really good find.

For some reason I liked Diablo 2. I can't really say why, the gameplay was repetative and the story was drivel, but it was fun to me I don't know if I'd still like that kind of style though, running around killing stuff and leveling up.

Just made a 'spotted' anim cause the spider had one. Went in game and it never seemed like spoider spotted me, just started runnng at me. Then noticed in the spider.def that this anim isn't used, but the spider Queen does have a 'anim sight', looks like a sound is attached. Did you guys just decide not to use that anim? Or is there another reason. Oh yeah, what is the actual purpose of the footstep tag in the anim dec. Is it for sound?

But then I gotta do all the rigging all over, along with adding to a model I thought was OKed. and adding another texture on top of that. In addition to the fact that there is really nowhere on the model to put a grill or have a furnace. The box below the tank is a gear box. The back has a piston... I think moss is fine, it'll give players another reason to use moss, the other bots can be stopped by water, although the idea of lockpicking a bot has been brought up too. I think it makes for better gameplay, it's not just a bot is coming, get the water ready. It's "what kindof of bot is coming, am I prepared? What do I need, should I look?"

The whole drugs thing was just a joke. By all means, if you have more reason behind your opinions than you presented in your first post, feel free to tell us about them. Without them it looks like your opinions are quite arbitrary and crazy; hence "what are you smoking?". I wasn't seriously suggesting that you were on drugs. Y'know, this reminds me of an article someone showed me just the other day... (referring specifically to point #1 there).

I like the moss arrow idea, since that would be gunky, maybe hard for it to walk in too. The light would still be on, maybe it would just be set back to idle. I don't think it should be vine though, or rope as they don't really put out matter (gunky stuff in laymans terms). The black jack would be quieter IF it doesn't get alerted while being clubbed. (how many hits disable?) If D3 will make the head (earphone) react, then deffinately it should NOT be animated for search mode. I like it for idle and walk though because it just gives it more flavor. Make it look like the bot is searching on it's patrol (even though it isn't actually doing a search) Then again, I think I just commented out the look min/max cause I wasn't sure they'd be needed. As he doesn't have eyes. But to some degree I know he can't be blind, that would probably make him not function as an Ai. I just want it to have the impression for the player that he is listening, not looking. I don't think it would be too noticable by player either way. Obviously if they are standing silently in the light and an Ai comes by they know they are busted. I think the players mentality will work into our favor there, they know they have to be in shadow AND quiet. No reason to actually say 'this bot can't see you in the light', we just need to diminish it's sight a bit so he doesn't see as well as the others. Thanks for bringing that issue up, I will test out a bit before deciding on those anims. Most likely I will do a few and they will just be offered up for critique, then I will get more focused on actual release anims.

What anims are you referring to? The only one I can think of is the death & search anim & I only modified those. oDDity is the original animator for these. There's no real standard, just what looks good & natural. I'm not sure how the blend anims operate. We need to have the origin move or they'll walk in place. First animate them like they're walking in place then move the origin (which should move the whole mesh) so it'll match the animations. If you're having a hard time matching the footsteps, like the feet are sliding around, modify the animation so to match the origin movement. It's been too long since I looked at it. I think I added it for some odd reason or another I'll get back to you if I remember why. If ik is working right in max, you should be able to drag the waist bone up & still have the feet planted on the ground (depending on how high you drag up though). I do have experience in max but not with the ik stuff. 0, 0, 0 will always be on the ground (except for jumping, running, or walking) so moving the origin up will actually move the mesh into the ground. You should be able to stretch the bone between the origin & waist, but my max experience is slim.

See entry 238. I'm bringing this here, because I can't possibly reflect all opinions, and this probably requires some design decisions. The following are what I can make of the situation after using it for a bit: DoomEd: 1. Create a brush. Convert it to func_static. Deselect 2. Re-select it and drag it - it moves. Size it and it resizes. Pro: The entity is treated as a single item to the user. Ease. Con: For all intents and purposes, there's no real 'draggable origin' functionality. Kinda lame. DarkRadiant: 1. Create a brush. Convert it to func_static. Deselect 2. Re-select it and drag it - it moves*. Size it, and it does not size. 3. Hit tab. You've now selected the brush itself, and you can resize it. 4. Drag it, it moves and the origin does not. The entity seems to be two objects to the user, a brush, and a parent origin. Maybe cumbersome, but we'll see... Pro: this allows the user to drag the brush around with the origin*, to have draggable origins. Then, reposition the brush after the origin is placed. Kinda cool (although the bug below* makes it actually work better). Con: requires extra steps to make sure you are moving the right thing, and can be annoying. Perhaps the selection order should be reversed? (brush first, then parent origin (they more likely/frequently want to move the whole object than just the origin)) Problem: As mentioned, selecting the brush first currently causes the origin to stay fixed. So if you select your door to move it, the origin stays where it is. If you drag it across the room, the origin is still on the far side. Annoying. *Bug: (mostly inconsistent behavior - the main reason I started this thread, because it's not clear if this is truly a bug, or the intended behavior, but either way it's acting inconsistently) 1. Create brush. Convert it to func_static. De-select it. 2. Re-select. (at this point, you could drag the unit around, but not resize). Hit tab. Resize the brush a bit. 3. Problem #1: Hit tab. Now that you have resized, you can no longer tab-toggle the selection. De-select the object, and then re-select it for the next step. 4. Problem #2: Drag. Now that you have resized, you somehow broke the connection, and now the origin moves around by itself, leaving the brush behind. Again, that's actually pretty cool and useful. But it's not clear if that's a bug, or intended, and either way it's behaving inconsistently/exhibiting multiple behaviors. So I'm posting here because I don't pretend to know the 'absolute best' way. However, I am inclined to suggest the following: 1. Select brush first, then the user can tab between origin and brush (as now, just reversed). 2. When the brush is selected, it translates, rotates, or sizes, all as a whole (takes the origin with it). 3. When the origin is selected, it translates alone (leaves brush out of it). We then have the dual treatment (assuming that's desired), we have draggable origins (big improvement over DoomEd), and hopefully it clears up the bug/inconsistency above. Sorry for the rambling form of this post. It's been revised several times, and it's still confusing, but it's a confusing issue, with a twist.

Figured I'd show the progress, been awhile scine I touched this guy. Didn't want it to stagnate too long. Got 'im rigged. gonna try to animate him. That shouldn't be a problem, the rig works good, just have to work through the process once. The first time always seems the hardest but the chest prepped me a little. I decided to leave the 'ear' in the cneter, was really the best spot for it, fills up that space and with it there he can turn to hear in almost all directions without it bumping the lantern. I thought my idea of the 'ear' hearing and screaming was kindof lame, plus I know you guys wanted it somewhat asym, so I decided to add a whistle. Should be easy to find a loud whistle noise eh? Simple steam whistle is all. Not really sure if we'll need an AF, the death could just be a fall down anim. Player doesn't need to drag bots does s/he? More reason to plan out the kill. ----@ springheel about that face bot, been thinking. Not sure about animal faces. Maybe humanish faces would be better. I really like the looks of the faces on the concept, maybe we can get redface to do a closer detail? I don't want human, but I'm thinking 3 animal faces might be 'lopsided' in a bad way. I think the head should be fairly symetrical and making a goat, lion and snake might be hard to do. Deffinately in any case hopefully it will turn out to be very gargoylish no matter what. I think that's the main thing. Redface's looks somewhat lionish from the side. somewhat human from front. I still do like the comedy/tragedy thing to a degree. But not so much com/trag as 2 faces with different expressions, the attack face almost expressionless.