Search the Community

I got Gothic 3 recently and I am completely satisfied with it gameplay wise except with a few things. But it really looks like the good old Gothic with not too much added. Except the combat system is weird and dumb at the moment, I hope they patch it up. Too much FedEx quests. And the stupid lensflare effect, thanks to fans that removed it. They really messed it up with the graphic settings. First I wasn't able to play it because I only had 1 Gb of Ram. Well, I was, but it barely worked. Then we bought up to 3 Gb (my dad uses Photoshop). I loaded it at low settings, it ran OK but it was somewhat jerky in a weird way, and didn't look well, of course. My config is Radeon X850/X800, Pentium D Dual Core 2.8 Ghz. Worked OK for Oblivion, so I was a bit unsatisfied. I played like this for a while, with all the jerkyness. Then I wanted to have a laugh and put everything except AA and DoF to max. So I load the game... it works with absolutely the same speed as it did with the low settings. Then I put AA up to x16. Same thing. I even had the impression the game went smoother... anyway, on my system it doesn't seem to matter what settings I put. It slows down the same way in any situation. The only thing that seemed to matter is the vegetation and view distance of it (can be changed in g3.ini). It made the game a bit slower. Some guys on IXBT said something about the Gothic 3 programmers messing up the memory. They say that textures loaded in the memory become lost and have to be loaded back again, and that is where the jerkyness comes from. The game looks gorgeous, though (in my opinion). Since it is an RPG I don't need a high speed so I just play at max - FoD... Technically it is worse than Oblivion, but Oblivion always had that very slender and smooth look, so now I preffer Gothic 3. It always rooked a bit jagged but for some reason I consider that more realistic and immersive.

There is also a thread at TTLG: http://www.ttlg.com/forums/showthread.php?t=121677 The whole thing is absolutely mind-boggling.

Yep, though I assumed he was the same height always: http://forums.thedarkmod.com/index.php?s=&am...st&p=153690 Don't know when exactly this may have happened but it's been this way a while now.

OK, the first part of the new filtersystem is implemented. Texture filters can be specified in the game file, are available in the Filter menu and are used by the Model Selector to hide surfaces (this enables models with collision hulls to be viewed properly). Still to implement are entity and object-based filters, and the conversion of brush, patch and entity render code to use the new filtersystem (which is expected to be a large task).

No I run it under Windows. I found the problem now. It happens when I'm running it in 1600x1024 mode. When I run it in 1024x768 it works. And I downloaded on patch and installed it.

Not sure what's goign on there. BG has always been perfectly stable for me, in fact, I can never remember it crashing at all, and I've played it for at least 1000 hours. Have you downloaded the lastest patch for it? http://www.bioware.com/games/shadows_amn/support/patches/ I assume you're running it on some sort of windows emulator for linux?

Well a clean-sweep of the FilterSystem turns out to be too complex, unsurprisingly since the interface is used all over the application. This will have to be an extend-migrate-remove job, with two filter systems in use for a while. I think I will proceed as follows: 1. Extend the FilterSystem interface to provide the required new methods. 2. Add a top-level "Filter" menu, which is populated by the FilterSystem implementation. 3. Get the FilterSystem using its rules, and add functionality to the ModelSelector preview to query for texture filters. 4. Migrate Brush, Patch and Entity code to use the new FilterSystem. 5. Remove old FilterSystem I wonder if it would also be a good opportunity to move the FilterSystem into its own DLL - theoretically anything that uses a Module interface can be in a separate binary, which might reduce build times.

are you MageofFolenn on Black Cat Forums? B/c if you aren't, you must be soul-mates, or long lost twins or something.

I am perma banned on Black Cat Games forums for raging and also I was framed by some ppl so better not to tell anyone anything. Lest ye wish to unleash Ragnarok once more.

