stgatilov

Wow... I've seen exactly this candle from the training mission flickering! So this is not linux problem, this is some change from update 1.03.

I measured the time from pressing "+" (quicksave key) to the moment screen unfreezes. So this is not just writing, but the whole saving process. This text is not code comments. I think it is something like description of objects from DarkRadiant. I can try to understand what is it, but TDM team knows it much better anyway. It may be difficult and tedious to eliminate it. Though I hope it is not difficult... But compression is completely orthogonal to saving process anyway:). P.S. Should I post to "I want to help" forum?...

Yeah!!! I finally made it! The savegame files are written compressed now (reading is not done though ). I use CRenderPipe to create a pipe. This pipe is passed to idSaveGame for writing. I also create another thread which constantly reads from this pipe and stacks the data into std::vector. After all the game saving is done, I compress the resulting std::vector with zlib's compress and write the result to idFile *f parameter which is the read destination file. So conceptually it is: dump the whole savegame to memory, compress that memory, write it to file. The results are the following: Uncompressed save: 87Mb size, 7 seconds time. Compressed save: 4.4 Mb size, 2.5 seconds time. So writing compressed savefile is MUCH faster than uncompressed. Even if we compress the whole save file at once. The question is: what to do next? The way I use CRenderPipe now is weird I'm afraid that all this mess simply won't work on linux implementation. I think it's better to create some common named pipe class. Then use it in compressed saving/loading. CRenderPipe serves a specific purpose which is not enough for saving/loading.

I feel the same way. It is very arguable that compression will increase save/load time. Maybe it will decrease it. Right now I'm trying to use CRenderPipe for intercepting the savegame data...

I personally don't like 80Mb savegame files They contain a lot of redundant information. It is like a dump of gamestate... They can be packed easily. For example, after compressing with standard gzip savegames become about 20x smaller in size. Player has do it himself if he doesn't want to store Gigs of saves on hard drive. How about compressing/decompressing savefile "on the fly"? Just chain save/load file streams with some zlib stuff. I hope that it won't slow saving/loading too much. I decided to try implementing it myself. I downloaded new 1.03 code and looked how saving is done. The problem is: all the data of savegame is written to idFile *f which is passed to idGameLocal::SaveGame from closed piece of Doom3 source. The implementations of all idFile classes are also closed. So there is now way to insert compression inside idFile. So I switched to another idea: write savegame to memory buffer, then compress it and dump results to idFile parameter. Luckily there is idFile_Memory class which seems to do what I need: store everything that is written to it to memory buffer. The problem is: though I see idFile_Memory declaration I cannot create this object. I cannot reference constructors (undefined symbol). And I cannot find method for creating memory file in idFileSystem. So there is declaration of class idFile_Memory but no way to access it . After some googling I found this version of filesystem.h. It contains method OpenMemoryFile which creates idFile_Memory. This address is referenced here in ET:QW forums, so I guess it is from Quake4 SDK. Has developers fogrotten to open access to Memory files in Doom 3 SDK? Is there any simple way to use idFile_Memory? If the idFile_Memory is not usable, then the only proper way to implement on-the-fly compression is to create my own class with idFile interface. But in this case I'll have to implement all the bunch of functions idFile has for writing different types of data. I'll have to rewrite piece of closed Doom3 source... Maybe someone knows how to solve the problem? Or he has any suggestions about savefile compression? Why is it not implemented yet? Anyone except me wants to see automatic savegame compression?

It is a very important idea, it should be written down: Be sure to post some screenshots from a zombie mission on moddb the next year. The more frightening the better. Maybe it will force people to look TDM at least

This minor issue was already discussed here. But still... The savegames are very large and contain some strange unnecessary information (there is some text that looks like DarkRadiant docs... what is it doing in saves?!). Perhaps some data should not be written to the saves. But the easiest way to greatly reduce the size of saves is to zip them. I know that all the necessary zip libraries are already used in TDM code. The idea is quite simple: pack the whole FM directory when uninstalling mission and unpack it while installing if required. Maybe someone knows another ways of solving the problem? What are the plans of the TDM team about saves? (And of course this is not very important... )

This mission is completely nonlinear! The space is rather small and compact but it is all filled up. At the beginning it is even difficult to choose where to go There are many places that have no loot and no items. It makes the proper feeling that money isn't lying around in every corner. There is a room on the first floor of the hotel with two books. One of them has three pages. But the last page has a bent corner representing that it is not last. When I scroll to the next page the book closes automatically. What's wrong with this book? Scrolling through the last page causes the readable system to mess up a bit. After that I frob the another book in the room (which is OK) once - it opens. Then I hit frob again - it reopens without closing. After each frob while reading it the new instance is created and the old ones doesn't disappear.

