Search the Community

Yeah it would'nt, so it's pretty useless for us anyway. Not to mention a lot of the lights are meant to be take-outable... However, you can leave a paramater in the material files exposed to do some nifty shit with it - for example have a script which changes parm7 (which is tied in the material file to a door texture) and make a door fade in/out - which would be funky but would make the player think "wtf?". But yeah, with using this method, you could have the material change as a light is taken out, thus having a proper effect, though you'd have to have the main model broken up into several pieces, and overall it's a massive pain in the ass for less functionality and slightly better looks - what's the use if the rest of the lights cast sharp shadows?

Hey, Just wanted to post so that people don't think I'm MIA. Haven't had a chance to complete the model yet, got too much stuff going on with work and home stuff, but things should hopefully settle down after the holidays. I'll keep in touch, and I'll let you know if it eases up earlier.

That looks like a problem we had with the light gem initially. I think it's something to do with smoothing being enabled on the model or something.

OK, the problem is that you have a function ColourSchemeEditor::destroy() which calls "delete this". You must never destroy something with delete unless it was first allocated with new, which in this case it wasn't, hence the double free. It is best never to use "delete this" at all, it is dangerous and almost never needed. Your ColourSchemeEditor instance is automatically deleted at the end of EditColourScheme() since it is a local object. I think in this case you would be better off not using a recursive gtk_main() loop. The recursive loop is used when a dialog must block until a specific value is selected by the user, after which the main function can resume (such as when a Model selection is required). The ColourSchemeEditor does not return a value, it just allows the user to modify values that are held in the XML registry, therefore it does not need to block the calling function. I can explain in more detail if this is not clear.

