Search the Community

Yes, me too. It can be deleted just easily as 'unnamed' if not needed. I'd also like save-prevention prevented! I mean sometimes you try to save and it doesn't save at all because it thinks there has been no change so it does nothing - secretly. So you don't even know it hasn't saved. I find myself dragging out a brush and deleting it to force it to save. If I say, save, I want it to save. I see no reason for it to refuse. If I want to save the same thing ten times in a row that's my problem.

Spawnargs are usually parsed by the SDK code at spawn time, hence the name. Sometimes, the code reads the spawnargs later during runtime too, but this is not usual and can't be relied upon. So I take it you set up multiple responses to STIM_FROB and want to deactivate one of them? This should be done by a response_effect I guess? That's a feature request to go on the bugtracker then, please. This has to be updated in the S/R Editor as well as in the Mod code. I guess what you need is a response_effect toggling the frobability. I can add such an effect fairly easily => bugtracker (The Dark Mod). I seem to recall discussing us whether the S/R IDs should be shown to the user (in the first S/R Editor incarnation, they were there), and for some reason we decided to remove them. At any rate, I don't think that Stims or Responses can have ID 0, so I guess the list should be canged to start with index 1. Can you reproduce that crash and send me the map? Even if the settings were incorrect, DarkRadiant has to handle that and should not crash.

Seeing our small wood collection, I wanted to add more woods. However, while adding a few models for the first time, I was actually stumped that these use quite nice and detailed wood textures. But, these textures aren't usable in a normal map. So, I looked around, and for instance, winrack_d.tga is just a "normal" texture. There are others which are very model specific and in "parts". So, I think we could use some of the generic textures in maps. Should I: * recompress them as DDs, and move these textures to the dds/darkmod/etc folder, then add a material entry, and fix up the model, or: * just add a material entry that references the texture where it is already? Would prefer the first option, of course, as it seems more clean. But maybe there is a reason this isn't a good idea. In any event, this would allow more diversity in map/world textures without wasting more texture space (and recompress as DDS is always good, anyway). Speaking of darkmod_hires, I _still_ cannot check it out, I always get the broken connection error, no matter in which folder I try to check out (either error or it checks out a subfolder ok, but I cannot complete the checkout at the main folder). So I cannot upload stuff to there, either. Already had sent sparhawk forum posts and at least one PM on what the problem can be and how he could fix it; but he hasn't even replied. So, sparhawk if you read this, can you please get back to me on the hires repository?

I loved quake 3 way back when, my buddy burned me a copy of it in middle school and id lan it with friends all the time, i stayed up for like 24 hours straight playing it once lol. For some reason long chains of one letter work as a valid CD key in it like jjjjjjjjjjjjjjjjjjjjjjjjjjjjjj is a valid CD key, crappy code or somethin =p

Woah, woah for some reason those pics were pretty funny Also I like playing with your name. "Woah! Woh-oh-oh - what is he good for, absolutely no-thing..." Maybe you don't know that song.

If you look for some tutorials you can learn the basics in a few hours. It is really hard to learn when you just want to experiement with it, without looking at a manual. Fomr the big apps you can usually do a lot just by clicking around. Not so with Blender. On the other hand, the interface is asboluelty streamlined to support the workflow. If you learn the keys you must use you can do a lot of stuff in a short time once you are used to it. I saw on the blender forums that there are now also video tutorials available. This might be helpfull. Search on D3World for "blender tutorials" and you can find them easily, there is a direct link to these.

