Search the Community

Ok, the new PK4 is up. IMPORTANT: In order to activate the new lightgem path setting, everybody has to delete the line containing the old path in the DoomConfig.cfg file: seta tdm_lg_model "models/props/misc/lightgem.lwo" It will be replaced with the new default setting from within the PK4.

Noselfshadow prevents the lightgem to cast shadows on itself, so I guess that was fine. Replacing that with noshadows is probably even better, because there's no benefit in letting the lightgem cast a shadow. The performance gain is probably not noticeable, but a penny saved is a penny got. I'll change the lightgem in a minute, I first have to finish my current piece of code, so that I can commit it. The PK4 will follow soon.

Feel free to PM me your reactions, Nyar... I'm interested that you didn't like some of it. Or you could use tags, with appropriate and visible warnings.

Nope. I'm .:MOO:.TheDestroyer|CK|, a JKA clan. I am also a member of The Jedi Academy [.net], also a JKA group. TJA is a major 12-13 thousand people family. Cool eh? for the links, get star wars jedi knight jedi academy, learn to use it, then download http://jediknight2.filefront.com/file/OJPE...me_Manual;80816. With this, and Open Jedi Project Enhanced v0.0.9v you will learn to fight. OJP-E changes saber fighting big time. Swdroids.com is just a good lookin' site w/ nothing on it, its just my major file center. I test forums on it, etc. etc. I'm working on different projects such as a RP kit for STar Wars Jedi Knight: Jedi academy. -TheDestroyer

There is no persitent list as far as I am aware, the code just visits each Archive (which may be a PK4 or a directory like ~/.doom3/darkmod) and asks each Archive to search for the matching files within itself. There is still a bit of inefficiency because the VFS visitor class gets passed a filename, not a file object itself. It then opens this filename using VirtualFileSystem::openFile() or ::openTextFile(), which actually initiates a NEW search through the VFS for the named file. Changing this would be quite difficult however, because the visitor class would need to be passed an object which can be opened as either text or binary depending on the requirements, which would mean merging ArchiveFile and ArchiveTextFile into a single class (which would be a good idea, but probably a lot of work). I'm also not sure how much real difference it would make to the speed.

I've rewritten the filesystem visitor code for improved performance (no "Searching" delay when populating the model list), but there is something wacky going on with parsing the resource files -- it seems that everything is read twice, so absolutely everything shows an "already defined" warning. This requires further investigation, but I wanted to get the performance code committed first. EDIT: Found the problem (I think), and it may not be a DR issue: there is a file called materials/andy.mtr in BOTH pak000.pk4 and pak005.pk4 in Doom3/base. The previous code built a unique set of filenames first, before visiting them, which means that only one of these files would have been looked at. Now, the callback is used immediately without first building a unique set -- but because the callback uses the filename to open the file during the visit, the same file is opened both times (because the name lookup just returns the first matching file). I think I will add back the unique set code (using std::set, not some ghastly linear search through a GSList) so that only one file will be visited. However, this will mean that definitions will be missed out if they are defined in an MTR file which has the same name as an MTR file somewhere else.

We've come full circle. So... http://forums.thedarkmod.com/index.php?s=&am...st&p=118792 (I could/will make a bugtracker entry of course; I just wanted to know if the request was outright rejected before doing so, or if it would be considered)

Not sure I've understood this. I create a gate, rotate it 45 degrees so its rotation values are 0.707107 0.707107 0 -0.707107 0.707107 0 0 0 1 I want to make it 8 times thicker which is the Y value so multiply each of the middle column to get... 0.707107 5.656856 0 -0.707107 5.656856 0 0 0 1 But don't seem to have done it right as the result is clearly wrong. (sorry did the above off line in Courier New and it lined up correctly but somehow the code tags move it out of line)

Anyway, if no one can vote at all, then it basically locks in the result as of last night. I don't think it will hurt you, all in all. I think being popular on some internet forums worked in your favor for having a consistent turnout throughout, so if anything a final push might have worked against you, in relative terms I mean ... but that's just a guess.

Sorry for the global post, but this is joebarnin and I can't post to the private forums or sent a PM. Here's the error I get: ----------------------------------------------------- Forbidden You don't have permission to access /darkmod/index.php? on this server. Baby Jesus cries... ----------------------------------------------------- I am logged in as joebarnin when I try to post.

I guess you can put it that way. 1. Avoid name conflicts of shaders (this is vital, TDM will emit warnings for shaders or entityDefs of the same name) 2. Avoid name conflicts with vanilla TDM files. I think we haven't decided on a clean way of how to enable betamappers to override mod default content (the most critical example is the file tdm_ player_ thief.def - assume you want to override the player's start health), which is something we might have to consider when doing the concepts for the map loader GUI. Generally, if you need to tweak vanilla TDM content, copy and rename that definition and put it into a new custom file which is then included in your mission PK4.

@Fidcal: The contents of PK4 files will be overriden by the contents in the darkmod/ folder. This means that a material file materials/test.mtr within a PK4 can be overridden by a file of the same name outside of the PK4. I recommend creating an own shader file .mtr and putting all your custom shader definitions in there. Generally, beta mappers should avoid name conflicts with any files of the mod itself.

If you do a search in the public forums for "sinusoidal shearing", you can probably find Gildoran's examples of grass that sways using animated textures. There is also a tree that we were given by EOC that uses animated textures to make the leaves move. I don't know a whole lot about animated textures myself--I've used them a few times in menus, but that's about it. I know that you can scroll side to side or up and down, which works like a conveyer belt if you have a tilable texture. You can also rotate the texture. The speed of motion is customizable, and you can also make the texture go forwards and backwards (the swaying effect). I'm pretty sure you can also increase the intensity of the texture (a 'pulsing' effect).

