Search the Community

I have a problem. I still work on an entity definition file for XreaL. I would like to use the rotation tool to have abitrary rotations for the following entity: entityDef info_player_intermission { "editor_color" "1 0 1" "editor_mins" "-16 -16 -16" "editor_maxs" "16 16 16" "editor_rotatable" "1" "editor_usage" "Camera for intermission screen between matches. This also automatically generates the podium for bot arena matches (see Notes). Can be aimed by setting the 'angles' key or targeting an pointing to an aiming entity. Use only one per level." "spawnclass" "idPlayerStart" "editor_var angles" "alternate 'pitch, yaw, roll' angles method of aiming intermission camera (default 0 0 0)." "editor_var target" "point this to an info_notnull or target_position entity to set the camera's pointing angles." "angles" "0 0 0" "target" "" } However I cannot get it to work. It looks like "angles" as keyword are not support by DarkRadiant at all. I just want DarkRadiant to set the "rotation" keywork and to show me the direction of the forward vector but it only sets a yaw "angle" keyword all the time. Any suggestions?

There is a gallery that should have pictures of every model on CVS. You will find it here: www.tjoff.com/jens/darkmod/gallery/ Springheel has been managing it for the last few months but we have now created a generic account that you all can use if you want to add or edit a model. The idea is that this page should mirror what's on CVS, and also include notes about any problems attached to the model. If your model has several skins, please include them in the model picture. Login: www.tjoff.com/jens/darkmod/gallery/admin/login.php User: darkmod Pass: unclegay

Just looking for a button. There is still only one surprisingly - the numberwheel button - but this is under mechanical whereas there is a separate folder mechanical/switches. This whole folder wants reorganizing really but I guess that will break maps. I would always have a misc subfolder otherwise there is a mix of folders and models whereas in Windows we're used to folders being listed together. So we might have something neat like... chains gauges gears misc .. L watermill pipes switches .. L buttons .. L levers I don't mind doing the work but I don't want to break anybody's map without agreement.

Hi guys, I've been banging my head against this problem for the past two days trying to figure out what is wrong. I've read tons of posts and tutorials, and as far as I can tell everything was done correctly, but then again I could be wrong. I've modeled a tree since for a map I'm playing with the trees already made won't fit with what I want, but when I load it in, with the textures placed in the right place, the textures applied to the model and path changed in the ASE file, as well as having an .mtr for the textures, I get this: I've changed stuff, reapplied uvs, and still get the same thing. here is the .mtr file and part of the ASE file (the second material is set up the same, just the texture name changed.): I'm sure I'm screwing up somewhere, but I'm not sure where, any help would be greatly apprecaited. Thanks

Please track all changes made to existing model names or their material definitions for the ongoing effort to bring naming closer to convention here. This will aid in finding any errors made and bringing dependent assets (e.g., maps) forward with the changes. Also, speak up if you disagree with any changes made. To get things started, baddcog made the first changes, copied from the other thread: In addition, I've made the following changes tonight. /door_related: - gkey1 -> key_gold01 // affects: tdm_prop_items.def - skey1 -> key_silver01 // tdm_prop_items.def - padlock_key -> key_padlock01 // none - bc_key01 -> key_fancy01 // doors.skin - bc_key02 -> key_fancy02 // doors.skin - chest_lock_01.ase -> lock_chest_01.ase // none - deleted bc_broom.ase (mentioned by baddcog above) And uh... yup, this is going to be a long job.

