Search the Community

Yes, spine2 is the region higher than above. That seemed a little higher than the heart, but probably either one would work.

I added two AI a guard and a thug. I made some patrol points and attached them to the thug. They are both on my team and the guard just sits there. I didn't give them a head as I'm assuming that they all have a default head. But when I run the map, the AI aren't there, and in the console there are just id:render errors with NULL exceptions for ANIM I think. Didn't save the text sorry. Do the AI's that come with the demo work completely or do I have to use only certain ones?

yes they have at least the very very basic rough loops required as fas as I remember. Here's an image to illustrate what I'm talking about: However I could of course model that head for AI use again - it's just unusable in its current status, as it doesn't even have a modelled mouth and even eye blinking wouldn't work.

It got used too much. We spend more time hanging out on IRC chatting than doing any real work. lol

Yes, they should work completely as in Den and all have default heads. Try deleting the .proc, .cm. and .aas32 files that acommpany your map then dmap again. Also make sure the AI you placed definitely are on or above the surface of your ground; maybe you placed them in top view and they are below in the void? I don't think so but I'm just trying to think of possibilities. Finally, if that fails, do a new map with a single room, light, player start, and one AI and see what you get. If that is OK then maybe there is some other problem with your main map.

Hm, that could work and be friendly. I assume you mean to force them to choose one, and perhaps if it's active, it can't be toggled off? That way, it'd be both safe and flexible. Edit: Confirmed: no loading probs, and context items are disabled with no selection.

I think I'm done with the layer stuff now. Layers can be assigned and the information is saved into a separate MyMap.darkradiant file. I'll try to sum up what has been changed: Layers can be created and deleted via the LayerControlDialog (default shortcut is "M"). Their visibility is toggled via the togglebutton on the left of the dialog. Nodes can be added to, moved to or removed from a layer. Nodes can be part of one or more layers (but must be part of at least one). A node is visible, if any of its layers is visible - in other words, a node is hidden when all its layers are hidden. The context menu (see shots in a previous post) is the intuitive way of assigning items to layers. If a Node is removed from all layers, it "falls back" into the Default layer "0". If a Layer is deleted, all nodes will be removed from it (the previous item applies here). The node-to-layer mapping is saved into the .darkradiant "Map Information File" and restored upon map load. This has been implemented just a couple of hours ago, so this requires some more testing. There are shortcuts for "MoveSelectionToLayer" #0 to #10, "AddSelectionToLayer" #0 to #10 and "RemoveFromLayer" #0 to #10. The visibility can also be toggled quite easily via shortcuts ("ShowLayer0" to "ShowLayer10" and "HideLayer0-10"). What does not work yet or is likely to cause problems: "New Map" doesn't clear the existing layers and their names. Renaming layers is not implemented yet. If the map is opened in DoomEdit or the savegame is modified such that the order of the elements gets changed, the node-to-layer mapping will be messed up. The actual map data is safe, but there is no easy way to preserve the layer settings when the map is altered by another program. In that case, people will have to re-do their layer mapping, moving all elements to Layer 0 and start afresh. A separate "Layer" menu is planned which will provide some more convenience methods like "Select all items in Layer 0", etc. Future stuff. A new snapshot build is up on the FTP: http://208.49.149.118/TheDarkMod/DarkRadia...t-0.9.6pre2.exe Please check it out and post back here.

Hmm for some reason it was taking 29 minutes to compile in doom3 So i went back in and noticed that almost all the brushes and patches had been cloned over their parent geometry. Holy crap what a lot of work that is to go and find all the clones that are over top of their original geometry. Is there a faster way to get rid of those? Like make a small program to parse the .map file to find those things with the same vertex points and delete the first one? Do you guys have anything like that?

