Search the Community

Here are my concerns about that, though as a modeler, mapper and the main force behind setting up the .dds folders, you will probably have greater insight into this than I do, so just tell me if I'm wrong. Issue 1. Right now there are only a few textures being used with addnormals (personally I didn't know about it until you told me, and I assume others didn't as well). I'm hoping to make much more use of this in the future, however, so let's say I'm making a new model and I want to add a stone block texture to it using addnormals. I look through the editor and find the block texture I want. I track down the material name and enter it into my material. But it doesn't work. Why? Because it's a .dds file, though I had no way of knowing that while scrolling through the editor or material files. If I wasn't aware of the .dds issue, this could cause a lot of headaches. Issue 2. Since I DO know about the issue, I'd next have to retrieve the right .tga file from the hires repository and transfer it to the main texture folder. Now we have two copies of the same texture, one .tga and one .dds. That seems like an unnecessary waste. I could of course delete the .dds normalmap when I transfer the .tga version, but beyond the added potential for confusion, that leads to.... Issue 3. Compressing normalmaps has to be done with a special plugin that not every modeler or texturer is going to have. The plugin that might compress a diffusemap properly will not necessarily work on a normalmap (or so I understand). This could cause problems for people who aren't aware of this, making their normalmaps not work. I expect, to try and avoid this problem, some people will be uploading their textures as .tgas in the main texture folder (especially if some model textures are now going to go there) hoping other people can convert them later. So when we find .tga normalmaps in the main texture folders, how do we know whether they are there because 1. the person uploading them didn't make .dds files yet, or 2. they're being used in a shader with addnormals? Checking to see if there is a .dds version wouldn't help, as shown in scenario 2. Anyway, it just seems to me that keeping some normals as .tga and some as .dds is only going to cause confusion and make the texture folders harder to maintain. My vote is to be consistent and keep all normalmaps as .tgas. It seems like the only reason NOT to do this is to save space, but if we start using addnormals regularly, we'll probably save just as much space by not duplicating normals as we would be keeping some of them .dds. (Btw, do we know for sure that .dds files work with OTHER special keywords in shaders, like blends?)

That's right. Could you make another profile of the "Select All" command? It is also very slow and I'm curious what the reason is.

Funny, we all have different opinions besides the fact that they are indeed good models. my opinion in case you care I think PinkDot is right that there could be a little more detail. Of course it could go either way. If the maps are object specific more detail for sure. If however you were thinking of mod bloat (I like that term) and you just reused existing textures I'd say job well done. We don't have very many generic textures that can be used for alot of stuff so it's hard to do and get a good effect. I think the shapes are great as is and agree with Komag that you have the right shape for the axe handle, better leverage that way. I think the axe handle looks odd for different reason than sparhawk, I'm not seeing a rust anywhere. I think it looks odd because it is big enough to be a 2 handed axe, yet only one hand could fit on the handle. I also think the bent handle axe is too big, looks like a one handed wood axe to me, but is too big. Deffinately not a fightin axe so I wouldn't even have a large one. The silver fighting axe though, you could have a small one handed (just scale that model down 50%), and a 2 handed - as is but the handle should be 100% longer.

Nice little game, reminds me of Risk. After playing a few rounds, I would like to provide a bit feedback: - I dearly miss a Move All button (Right-Click-Drag?) to bypass the "Leave behind" window - A selection frame to issue a command to multiple ships at once would be nice - I like Holst's Mars, but after a while it gets on my nerves. Something less dramatic and more ambient would maybe be better suited for longer games. Also, it crackles and pops for some reason on my machine. The ogg itself is fine when I played it in winamp, so maybe the problem is with the vorbis module? - The graphics could do with a wee bit more bling. Alternatively, I could imagine a very "strategic" look (triangles for the ships, circles of different size for the planets, dotted lines, spacey background) to work well. You know, the stuff you'd expect on a strategic console in Star Wars.