The key models have some problems: * they need re-orienting so that all key models face the same way. Currently some of them are rotated, meaning if you add a key-entity, you need to rotate them around different axes, which is quite cumbersome. In addition, selecting two keys and rotating them around the same axis is impossible (so you can't f.i. rotate all they keys and the board on the wall at the same time): * Two collision models are missing. Also, the collision models for the keys with the ring do not have a hole, meaning you cannot put these keys on a "pin" without D3 complaining about them being stuck "in solid". (I am not sure if such a collision model is possible, tho)

I am looking for a big dining table for my old mill. However, the "huge" model doesn't even fit into the room (and believe me, the hall is big and the other models are just too small. Could somebody please take one of the existing tables and enlarge it by a factor of 2, or take the huge table and make it 50% smaller? Oh, and please gridalign the table's origins, also making the tables an even grid-size would be very much appreciated. I tried to place two small tables next to each other, but they do not align, leaving a gap

Dmap seems to ignore a shadow mesh I added to my galleon model. It's definitely there, cause I can see it in DR. (black texture with SHADOW on it). But in game, when I turn the shadow silhouette on (r_showsilhouette 1) I can see shadow detail which shouldn't be there. (exactly same as visible mesh). And I think that fps is lower now than before instead of higher. I used textures/common/shadow material for shadow mesh. Did I forget about something?

I get an error message on opening the "choose model" window the second time. (It works well the first time I open it) I can continue to work, but the model preview is gone. I get the same message every time I open the model window afterwards. I get two more messages on closing DarkRadiant, don't know if those are related to the model problem: I'm using the latest compile of DarkRadiant. (from today, around 3 hours ago)

Thought I should report this console warning.... WARNING: ConvertLWOToModelSurfaces: model models/darkmod/mechanical/pipes/tap1.lwo has too many verts for a poly! Make sure you triplet it down

I created a new bursh and then selected "Create Model...". Now when I look at the models, some of the look a bit weird. Mostly loot, that I'm looking at. For example the goblet1.lwo is viisble but it is enclosed with a default texture which looks as if there is something like "collide" written on it. I assume this is the collision model? if that's the case, it's a bit strange to look at, because you can't properly see the model. Other models like snail.ase look ok though.

Not sure what is causing this. I'm testing under windows since I can compile on linux for some reason. Basically, I'm seeing this when I make the model viewer any larger. As you can see, it's cutting off the top of the model and not scaling the actual render view...just creating empty black space. Not sure if this has something to do with the user.xml file mentioned elsewhere...but I cleared all of my DR settings, so I thought that this should reset it as well. This is also a fresh installation, I removed all previous versions. In regards to the model preview, I had anticipated that it would be resized more like this, rather than a large rectangular box. This may be an issue with my files, so I'll wait until someone has a look into it. If it is only scaling up to a large rectangle, it would be far more beneficial to reduce the width of the other two windows and give DR users a nice large window to view their selections. I will report this in the DR bug tracker as well, with a corresponding link to this thread.

Just browsing through the doors in our repository, I notice that some of our doors face in various directions. IMO they should be standardized and should face in the same direction. Also one of our doors has it's origin on Mars. I'll fix up my doors to have the same facing and will fix the origin of this door model as it's unusable atm. To clarify - most of the doors, when placed into the editor, have their origin on the left with the rest of the door to the right of it. Some doors, however, such as my old wood door, face to the left. Anyways, is there any objection to me fixing this? I'll fix my ones and will fix the origin issue of the other door now, but will wait with the core doors.

The shadow mesh for the thief (models_src\thief_mb) is missing from fbx_import.mb, but is probably present in the other mesh files in that folder. Do we currently have any modellers who can work on AI? I haven't seen ascottk recently. If not then I guess I will have to adopt this role too and try to work out how to get the shadow mesh back into the thief model.

Jeez, I'm really loving the forum community for TDM. I mean, the replies I get for my topic is damn amazing. I jus post a topic asking about a release date, and I get 50 replies talking about wether or not we should add a bloody sword to the game(I personally think you should, as it came in handy when I got cornered). And im getting tired of people saying "If you get caught, or if you run out of flashbangs to use to run away with you dont even deserve to be playing the game" or something like that, I mean, not everybody spends so much time playing a damn stealth game so that they never ever get caught, plus a sword, and (my favourite weapon by far in any theif games) the bow, added more replayability, so you could always replay the game and just try to rampage through the level, or sneak, but be a bit more brutal, using the aggression to pick off your enemies in the dark with the sword, or bow, or (I almost forgot another useful tool) the blackjack. If theres one this that I dont like about the forums its that I cant figuire out how to reply in a topic... or maybe thats just my problem for being so stupid, but either way, can somebody please tell me before I have to start a new thread everytime I want to say something?!

I don't think we have any non-corpse ragdolls for testing physics. It would be nice to get some of these, and they can be very simple. For example: Take the existing bucket model we have, and add a handle to it. Then make a ragdoll for it that just has two bodies (bucket, handle) and one joint (hinge joint connecting bucket and handle). Making the AF file for the ragdoll can be tricky, but I think we have some modelers with some experience in that now. Another more labor-intensive example would be a morning star or flail.

After some fund raising we were able to get a IPB perpetual license which makes us able to upgrade from an unsecure 1.3.x board to a fully updated 2.0.4 board. Feel free to poke around and look at the new features etc. The skin is reset to the default IPB one, because the old one won't work on this version. We'll get working on it ASAP. Happy posting!

Some of our really old models could use a little touching up, so I've been going through where I can and making some adjustments. I'm trying to keep the dimensions and origin the same in case they're already being used in maps (but I'm also grid-aligning them at the same time, so they might be a bit off). Here's the first alteration to squarehanginglamp.lwo. (edit: Moved to forum where beta-mappers can see it)

