Search the Community

Yeah, I recently switched to a Dell 24" widescreen LCD monitor. Compared to my old 17" CRT, it's like sitting in the cinema. Native resolution is 1900x1200. They certainly are worth getting - as long as you get a good one. Why did it take a month to arrive?

That "long" stuff gives a vague impression of a 64-bit issue, but I know absolutely nothing about 64-bit coding so I couldn't say for sure. I have certainly never seen that error myself.

Yes, it's definitely something to do with the Uv map and how it's welded at the edges, but I can't remember exact details, since it's a long time since I've done anything for the Doom engine. Try unwelding everything, selecting all the polys from one UV map, use 'copy map' from the Uv panel. You then type in a name for your new UV map and it copies those polys to it. Then you can delete the old one. Do this for both UV maps that have the same vertex in it, and then weld everything again. edit: I think I maybe fixed problems like this using Deep Exploration. I'd load the lwo in to it, convert it to a maya binary file, load that maya file, convert it to an obj, and then import it back into lw.

LotP could have benefited from even more explorable areas, but maybe that's my recollection clouded by playing that level about a million times. When you think about it, I guess it had a pretty good amount of different places to go. I think there may be a design trap, in that if you make a really really large, detailed space mostly for the purposes of atmosphere and realism, users may have different expectations than the designer about what the point of the mission is. LotP had a good amount of diversions for the size of the level. Tracing the Courier had very few. It was mostly a shell of a city. I always wished there was more to explore after the courier part was done. But that wasn't the point of the mission, but it had to be that large and detailed for atmosphere and realism. Ditto Assassins. What I do think most definitely, is that diversions should be interesting. I was just playing a new FM just a little while ago but actually quit from boredom. And I don't do that often. Most of the buildings were enterable but there wasn't any point to them except to get some loot. I will dare to name names here, since it's just us, but one very beloved FM maker actually has a couple of stinkers under her belt. For all of the gorgeous architecture and loving attention to detail she is famous for, there were one or two missions that were just so BORING. One building after another, get in, find loot, go on to the next building. Before I'm pummeled I'll add her other missions were fabulous. But even the mighty must fall on occasion. So I guess each enterable building or other diversion should be unique in its own right. It should have a memorable challenge, unique configurations of lighting and guards, cameras, whatever. Going in and getting a little loot is NOT memorable. A weapons shop is good, cause weapons are good. A bank is good cause there's lots of loot in a bank plus real opportunities for stealth puzzles--loud floor, alarms, guards. A post office might be good--maybe you go in to intercept a letter. There are lots of opportunities to make the enterable buildings you do decide to make something special and interesting. They should make you catch your breath and say Whew, that was something! when you leave.

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 was trying to think about what keeps me interested in the potential of episodic content, in spite of all the downsides that this thread is bringing up. I keep thinking it might be like t.v. (good tv, like with cable series, Entourage, Rome, Deadwood, Carnival, The Tudors, Sopranos...), where you get invested in following the story, and it's a damn good story, and it's polished and looking good. But then you have to factor in the long development time just to get out single episodes. And then the admittedly swarmy idea that, when it's a game, it comes across as "milking" ... if they can give us all these great additional levels, why not just package them into the original game we're paying so much to buy. But I still can't completely let go of the idea of a nice potential in the tv analogy. The one way I thought that it just might fly is if they had episodic content packaged as a subscription service (like cable; I seriously doubt it could ever be like network tv where advertising alone could carry the cost ... although that might work for some indie game, but not a polished game, but anyway, that would also probably make the episodes suck like network tv. I'd rather them be cool like cable series.) But also like cable, it shouldn't just be one game, but a couple of series packaged together ... and maybe they can share development costs (using the same engine and certain assets, although they are in different genres) to reduce costs for all of them, again like cable service. And then there's the idea that they could just bundle themselves with cable tv altogether, so that they add an option to HBO service to has HBO Game series as well ... and they promote and write them like the excellent tv series they have going. Somewhere, swimming around in all of that, is something that just might have the potential to be something cool, and something that I wouldn't pay too much extra for by itself, but wouldn't mind paying a little more to add it to my HBO service, and that gives me more than just one game. And they'd have to be damn good. But I still don't know if it will fly.