As long as the concretes are not really duplicates, I don't see a reason why to remove them. If they are below par, it's ok, but removing them just because we have "enough" doesn't cut it IMO. After all, they can be also used to have similar surfaces without repetition.

Well, we do only have the muffin and cake (which I think is to be aced/replaced anyway) and your loaf which I don't have (is it on SVN, I thought I was up to date) I really think we need to start using subfolders myself, that's why I added that one. It's possible we will end up with 20 kinds of food, 30 dishes, silverware, pots, pans, bottles, sacks... Pretty soon we're gonna be scrolling thru 50+ things to find a loaf. I'm a firm beliver in organization and it needs to be sooner than later or we'll start getting map issue and it'll be too late later. Another good reason to sub-folder is certian objects have different props. If I'm building a level and looking for something to feed the player I don't wanna search thru pots and pans. I think that's a problem that we keep facing is lack of good folder structure from the get go. We have sacks in kitchen and under containers. Iwould've never pout barrels under containers, I can live with it but doesn't make sense to me. Containers should only be things that hold something for player IMO. I can find instances of this in each folder, graveyard has bones_... then way down the list skull. I'd personally rather open a graveyard folder and see gravestones bones debris stautes then if I want a gravestone I can look only at gravestones and search the 10+ stones, if I want statues I'd only look in that folder... that's my 2 cents anyway

I can get this super slowdown problem in either Doom or in Dark Radiant. I'm sure now I've had this before but dismissed it as a memory glitch. If anyone else gets this problem, the 'rules' to avoid it seem to be... . It may or may not be Nvidia graphics card related. . It only affects the loading phase of either Doom or Dark Radiant. . So far I've only noticed it if a grass texture is being used but I'm sure certain other textures will have the same effect. . Always open doom first BUT DON'T OPEN AND SHOW A MAP IN WINDOWED MODE (ie, if you DO open a map then go to the Dark Mod menu so it does not show.) THEN open Dark Radiant. . If you should open Doom first in windowed mode and also open and show a map in Doom and then open Dark Radiant then Dark Radiant might slow down so close it, switch Doom to the Dark Mod menu and THEN re-open Dark Radiant. . If you accidentally or for whatever reason open Dark Radiant before Doom with a map showing then select 'new' map from the file menu and (IMPORTANT) use the 'flush and reload shaders' button on the texture browser and THEN open Doom. When Doom is running then re-open the map in Dark Radiant. Once both are running OK then there seem to be no further problem so it's workable.

I have am chine setup in my living room which uses WLAN to connect it to my network. Otherwise I would have to pass a cable there (which in the long run might be better probably). The issue now is, that my neighbour also has a WLAN and our houses are back to back. I think this is the reason why sometimes my connection is extremly bad to my machine (as right now while typing). So I wonder if there are ways to improve this situation. Either by changing the frequency, shielding or maybe disrupt my neighbours waves without disrupting mine or similar. Actually I don't care that much if my neighbour is pissed off, because we are not really on good terms anyway.

radiant/ui/ortho/OrthoContextMenu.cpp: In member function 'void ui::OrthoContextMenu::checkMonsterClip()': radiant/ui/ortho/OrthoContextMenu.cpp:154: error: no matching function for call to 'SelectionSystem::foreachSelected(ui::ModelFinder (&)())' include/iselection.h:143: note: candidates are: virtual void SelectionSystem::foreachSelected(const SelectionSystem::Visitor&) const radiant/ui/ortho/OrthoContextMenu.cpp:157: error: request for member 'modelList' in 'ui::visitor', which is of non-class type 'ui::ModelFinder ()()' radiant/ui/ortho/OrthoContextMenu.cpp:157: error: request for member 'onlyModels' in 'ui::visitor', which is of non-class type 'ui::ModelFinder ()()'I get this error message that says that my visitor is no class. typedef std::vector<scene::Path> InstanceList; class ModelFinder : public SelectionSystem::Visitor { InstanceList targetList; bool onlyModels; public: ModelFinder() : onlyModels(true) {} void visit(scene::Instance& instance) { Entity* entity = Node_getEntity(instance.path().top()); if (entity->isModel()) { targetList.push_back(instance.path()); } else { onlyModels = false; }}}; But this is obviously a class. For completeness here the lines that cause the error: ModelFinder visitor(); GlobalSelectionSystem().foreachSelected(visitor); I have really no idea what the reason is, as this is really just a normal class. Any ideas?