In Texture Tool I'd like to see an anchor and scale stretch for brush surfaces similar to patches. I just textured 4 surfaces of a wooden table top. Ignore the long sides which follow the grain and can be bodged easily, the texture has to flow along the top down the short side back along underneath then back up the other short side and match the top again. Well I got through three sides, top and two vericals but then realized I was going to fall short and the underneath would not reach the far edge. I checked my table which I'd made 56 units long to fit nicely in a room. I guessed it was tiling every 64 units so I calculated if I reduced the scale of the underneath by one seventh then it would reach. (grabs calculator.) This I did but of course the texture was then repositioned in the 'texture world' so I had to drag it back but I got it there in the end. But that would have been much easier if somehow in Texture Tool I could drag one edge (the other remaining anchored) which would rescale the surface automatically. Not sure what to aim at though other than eyesight to see where the texture starts to repeat, or possibly keep on eye on the camera. Also in Texture Tool, can it be possible to drag a whole brush surface from any vertex not just the centre? When aligning two brush surfaces if you zoom in close enough to see the vertices for good alignment you can no longer see the centre to drag. Zoom out to drag and you can only see the vertices so tiny it is hard to align - probably impossible for a very large surface. If you could zoom right it on one vertex and drag it to the vertex of the other surface that would make it much easier. I mean of course it would drag the whole surface not just the vertex as with a patch. It's also hard to figure out the rotation of one surface to another. I first did the top. Copy and paste shader to edge. Clearly wrong. Rotate 90 degrees. Tried different flips and drags and eventually got it. Then the other edge seemed worse. I could actually align it in Texture Tool yet it did not seem to match in camera the texture covered in Texture Tool. More flips and rotates ans scrolls. Eventually I thought I'd got it by chance. Then I looked in Texture Tool and I had put the surface over the other surface. It aligned but they were both covering the same piece of world texture. Clearly I had kind of mirrored the texture. Back to the drawing board. My top rotation was -90. The far edge I'd already aligned was 0. So, I guessed, let's try -180. That worked and now I could align it in TT. Same with the under surface. I manually typed in rotation -270. OK, I'm saying all this because is this how it should work? When I copy and paste from a top surface to a side should it not automatically be the correction rotation?

If you are serious about mapping with TDM, you could also apply for betamapper status. This way you could work with the full resources, and get to play with always the latest code. (Although this can be an advantage, it can also be a disadvantage - the current code changes rather often and so sometimes things break

That would be a handy one to have, as we could work it into the door code that Angua's working on. It's already impressive to see them turn around to close the door behind them--it would be that much more impressive if they reached out in the direction of the handle as well. It would make more sense for them to reach out with their right hand, but if they're alert and/or carrying a weapon, that would result in some pretty bad clipping. Might be worth doing two versions eventually, one for when they're carrying a weapon one one for when they're not. (Do AI stop and close the door behind them if they're in pursuit? That would be humourous.)

Amazing work sir, as always.

I think it will work quite nicely.

Yeah, I had somehow overseen Gildoran's explanation, but thanks again. I know from quake 3 how those mirrors work. I remember one time, we played one of my q3-maps online and somebody said "Wow nearly the whole level is rendered twice, that is bad!". Well, I had a couple of mirrors on the floor of some strafepads and the level was openair... But by that time it was already totally possible to create such a performance killer. Only on really slow machines it didn't run very well, but then they could just disable the skybox ingame and it was a lot smoother already, since I used a very big skybox.

That sounds doable in a few hours of coding. While I'd still prefer the "thorough" solution of making selections undoable in general, this might work as a temporary solution.

What about a manual "save selection" hotkey? You could have the four parts selected, hit the hotkey saves simply the info of those four things selected. Later on after doing other things, you could hit the same hotkey (with nothing selected) and those four things light up. If one or more of them has been deleted, name changed, etc, it simply wouldn't work at all (I think that's better than having three of them get selected, because you might "think" all four are selected and not realize something's missing)

I feel your pain, but this is not easy, unfortunately. The SelectionSystem is completely independent of the UndoSystem, i.e. selection states are not stored at all. There is already a request on the bugtracker to include the selection status into the UndoStack, but I don't think I will pull that off anytime soon. It requires quite some work, about one or two weeks of coding, I reckon.

Okay I think it was those tiny patches that were hard to see, because it took a long time during the "Fix t junctions" part of the compilation process. I found as many of them as I could and now it complies fast again. Okay back to work.

That makes sense but is also the most ridiculous thing ever. *sigh* So this isn't going to be fixed then, just use the menu? Would it be possible to assign a shortcut key to Patch->Bevel? Hey I just added this: <shortcut command="PatchBevel" key="B" modifiers="" /> to the shortcut list in input.xml. It doesn't work in the editor though. am i missing something?

Something I would like and I don't think would be too much trouble is more accuracy when defining the background image scale. At the moment it works in tenths but the jump in image size is quite significant and it's hard getting a good scale to most images without editing them in GIMP etc first. Is it possible to change it to work in hundreths? Or even adjust the scale parameters? (it ranges from 0.1 to 20.0 and I don't think I've ever used over 2.0) Hopefulyl that's not too difficult to do