Yep. I'll post full documentation and a testmap with an animated chest once I make that SDK change this weekend. No, CombatModel 1 always activates the render model as a collision model for projectiles, but the AF can also be active at the same time if it happens to be set up that way. You might want this for example if you want your object to use coarse AF bodies to block the player and bounce crates off of, but also want surface-based collision for projectiles and melee attacks (e.g., arrows sticking in wood parts of the object and bouncing off metal parts). If you're not careful about setting the contents of the AF bodies to "solid", the AF bodies will override the combat model and intercept incoming projectiles/melee before they hit the combat model, and just register a hit on surface type "none". For the cases of machines, just using the AF bodies with no combat model should be fine. Right, idAnimated spawnclass and "ragdoll" pointing to the AF file goes in the def. Plus combatModel if you want to use that (for very simple models that we want arrows to stick in, that's probably fine). I agree. The specific request was for a sign that swings back and forth by itself as if in the wind, but that can be done with a script that pushes on the sign with one line of code, and could be simplified further for FM authors who don't want to write script things. The only thing I'm not sure about is a *squeak squeak* sound when swinging. With an anim this would be easy (you can play sounds with what's called a "frame command" in the def file where you define the anims). With ragdolls, I think there's a spawnarg you can set to play sounds as it rotates around the joint, but I'd have to look into it more.

Would it be possible to make a set of AI that are sleepers, wearing nightgowns and saying sleepy things, that mappers could use? They could have a few special features, for example each sleeper has a unique relationship with its particular bed. The sleeper can awaken, look around and cause trouble for the Thief, but when he KOs them, and puts them back into their bed, and only their original bed, that particular situation does not trigger the AIs reaction to seeing a body. Of course I have no idea how to do that but it doesn't seem impossible on its face. It just seems that if a guard, who would know the sleep habits of the castle back and forth from being up all the time watching people at night, would have a good idea if someone was sleeping in someone elses bed. If he sees the Captain of the guard sleeping in the scullery maids cot, he is going to know something is not right at best he would wake the captain, assuming he was drinking, and take him to his quarters. So I have no problem with guards alerting when they see a body in a bed, even if you could "arrange" it properly. But if a sleeper is KOd and then placed back into his or her own bed, that should not really be something that would set off the guards right away. I would not even see the need for arranging the body, as long as its on its own bed it would be cool. Again this is supposing these things are possible.

Yep, thought about it already not necessarily. You can make a map for ADD stage, where only glass is lit leaving the wires black. Actually I prefer to make it on one texture, so the effect is more subtle. I'm at work now, so I can't post screenshot, but you know what I mean - when you see something thin against strongly lit surface it partially disapears. You can't achieve that effect with separate layers. (not in real-time engines, I mean... )

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.

Thanks, I'm glad you like it. I've spent a bit of time on it... Yes, you're right. I wanted to make wires overlit (is this a right word? ) by light, but that wasn't convincing. Texture is already improved, but I'll post a screenshot later. Now, before I go to bed, here's some small boat plus oar. Another variation is modeled already but not textured yet. And some other skins are on the way as well. That's what I'm currently working on

As if that ain't enough although it shows OK in DR but in doom I get... WARNING: ******* leaked ******* WARNING: Couldn't load image: textures/darkmod/stone/brick/tiling_1d/old_worn_ greybrick And it seems to leak right through the texture. So it seems to me likely that top line is used by Doom not just DR? and should be... textures/darkmod/stone/brick/tiling_1d/old_worn_greybrick_tiling_1d Saved it. Reloaded Doom. Dmap... WARNING: ******* leaked ******* WARNING: Couldn't load image: textures/darkmod/stone/brick/tiling_1d/old_worn_greybrick 'old_worn_greybrick' without also '_tiling_1d' is not used anywhere in the def so don't know where it is getting that from. Path too long?

Great job on the rope arrows, guys! Will crates of the same size have different weights possible? For example, there might be a small crate that you want to shoot a rope arrow into to climb up, normally this would be a problem, but this crate happens to be filled with many metal objects, so it's much heavier than a typical small crate. Could you climb up such a small yet heavy crate without pulling the crate down? The thing about dragging a crate with a rope arrow sticking in it and holding the loose end with another crate doesn't seem to make sense. If you could shoot a large crate with a rope arrow high above you and then climb up onto the crate and then pick the crate up and drag it back down some long staircase to where you were or to some other location, with the deployed rope dragging behind the crate, and then maneuver the crate so that you could walk around to the other side of of some hole in the floor or other such opening with the rope dragging over the opening but not falling through it just yet, what good would that do you? If you were able to get the crate to other side of the opening with the rope dragging behind in the first place, then there is no need for using a rope to get across the opening. hehe

I'm compiling right now, I'll post back here in a few minutes, stay tuned.

