Search the Community

So to test it definitively, we could put a map in a .pk4 in addition to a new hud.gui, and it should overwrite our hud.gui. Does this happen?

Jumping and mantling can be done reasonably "easily" - you just need to do enough precomputation of reachabilities. (I've put quotations marks around "easily" because it's a bit of a pain to implement, but the theory is straightforward enough.) From pathfinding's point of view it's not much different than being able to walk between two adjacent pathfinding nodes on a flat surface; the AI just does a few slightly more involved things with physics and animations to execute the movement. You do need quite a few more animations to get it looking good (if you can do it procedurally ala Euphoria, even better), but it's doable if you have the manpower. The Doom 3 AAS code actually has stubs for a whole bunch of movement types, like jumping and crouching and so forth, which is left over from Quake 3 (D3's AAS is basically ripped straight from Q3). It doesn't actually work, but the enumeration values are there, and it could in theory be made to work. It's a bit more of pain without the full engine source code than it would be otherwise, but we do have enough access even with the SDK to hack around AAS limitations. That's how AI handling of doors and elevators (as seen here) works, for example. I can unequivocally state, however, that The Dark Mod will not have jumping and crouching AI on release. Or ladder-climbing AI for that matter (ladder climbing is actually a fair bit more complicated, as there are some nasty exploitable edge cases; search the forums if you're interested, there were some previous discussions on this). Unlike Ubisoft, we don't have the manpower.

Files in the directory override PK4s. The confusion may arise because Quake 3 did it the other way around. So in order to use PK4s vs. unzipped files for FM distribution, the mod assets would have to be in PK4 files and the FM assets would have to be unzipped. The fs_game_base thing definitely sounds promising though.

What I said earlier at http://forums.thedarkmod.com/index.php?showt...st&p=154037 about giving entities distinctive names before merging - you also need to change the model name on func static brushes else they don't appear, eg, search and replace "name" "func_static_ with "name" "func_static_IDX but also... search and replace "model" "func_static_ with "model" "func_static_IDX But this glitch also made it clear how much the sky reduces performance. Yikes - it's gotta go. Wonder if that is why I got good performance the other week in saintlucia?

Interesting. I didn't know about that. We do, but I didn't think it was possible without extracting the contents of the FM PK4. I'm happy to be proved wrong. Could we set fs_game to an "FMs" directory and fs_game_base to the main mod directory? Would that break anything? (Yay for having dev discussions on a public forum. )

I'd say fanmission makers should have ability to override TDM stuff. Maybe in DR there could be a command something like Check Resources Names (or some other...) which would look for same names in your pk4 and original TDM folders and would give you a list of name conflicts. It would be then up to mapper to ignore those which he wants to override or to change names of its own assets to avoid conflicts.

Do we have an access to the assets loading code? Could we give priority to the pk4 which contains currently loaded map?

BUMP I'm about to start making readable prefabs for use in the next release. We need to make a decision soon about where the body starts if there is no title. Just to sum up... Mappers will often struggle to squeeze all the text they want on to one page but often one page is better in-game, eg, a scroll or sheet of parchment. Posters and notices often need a title, eg WARNING! but most messages and letters do not. At present with the current guis, messages will waste the space reserved for the title; in RL probably a handwritten note will start near the top not 3/4ths of the way down and this will help the mapper get his text on one page. These are the four possibilities I know of: Remain as we are and waste the title space if not needed Duplicate every gui that is affected so some have no title space Move the body start point up to the top where the title starts. This will mean if there is no title then the message can use the whole page. If there IS a title then the mapper need only put a few \n\n\n\n at the start of his body message. This is easy to do for the mapper. It is fairly easy to change the guis - just alter a value. It will 'break' a few existing maps: A message with a title will have the body text overwritten on it and one without a title the body will start at the top whereas the mapper might have intended it to be centred vertically. Implement Gildoran's idea (above @ http://forums.thedarkmod.com/index.php?showt...t&p=147997) to have a conditional body position that will start higher automatically if there is no title. This will only 'break' existing maps insofar as body text without a title will start higher than the mapper expected. I could not get this idea to work as I recall but no doubt someone could figure out how to make it work? If this can be decided before the next release then there is no chance of readables in the release being 'broken' later.

That's not true for Doom 3. The unzipped files (outside the PK4s) override the ones in the PK4 archives.

I couldn't have said that any better. Oh wait, I did!! No, just kidding. You hit the problem on its head!! @Fidcal: Even if the file exists unzipped, the file in the pk4 has priority. It took me quite some frustrating time to notice that back in the old q3 editing days. I had my map pk3ed to sent it to a friend for testing purposes. Then I wanted to change some things but didn't see the proper effect ingame. That was really mean!! So do yourself a favor and delete those pk4s now if you test your map from time to time in that TDM install!!

T%he author will zip up the files and rename MyMission.zip to MyMision.pk4 and you'll need to download and place in correct folder. (I can't tell you what that is yet) For now you can run Doom3 and when it gives you the start game menu you will see a MODS button. If it was a doom mod it would start from there. Darkmod has it's own menus so it looks similar to Thief/Morrowind start up menu, there will be a FM selection.

thank you so much,sounds great i am just a fm player so the fms will have the .pk4 or does the person getting fm have to change it,i am not good at stuff like that

You do need D3. To make levels you would need the beta mappers stuff. To play levels you would need the FM AND the Darkmod stuff (not yet released) They will play thru Doom, so no you won't use Darkloader or Garrett loader. It's possible someone will make a loader when FM's become available, but it is unlikely it will be needed as Doom reads zip files (renamed .pk4) Thief did not read the zips, they needed unpacked.

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.

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.

As recently mentioned in the public forums, there is a small popup window appearing when loading a map: I need a design suggestion for this popup, maybe some small, centered parchment on the clock background or something. In principle, I can come up with something myself, but I better leave this to the artists for consistency reasons.

Btw, the progress is tracked here: http://forums.thedarkmod.com/index.php?showt...st&p=153102 Currently I am teaching the Games::D3::Parser to correctly parse material definition files. Once it can do this, it will be easy to extract the diffusemap/specular/bumpmap for each material and then figure out the DDS vs. TGA file from it. (That's the theory, anyway

Good question Ishtvan. That's certainly something we hadn't anticipated, and I think our coders should be reprimanded for not having their thinking caps on straight! We'll settle this issue in the private forums!!!!

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.

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

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 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've mostly used Cubase earlier, but have switched to Reason for it's midi capacities. I was wondering if any others use Reason, and maybe if you have any general or specific advices concerning making ambient music in this program? Let this be a thread for us (I presume there are more than me) who use Reason and who want to share our thoughts, tips and tricks about it with the other contributors/team members. Since I believe most people that make ambient music use Reason, I thought this thread justified in the DarkMod forums. One thing in particular I would like to know is recommended patches for bass ambience, like the one in 'Outside the Mansion' and 'Defiled Church'? I've tried a lot of patches, but can't find any that really has the right Thief-sound, not necessarily like in the aforementioned tracks mind you. (I may just be picky, but that's better than sloppy methinks) /K

So....how many of the changes I just finished making to the mesh two weeks ago are now obselete? http://forums.thedarkmod.com/index.php?s=&am...st&p=151102