As far as I understand, adding HDR will not affect anything axcept what you see on your screen. The gameplay will be the same. The lightgem value will be computed on CPU and will be the same with and without HDR. So the conditions in which the guard sees you does not depend on HDR because HDR won't affect internal calculations (AI and illumination of player are part of them). Ghostable mission will remain ghostable by same manipulations, and inghostable mission will remain inghostable. The following things should be handled carefully: The look of the lightgem will be changed. If you enter a darker room, then the overall brightness will decrease, and the autoexposure will make everything including the lightgem look more bright. Moreover, the look of the lightgem will change after simply turning your face to a dark corner without any movement. So the lightgem look will be messed in some way. I don't know for good of for bad . Anyway, I think that lightgem can be handled separately from the other scene, so its behaviour with autoexposure can be fixed to whatever you like... Another thing is the autoexposure principle itself. In the training mission there is a guide how to set gamma and brightness settings to get visually standard image. The thief spends a lot of time in shadows. And he shouldn't see anything in a very dark room. So the autoexposure should be introduced very carefully: the exposure adaptiveness should be bounded somehow. Because of the performance loss some players will have to play without HDR while others will turn HDR on. So the players will get conceptually different pictures in the same level (the brightness/contrast levels will be different) with and without HDR. (Please correct me if I'm wrong somewhere) P.S: The pictures are great. And the light is more important in thief game than in any other. I would be very pleased to see HDR in The Dark Mod.

This would greatly increase difficulty in this mission, but overally it is good. As for me guards' ability to relight torches is much worse that the potential ability to turn the lights on: you spend water arrows (limited supply) on torches but you can push the button infinitely many times. I use water arrows very seldom in TDM because I know that any guard passing by can easily restore the light. By the way, can any guard relight the torches or mapper can restrict a guard not to do so?

Well, I won't say that the mission is easy. I decided to go on apprentice (not fond of ghosting) in "KO them all" style. That torch guys are the real problem! I forgot to hid the bodies from them and soon I got to the situation: Two thoughts came to my mind: The place is guarded really well. So many guards want me dead.Where is my GRENADE LAUNCHER?!!I spent a lot of time hiding behind those crates. I realized how beatiful the night sky was! I noticed a bug in the my mission complete stats screen: "bodies found: 0" is a VERY wrong statement . They found bodies rather often and I am absolutely sure that I didn't quickload after that. By the way: The guards are clever enough to relight the torches. But I've never seen them turning the lamps on. It is not good that the guards patrol dark rooms after I turn off the light. Maybe the difficulty levels should be like this: Easy: killing is allowed + plenty of broadheads (just shoot them all).Medium: no killing restriction.Hard: no KOs + (optional) ghosting.There is no clear necessity in KO restriction in this mission (at least nothing was said about it in briefing). "no KO style" is just an act of "increased thief's coolness". Thanks for the mission! I really liked it. Maybe now when I know the way in I'll play through it on ghost.

Yo-ho-ho! TDM is in the best 100! Voted for it again. Now I know there is a Deus Ex mod... Already downloading Maybe I'll share my vote between Dark and Nameless.

Know what?! I changed Error to Warning in FreeCurrentPVS in pvs.cpp and rebuilt. I was almost sure that this won't give me anything as the problem is in Doom3.exe and not in gamex86.dll (or I don't understand the DLL system...). The crash is gone. The corrupted sessions are terminated more or less correctly (at least without a crash). Save/load works OK. I've finished the trapped mission from corrupted save and seen the mission completition statistics. I know that this kind of "fix" is just running away from some stability problem (memory leak or corruption maybe). But I prefer using the gamex86.dll with this hack.

I am interested in the arrow flight problem I read wikipedia about lift force and air drag. I tried to model the arrow in 2D affected by two forces: 1. gravity: F = g*m; directed downwards applied to center of masses 2. lift force: F = kl*V*V*sin(a)); directed orthogonal to arrow direction directed upwards related to arrow when a>0, downwards when a<0 applied to the tail of arrow a - signed difference between arrow angle and velocity angle. For example of the arrow flies horizontally but is oriented 5 degrees upwards, then a is equal to 5 degrees. There is another type of drag: 3. parasite drag (assuming turbulences): F = kp*V*V*(sin(a) + C); directed opposite to velocity direction the application point does not matter But parasite drag will just lower the arrow velocity. So it is not as interesting as the lift force is. I used kp=0 (no parasite drag at all). Maybe the drag for arrow in TDM should be lowered? It will eliminate the feeling of arrow falling like a cannonball in a far shot. There is no need for big air drag for arrows I think. Well, about the results 1. Even with very small coefficient kl the arrow direction is naturally aligned to velocity direction. This is because any difference in angles (variable a) creates momentum which returns arrow direction to normal state (near a=0). By the way, how is it implemented now in TDM? What makes the arrow direction to be the same as velocity direction? If the only force is gravity, then arrow orientation will never change at all. 3. All the other stats are the nearly the same with lift drag and without it. I wanted the arrow to save height for longer time. But now I'm not certain this effect appears in the real life. EDIT: I've launched the training mission and played a bit with archery. I feel that the arrow flies well and nothing should be changed Anyway, shooting too far is very rare event in TDM gameplay.