Here's an example of how the new weapons can easily be modified by different skins. By swapping different wood and metal textures, it's easy to make many different looks. These are just a couple. The rustic axe and mace could still use some work, but the others are "decent". I could work on them longer to make them even better, but I'm going by the philosophy that it's better to get lots of decent models in game now, so they can be used and then tweaked later, than a few excellent models here and there. Anyway, I think I'm going to take a break from the weapons for a bit and do something else. For those keeping track, our weapon totals are: 4 swords (longsword, shortsword, dagger, ceremonial sword) 3 axes (battleaxe, handaxe, rustic axe) 2 polearms (halberd, spear) 1 quarterstaff 1 hammer 1 mace ---- 12 melee weapons 2 longbows 2 shortbows ---- 4 missile weapons http://forums.thedarkmod.com/index.php?showt...enant&st=25

Sorry, I meant pk4 *file*. Yeah, I suppose a map-specific folder would be useful for team mappers.

What do you mean with PK4 folder? The one that mappers will usually release? For team maps we don't have any PK4's yet, but they still need to store the models somewhere.

I guess it's different for maps that are being made by team-members. Normally something like that would just be put in the mapper's pk4 folder, rather than being added to the mod repository, wouldn't it?

No it can't, and for my part I am opposed to this functionality for a couple of reasons. 1. It alters the DarkRadiant paradigm from a consumer of assets to a producer as well, which raises practical issues relating to the ability to edit resources within a PK4, the default location for autogenerated MTR files, the naming of new materials and so on. These are not insurmountable problems, but I am not sure there would be a clean or elegant solution to them. 2. Attempting to shoe-horn an inappropriate workflow onto an implementation that does not correspond to it is generally a recipe for unpleasantness. Just look at the HTML files generated by Microsoft Word for an example of what happens when you try to use a "clever" tool to autogenerate data which is intended to be written correctly by hand. I would not be opposed to writing tools to assist with creating material definitions, either as a DarkRadiant plugin or a separate Python program, but I don't think we should try and hide the use of MTRs behind some kind of "fake" realtime editor.

You know, my modelling has gotten a lot faster once I remembered the reloadmodels command...no more waiting for maps to load in between every model change. Just for people who don't know about it, there are tons of 'reload' console commands you can do to update changes immediately. http://forums.thedarkmod.com/index.php?showtopic=2149

You could be right, but to me that seems really excessive, especially when we can use skins to create different versions of things. How many different kinds of dishes are there? Do we really need six different kinds of bread model or four different types of spoon? Remember this is a toolset. We aren't necessarily supposed to include every single model a mapper might conceivably want--if we did that the size of the mod would be enormous. If a mapper is making a bakery and needs six differently-sized loafs of bread, there's nothing stopping them from resizing the existing models and adding them to their pk4. But do we need everyone who is downloading the mod to download six different bread models? That's not entirely connected to the issue of sub-folders, but it is related. If we decide to add more folders (which will mean breaking maps) then we should definitely do it all at once, not a few at a time. How many models is too many for a single folder?

I'm using IE7... but it does the same BS on Firefox. http://forums.thedarkmod.com/index.php?showtopic=6164

First of all: can somebody (New Horizon?) give him Applicant or Contributor status so that we can discuss things in more detail? @Arcturus: I could take a look at it now, and I have some feedback for you. - While the normalmaps look good in theory, they are almost not noticeable for the "old" and the "white_brick" textures. They should be much more pronounced. I looked a the textures using "r_skipBump" and could hardly tell any difference between the appearance with and without normals. edit: Ok, after looking at them at smaller scale it actually isn't that bad, but the lights have to hit the texture at really sharp angles to make it properly visible. So don't take this too seriously. The brick normal can definitely be deeper though. - The normalmap of the tile textures is very grainy or noisy. It makes the shingles appear like sand, which feels a bit wrong. The roughness should be decreased a lot, this would look much better. The diffusemap is non-tiling, which can probably be fixed easily. - The "old" texture has non-power-of-two dimensions (1068 pixels). This will not work when the imagesa re converted into the DDS format. All dimensions should be powers of two: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, etc. Width and height don't have to be the same, of course. Please don't be discouraged by my feedback. If you are willing to put some more work on the textures, I can imagine that these could fit into our repository. I (or somebody else) can give you some more detailed instructions in the internal forums with respect to techniques and organisational stuff like naming conventions, DDS conversion and such. edit: Thanks for moving that, N.H.

I'm not sure if this has been discussed before... I've just searched the forums but couldn't find any information about it (probably because I'm not sure what words to search for). I'll try to explain: In Thief3, you could wander around in the city, without people yelling ooooh, thief, because you're just a passenger pedestrian, and there's nothing that makes people think you're a thief. Apart from those who know who you are... This is what I really liked in Thief3... and if I remember it correctly, it wasn't the really case in Thief 1&2 (or at least it didn't really stand out as much as in Thief3). Also, it's funny how your own footsteps are "triggered" (people will come and take a look), and footsteps of a guard ain't. You probably know where I'm going to: how will others know you're thief and not just a regular guy, servant or guard? I recently saw a trailer of , and I immediately thought of Thief. Of course the game is a lot different, but the interaction with the crowd is a bit similar. Hitman also had some interesting ideas: the less you act like a regular guy, the more people will find you suspicious. I'm just wondering how this will be done in the Dark Mod Of course, most of this will apply to what's going on in the streets, and not really the mission itself.

I'll set you up as an applicant, then you can post your samples in our private forums.

I don't think the team has ever 'collectively' said any such thing. I think it's far more likely that they're too busy with new projects to respond to questions raised about a game they released three years ago than the possibility that they regularly read our public forums and were personally offended by the occasional isolated comment from individual team-members that they didn't think much of D3 as a game.