These are my relevant DoomConfig.cfg settings, be sure the have normalCompression set to 2, this might be the reason (it enables the use of RXGB DDS compression for normalmaps): seta image_ignoreHighQuality "0" seta image_usePrecompressedTextures "1" seta image_useNormalCompression "2" seta image_useAllFormats "1" seta image_useCompression "1"

Ok, I confirmed it. Addnormals does not work with dds normalmaps for some reason.

You can't not have a far clip plane, this is a requirement for OpenGL rendering AFAIK. The reason is that the depth buffer contains numerical values which have to map from the near clip plane to the far clip plane in order for Z buffering to work correctly. It is up to the programmer to position the planes correctly so that the entire scene is enclosed but the Z buffer does not lose too much precision. I have no idea whether the OpenGL clip planes have anything to do with your problem though.

Yeah. Kids will be definitely time consuming. But this takes time. As long as they are small you have more time. Once they grow more up they also want to do what you are doing. But you definitely should devote as much time to them as possible. If you don't, then you will rue it later for various reason. And what is done can not be made undone, no matter how much you regrett it later.

The dock looks great! As for advice: The less you change from your current live, the better I think it is. If you live together for some time already, you will have developed an agreement anyway, so there is no reason to change it just because you are married now. It is definitely advisable to keep some free rom where each of you does his own thing, so you don't lock on each other without alternatives. Congratulations.

Yep, got it and I can see the problem. I'll see what I can do about it, I'm not sure what the reason for this is.

I'm once again diving through the libraries and once again I'm thinking about how this could be done better. Being well aware that this part of DarkRadiant is probably the most critical, I still think that there must be something that can be done to makes our lives easier. Orbweaver, do you think it's possible to make a slow transition with the old and a newly setup nodesystem side by side? Or would that be far too cumbersome and pose a serious performance drain? On a side note: Today I watched angua pasting a large part of her caves map into the bonehoard.map file. In the map there were about 3600 primitives and 550 entities. She selected only 300 of them and the system (2x 1.6 GHz) worked and worked for about 15 seconds before the new selection turned up. Maybe there was the renderer slowing down things as well, but this is not the only reason, I think. I had a look at the scenelib.h where the Instance class is defined and I think that there is some serious recursion going on. Each time the selection status of a BrushInstance is changed, it calls the selectedChanged() method from the base class. This checks for a parent and if a parent is found, it traverses the whole subgraph and this parent traverses the subgraph again - I haven't dug deeper. This is completely insane, rather than propagating the information from top to bottom through the hierarchy, the callbacks are pointing across the scene. What's your estimation on this? Is this another mammut-task like the dmap compilation stuff and should we rather leave it as it is?

Yeah, I didn't remove the class because I couldn't figure out its purpose and didn't want to break anything. If there is really a need for a container which retains insertion order but also ensures unique elements, this would need to be implemented using both a list (to retain order) and a map associating objects with their list position (to provide quick access to known elements). I suspect, however, that the only reason this class exists is because the developers couldn't be bothered to define an ordering over the Node objects, which is required for std::set presumably, and somehow didn't notice that their solution was going to be appallingly slow.

I haven't had a lot of DromEd experience. I've started dozens of maps, and never finished a single one, for this reason or that. Right now, i'm designing a rather ambition map (at least, by my standards) that in all likeliness will probably never see the light of day. But with some help, maybe it will. I want to create a rope that garrett can swing on. Nothing fancy like swining around a corner or anything. just running, and jumping and then swinging on a rope over a chasm of doom. does anyone know how this could be accomplished?

