Search the Community

Yeah, minimizing quake 3 wasn't possible without an additive tool. But in the early version of Doom 3 it was like that too I think. At least I tried to switch to the "doom 3 advanced graphics mod" readmefile while ingame to check for other commands and it didn't work, so I thought to myself "Id-software crap again" ... I guess they have fixed this issue with an update. Wow, I am really suprised. First they altered pk4 handling and now this... =)

Well, the strange thing is that the animations actually *work*, already. I was under the impression that you would not be able to export the animations if the number of joints don't match up. I think I recall Ascottk saying something about the Maya export culling out joints that aren't used, and that you have to use a -keep option when exporting? But again, I would have expected the animations to not work, and they clearly do, so I'm not sure whether there's actually a problem here or not. I'm pretty sure I can get the beggar working as is...I just have to find the verts that are weighted to joints that exist only on the citywatch and delete them from the beggar. But I don't want to do that if it's going to cause problems in the future (there aren't very many verts though, just 8-10). edit: Is this related to a recent change? http://forums.thedarkmod.com/index.php?showtopic=7856 I'll return the thief to it's current state so things work.

Putting to many PK4s into the directory is not a good idea anyway, as there potentially will be nameclashes. Each set of PK4 should eb an individual mission, and as such it should be in the directory, but not more.

If you only knew. We're definitely making constant progress, the internal forums are quite busy at all times.

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.

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?

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.

I've uploaded a new pk4 to svn. Lean is now a hold, rather than a toggle. Still a bit buggy, though, if you quickly press and release the button.

You mean a new hud.gui in the unzipped folders? The pk4 with the map within it should definitely overwrite the one in the unzipped folders. I can't test that right now though, my system is in a ...state of dismemberment.

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?

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.

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?

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.

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

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.

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.