Another note I found intriguing: "Players who have the Windows security update KB917422 installed may suffer from an application error when running Battlefield 2142. This error can be solved by uninstalling the KB917422 update. " So you have to uninstall a critical Windows security patch in order to play

I'm sure some sort of third party patch will eventually come out that will disable the advertising and privacy intrusion "features", but until then I'm not buying into 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.

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.

Combat is a pretty large task, and IMO we should have a more unified design for how melee combat will work before we work on specific parts of it, otherwise they may have to be redone if the overall combat design changes. One small, slef-contained task would be flash bombs. Step 1 would be the weapon script (kind've like the D3 grenades), and step 2. would be their effect on the AI (set their visual acuity to 0 basically, and maybe create a new AI state variable for being blinded so that the AI script can later start a new "blinded" behavior state, that would come later). Then there's the effect on the player. Another small task might be functioning moss arrows. We have the code to detect a moss surface and play no sound when the player steps on it, but we need the moss arrow to actually create those moss surfaces, by spawning some blobs of moss that fall down and stick to the floor (maybe when they stick to the floor, they could spawn flat, thin "moss patch" models that would be textured with the moss surface). We also want the moss arrow to have some secondary uses in the future, but that should be fine for now.

I can't get the verts to line up with the bevels. Is there an easier way to do this?? Are there any tutorials? EDIT: Nevermind, it was very easy. I was on the right track originally, but I made a 3x9 patch mesh, when I should have just made a 3x3 one and made a 90 degree angle with the verts.

Ok, I will go through the class and look where I can add the const. edit: I added some const qualifiers to most of the strings, should be better now. The patch is already in your inbox. Wouldn't it be easier if I directly sent this into SVN? Not that I plan to go an a SVN rampage as soon as I have access - I can ask you for permission before I commit anything, so that you can still control the commits. I'm currently working on outsourcing the toolbar icons to an XML file so that it is a bit more customisable. At the moment the icons are added to the GTKToolbar in mainframe.cpp line after line. I had something like this in mind: <?xml version="1.0"?> <project version="2.0"/> <toolbardescription> <settings> <!-- future settings go here --> </settings> <toolbars> <toolbar name="basic"> <item type="icon" caption="Open an existing map" bitmap="file_open.bmp" command="OpenMap" /> <item type="icon" caption="Save the active map" bitmap="file_save.bmp" command="SaveMap" /> <item type="spacer" /> <item type="icon" caption="x-axis Flip" bitmap="brush_flipx.bmp" command="MirrorSelectionX" /> </toolbar> </toolbars> </toolbardescription> What do you think? (Should I open a new thread for this?)

I tried a few but I'm afraid I will have to use google. The changed files are on their way, I manually figured out which ones have been changed. Just a line in sconscript, and a few changed files in libs/parser and plugins/shaders. edit: found it, it's "create patch". This creates some unified diff file with all the changes. Next time...

Nonsense, I've played it through about 15 times and never had any problems with dead ends or wishing I'd made separate saves eariler. What specifically went wrong with your game? Of course there have been various patches released, so install ToB and get the lastest ToB patch.

Not really, a manual merge is the only real way to do this. Fortunately SVN makes it very easy to get a repository-wide diff of each revision, and using patch on Linux I can merge in changes without too much effort. Obviously this will get harder as the two codebases tend to separate, and patches for GTKRadiant will no longer work - fortunately most upstream fixes are irrelevant to DarkRadiant (like enhancements for Enemy Territory support, or bugfixes in code that I have already replaced) so this won't be too much of a problem. The "enhanced texturebrowser" functionality is similar to what I was intending for the media browser, except that it limits space by combining the tree and the texture view in a single window, and also only allows single-level browsing of texture "families".

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

For some reason patches that intersect brushes cause the brushes to be subdivided in this way. I have no idea why this is, as it doesn't appear to me to provide any performance benefit over leaving the brush face whole. The solution is to convert the patch into a func_static entity to remove it from the worldspawn and stop it from subdividing brushes.