Announcement

Collapse
No announcement yet.

Further proving how much of a n00b I am... (quakec)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Further proving how much of a n00b I am... (quakec)

    So, I am fairly sure spike can answer this question.

    I use darkplaces as a development and main engine, simply because it's very cross platform, and it's in both the Ubuntu and Debian repositories, making my life easy.

    However, today, I decided to run my sbdm mod on quakespasm, another engine that is available in the repos. Surprisingly, I got an error message when I set my -game option to my mod, which would be this:

    Code:
    ========= Quake Initialized =========
    
    couldn't exec autoexec.cfg
    Host_Error: progs.dat system vars have been modified, progdefs.h is out of date
    
    ERROR-OUT BEGIN
    
    
    QUAKE ERROR: Host_Error: progs.dat system vars have been modified, progdefs.h is out of date
    Now, I based my mod off of cleanqc v106, and that progdefs.h looks identical to the one in my mod. This concerns me, because I don't want my mod only running on darkplaces, its supposed to be ambiguous.

    So, here are my questions:
    1. What the hell is happening?
    2. Why is it happening?
    3. Why does this work in darkplaces, but not quakespasm?
    4. How do I prevent this from happening, and what is the solution?

  • #2
    Looks to me like you might have changed some variables in the top half of defs.qc. which must be defined in QC to communicate to the engine (.ammo_nails, for instance, because the engine draws the ammo count for nails on the status bar). Not sure why DarkPlaces accepts it though.

    Just my initial impression. Could be wrong.
    'Replacement Player Models' Project

    Comment


    • #3
      progdefs.h is obsolete. delete it. its generated as a byproduct of old qc compilers, the purpose being that it can then be compiled into every single part of the quake executable, thus its only useful if you're id software.
      the qcc does a crc check on the resulting progdefs.h which serves as a convoluted way to crc the types, names, order, etc of the defs up to end_sys_fields. this is why it lingered as long as it did, and should also explain the error message.
      fteqcc doesn't even write it any more, because quite frankly its useless. so if you have that file and you're using fteqcc then yeah, it won't have changed even if you totally rewrote all the systemdefs in your mod.

      a quick fix is to just copy+paste the defs up to end_sys_fields from a known-good version into your defs.qc. you don't even need to delete the ones you previously had in there, but you should still clean up anyway.

      in future, pay attention to 'progs CRC not recognised from quake nor clones' warning.
      Add this to your code somewhere:
      #pragma warning error Q208
      that'll then make identical screwups fatal in future.
      Some Game Thing

      Comment


      • #4
        Originally posted by SpecialBomb View Post
        So, I am fairly sure spike can answer this question.
        I am fairly sure that in the last 2 decades there is not 1 Quake related question that Spike could not have answered.


        Originally posted by SpecialBomb View Post
        I use darkplaces as a development and main engine
        That is not a smart thing to do as DP does many things different than other engines. Maybe better stick to fitzquake derivates.

        But on the other hand, a lot of *mixed source* engines have been born recently. Copying lots of features from existing engines into others.

        So, making a 1-mod-for-all-engines gets more and more diffcult. You can clearly see this on the recently released Quake mods, which are only made for 2 or 3 engines.

        Anyway, developing & testing a mod in ALL engines is nonsense as well. You should make a decision and walk that path then.


        If you are working on a multiplayer mod (that is what I understand from your post) you should not use Darkplaces, as it is not largely used by multiplayers. There are other more popular multiplayer engines out there I guess...

        Best of luck for your project,
        Seven

        Comment


        • #5
          The multiplayer base is so small (20 people maybe), if you do make a rockin mod people will use your engine of choice. DP and FTE are two great engines for multiplay. The reason the 20 players use pq/qrack is because they are stuck with the "it feels like i remember how i used to play, and can still win this way" and the fact that they are reluctant to change. Which is also why DM3 is play more than 90% of the time.
          www.quakeone.com/qrack | www.quakeone.com/cax| http://en.twitch.tv/sputnikutah

          Comment


          • #6
            Originally posted by R00k View Post
            The multiplayer base is so small (20 people maybe), if you do make a rockin mod people will use your engine of choice. DP and FTE are two great engines for multiplay. The reason the 20 players use pq/qrack is because they are stuck with the "it feels like i remember how i used to play, and can still win this way" and the fact that they are reluctant to change. Which is also why DM3 is play more than 90% of the time.
            Lol, I know.

            I really like the netcode in DP, simply because it bases entity messages on delta change, so that way it's really unlikely to have latency due to entity spam, which happens a lot in my mod. I also like that it has a much better mouse resolution, so that my rockets actually go where I want them to.

            Comment


            • #7
              Spiked Quakespasm R7 can connect to DarkPlaces servers that are running the usual DarkPlaces protocol (DPP7).

              http://triptohell.info/moodles/qss/q...m-spike-r7.zip
              Quakeone.com - Being exactly one-half good and one-half evil has advantages. When a portal opens to the antimatter universe, my opposite is just me with a goatee.

              So while you guys all have to fight your anti-matter counterparts, me and my evil twin will be drinking a beer laughing at you guys ...

              Comment


              • #8
                Originally posted by Baker View Post
                Spiked Quakespasm R7 can connect to DarkPlaces servers that are running the usual DarkPlaces protocol (DPP7).

                http://triptohell.info/moodles/qss/q...m-spike-r7.zip
                qss's own protocol extensions also do the same nack-deltas thing, so you can just use qss as the server instead. no need for dpp7.

                @baker
                either way its fairly trivial to add client-side support for nack deltas, be they fte's or dpp7. its the server side that's hard.
                on the other hand, qss has less checks for PEXT2_REPLACEMENTDELTAS than it does for PROTOCOL_VERSION_DP7, and that's despite the dpp7 references being just the client side (and many of those repdelta checks are just to trigger host_errors when the server didn't enable it). Which is frankly the main reason that I went with that instead of dpp7 - its much simpler to integrate (same reason I added dp-compatible downloads instead of fte's extension, see! I'm not excessively biased!). the dpp7 stuff that I did add was really only because dp servers default to dpp7 and have no graceful fallback, its also not very complete, but 'should' be enough for running vanilla quake.
                either way qss doesn't support prediction
                but yeah, I really ought to make a qss-r8 release some time - there's a few serious bugs in r7.
                Some Game Thing

                Comment


                • #9
                  Originally posted by Spike View Post
                  I'm not excessively biased!
                  Hehehe, never thought you were. Yeah, it's nice you know in detail how non-Spike engines work.

                  Originally posted by Spike View Post
                  @baker
                  either way its fairly trivial to add client-side support for nack deltas, be they fte's or dpp7. its the server side that's hard.
                  I imagine DPP7 works roughly like this:

                  1. Accumulate a buffer of server frames. Probably needs to track client state.
                  2. Timing calcs of some sort.
                  3. Recalculate player entities and possibly projectiles based on slightly retroactive frame information.
                  4. Probably missing 2 items because I haven't been thinking about engine code.

                  I imagine monsters are not predicted, just like I imagine weapon pickups and teleportations are not predicted.

                  Somewhere I have a link to notes you made in a text file on your web site.
                  Quakeone.com - Being exactly one-half good and one-half evil has advantages. When a portal opens to the antimatter universe, my opposite is just me with a goatee.

                  So while you guys all have to fight your anti-matter counterparts, me and my evil twin will be drinking a beer laughing at you guys ...

                  Comment


                  • #10
                    so, progdefs.h...

                    Just to get this together again, I essentially need to update all of the global variables I have defined in defs.qc into progdefs.h?

                    Also, @spike, I have no idea if you can, but it would be really cool if you could put your FTE engine on the Debian repository.

                    Comment


                    • #11
                      SB, just the ones up to end_sys_fields. those are the only ones the qc compiler built into the progs crc, so those are the only ones whos order+types+names must match.

                      ignore the progdefs.h file itself. its existence is merely a legacy.
                      Some Game Thing

                      Comment


                      • #12
                        Ah, okay, so I think I figured out what I did then.

                        When I made all of the global variables for my voting system, I stuck them in the system globals section. That is probably fucking up everything, am I right or wrong?

                        I would expect it to because that a very particular section.

                        If it is the case, I will at least learn the lesson that I shouldn't mess with any sections that are messed with by the c code.

                        If not, I am at a loss.

                        Comment


                        • #13
                          Yep, that's your problem. You don't want to modify in any way, shape, or form that section of code. Add any new fields to the bottom half of defs.qc, you should be fine.
                          'Replacement Player Models' Project

                          Comment


                          • #14
                            @Dutch

                            Thanks, I will fix that later, as I am very tired. I can still define globals in the other sections, right?

                            It pretty obvious that its a yes, but quake is a tricky thing.

                            Comment


                            • #15
                              all that really matters is:
                              a) your globals/variables/functions/fields are defined before they're used, actual order doesn't really matter. violating this rule generally results in compile errors, and can actually be worked around with -fautoproto in fteqcc.
                              b) you must not change anything before end_sys_fields (this order DOES matter, the vanilla engine is hardcoded to it. FTE and DP are not, but they still use it as hints for whether its a quakeworld vs nq vs hexen2 vs csqc vs menuqc mod). There is no practical way around this.

                              as I said before, fteqcc has a similar check to the engines, in the form of its 'Q208' warning - 'progs CRC not recognized from quake nor clones' means you violated the 'b' thing above, and the progs won't work in QS until you fix that warning.

                              (so yeah, just move your custom defs to the end of the file or something)
                              Some Game Thing

                              Comment

                              Working...
                              X