stgatilov

The "peculiar lenses" don't work for me. Neither the ones I bought, nor the second ones I found in some tower. Every CInventoryItem (C++ object) stores pointer to entity in m_Item. In my case, this pointer is dead, i.e. it points to an entity which was removed some time ago. I guess for the glasses to work, it should point to the "atdm:xray_glasses" entity. The reason why it works for some people is either because the glasses don't die for them, or because they die but not completely and no other entity created afterwards takes its entity number. So the main question is: who kills the glasses entity and why? UPDATE: Just to add some more detail. I think I'm playing clean latest version with latest TDM beta. I got lost pretty quickly, so I completed all the objectives and explored most of the map first. Then I returned to the starting area and went to buy a sword. There I noticed the glasses, bought them and tried to use them instantly: they did not work. Then I explored some more and found second glasses in the tower + a piece of advice to use them. Now I have two items, but they don't work anyway.

beta212-06 is released.

This case in Poets and Peasants is something new: In this case we have on same line: light brush wall fully closed room closed door with visportal in a brush wall player Since only backfaces cast shadows, only the door and the first brush wall can cast shadows. The brush wall does not cast shadows because the entirety of its area is unreachable by light. So the door should. It turns out that all doors that are connected to visportal should automatically get this "forceShadowBehindOpaque" flag. When the door is closed, it closes the visportal and thus becomes part of the wall, just like a brush would be in its place.

Some GUIs use some kind of pseudographics. Reducing the spacing also breaks such readables.

Ok, here is the source of the goddamn precision issue: static void WriteFloat( idFile *f, float v ) { if ( idMath::Fabs(v - idMath::Round(v)) < 0.001 ) { f->WriteFloatString( "%i ", (int)idMath::Round(v) ); } else { f->WriteFloatString( "%f ", v ); } } I guess I'll never stop finding more weird tolerance stuff in this codebase Anyway, I'll fix this after 2.12: never know the consequences. UPDATE: Here is issue in bugtracker 6480

I looked closer at the problem in Dragon's Claw, and this is caused by some kind of precision issue in dmap. The .proc file contains imprecise BSP plane: /* node 18377 */ ( 0.0399680398 1 0 1202.8780517578 ) -38 18378 And also there is a visportal stored there: /* iap 62 */ 4 37 50 ( -96 -1200 -488 ) ( 304 -1216 -488 ) ( 304 -1216 300 ) ( -96 -1200 300 ) The game loads the visportal polygon and computes portal plane from it, which is: plane (a=-0.0399680398, b=-0.999200940, c=0.00000000, d=-1202.87805) As you see, the plane normals are different by 0.2%. The visportal plane computed from polygon is almost perfectly unit, but the BSP plane is not unit (length slightly greater than unit). This makes the game think it is on the left of visportal in one place, but on the right of visportal in another place. I tried to re-dmap but the data is the same. I'll try to see what is going on. Indeed, making the portal axis-aligned would have most likely fixed the issue.

I can reproduce this one. Enable noclip and execute: "setviewpos 207 -1212 -408". Tiny movement by Y and you get proper view, but here exactly at visportal it gets closed. @Daft Mugi, does it look like the issue you have? I bet it does not.

I tried to debug this. It turns out that "global variables" includes all immediate values (including string literals which take 128 bytes each) and all global function declarations (4 byte per function, including even engine events). I see 119240 bytes before starting Iris, and 124924 bytes after starting it. On Bakery Job, I see 109680 before starting game, 109700 bytes after starting it. So It seems that core game takes about 110K, but Iris itself takes only about 10K, and the limit is at 196K. Does not sound like a big problem for missions. With addons, you have to compile all of them at once, and perhaps there is a lot of code, so you reach the limit. Ok, let's double MAX_GLOBALS for 2.12.