Maps and assets are two different things (though I can't see any reason to keep that particular map, personally). A half-finished map doesn't affect anyone else's efforts. A half-finished asset can lead a mapper into believing that it is ready to use.

The main idea behind the above design is to think of a SpacePartition as nothing more than a set that can iterate over intersections quickly... as such, there's no reason to make SpacePartition a singleton class. Whether or not everything is a Node isn't something I care about much... I just set up the example design that way because having a map which contains entities which contain primitives seemed like the simplest way to do things to me. Are we planning on handling anything drastically different from a Quake architecture? What did you have in mind? I was under the (mistaken?) impression that part of why we're redoing the scene graph was because DR had efficiency problems with intersecting large quantities of brushes. Could you point out which parts of the design had behavior that was too Doom3 specific?

The SpacePartition should be able to sort things regardless of their position in the scenegraph tree. Am I missing something here? I think there's no reason for having two spacepartitions, especially not two specialised ones for entities and primitives. I'd vote for leaving everything as Node, because that potentially covers all kind of map types, not only the ones for Doom 3. If you're concerned about the worldspawn being a single large entity, that's not a problem, because DarkRadiant can already deal with that. During runtime, the primitives act as single Nodes anyway, so it doesn't matter for the SpacePartition whether they are child of worldspawn or not. Hm, a certain quick-access list is probably speeding up a few things, I agree (especially for Light entities, because a new Renderer might want to access the lights very quickly), but they also increase the amount of run-time maintenance (but maybe this doesn't turn out to be a problem). At any rate, we should ensure that the structure we create is not too Doom 3-specific, otherwise we're stuck again if anything about DarkMod maps is subject to change. The current approach is that Filtering actions update the filtered status of the nodes (instances in our case). That way the filter comparison (which can be computationally expensive, like evaluating regular expressions or lists of filters) happens only once and gets updated only when the actual Filter settings change.

Is there a good reason to put Entitys and Primitives in the same SpacePartition? Since a scene graph could be pretty flat, maybe it would be simplest if we could think of SpacePartition merely as a set which can efficiently iterate over elements that intersect something, rather than go to the trouble of having a single SpacePartition keep track of all levels of the scene. This would perhaps allow SpacePartitions to know nothing about the scene graph. Here's one possible example implementation: SpacePartition would be a subclass of some kind of Set API, but it would define additional functions to iterate over objects intersecting something. This way, objects that only know about Sets can at least iterate over an entire SpacePartition ... a map exporter may want to do that. There would be a Doom3Map object that has an entities() function. entities() returns a reference to a SpacePartition<Entity> to users wanting to iterate over its Entitys. This might be implemented by returning a reference to an Octree<Entity> member. Entity would have a polymorphic function primitives() which returns a reference to a SpacePartition<Primitive> containing its primitives. WorldSpawn might implement primitives() by returning an Octree<Primitive> member. Other, smaller entities might implement primitives() by returning a LowOverheadSpacePartition<Primitive> member. LowOverheadSpacePartition might simply be implemented in terms of std::set and use linear searching to filter out elements. This could have the disadvantage that to iterate through all the Primitives in a Doom3Map, we'd need two loops: RayTest ray( mouseclick ); SpacePartition<Entity>::IntersectionIterator entity; for ( entity = map.entities().intersecting(ray); entity; ++entity ) { SpacePartition<Primitive>::InsersectionIterator primitive; for ( primitive = entity->primitives().intersecting(ray); primitive; ++primitive ) { primitive->doSomething(); } } Of course, if this were a problem, we could make a primitives() function for Doom3Map that returns an adapter whose iterators implicitly iterate over entities. To filter for specific kinds of Entitys, two routes would be possible: For specific cases that need to be optimized, we could declare additional SpacePartitions to keep track of specific sets of objects (more than one SpacePartition would point to the same object). To quickly iterate over Lights, we might have an Octree<Light>. To keep track of which Entities are currently visible or hidden, we might have a couple of Octree<Entity>s. Unfortunately, I'm unsure of the best way to have an entity update a SpacePartition when its AABB changes... (would callbacks be reasonable?) For filtering in general, we might simply iterate over a SpacePartition and disregard objects not matching our filter. For example, to find only Lights that are visible, it might be easiest to iterate over map.lights() and disregard any light that's hidden.

