Jump to content
The Dark Mod Forums

Tels

Member
  • Posts

    14984
  • Joined

  • Last visited

  • Days Won

    23

Posts posted by Tels

  1. Regarding the "jagged edge", what could help would be some sort of better "pre-computing" the shards:

     

    Make a difference between "internal shards" and "edge ones". The internal ones are only touching other shards, but not world or other geometry. That bit of information can be computed when the shards are computed.

     

    During the cracking, the shards can have different "stay in place" lifetimes. At the edge, a lot longer (they could even stay until you touch them), while the inner shards will fall away as soon as a neighbour shard falls.

     

    The effect could even be changed that one shard only falls if it is either the point of contact (initial shard), or connected to that shard (propagate the impact to neighbour shards). I think the current model is "every shard falls as soon as the pane breaks" and that is not only unrealistic, but also very performance heavy.

     

    If only the shards near the impact point would fall, you get much less physics engine strain, and the jagged edge, AND for bonus points you get the " play needs to clear out the glass" effect.

     

     

    As for the alert to AI: is there a reason to not always send out a "borken object" stim once the object is broken? Ok, in the currently algorithm the glass vanishes, so this is unrealistic, but if the shards only fell in "stages", the stim could be sent until all of them are gone.

  2. NagaHuntress, I'm still not being able to build TDM on my new system. So far the build progresses until:

     

     

    /usr/bin/ld: cannot find -lX11
    /usr/bin/ld: cannot find -lXext
    /usr/bin/ld: cannot find -lXxf86vm
    collect2: error: ld returned 1 exit status
    scons: *** [build/release/core/sys/scons/doom] Error 1
    scons: building terminated because of errors.
    

     

    Do you know what that might be?

  3. After some more investigation, I discovered that AIs were going dormant. While dormant, they stand still and just run their animations, and, as I've seen before, they won't collapse if KOed or killed while dormant. AIs that were immune to this were those that were tagged as never dormant.

     

    Investigating deeper into why they were being dormant, I found they were being set to dormant due to game thinking, that according to portal visibility, the AI and the player were in disconnected areas. From there the bug was found to be that the PVS wasn't allocate enough bytes for some optimisation tricks to work correctly.

     

    After fixing that bug (see attached patch attachicon.giftdm--pvs-bit-correctness-fix.txt ) AIs no longer stood still, they could now see the player properly, and the sky box was being drawn correctly. So apparently the root cause of the remaining bugs were the same.

     

    With that fix, my 64 bit version no longer has any known bugs. Soon I'll try to playing a good sized mission and see if I run into any more bugs.

     

     

    The other attached patch ( attachicon.giftdm--dormant-ko-death-fix.txt ) makes it so that AIs will collapse if they're KOed or killed while dormant due to being in a disconnected area. I'm undecided as to the value of this patch, as it doesn't affect players in normal play and will only be of interest to scripts that remotely kill/KO AIs in disconnected areas.

     

    The first patch is a very good find - if this opens up a 64bit version, that would be mighty cool. 64bit builds not only can access more memory and don't need 32bit compatibiity libs, but they can also use modern CPUs better - all of which are fantastic to have on Linux :)

     

    The second patch looks like it can never hurt and only do good, so I'd say it should go in.

  4. Okay, I've figured out why melee attacks with weapons aren't doing any damage. The root cause is that temporary object is being deleted before it's data is used.

     

    In function idAnim::CallFrameCommands() case FC_MELEE_ATTACK_START and FC_MELEE_PARRY_START have the following code for extracting weapon names and attack/parry names:

    const char *WeapName, *ParName;
    int spcind = command.string->Find(" ");
    WeapName = command.string->Left( spcind ).c_str();
    ParName = command.string->Mid( spcind+1, command.string->Length() );

    What happens is that Left() creates a temporary idStr, and WeapName stores a pointer to its C string. Because this string is short, it will use idStr's internal base buffer and not allocate anything from the heap. Then once line has finished excuting it deletes the temporary idStr, leaving WeapName with a stale pointer.

     

    On the next line Mid() then creates a new temporary idStr and AttName/ParName stores a pointer to its C string of that. This new temporary idStr reuses the storage for the previous temporary idStr. Because the storage is recycled, the two strings pointers (WeapName and AttName/ParName) point to the same string, which is what's meant to be in AttName/ParName.

     

    The end result is that WeapName doesn't name a weapon name, so the weapon look up fails and it can't do the actual weapon attack/parry, however, it still plays the animation.

     

    Whether or not this bug manifest depends upon when it deletes the temporary idStr for WeapName. If immediately it will bug with melee weapons having no effect, or if its deleted when the scope ends the bug won't happen. So ultimately its dependant on the compiler, and possibly it's optimisation options.

     

    Submitted to the bug tracker as #4199 with a patch to fix it.

     

    I looked at the patch, and it seems it just works around the issue by using different instructions. Should this really be fixed by removing the usage of c_str() everywhere (there might be a lot of other places the same happens), or should idStr be fixed to not return a pointer that later can get re-used?

     

  5. I'm in the Rhine-area near Koblenz/Bonn, and if the meeting is past the 10.9., I might join up - or even do some organisational stuff. Bevor that I'm unfortunately away traveling. Now I wish I had logged onto the forum a bit earler :)

     

    The Middle-rhine area is shock full of old towns and villages, the churches here are usually from 12xx or something, and there are a lot of really really cool locations, all about 50km from here. Airport Bonn/Cologne should bring the travelers from UK close enough, and there is also a good train service.

     

    It might be bit far from people from Chech, tho.

     

    Here is a bit of info in English:

     

    http://www.romantic-germany.info/Romantic-Rhine.4110.0.html

     

    https://en.wikipedia.org/wiki/Middle_Rhine

     

    As for drinking, aside from famous German beer, there is a lot of good quality wine produce in the area, especially in the Ahrtal and Mosel.

     

    I could offer accomodation for 2 or 3 people and there are also a lot (and I mean a lot) of cheap hostels and Bed & Breakfast locations in the area - the entire area is one gigantic tourist location :)

  6. It actually adds a lot to the atmosphere. I always found it a bit weird to see AI shadows, but not the players one in the game which doesn't have it. Btw, i could have sworn that in Splinter Cell Chaos Theory the AI sometimes actually reacts to seeing the players shadow. Not entirely sure if that's the case, but i sometimes wondered why i got noticed when sneaking up from behind. Didn't always happen though, so i'm not 100% sure if it's true.

     

    They probably hard-coded it for a few places. It's a surprisingly hard problem, either the game gets insanely difficult, or the effect is worthless.

     

    I'd too would love to see the player shadow getting fixed, tho. It adds to the athmosphere a lot when it looks correct.

  7. I'll think about access routes and sneaking into places when I'm walking around them, especially big complexes like office buildings, but just imagining it, like as fodder for a screenplay or game level.

     

    I do sometimes wonder at night, how hard would I to spot? Could I really hide in the shadows? Would my footsteps be heard?

     

    And of course one is much more aware of access routes. OTOH, I saw quite a few break-ins afterwards, and typical burglers don't care about ghosting, or getting in unseen or unheard - they take the quickest route in and out even if this means smashing in a window or dismantling a doorframe.

  8. Just bought it. You can write me off for this weekend! :D See ya on the othe side! ;-)

     

    Edit: Dang, one and a half hours downloading 30 Gb. :smith: Sad STiFU is sad!

     

    It would take me approx. 30 hours to download this. So shut up and play!

    • Like 1
  9. The compilation goes further if you install:

     

    libstdc++-4.9-dev:i386

     

    But then it stops again:

     

    cc1: warning: command line option ‘-fpermissive’ is valid for C++/ObjC++ but not for C

    In file included from /usr/include/png.h:540:0,

    from lib/devil/il_png.c:21:

    /usr/include/zlib.h:86:5: error: unknown type name ‘z_const’

    z_const Bytef *next_in; /* next input byte */

    ^

    /usr/include/zlib.h:86:19: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘*’ token

    z_const Bytef *next_in; /* next input byte */

    ^

    In file included from /usr/include/zlib.h:34:0,

    from /usr/include/png.h:540,

    from lib/devil/il_png.c:21:

    /usr/include/zlib.h:1025:29: error: unknown type name ‘z_const’

    typedef unsigned (*in_func) OF((void FAR *,

    ^

    /usr/include/zlib.h:1029:33: error: unknown type name ‘in_func’

    ZEXTERN int ZEXPORT inflateBack OF((z_streamp strm,

    ^

    In file included from /usr/include/png.h:540:0,

    from lib/devil/il_png.c:21:

    /usr/include/zlib.h:1349:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘Z_ARG’

    ZEXTERN int ZEXPORTVA gzprintf Z_ARG((gzFile file, const char *format, ...));

    ^

    /usr/include/zlib.h:1748:15: error: unknown type name ‘z_crc_t’

    ZEXTERN const z_crc_t FAR * ZEXPORT get_crc_table OF((void));

    ^

    /usr/include/zlib.h:1758:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘Z_ARG’

    ZEXTERN int ZEXPORTVA gzvprintf Z_ARG((gzFile file,

    ^

    scons: building `build/release/game/lib/devil/il_profiles.os' because it doesn't exist

    gcc -o build/release/game/lib/devil/il_profiles.os -c -fPIC -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -DXTHREADS -fno-strict-aliasing -DHAVE_CONFIG_H -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. -Iinclude/devil/IL lib/devil/il_profiles.c

    scons: *** [build/release/game/lib/devil/il_png.os] Error 1

    cc1: warning: command line option ‘-fpermissive’ is valid for C++/ObjC++ but not for C

    scons: building terminated because of errors.

  10. We're working on tweaking DMAP for 2.04 to speed it up by cutting down its console output. It's the console spam that makes DMAP take 4x as long when you have vsync turned on in the video settings. And even when you have vsync turned off, DMAP is significantly faster without the excessive console output.

     

    I'm hoping for some feedback from current mappers who use Windows (I don't know how to compile for Linux, sorry).

    I'd like to try it in Linux, unfortunataly, it doesn't compile here anymore. Is there anyone still testing TDM on Linux?

  11. It's a teaser trailer. A teaser for the trailer. That's common these days, no idea why.

     

    The attention span shortens every... oh look, shiny!

    • Like 2
×
×
  • Create New...