Jump to content
The Dark Mod Forums

Search the Community

Showing results for '/tags/forums/long post/'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • News & Announcements
    • The Dark Mod
    • Fan Missions
    • Off-Topic
  • Feedback and Support
    • TDM Tech Support
    • DarkRadiant Feedback and Development
    • I want to Help
  • Editing and Design
    • TDM Editors Guild
    • Art Assets
    • Music & SFX

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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... )
  6. 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.
  7. 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
  8. 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?
  9. 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
  10. I'm compiling right now, I'll post back here in a few minutes, stay tuned.
  11. 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.
  12. 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.
  13. 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.
  14. @greebo (second post): Ah, I know what you mean, you talk about the return optimization, right?
  15. 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
  16. 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.
  17. 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.
  18. Hehe, same-time post, the reply was meant for OrbWeaver. Your reply wasn't there when I started the reply. Sorry for the confusion.
  19. 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.
  20. 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/
  21. 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).
  22. Sure, that sounds fine by me. Are the files on the FTP? And what are the names of them? Also do they have an origin bone so that we can set movement speed based on the animation itself? Thought I would post this publically so that we can get feedback from the other animators. Ascottk in particular has done a lot of work with the D3 skeletons and may be able to help. I've asked Solis to handle adding some walk animations to the D3 monsters we're using in TDM. With some of them, a slower version of the run animation might work, but in others it probably wouldn't. One question that Ascottk might be able to answer: I notice that both the zombie_boney and zombie_morgue have the zombie_base model 'inside' them. Does that mean they use the same skeleton? If so, would it be possible to take the animation from other characters using that skeleton and just apply them to those particular models, the way you did applied the citwatch animations to the thief?
  23. What about lock picking in TDS? I thought that was pretty darn good and innovative too. Even the “as shipped” version was pretty good. The Minimalist Project made it excellent by removing the HUD (thank you NH). Honestly, where TDS failed was in capturing the imagination of its own community. After all, it is, and has been all along, the community around the games that has made the Thief series such a crazy success. No matter how good the originals may or may not have been, were it not for the community, they would be long gone and forgotten by now. So while we can complain about all the bugs and flaws, be they large or small, but it is really the sum of the whole, the delivery of the game to the wrong audience that killed TDS. I don’t think anyone would argue that DROMED or either of the original thief games were bug-free, or user friendly, but they captured the imagination of our community and got us fired up so we were able to work past the aggravations to make good missions and improve the game. TDS failed to do that, partly because we felt betrayed over the game being “dumbed down” for console use, and partly because it just didn’t breathe fresh life into the game like we expected it to do, for so many reasons. There’s no way I would play TDS without the Minimalist Project and I thought some of the side quests were just a little too “Nintendo” (run around the city shooting special stones with moss arrows, or shoot a combination of elemental arrows through the magical portal. . . Puhleeease!) I did enjoy the game once I got used to it.
  24. Yes, the localToWorld transform needs to be set correctly from the Node/Instance/Entity (one of those -- I would guess the Instance, but unfortunately I know very little about this area). Looking at how the light volume classes do it is probably your best bet. It definitely needs to be separate from the light volumes, and should be connected up as a registry setting (just like the light volumes). Adding a toolbar icon will be necessary in the long run but if you don't want to mess around with GTK then just using a registry setting for now will be fine.
  25. Spiral staircase, gonna touch up the tex a bit. Make a skin or 2, one with metal stairs. Thinking about changing shape of handrail post, maybe just another model with different posts, something rounder. Possibly a 'broken' model too missing stairs. This is a full 360 staircase, 256 units high (hopefully about one floor for mappers-would be great if someone could test it) Thinking about doing a 1/4 model and 1/2 model too. Somehwere around 2200 polys
×
×
  • Create New...