Crash, no. But it should be avoided because it will screw some things up. Soundprop doesn't work properly if an object is outside the map, for example. But as long as it's enclosed by brushes (I think even solid brushes should be OK) then it'll be fine, so this shouldn't be a limitation in practice.

Yes, taking an IMapExpressionPtr as argument is better. Don't hesitate to post if you're getting really weird compiler errors. Most of them are easy to fix or to search for in google (and you're learning quite a bit from googling), but some of them are really hard to find, so it might save you some headaches. (I once forgot to close a namespace bracket in a header file and consequently got weird errors in the "parent" file - took me a bit to find that one.) Regarding the empty Image object: That's one thing I like about pointers over references: pointers can be NULL, whereas you can't have empty references. The solution would be to implement some exception handling, which is mostly fine, but in some situations I find this cumbersome and prefer to have a pointer-like object. Anyway, passing the IMapExpressionPtr should be fine here. Keep it up.

There's a pretty good wikipedia (FWIW) summation here of the situation on the book and series: http://en.wikipedia.org/wiki/A_memory_of_light Basically, -He intented this book (12) to conclude the series -It sounds like it was going to be very long -He took a ton of notes so in case he died, someone could finish it for him, properly -It's now up to Harriet (wife) and the president of Tor books what happens next I personally of course hope for conclusion, but I really don't think it will feel the same, even if the co-author imitates his style perfectly. Maybe if they can assure the notes are followed to the letter.

@greebo (second post): Ah, I know what you mean, you talk about the return optimization, right?

That's not possible, since there is no MapExpression class, only IMapExpression, which is virtual. So that's not possible. Edit: refering to your first post

Moved your post to our application section. You'll definitely need doom 3 before you can use the mod, but you should be able to find it for a reasonable price.

Well, new Beta mappers are always welcome, especially with Dromed background. However, without Doom 3 you won't be able to do anything, so if you're determined to get into Dark Mod mapping, my first advice would be to grab a copy somewhere and to post a few screens as soon as you have some available.

The head does have an entityDef at some point, because it is a separate entity. However, looking at Id's code, it looks like heads are a special case, where they just take a model argument and don't set up the entity spawnargs until runtime when the head is spawned and attached. It's going to require SDK changes to do something as simple as put spawnargs on our head entities. We could try and use the standard attachment system for heads so that it reads the entitydef like all other attachments. However, I think there is some other stuff that happens only to heads, like setting up the head animations, copying animation joints from the body, etc, that would probably have to be changed in that case. That may take some time. Alternatively, we could add some code to copy over head-attachment spawnargs from the AI to the head. E.g., writing def_head_attach_* would set up attachments for the head by copying that spawnarg over to the head args before they spawn ingame. Id's code is already doing this for the sound spawnargs (snd_*). This would take less time to program, but would be uglier code. idActor::SetupHead headModel = spawnArgs.GetString( "def_head", "" ); if(headModel[0]) { // ... // copy any sounds in case we have frame commands on the head idDict args; sndKV = spawnArgs.MatchPrefix( "snd_", NULL ); while( sndKV ) { args.Set( sndKV->GetKey(), sndKV->GetValue() ); sndKV = spawnArgs.MatchPrefix( "snd_", sndKV ); } headEnt = static_cast<idAFAttachment *>( gameLocal.SpawnEntityType( idAFAttachment::Type, &args ) ); I'd vote for the first option, make heads read from an entityDef to start with, but I don't know how long it will take to find all the things that would be broken by this and fix them. I guess we should leave the setting up the head code alone mostly, and just change it so that it reads and spawns an entityDef instead of just reading the model. Of course this also means more work for people setting up the AI, since they'll have to make a head entityDef as well as modelDef.

Hehe, same-time post, the reply was meant for OrbWeaver. Your reply wasn't there when I started the reply. Sorry for the confusion.

Check your pm and nevermind sry. For visiting my post I have provided you with awesome zombie game. What was that about games sucking or something or the 16 bit era dead? It's alive and well eveyone. http://www.freewebarcade.com/game/the-last-stand/

I also felt that I played Tomb Raider when I was searching for all those long lost artifacts. Zombies, undead and burrics are ok but I don't like missions in which they are my only opponents. I prefer to steal from men rather than ghosts. Thief 2 is my favourite. It has the best maps - large and in many different styles. I loved the architecture variety, I even liked art deco. TDS (edit) has nice yet monotonous graphics. It was almost black and white which was boring to me (even if more realistic when action takes place at night).