I found all the videos i was searching for. Feels good to watch them over and over. Brings back good memories. I'm still looking for Gumdrop tho. He's been missing in action too, and he was the one who painted my logo (see link below). I'm searching for him in hopes he still has the orignal PSD files we worked with. Other than that, I'm building my resource library slowly. Just acquired all the Thief 1&2 media. ie. OM vids and Sounds. I updated all my editing software so we're solid there. I was actually thinking about Playing Thief again. I mean... I haven't played T1/T2 in years, and I bought T3 not long ago... but for some reason I'm not liking it anymore. When I bought the climbing gloves for 2000 and then found out they are pretty much useless... it put a bad taste in my mouth. I can't enjoy thief without Rope Arrows. I just can't. So, once I get the T1/T2 games going with Darkloader and all the patches... I should be close to where I was. There is a small amount of stuff I'll never recover. Little tid-bits I gathered along the way... but it's all good. That's why I'm here now. Hoping to work with some pros around here. I mean... CoSaS is a bunch of great ppl also... and I'm still working with them... but this feels different... because it IS different... and I like the way things are moving over here. So we'll see. Maybe I'll get to work with the MOD and possibly cross a threshold into new amazing video territories.

In the future, please make sure that all filenames are lowercase (they could be uppercase as well, but for consistency). Reason is, if they have mixed case, it will create problems on the linux port, if the case is not the same everywhere. So this especially includes references to files.

There's no reason why they couldn't be made to roll down stairs. In fact, they could practically much use the code for grenades from Doom 3 without modification.

I don't see a reason why the HD layout must reflect the editor layout. The important point is to have a strict rule how to name the textures and where to put it. And from this, if you have the name in the editor, you can easily find the texture in the directory as well, because we HAVE such a rule in place. There is no need to keep it on a 1:1 basis and in fact for browsing the textures directly, outside the editor, the falt structure is even more usefull.

Privacy does not just relate to an individual though. An organisation can demand privacy. A government can say 'we want to keep this private', i.e. 'we dot' want the public to see this', i.e censorship. You can argue that if something deems something as 'private', or it is deemed 'illegal' then it no longer can fall into the category of censorship, but that gives virtually everyone free reign to censor things by stealth. I think you can only argue against censorship if you can come up with reason as to why it would be in the public interest to see what is being censored, or why it is against the public interest for it to be censored, I don't think you can just give a blanket statement against all censorship as a principal. Likewise, a reasonable argument has to be given as to why the item in question should be censored. Now, just to trip you up, here's another scenario. One which will no doubt arise in the near future. CG child porn, so no privacy issue is at stake. The characters are all totally photoreal CG models, so good it looks like a real movie (not quite possible yet, but it's only a matter of 10 years away at the most) Is it ok to make this freely available to anyone who wants it, or should it be made illegal (censored). Whether people distribute this by the back door is not really the issue, the issue is should a formal stand be taken against it, entirely on moral grounds.

Correct. I was already proposing this before the reorg, but was turned down, because some felt that the directory should match the shadername, which I don't see any reason for.

You see? You purposefully look away. Wich means that you would want to look, but for some reasons you don't. The urge is still there. I do the same but for a different reason. I always think that I wouldn't like people staring at me in such a situation, and I think that most other people don't like the same, so I try to respect that. Also I find it always highly annoying when a traffic jam occurs just because people have to stare. The worst that I experienced was my neightbour above me. He was smoking in his bed and felt asleep. In the morning I woke up and heard some bustling outside, so I looked through the spyhole. I saw some firefighters doing something before my door, and I was 100% sure that there was a corpse. When I went to work 15 minutes later, I saw that they had put the corpse in front of my door, because they had needed leeway and so put him somewhere where he was out of the way. He was covered with a sheet, but a burnt arm was sticking out, and that was already enough to see.