Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by LDAsh

  1. I like the idea of individual HUD elements only being visible when contextually relevant and otherwise fading off pretty quickly to leave the screen perfectly clean. All of the elements could still combine to give the impression of a visor but even the ammo would only be visible when the gun is actually in use, including initially. All elements could be invoked with a key, which keeps them active when the key is held and lasts maybe 3-4 seconds when tapped, but otherwise all fade away quickly.
  2. Great work on the video, keep 'em coming because this isn't necessarily just a nice resource for TDM mappers but level designers in general.
  3. I don't mean to sound offensive or condescending or anything, but maybe you could get into the habit of doodling a rough map onto a notepad (IRL).
  4. For now I have a couple of materials to offer, to see if they are worthy or not. Both of these I will put on (among other sites) http://www.opengameart.org under CC-BY. (*anyone is welcome to use these for whatever purpose) http://www.violationentertainment.com/temp/fnlltstnwcndrblckwll1.zip http://www.violationentertainment.com/temp/fnlltstnwhxyvrsalfeflr1.zip This is based on the cinderblock and hexagonal-tile floor you could find in UNATCO/MJ12-lab/Versalife. Again I'm yet another one working on a large project that is strongly influenced by the original Deus Ex and did actually consider using TDM at one point, but have since decided on a different engine that can handle much higher amounts of detail within large open environments with heavy use of batched LOD from the vertex buffer. That is not a criticism of TDM, it just is of idTech4, so I hope nobody will get twisted up into knots about that, it's just my personal decision. We still use Radiant so this community is very important, but we're using it in a different way. I would offer to do some mapping for this project too, and I might try a small UNATCO map, but to be honest, I think the technology is really outdated and I would rather spend my time on something that won't look like a mobile game. Again, I don't mean to sound offensive, just being objective about it. In my experience, you can't really get modern polycounts without the engine choking itself to death, and it's not far off what a modern smartphone can handle these days, polycount-wise. BFG edition may be different but without 'VBO-LOD' it's still not going to be something for posterity. I would really like to see this project take off but I doubt it is going to, unless 1) enough quality materials are hoarded for mappers to use, 2) mappers to actually use them to sprout some shots to show around, then(/while) 3) some very talented folks to get quality player models and v-weps cooking, which might be very hard to find. The quality stuff TDM had pretty early on in that regard is why I think we're all here right now, in my opinion. Also, I don't think salvaging (/vulturing) from other mods is the right way to go. Permission to use a material or 2 might be fine, but otherwise the project is at risk of becoming a junkyard. Bladeghost's PK4s have a lot of Doom3 assets in them, FYI. About more materials - I have a huge amount more, almost 5000 now, all can be used commercially, however I am a bit fuzzy on the license of some of them in regards to open distribution, such as from www.cgtextures.com, which I've used a lot for outsourcing. Also a lot from www.episcura.com which has been offline for a few weeks now and makes me a little worried. They might have been acquired, hopefully not by those sleazy TurboSquid slimeballs. I've tidied up a lot and made custom normalmaps (hand-made high-res heightmaps made with love, so NOT just typical photo-to-normal click-bang trash) and the other maps, but I am unsure about breaching the license agreement if they are to be put in some publicly accessible repository. On one hand it 'feels okay' and others have done it, but on the other hand I did actually _read_ the license agreement. Any advice concerning that, I would appreciate it. For the time being, if these 2 samples are good enough, I will provide more of what I am certain I can distribute, that I have not outsourced, created personally, or that was marked as public domain. Like I said, these will go on OGA as CC-BY so there will be no issues about anyone using them. Finally, my submission for possible titles (to vote on?) is "The Deus Mod" . . .
  5. Just curious if (the beginning of) this project is still happening? I'm still interested in being a part of it and still intend to focus on getting appropriate materials for mappers to use, just been too crazy-busy with other stuff to prepare anything just yet. I might do a small amount of mapping with it too, if it's still going. I'm interested in doing accurate reconstructions of the original DX starting with UNATCO HQ, but using more modern standards such as chamfering all those terrible infinitely sharp edges everywhere.
  6. Another idea that came to mind was to convert the PROC file to something that can be imported back, and I swear there was a way to do that, but I can't remember if it keeps the material headers and UVs enough in tact or not. Probably not. Never really needed to do this before, but I do remember it was possible as I compared how PROC files are carved up compared to idTech3 BSPs. __________________________ (edit): I believe "Noesis" was what I had used to do it:- http://richwhitehouse.com/index.php?content=inc_projects.php&showproject=91 __________________________ (edit): Ah yes, Noesis can convert PROC files to OBJ and keeps all material headers and UVs in tact. It separates by materials and Blender can easily separate further by "loose parts". Lovely.
  7. That's really awesome. I had read about it briefly before but obviously not carefully enough. I thought it was more for bunches of LOD'd objects that already existed in a map. After playing around with it a little, it seems like this performs its magic at the DMAP stage, so my question/request now becomes:- Is it possible to force this into unique entities (entries) into the actual map file so that seed can be initially used but then objects can be manually manipulated afterward? It would also allow these objects to be exported into something like Blender for extra tricks and then imported back into Radiant via OBJ format. I realise this defeats the purpose of the density settings, etc., but I still think it would be handy to have complete control over every object individually.
  8. In working on things like debris, junk/litter and all kinds of organic scenes with rocks and bushes, I think it would be great and save a lot of time to have some tool that can import a number of something at once, randomly "scatter" and randomly rotate (with axis-restriction) large collections of mapobjects. For example, a mapper would load in a bunch of such objects in one spot (even overlapping) with one operation, select the multiple objects, then perform the operations separately. "Import #" ('import multiple') would be an extra feature of "Choose Model" dialog, I imagine to the left of Cancel/OK a field where the mapper can input the number of these objects to bring in at once. "Scatter" would have a value that represents extent of area, so say the mapper types in "512", it would relocate/redistribute the group of objects in a 1024x1024 unit area. ...(if this could be done while also snapping to whatever geometry is connected below it, that would be a huge plus, but also much extra coding work, I imagine.) "Rotate" (or 'randomize-rotation', for disambiguation) would take a simple X/Y/Z option and rotate everything at random (uniquely) by that axis only. At the end, creating such random mess for organic scenes and dirty/destroyed urban scenes would be much quicker, and hopefully these tools wouldn't be difficult to implement. What do mappers think of these ideas? If you agree they are worthy requests (or not) please chime in.
  9. This is much like what I'm working on, and I even spent a lot of time mulling over whether to use TDM or not. It was tough but I decided to go with an engine that was much more optimised in terms of LOD. We still do use Radiant, particularly DarkRadiant, as a core element of our workflow. But anyway, I have a LOT of materials (over 4000) that can easily be thrown into an idTech4 project, all urban/tech/scifi/industrial themed heavily influenced by Deus Ex. I believe indie developers should be trying to work together and it doesn't mean we'll be stepping on toes, because who really cares if we've both got a door texture or cinderblock wall texture that's exactly the same? I don't think the audience will care. I think the weapons and characters are more important, but that comes later. Getting environments (mapping) cooking first is the place to start, but that can't really happen without a decent collection of textures to work with...
  10. Yous dudes might find this interesting:- http://www.imagemagick.org Particularly, the ability to use command-lines to achieve complex manipulations and easily share them with BAT files. I was looking for a way to batch-process mipmaps with certain adjustments, stuff like making glass more opaque at a distance/angle, and trying to make glass then completely opaque so it can then be used to close a portal. I don't know if TDM has distanced-based portals in it, I think Quake 4 but Doom3 did not. I'm also trying to have greater control over foliage, etc., to help thicken or thin the alphas out at a distance. There are a bunch of things one might want to toy with mipmaps to achieve, and this is great software for it:- https://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=30567&p=138376
  11. I've always thought the sign of a great game is one that I enjoy losing almost as much as winning, and can hats-off to the AI when they see me mangled in a puddle of my own blood. With some smart decisions in the early design phase, I think it doesn't need to take a whole bunch of extra effort to please both crowds, on an easy setting that holds the player's hand, to a difficult ("realistic") difficulty that pleases the more hardcore audience by not assuming anything about their intelligence. It's always going to be extra development work, but can be severely minimised. Sometimes I think it might be a case of - instead of using the terms "easy" or "hard", using some other words that aren't such an affront to their sensibilities, whatever those words may be. Don't put a pacifier in their mouth because they choose easy, like in Wolf3D, folks these days don't have a sense of humour about themselves like we used to. The idea of 'adaptive difficulty' is interesting but I don't think it's a solution that's ever been very well implemented. Perhaps the issue is that most gamers like to jump into a game on the hardest setting and expect the game to not be ridiculous, they still want to take thousands of bullets to the face without a hiccup, while every enemy collapses in agony from being grazed on the pinky, and such. They will sooner rage-quit than try again on a lower difficulty. It's a matter of pride, both for the person and their hardware. The same people probably max-out all graphics quality settings and if they get low framerates they will just uninstall the piece of crap rather than try again with more modest settings which likely wouldn't be a very noticeable visual degradation anyway. Again, I think this could be solved by not using words like "low" and "high", and giving some clear warnings (red popups) about what maximum settings are going to be more of a framerate penalty. It would kind of put more perceived emphasis on the developer being at fault if poor performance is the outcome, rather than the 'customer'. I think in many ways developers dig their own graves when they give the impression that the hardest difficulty gives some implications about the girth of the player's testicles, likewise implications about how if you can't sustain 60FPS with all settings maxxed-out, it means the player's computer is a worthless paper-weight. Folks these days are very sensitive about these things and will react negatively, but I think it can be avoided.
  12. TDM 2.04 runs fine under XP x86, in terms of loading up the main menu, but this is what happens when I try to load any mission:- So we can all relax that TDM possibly does work under XP. I am most pleased to present this error to you all and good day.
  13. Yes and especially for this image in your first post, it will cause a lot of trauma for people to see that. I can hear the splashings of vomit already.
  14. The trend is to take extra time and efforts to not support XP on purpose, even when it's quite easy to do so. These damn XP users, they only understand the language of whippings and lashes, otherwise they will just never learn... It's still not quite so cool because it still works on 32bit systems, but that's just for now. It will be "fixed". The day approaches closer when everyone can begin to down the pants and dump some turds on Windows 7. Don't think it won't arrive.
  15. Just grab your favourite hex-editor, make a copy of the EXE and open it up, and find the reference "DarkRadiant" that comes after "cannot find APPDATA environment variable" (in later versions it's the reference just before it), and change it to whatever you want. So far I haven't found it has broken any functionality although I can't guarantee that, but one thing you need to make sure of - keep the reference the exact same amount of characters, so for example call it "BarkRadiant" or "LarkRadiant". You don't need to make a whole other folder for it, just a different EXE in the same folder, and it will use the different settings.
  16. Maybe this is iffy advice that will be looked down on, but you can hex-edit the folder reference used by DarkRadiant EXE (in "Application Data" folder) and have many different versions of DR with many different settings there.
  17. These are the times we live in, where it 'pays' to have multiple HDDs/partitions with different OSes to multi-boot into, or have 1 very powerful PC that can run them in virtual machines in a decent enough way. For me, I do a little of everything, with multiple PCs and multiple OSes in partitions/HDDs, so it's a bit of a juggle but I at least I can do anything I need to. I still prefer to stick with XP and 7 for most uses, but I'm starting to embrace Linux more and more. I doubt I will ever touch Windows 8 just like I will never touch Vista. 10, I still don't know about... Maybe I will wait for 11, whatever that will be called, and give M$ that one final chance to not shoot themselves in both feet and fall down on top of Apple.
  18. Incidently it farts a 404, but the link that nbohr1more provided (assuming it's the same), only some of the "notes" actually explain what missions they try and what they are doing with their CFG/GPU-settings, which is extremely important. For example, many versions of Radiant hate v-sync and the difference in performance is drastic with that. idTech4 is such a highly configurable engine and based on the OP stating "I'd like to play most TDM missions with a decent, smooth frame rate if possible, but I don't need everything maxed out or anything like that" then I would say ~$200 would easily get that, and not necessarily looking ugly either. When he says "most TDM missions" I assume he already understands some have performance issues due to poor/ambitious designs.
  19. I'm not sure a distinction is being made between "minimum" and "recommended", this is after all still idTech4. Somewhere between minimum and recommended is where a reasonable answer is. It's curious to note what kind of system can run Thief 4, and by "run" I'm not talking about maxxed-out, just run. The issue is with the campaigns (missions) and the content within those campaigns being very different and very inconsistent, so to say an i5 with 8GB of RAM and a GTX660 isn't going to cut it for all settings maxxed-out on something like this (http://puu.sh/jExps/647c6c3484.jpg) is probably true, but for decently optimised campaigns and careful tweaking of a user's CFG file, I can say anecdotally that a far more modest system will play most of what TDM has to offer at a reasonable framerate, and any major drops are due to the author of that particular campaign being not all too savvy in the art of development, and not to be told "you're gonna need a new computer duuuuuude". That is, of course, if user is inclined to spend time tweaking the CFG and not just setting everything to maximum and diving in head-first into a heavy (aka not very well designed/executed) campaign. In short, my experience/opinion - yes, there's a system out there for ~$200 that will run TDM fine with reasonable expectations. It gives me an idea, perhaps a "performance rating" might be handy for the mission downloads page? I know this might be controversial and lead to warfares, but think of the end-user and first impressions. People might be put off if the first thing they try to play is also the most heavy and sluggish of missions compared to ones which are lovingly optimised and well designed.
  20. It's uncertain if "there are no license on formats", I will conclude the issue is unresolved based on my extensive Google searches about it, rather than take anyone's word for it as anything more than an assumption.
  21. The only other things I can imagine are particles, and that might be going too far, I don't know. Placement of lights and particles are not deal-breakers, in my opinion, they can be redone in other software/engines reasonably quickly. Beyond that, you are talking about the carving/merging and vis-ing of the BSP/PROC format, and I might be way off about this, but I assume those are proprietary formats and can't be used without a license, else get into some legal problems with big companies. I know this is the case with Valve, but idTech is a little cloudy. This is why we need to be especially careful within Radiant to make sure all edges and vertices align, so we can smooth everything nicely, and also split up the maps into what I call "sectors" so the LOD can function and the whole thing can be portalised. Then the BSP/PROC compiling process isn't much use to us anyway, compared to the ability to LOD _everything_, which idTech could never do. A small price to pay to be able to stick with beloved Radiant, because you just can't make 3D environments any faster, even very high-detailed ones using modern standards, into the millions of triangles.
  22. Sure, and mapobjects can be easily split in up by "separating vertices by material", so it's all the same once you're in Blender. I was mainly talking about placement and consistent workflow, to do as much mapping within Radiant as possible, and it's exactly why I'm willing to pay a nice chap to export light information (coords, proportions/rotations, colour, strength, etc) from a .MAP file to something that can be imported into both the engine and possibly Blender, via a Python script. Then it might be possible to set up lights in these Radiants too. This would be a lot better than just having the useless little diamond meshes floating in the air.
  23. If working with another engine and wanting to do as much as possible with Radiant in the workflow, placing all the mapobjects in Radiant and being able to export them "per scene" is important for minimising the number of batches and creating texture atlases for everything, instead of ending up with a sandboxed junkyard, like some other indie projects. If not most, dare I say, end up with thousands of batches and everyone too burned-out to want to fix the framerates when it's easier to tell everyone to just suck it up and buy a new PC. I'm not interested in making those same mistakes. It's also handy if there's some mass operation needed on large collections of mapobjects at once, like welding and smoothing, or for unwrapping shared UVs for baking lightmaps. It saves a huge amount of time. The engine I'm working with has LOD stages for static meshes so we can LOD _everything_, including the map itself, and we have a script that can automatically increase and decrease the tesselation of all patches in the entire map just for that purpose. Especially because of that, we need everything to be combined together as whole chunks. If DarkRadiant could do this, it would not only be more convenient but peace of mind over any legal issues about trying to use it commercially.
  24. It would be nice if DarkRadiant could export chunks of mapobjects (exact positions/rotations), so they can be combined in other software. Currently a way I know of doing that is to use the Quake 4 editor, it can export selections of models to 1 OBJ, and even though that version of Radiant is fairly easy to obtain (you can combine the demo PK4s with the patch EXEs and launch the editor from the intro movies, and all freely available) there are a lot of funny-shaped eyebrows about the legality of doing that for "serious" projects.
  • Create New...