I ran TDM in the debug mode and caught exception with the same stacktrace as reported by Haplo. The interesting thing about FreeCurrentPVS error: it is a well-known problem of quake4 servers. Google leads to: http://www.quake3wor...hp?f=17&t=22693 http://www.q4max.com...opic.php?p=6128 And q4max even introduced some sort of "solution": fix: (RB) "FreeCurrentPVS: invalid handle" server errors. Error reduced to a warning, code protected so that it cannot do any harm, and causes of calling FreeCurrentPVS with an invalid handle corrected. (from http://www.q4max.com/changelog/ ) As far as I understand they simply ignored this assert

I replayed the mission on easy without loading at all (like Diablo 2 hardcore). It was a bloody mess... 4 guards killed, 5 KOed. Hungry thief fell into RAGE! Though two of the guards were killed just for archery training Only the third attempt was successful. The first attempt failed: I was caught in the dining room. A cook alerted two guards and they started searching the area. When they were done they tried to return to their duties. And they got stuck between dining room and library. I threw some junk at them, they got realerted but they didn't come away. This problem (several guards get stuck in a narrow passage) should be dealt with. Don't know how though... The second attempt failed because I tried to blackjack a sleeping guard. Don't know the purpose of doing that . Always did it in original thief with no problem. But here I failed.

You can ask player to bring the body up the stairs. I think without shouldering it is nearly impossible: the bodies are to heavy to lift up. Though if a player tries hard he will do it... If the height of each step in the staircase is near 1/3 of player height (gigantic steps) it would be really impossible to pull it up. The correct way is [shoulder the body + throw it on the next step] repeat.

The game crashes when you press quickload while already running a corrupted game. More precisely: the game crashes when it tries to destroy a corrupted game session. I think he means loading the corrupted save from fresh TDM game. Maybe you mean megabytes?

How could a Master Thief finish like this? He sold his sword, lantern, compass, ... and even BLACKJACK! Seems like the economic crysis happened in the city: there are too few rich people to steal from. The issues: These are all minor issues of course. I should have chosen "medium" diffuculty instead of "difficult" I think. There are a lot of very well hidden secrets in the mission to search. I like searching the place up when all the guards are KOed . But when the guards are in place it is much more tiresome to do the third-fifth patrol through... About secrets/objectives/loot and etc: I noticed the guards with swords can throw a bottle or the like at you if they cannot reach you. I saw how one of the two alerted guards threw a bottle at the obstacle that was too close to them and hit another guard. As the result they started fighting each other. The duel was quite spectacular... After some fencing the guards who lose started running away But eventually he was caught and executed. Overally, The mission is very thief-like. And very challengeful!

Thank you very much for this mission! Thief without weapons is much more intensive and scary than just hitting heads with blackjack. The only minor issue I've seen is the one already mentioned by SneakyJack in his review: Two guards got stuck facing each other. It happened at the upper floor in the room where blackjack was. I had to make big noise to return them to the patrol.

I have encountered the issue #1. At the beginning of the mission quicksaving/loading works correctly. All the saves produced are "fine". But after some moment the savegame becomes "corrupted". After loading such a "corrupted" savegame: I can play the mission as long as I want, nothing strange happens.Saving the game works OK (but the produced saves are "corrupted" in the same way).When I try to quickload TDM crashes immediately (Visual Studio catches some exception). When I try to load a save which is "fine" it also crashes. When I try to quit mission it crashes. And when I win the mission it also crashes without showing stats screen or win movie."Corrupted" quicksave can always be loaded from fresh TDM successfully. They can also be loaded after loading some "fine" savegames.The .save file size is as the same (20-22Mb) for both "fine" and "corrupted" saves.So the problem is most likely in finishing game session. And this problem survives save + restart + load. Now I have this problem in map: "Trapped!". Also seen the same problem in the other map. In the first map I solved the problem by loading the last "fine" savegame and playing from it. In the "Trapped!" I decided to finish the mission without unnecessary loading... I do not know what pushes the savegame into the "corrupted" state. This bug is very annoying since after catching it each loadgame requires TDM restarting (which is very slow). And it is very sneaky because you understand that the game is corrupted only at the first quickload after corruption. And this bug can really spoil the fun for those who maintains only one save file (for example who often quicksaves but never does ordinary save).

Bravo! Great map, I liked it so much. The story is great! It is very difficult to predict at the beginning of the mission what is going on. Eventually you find out that everything is interconnected. The ambient sounds are very cool! The finale is performed thrillingly! I understand that walkthrough is very linear (bacause of key locations + triggers). But this is the only way to ensure the correct order of information gathered. The only strange thing I noticed is how movable objects are placed on the tables. When I try to take a candle from the table it jumps down through the table it is standing on and hangs in that state intersecting with the table in its middle.