While thinking about engravings on the tombstones I thought up some Builders' cross symbol. I have no idea if there is one already - I just wanted to do it. So, here are results: Quick concept: (could be used for any kind of ornaments, with some variations) And here's model for cathedral. (screenshots are made in drumple's cathedral). Textures need some tuning up but you can see the idea already. What do you think about it?

It would definitely be cool if skins could be swapped like that, but I don't think they can be made to work that way. The skin chooser in Dark Radiant will make it all invisible to the user anyway, so it will just be a nice long list beneath the model name.

Thanks greebo! That's useful indeed. But it would be even better if I could apply two (or more) separate skins for one model. Let's say grave - I would like to change independently texture of stone, texture of engravings and texture of some ivy wrapped around the grave (to nodraw if you don't want it). It would be easier to change them sepatately cause I wouldn't have to multiply every possibilities. For example: 3 types of stone x 5 engravings x 2 (yes or no for the ivy) = 30 skins for each grave... This might be quite long list...

I have a question about the skins - can we assign two separate skins for one model? Cause these big Hammers have 2 diffrent materials, which I want to be able to change independently. Also with the graves models - I would like to make the entire stone material to be changable (to f.e. diffrent colour stone, with some cracks etc...) and independently I would like to change the texture with some text or carvings on it. Is it possible?

Oh, I wasn't talking about getting rid of it, just not using it as the default. BTW, I see the proguard's helmet is already separated, so I'll work on the offset values for it as well. edit: oops, Ascottk can you upload the proguard helmet? It's listed in the props.def file but the model isn't in the wearables folder yet.

Ok, I'm going through the theif model to see which, if any, D3 heads will fit on him. Ideally we will have an attachable hood to add onto them as well at some point.

There's geometry missing, and no normal maps. THe correct final model is 'farrelltried.lwo' I couldn't find the normal map for him in my rar files, I'm not sure how it escaped, but I found a version of it on the bottom layer of the psd file 'farrell_d'.

Some more, edit: (btw, the proguard has never been my favourite-looking model--it is far more medieval-looking than the rest of our characters, particularly with the checkerboard design. I may eventually replace the default texture if no one objects)

A couple of mappers have pointed out that the current "categorised" entity inspector is cumbersome to use, because it hides information underneath category entries and increases the number of mouse clicks required to add or edit keys. From my own use I tend to agree with this view; it is also the case that the code is quite complicated owing to the need to work from categories to keys rather than the more natural "show a list of every key on the object" approach. I am therefore going to start simplifying the entity inspector. I was thinking that the interface would be similar to the following: 1. A flat list, showing all of the keys currently set on the object. This list would display the key, the value (in text format) and the type icon (vector, text, model etc.). Right-clicking on this list would provide a context menu with an Add option, that would in turn display a separate dialog with the current categorised keys, along with their descriptions, which could be browsed and added to the current entity. 2. Below the list of keys, 2 textboxes allowing entry of keys and values manually (like DoomEdit). 3. The current key-specific editing widget, allowing a more user-friendly modification of the current keyvalue. I believe this dialog would provide the best of both worlds, by allowing advanced mappers to type in their keyvalues in the DoomEdit style, while simultaneously providing a user-friendly GUI-based approach for those who wanted it.

Sounds ok to me. As long as there is some possibility to recognize/distinguish keys in that list, I can see that the flat list is faster to use. What I would add: I could imagine that colouring the property key/values according to their category (blue for model, green for light, red for readable keys or something like that) would help distinguishing if there are a lot of spawnArgs displayed. Is there anything we should keep in mind for future expansions like displaying keys that are inherited? Or should we perhaps display the inherited values in a grey colour to reflect their origin?

The polycount takes into effect ALL faces on the model, including collision meshes, shadow meshes or whatever. Perhaps this is what the issue is? Do the models you are testing contain shadow or collision meshes?

The Thief: I notice that the thief has the same strange twist in his right foot as the citywatch had. Also, from the side, he seems to be leaning backwards almost to the point of falling over, or is that a trick of perspective? I couldn't tell. Also, don't we have the thief's sword model somewhere? It might be the longsword that is making him look off-balance. note to me: The thief texture needs some definite work. It looks very low-res and boring at the moment.

I was working recently on another skins and models variation of The Hammer statue. Here are two skins for the big one: Now the broken and rusted models: (I might do some flinders for the broken model to put around) And some smaller versions - the bigger one is intended to put outside, not in the church. So, these are only 4 models all together but with 9 variations. I'd like to do also some small copy - some portable statue - to be put on the altar or as a loot item (that one could be covered with some ornaments).

I read something about increasing the ik_footSize results in speeding up the character. That might be another possibility except I haven't tried it yet. Perhaps we could increase the foot ik size when the AI is alerted if it works? entityDef monster_demon_imp { "inherit" "monster_default" "scriptobject" "monster_demon_imp" "model" "monster_demon_imp" "ragdoll" "monster_demon_imp" ... "ik_numLegs" "2" "ik_footSize" "4" "ik_waist" "Body" "ik_hip1" "Lupleg" "ik_hip2" "Rupleg" "ik_knee1" "Lloleg" "ik_knee2" "Rloleg" "ik_ankle1" "Lankle_r" "ik_ankle2" "Rankle_r" "ik_dir1" "Lknee" "ik_dir2" "Rknee" "ik_foot1" "Lball_r" "ik_foot2" "Rball_r" ... } EDIT: That might actually look funny: Speed walking

Sorry, I didn't entirely understand that. Right now we have two TDM zombies. One is a variation of zombie_boney (which has two skins), and one is a variation of zombie_morgue. If you load either one up in the editor, you can see parts of zombie_base poking through. It's as if that model is inside each of the other two models. What I'm wondering is if that means both zombie_boney and zombie_morge use the same skeleton as zombie_base. Because zombie_base has a LONG list of animations that it would be great to have for the other two zombie characters. Are you saying that without the .mb files (which I doubt are included in the D3 folder structure) it isn't possible to share those animations, even if the skeletons are the same?

OK, the first part of the new filtersystem is implemented. Texture filters can be specified in the game file, are available in the Filter menu and are used by the Model Selector to hide surfaces (this enables models with collision hulls to be viewed properly). Still to implement are entity and object-based filters, and the conversion of brush, patch and entity render code to use the new filtersystem (which is expected to be a large task).

I don't know what the size of the nude model is, do you? There's not much point in using a standard if it's not the right size. That's a lot easier said than done. We already have three different female models, and I doubt they're exactly the same in the neck/shoulder area. Besides, a necklace will not hide the fact that the head tips forward or back as it moves around. We'll just have to try and limit the number of bare-knecked models we have, or live with the fact that we won't be able to do much head-swapping with them.

I'm talking about melee damage. Is the intended design that any helmet will stop 100% of melee damage? You hit a guy with a chainmail coif with a fully "powered up" overhand sword blow and no damage? If that's the case we're okay, if not, we would have to write extra code to propagate the damage, or make the chain coif part of the head model instead of a separate entity.

Man, Windows is ugly. Here is a better shot of the model selector with its bounding box display mode active:

I hope she's going to have some hair. Bald women aren't really my thing. Keep the details. Hopefully that cretin Jack Thomson will get on the case and give TDM loads of free publicity. Besides, I would like to use the nude model for, erm, developing my animation skills. Yes, that's it.

Looks good. I especially like her lips and the backside also looks very nice, but we would need a closer look to get a better judgment of the model. Of course the closeup is only required for artistic purposes *cough*.