LOL hood awareness That would be my main reason. We're always fighting the limited view of the monitor - increased FOV than in real life for that window, small HUD elements, etc. I have always "agreed" with the invisible body in FP games. I just feel like it's me and the game world, and that's it. When the character's body shows up, I get reminded it's me controlling the character, who's in the world. Different feeling.

My actual current job I have no problem with; the work is reasonably interesting, and the people I'm working with are good as well (not least because two of them are non-IBM, and the two that are in IBM were outsourced from other companies and haven't drunk the Kool-Aid like everybody else). My problem is with the company as an employer, and the way that they are so fundamentally disconnected from reality that they think that bullying, threats and propaganda are a valid substitute for actually rewarding people for the work they do, and giving them a reason to want to be in the company in 5 years time rather than just using the experience to get another job elsewhere.

I just don't tell them at all. Given that they hate my guts already (because I won't suck their greasy corporate cock like they expect) I don't want to give them any more reason to kick me out, at least not until I've found a proper job to go to.

I think what SE means is, that games don't get more realistic, if you start to simulate all this real life issues you are automatically doing all the time. Eye blinking, balancing on your feets, breathing, and all that. Yes, you do it all the time, but you don't notice it because your brain blocks out such useless information, unless it becomes vital for some reason. I only notice that I have to breath, when I'm underwater. So simulating all this "real" things serves only to draw attention to it, which is quite ridiculous. It would make sense to simulate this, if you would wear a body suit. But even then it would be a waste of processing power, because your brain is accustomed to doing this automatically, so all the sensors would constantly be triggered with movements that are done automatically and wouldn't enhance the gamefeeling at all. If you are in medical treatment after severe injuiries, this might be a good idea, but not in a normal game.

I finished the highlight for doors and changed the behaviour for items as well. Now the highlighting works in a uniform way for all entities. As you can see on the screenshot it may not be to nice for ingame, so I would need a texture that can be used for the highlight. Currently I simply use this one for testing: base/textures/base_door/doorlight_grn.tga http://forums.thedarkmod.com/index.php?showt...st=0entry4929 I think the texture should probably be just a white one so that it will brighten up the object in a uniform way but with lower brightness. Probably a moderately light gray. If you want to test the texture you can do the following: I used the frobTest.map. In materials/custom.mtr you (Renzatic) added this material description and I added this texture to it. Textures/Dark_Mod/Mansion/Doors/Mansion_Door02 { qer_editorimage Textures/Dark_Mod/Mansion/Doors/Mansion_Door02_ed.tga diffusemap Textures/Dark_Mod/Mansion/Doors/Mansion_Door02_d.tga specularmap Textures/Dark_Mod/Mansion/Doors/Mansion_Door02_s.tga bumpmap Textures/Dark_Mod/Mansion/Doors/Mansion_Door02_local.tga { // if ( parm11 >= 0.5 ) blend add map textures/base_door/doorlight_grn.tga colored } }

Yep, it's pretty much WYSIWYG. The problem above is one reason I added several new moons a while back. Edit: see the moons in /nature/skybox/starry1