[AI Non-Alert States] These barks are for AI who are not doing anything in particular. They're not alert or reacting to anything, they're just going about their business. These AI are basically talking to themselves, so just like when people think out loud, the beginning and end of their dialogue will often trail off into mumbling. State: Sleeping Sleeping Sounds: Make a noise like you're sleeping. (This should preferably be long, perhaps 20 - 40 seconds; breathe slowly, snore occasionally--maybe a mumbled word here or there). Number of Wavs: 3 male, 2 female Not every character needs a specialized sleep sound--generic male and female ones would probably be fine. State: Idle Relaxed: You're not expecting any trouble. These are your humming, whistling, and mumbling noises. Generic coughing, spitting, and humming can be shared by multiple characters. Complaints about aches, pains, or hunger would be common. You shouldn't refer specifically to patrolling, as you may not be on the job. Number of Wavs: 5 generic male, 5 generic female, plus 5 per character "I wonder if I can nab something from the kitchen when I'm done?" -- grumbler "Cobbler *still* didn't fix that damn nail poking me." -- grumbler "*chuckle* still can't believe how quick that was over." (referring to a fight or game) -- jock "Thy works will redeem thee." -- builders "I must remember to *unintelligible*." "Why is it so cold?" -- whiner/diva "Bugger!" -- thug/jock "How dare he tell me that *unintelligible*". "4 gold in one night...that's the last time I bet against him..." "A nice, steaming bowl of stew...is that too much to ask once in a while?" At Alert 0: On the job. Similar to above, but sounding a little more alert--you're at work and there's reason to expect trouble. Number of Wavs: 3 per character "When are they going to send someone to relieve me? It feels like I've been here for all hours." -- grumbler "Faith, I could use an ale about now." --grumbler/whiner/tough-girl "If I see anyone tonight I'll gut them before they can blink twice." --jock "Lord Builder, watch over us."-- builders "I've got a bad feeling about this shift." --pro "I'm getting so bored of this..." --whiner/jock Idle, Drunk: You're drunk, making you louder, dumber, and more obnoxious than normal. For Discussion: There seems to be three ways to deal with this: create a new "drunk" character set and use those vocals for any drunk character; make 'drunk' versions of all the characters, or something in between. I don't think all characters need drunk vocalizations. It doesn't make a lot of sense to have a drunk builder, or a drunk "pro" for example. I'd be open to drunk versions of a few characters (the thug, grumbler, bumpkin and tough-girl are all prime candidates), or a new character, "the drunk".

I'm not going to argue with you about whether this is a bug or not, so save your breath. Fact is, the cap selection algorithm doesn't work with every patch, it depends on the patch dimensions. On topic: I just tried capping two patches. I created the first using the Bevel command, and the second with "Simple Patch Mesh" (3x3), transformed to a bevel shape. Both worked. How is your patch vertex setup?

Well you see, it's not like I'm asking it to cap a complicated patch, it's just a 90 degree curve. If it can't even do that then something is wrong. Saying that it just "doesn't work" means that it's a bug. The feature is there to perform a certain task, and it's not doing what it's supposed to be doing, that's a bug. And whether I create a patch manually to be 90 degrees, or create one using the menu, they are both 90 degree bent patches, they are the exact same thing. they both follow the grid points as I always have grid snap on. So if the program is able to cap the menu made patch, it should be able to also cap the manually made one end of story. It's a bug.

That's not a bug, the "Cap Selection" feature just doesn't work with all patches. At any rate, you don't need to manipulate the patch manually so that it fits a 90° curve. Proceed like this: - Menu Patch > Bevel (this gives you the 90° patch) - Rotate, move, resize your bevel - Then hit Patch > Cap Selection (or Shift-C if I recall correctly) - Choose "Inverted Bevel" (this will create 2 patches complementing the curve) Time stamping of console entries is not implemented at this time.

Ah, I meant when I set it to -16. I hadn't tried regular 16 because I knew I wanted the patch to thicken downward instead of upward. I tried it upward and it works just like you said. If I start with an underside ramp and thicken THAT upward everything comes out correctly at the start. So I think the -16 on a top ramp should work correctly, but the sides are AWOL.