This is total size of all global variables. Here are the limits: #define MAX_STRING_LEN 128 #define MAX_GLOBALS 196608 // in bytes #define MAX_FUNCS 3072 #define MAX_STATEMENTS 81920 // statement_t - 18 bytes last I checked I suppose everything except for MAX_STRING_LEN can be raised. Perhaps create an issue for 2.13?

Unless we add some special subdirectory for addons, I'm afraid they look like core files. And having duplicate decl file in core assets is a problem worth complaining about. Also it might be a bit uncertain which decl wins in the end in such situation.

Antialiasing mostly affects some backend logic, while the commit changed data structures in frontend. It is very hard to believe they are linked in any way. Maybe the bug is not reliably reproducible? Maybe antialiasing is an important condition when it happens, but otherwise it is timing-specific, so accelerating frontend made it pop up. Or maybe antialiasing is just one way to slow gown backend and using maximum soft shadow quality or r_fboResolution 2 would make it happen too. Maybe the particular behavior is driver-dependent (e.g. NVIDIA masks the error away). Which GPU do you have? Which drivers do you use? Which CPU do you have BTW? I cannot reproduce it myself, even on Linux VM. Does it happen in the very specific viewpos and goes away if you move away slightly? Maybe someone else can reproduce it?

I deleted double-slashes in svn rev 16957. I think they were causing the issue. I believe it only happens on Linux, Windows side somehow reduces the double-slash to single directory separator.

Yeah, I wanted to implement some kind of testing framework on top of automation but did not.

I think the game treats everything inside "fms" as "mission assets", and everything in game root directory as "core assets". You can check it at the start of game console, where all the paths are listed.

I committed a fix in svn rev 10636. Let's hope it does not break something else in player movement.

I opened DarkRadiant and am now trying to understand how the sun lights were supposed to work. No idea thus far. Looks like an awful experiment with massive caulk overuse.

Does it happen if you disable Frontend Acceleration and set com_smp to 0 (don't forget to restore it back afterwards)? Does it happens with clean config (i.e. after deleting darkmod.cfg) ?

Do you realize that the original code is wrong? In fact, it has been wrong since revision 2, i.e. since the very beginning. Absolutely no reason to do anything special for one platform.

I added it to this article.

You can run listEntities *conversation_info* if this is part of the name. I'm not sure how it works, but I know it works when you want to filter by substring

beta212-05 is released.

Is it reproducible? Does it go away if you disable "Frontend Acceleration" ?

And yes, tweaking shaders is fast and easy, and has immediate effect, thus there are many people who do that. I believe we also had some external guy recently who did the same in "Want to Help" section. Maybe we should just add these shader tweaks into addon managers and allow people switch between them as they like? Just like people can install a program (don't remember its name) and add postprocessing like FXAA to any game.

I feel that tweaking shaders visually does more harm than good in the end. Here is one example of what shader tweaking leads to, and where I'll do yet another visually-breaking change: 6354 Before that is was untweakable specular which also broke visuals: 5044 What a game engine needs is a universal model (preferably well-known) with several tweakable parameters. In fact, the very idea of PBR and why it wins today is that it models real physics, and thus it works more or less the same way in every engine and scenario. It is a well-known standard (with minor variations). We can't have PBR yet (and maybe forever), thus we stick close to Phong reflection model, which has been around for decades and is also quite standard. Artists should make assets that would result in a beautiful picture, not shaders. But they can't do it if we have some weird non-standard lighting model which changes every year. We should never tweak shaders based on how average missions becomes seemingly nicer to us! If someone decides to add normal mapping, it should behave as an approximation for how real high-resolution surface should behave in our model, not as some kind of "beautifier effect". If you want to add some effect which is outside the current model, it should be done in a way that: it does not change how the previous model works (and how current missions look) it can be tweaked by understandable parameters it is applied in all shaders and all lighting the same way I believe we already have fresnel and rim, but it is kinda hardcoded and not present in all shaders. Yet another result of someone tweaking shaders based on how it looks and not on how sound it is mathematically.

Work find for me on latest SVN. I don't remember anything that could break it.