Jump to content

fau

Members
  • Posts

    20
  • Joined

  • Last visited

Posts posted by fau

  1. Try increasing values of Q_irand(), or replace them with constants in milliseconds in g_combat.c:LimbThink()

                    if ( level.time > ent->s.apos.trTime + ent->s.apos.trDuration )
                    {
                            if (ent->owner && ent->owner->m_pVehicle)
                            {
                                    ent->nextthink = level.time + Q_irand( 10000, 15000 );
                            }
                            else
                            {
                                    ent->nextthink = level.time + Q_irand( 5000, 15000 );
                            }
    
                            ent->e_ThinkFunc = thinkF_G_FreeEntity;
                            //FIXME: these keep drawing for a frame or so after being freed?!  See them lerp to origin of world...              
                    }
    
    
  2. This part in g_combat.c:G_Dismember()

            G_SetOrigin( limb, newPoint );
            VectorCopy( newPoint, limb->s.pos.trBase );
            limb->think = LimbThink;
            limb->touch = LimbTouch;
            limb->speed = level.time + Q_irand(8000, 16000);
            limb->nextthink = level.time + FRAMETIME;
    

    limb->speed is time when a limb will disappear.

  3. Nice catch - though, of course, inside SaberBlock() there are multiple calls to rand(), so that doesn't quite work out the way you said.

     

    Sure, as I wrote, this was an over-dramatized example :-)

    The saber combat works great and as a player I join all other people in this thread – thank you for my favorite saber combat system and game!

     

    I believe that the probabilities of various randomized things happening are not what they look like when reading the code due to correlations of rand() values. I don't have hard data to support it but I'm gonna collect it. Mods can unintentionally change these correlations by adding, removing or rearranging rand() calls and this is something to look out for and something that may hopefully explain different feeling of different mods in JK2.

     

    Footnote: Doesn't apply to JKA because it uses correctly implemented rand() procedures. Gonna add it to all my posts so people don't get wrong ideas.

    Smoo and MGummelt like this
  4. Let me explain this more in depth (concerns only JK2)

    Current JK2 QVM rand() implementation uses a linear congruential generator algorithm and returns LOWEST bits of calculated value:

    int rand( void ) {
        randSeed = (69069 * randSeed + 1);
        return randSeed & 0x7fff;
    }
    

    Unfortunately lowest bits have very short periods - at most 2^n for nth bit. For example subsequent (rand() & 1) calls yield (1, 0, 1, 0, 1, 0…) sequence. Now consider this simplified code example:

    if (rand() & 1) {
        SaberBlock();
        if (rand() & 1) {
            SaberParry();
        }
    }
    

    Of course SaberParry() never actually happens, despite the developer's intent. This is simplified and over-dramatized, but this type of unintended correlations surely exist in JK2 code due to this rand() implementation. Also consider that players who've never seen the code are aware that parry never happens right after block. One could say that they "recognize pattern" (although here it's just a dead code, you can imagine more complex and not 0/1 correlations).

     

    Now examine same code segment in a mod:

    if (rand() & 1) {
        SaberBlock();
        saberColor = rand();
        if (rand() & 1) {
            SaberParry();
        }
    }
    

    The situation changes diametrically even though a mod developer thought he wasn't altering block/parry behaviour.

  5. Ah yes, but not susceptible to being problematic like the ones that are inconsistent using the RandFloat function atop that file which is for deflecting and pushing projectiles away.

     

    The idea was that internal PRNG implementation was very weak and consecutive call could produce recognizable sequences regardless of current seed value, but now I see that it was fixed in Jedi Academy code, so this kind of falls. At least for JA. Still going to collect some data on JK2 and check this hypothesis.

     

    Mostly you'd just want to see what the assembly output looks like and the floats in real time and where they seem to drop off

     

    Maybe this is what you'd want to do for JA, but as I explained in JK2 it's not the issue and there are perceived mod discrepancies too. I'm personally interested in JK2 case, just hoping the core reason may be the same in both games.

  6. The original codebase obviously would still compile with those (if you wanted to have that crappy of a vs version, nobody wants to, its too old) OpenJK will not compile with < 2013 as of last year.

     

    Hmm fine. I didn't have using some ancient msvc for modern mods in mind, rather using it as a tool to find out where lies the difference. Eh, I feel like it's gonna stay a mystery forever (at least for those who don't believe it to be placebo). I have some new-found hopes regarding this PRNG but if it's not it then I ran out of ideas. Gonna spend the rest of my days trying to prove it's a placebo =)

  7. We've known about the icc compiler for linux for a long time.  But they used MSVC 2003 for Windows ofc.  ICC is also not free.

     

    Didn't know that ICC was used for linux. Kinda strange not seeing any preprocessor quirks for it, must have been a solid compiler :-) I don't understand how ICC not being free is relevant to anything though (the question being about original compiler).

    If you know exact MSVC version then what's the problem again? Did anyone try producing matching binaries with it?

  8. @@MGummelt, another question/observation would be with regards to the saber system in general.

     

    I'm sure many others can chime in but, simply recompiling the originally released SDK (also linux vs windows) even will cause differences in blocks and damages, more ghosting (visual hits that aren't hits) supposedly according to many people in the game and mod communities.  I guess the problems might stem from different floating point precisions etc and the original codebase being super picky about values in the collision code and w_saber.c.  But nobody has ever really nailed down what the causes are.  And obviously, most people aren't going to want to use ancient compiler versions anymore, its not realistic.  Someone had asked earlier on Discord what computer specs were used to compile JKA for Windows anyway?  And this problem isn't exactly new.  It's been highly debated and contested for many years as far as pure basers won't even use mods because the feels are different even if the code remains the same.

     

    I would like to chime in!

     

    There is a similar consensus among JK2 players and one I've shared for many years. However JK2 mods work under much more controlled environment as they are all QVM mods. There are no floating point precision issues or compiler differences, all this is handled consistently by the engine. Possibly PRNG can be used a bit differently in different mods, but I can't imagine it's so bad that there are patterns recognizable by players EDIT: I back out of this – it's truly awful, bad implementation of already weak PRNG (comes from id tech 3). Need to have another look. I thought it could be caused by some tiny timing differences but everything works on a millisecond precision and I'm sure in these mods there is nothing that would add a delay as large.

     

    On one hand I've heard opinions from other developers that this is placebo, double blind tests with altered mod name confirming it. Belief that something is different may come simply different server conditions.

     

    On the other hand I've never doubted the effect myself, nor has any other seasoned player I know, and I remember situations like when we changed mod on a popular server once – same machine, same location, same port, same dedicated server binary. The change was obvious and it took few days for all regulars (including me) to adjust.

     

    I understand that JKA has more possible causes for such behavior (dll mods), but I played it a bit and I didn't feel any larger difference between mods there than I do in JK2.

    It would be amazing to figure it out once and for all. This has bugged me since I started playing in 2004 and sadly prevented many good mod projects from gaining traction.

     

    PS I remember hearing from someone well informed few years ago that JKA modding community finally learned the original compiler name (some version of ICC). Didn't you? :-)

    Smoo likes this
  9. @fau, no problem about jomme, I have already accepted that none from jk2 cares about it at all (except, probably, @Boothand). And also, you should be able to record with jamme engine + your mod modules, no need to use jomme modules.

     

    What do you mean? Everyone I know who does any jk2 rendering more complex than this uses jomme, including me. It would be a huge pita like in the old days without it. You must keep in mind that there is not much activity currently though.

  10. The challenge is over and winning demo can be watched on YouTube: https://www.youtube.com/watch?v=W2xcjCqO2BM&feature=youtu.be

    Acrobat has already posted it in a General Discussion topic.

     

    And so another challenge begins:

     

    climbit_logo.gif

     

    Same server, same rules. If you happen to climb it in Jedi Academy with similar settings (no saber moves!) I'll include you in the credits, but only demos recorded on Dark JumpingServers are allowed for competition.

     

    Good luck, safe climbing

  11. @@ent sv_fps 20 g_forceregentime 0. It was recorded on Dark jumping server like all allowed demos so everyone had even chance.

     

    Anyway, the map is vertical enough that instead of urgency focus shifts to force power preservation. Force power was at 100 only in the beginning and for a split of a second near the end so it was a limiting factor all the time. There are few moments in the video where a slower path is used just to preserve force.

     

    Imo it makes it harder to improve runs by better execution, I think limited force is always bad in the long run.

     

    @ yeah, disabled in Germany. Sorry about that, it's map's soundtrack and I hadn't even considered anything else. You can download a demo here: https://jk2.info/viewtopic.php?f=24&t=600#p4938

     

    edit: PS @@ent sorry for not using jomme, but I found it a good excuse to port simple avi recording to jk2mv :P

  12. b_mountain.jpg

     

    To celebrate the release of latest Acrobat's "tower" map jk2.info is hosting a speedrunning challenge. There are two weeks to send your demos and they must be recorded on [Dark]JumpingServer. If you are not a JK2 player, worry not, movement allowed in this challenge is exactly the same in both games. Get JK2MV client from https://jk2mv.org and join us!

     

    Rules and original announcement on jk2.info: https://jk2.info/viewtopic.php?f=24&p=4766#p4766

    Smoo and Boothand like this
  13. Very interesting read. Haven't played JKA myself, but I remember Cube's nickname being in the news a lot. Thanks for the article and the interview, I hope there will be more :-)

×
×
  • Create New...