Let's not create the impression that the only reason we're "okay" is because we aren't charging any money for the mod. We're respecting all copywrite laws related to the issue. We are not using and sounds, textures or other assets from Thief games. We are not using any of Eidos' intellectual property. We are also not copying the most 'evocative' Thief icons, such as crystal arrows (used in the majority of advertising art for the game). Sure, there are similarities--they're both stealth games set in a medievalish-steampunk setting, so how could there not be? Comapre any two World War 2 FPS games and I'm sure they would look pretty similar as well. That being said, no I don't think we should charge money for the mod--that goes against the whole spirit of a toolkit. I consider my reward to be the adoration of the masses and the ability to play through cool missions made by mappers (though if you want to send me $20 I'm sure we can arrange something).

Hopefully I should get it out tomorrow since I have the day off work. The reason it takes so long is because I have to reboot into Windows and compile etc, which is such a time-consuming and painful experience that I don't have the energy for it during the evenings.

Thank you for the welcome and the information. I need to catch up with you. I will post my actions/questions on this thread. ps. My current platform is Visual Studio 2005 and I already have Tortoise installed. I asked sparhawk for an SVN account. For some reason I'm unable to download the correct Doom3 SDK from id site (error 421- too many users) and I already tried a couple of times. Is there another place for downloading the SDK? Some questions: 1. Are you using some Task/Bug tracking software? 2. How many hours/week do you spend on average on this project? This is just for my personal information.

This building was done entirely in DarkRadiant - except a few textures I made myself, and a few premade objects like lamps/ladders that I just selected from the model list: Technically, there is no reason why you cannot build your entire level in DarkRadiant (or even Doomedit, but DR has some advantages like working on Linux Making models for static meshes is sometimes done, but not really nec.

I can't find the thread where the moveable boat was discussed, I think it was buried in some other thread. Anyway, I took a look at this, and a few things come to light: 1. The current water was set up with unrealistic D3 masses. This water makes an oil drum with a mass of 230 kg (!) float. Things with realistic masses/densities therefore float like a mofo, hence the bouncing of the boat that you're seeing. We'll definitely have to re-tweak the density and viscosity of the water. Might as well use a realistic density (in kg/doom unit^3). 2. Some energy seems to be entering the system when something is floating in water. It could be just instability due to the huge bouyancy force of realistical-mass objects, but it could be a deeper problem as in things are not damping out as they should when floating. 3. On the moveable boat entity settings: - "bouncyness" was set high. This represents the elasticity of the object, how much energy it loses in collisions (lower number means it loses more energy). For some reason D3 items set this rather high, ~0.2 maybe to emphasize things bouncing around so the player would say "OMG Physics!!" But in reality most things don't bounce around like a rubber superball. I've been using a bouncyness of around 0.02 for most objects. This compounded the problem with the water bouyancy. - air friction shouldn't be that high. If it was done to fix the water problem, it's better to fix the water friction in the water, not by adding huge air friction on the boat. If you were to see the boat fall thru the air, it doesn't look believable. - once water density/viscosity is tweaked to be more realistic, we can set the mass back to something more realistic for that boat (however much you think it would weigh IRL, 500 lbs to 1 ton?)

Currently non-armoured parts of AI are set as surface material "cloth". I'm assuming that's why they don't spawn blood effects when hit anymore. Would it make more sense for me to set them to 'flesh', or is there a way to make cloth spurt blood only on AI and not from banners, etc? The only reason I can think of not to set them to flesh by default is for collision sounds. But I'm not sure how big a deal that is.

I was browsing through the textures and I noticed a set was seperated: textures/darkmod/stone/brick/pillar_bricks01 textures/darkmod/stone/brick/small_brown_bricks01 textures/darkmod/stone/cobblestones/flagstones01_light The only reason I had constructed those textures was to have several variations of the same stone texture with different shapes useful for different applications. (before, I couldn't have created a fireplace with the existing textures since they were mismatched) As these three textures are named now, if a mapper finds one texture, there's no clue the others exist and can be used together. In my opinion, they need to be named with the same path and differ only in suffix so that they appear adjacent to eachother. ...or is there another way we're planning on handling sets?

Hi this is bad marine ass from the Planetdoom and doom3world.org forums and I just thought I'd stop by to wish you guys good luck. I'm both a Doom and Thief fan, and I can't wait to see what happens when the 2 games get married I'm also a solo modder (current project is Doom 3 Aftermath), that means I do most of the work by myself like mapping, modelling, coding and texturing, and since I'm relatively new to the modding scene, I hope to learn more from teams like yourselves and I'm sure I could help out a bit with you guys if you're too busy or anything. Best of luck to the Dark Mod!

For whatever reason, 3 of the 5 changes in the rename commit above had their file extensions missing. So either I goofed 3 out of 5 times, but not on the first change, and not on the last change, or there's a nasty bug in RapidSVN. Either way, I won't use Rapid to rename, I'll do it by hand. Too risky and doesn't let me verify before committing. Sorry, fixed.