I've noticed that our commode model ( http://www.mindplaces.com/darkmod/screen15.jpg ) has some strange shadow problems. I just checked out the uvmap and it's a mess. I suspect that might be causing the problem, though I'm not sure. Modellers, does this look right to you?

Alright, you all probably know by now I'm using Max. Most of you are using Maya, Blender or Lightwave. So, we can each model according to a relative sized Ai. But how tall is that Ai, and which one? Now this is fine for most stuff no doubt. A knee high ceramic pot is a knee high ceramic pot. Who cares if it's 3.0 feet or 3.1 feet tall. I sure don't, as long as the flinderz match But seriously, I was just starting to work on a door, so I imported a few doors to match em up. The mansion doors and windowed doors are the same size. According to the scale I've been using those doors would be 11 feet tall by 5.325 feet wide. I figured those should be approx 10 feet tall, so I changed the scale and now they are 4.841 wide. If I bring it down to 8 feet tall it is 3.873 wide. So you can see the delima: First I'm not sure exactly which size it should be, but these are big in game so I'd say 10 feet. Second, they aren't very accurate h/w. I'd think they'd want to be 10x5 or 4x8, but even dimensions at least. From another modelers program, what size are these doors? Why can't all programs just default in feet? Let the euro's figure it out I haven't imported any door frames yet, and maybe they are filling the fractional gap, but what if author wants to just use brushes for doorframes? Or are we aiming for using object door frames on all doors? Anyway, I think it'll be nice for modelers later to have specific numbers to work with any program they choose.

Whenever I'm using models in a map, it drives me nuts when I use the entity direction buttons to have a model face south, and it instead faces west, and I end up having to try out a few buttons to figure out how to get the model to face the direction I want. (assuming I don't want to use free rotation) It'd be nice if the entity direction buttons worked correctly for our models. Is there any chance of making a rule that says all new models need to face east, so the direction buttons work correctly?

Baddcog, I see you added a new folder in the kitchen section for food. I can see the logic behind that move, but it creates problems when we already have food in the main kitchen folder. If we move them, it breaks existing maps. If we don't move them, it creates confusion when mappers look for food models. I'd rather not create new sub-categories inside existing folders unless there's a pressing reason. In this case, I think it's pretty intuitive to look for food in the "kitchen" folder. I'm interested in hearing how other people feel about it, however.

I didn't see anything on the forums about the compass designs so I made a poll. Here's the reference pics for a compass: http://www.100thpenn.com/compass.jpg http://www.pewter.it/400X400/0096601B.jpg http://www.smartstart-toys.co.uk/images/Compass.JPG http://www.stanleylondon.com/compass.jpg http://gallery.hd.org/_tn/std/maths/compas...OVray-by-BG.gif http://www.qpindia.com/pcat-gifs/products-small/compass.jpg If anyone has other suggestions or reference pics, post it here.

At over 700Mb, the models directory is now the biggest size offender by a long shot. Some of that is necessary of course, but a lot of it is not. The Thief-style wall lamp is a good example, with the diffuse being a ginormous 4Mb (despite being blurry/pixelated), and for such a small object. There's no reason it can't use a 683kb DDS, by the same conventions that have already been accepted for geometry textures. There's no noticeable loss, and a space savings of around 75%. That said, if no one objects, I'd like to take a side project (little bit here, little bit there, as the urge hits - that doesn't mean I promise to do it all, nor that outside help isn't welcome, but that's up to you) to convert them as appropriate to DDS. This would be diffuses and speculars only, as is also convention with the texturing division. It seems right now, the only model in the whole mod even using a DDS is the bell I made. Objections?

Anyone know how to do this in Lightwave? The model's origin determines how it will rotate (and I think comes into play in physics collisions as well) but some of our models have origins that are outside of the model itself. Ish mentioned recently that some crates need to be changed, and I know the weapons do too. But moving the origin isn't in the (very) small list of things I know how to do with LW. Is it something that's fairly easy to do? Dram, have they got to this in your course yet?