Announcement

Collapse
No announcement yet.

Vanilla Quake Fixes

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

  • NightFright
    replied
    Does this happen only in ID1 (original campaigns) or the addons as well? SoA and DoE have much less changes in their code than ID1.
    But yeah, it seems there is additional sv_aim code in weapons.qc, added by Maddes. (Sadly, in general Maddes did not only fix bugs, but also added features which are not well documented.)

    In world.qc, we have the culprit, actually:
    cvar_set("sv_aim", "0.93"); // set sv_aim for testing

    Download the attachment, extract included pak3.pak into your ID1 folder and see if that fixes the issue. If it does, I can put it into the actual release.
    Attached Files
    Last edited by NightFright; 09-06-2021, 08:38 AM.

    Leave a comment:


  • Dopefish
    replied
    Oh, I just noticed something that have been driving us nuts while playing in coop. For some reason, using this pak file, it keeps setting sv_aim to 0.93 every time we load a new level. Am I crazy, or is there any of these changes that might be causing this?

    Leave a comment:


  • Dopefish
    replied
    I could get the silver key in HIP1M4 now! The enforcers seems to still telefrag themselves on the upper catwalk of E2M1 (skill 3), but atleast that issue doesn't stop you from progressing

    I'm using vkQuake for reference.

    Leave a comment:


  • NightFright
    replied
    Revision 5 has been released. With this update, any so-called "nextthink ai updates" have been removed, hopefully eliminating the possibility of having issues related to item spawning in general. Thanks a lot to LordKane for his bug report! This one was hard to find and even harder to track down.

    Changelog:
    - Fix for items spawning too early (fixes HIP1M4 silver key not always spawning on skill 1 or higher)
    - Enforcer telefrag fix/improvement attempt for E2M1 on skill 1+

    Download link in OP.
    Last edited by NightFright; 09-06-2021, 03:12 AM.

    Leave a comment:


  • Dopefish
    replied
    Awesome! Thanks for putting in all the efforts in making this :]

    Leave a comment:


  • NightFright
    replied
    I still need to do some tests to see if monsters and items behave as intended now, but it should be ready tomorrow already. Fingers crossed! (I really hope it's the last time I need to correct anything, btw.)

    In the meantime, I put the latest d/l link in the OP. Sadly, I cannot do the same at Func_Msgboard.
    Last edited by NightFright; 09-05-2021, 02:06 PM.

    Leave a comment:


  • LordKane
    replied
    Originally posted by Dopefish View Post
    Just made an account here to mention this issue aswell. We were playing coop and had no idea of how to progress since we couldn't find that key. We were playing with vkQuake and QuakeSpasm

    Beyond that, it seems like it's been fine playing through Quake and both mission packs in coop with this ^^
    (Also, protip, it's always good to update the original post with the latest revision!)
    He did have a temp fix up, but a new revision is coming soon with a proper fix.

    Leave a comment:


  • Dopefish
    replied
    Originally posted by LordKane View Post
    I have noticed an issue with SOA with the fixes, the silver key in HIP1M4 (Research Facility) spawns inconsistently:
    Just made an account here to mention this issue aswell. We were playing coop and had no idea of how to progress since we couldn't find that key. We were playing with vkQuake and QuakeSpasm

    Beyond that, it seems like it's been fine playing through Quake and both mission packs in coop with this ^^
    (Also, protip, it's always good to update the original post with the latest revision!)

    Leave a comment:


  • NightFright
    replied
    It seems more and more that the nextthink AI "fix" for monsters rather tends to create new issues elsewhere.

    TBH I have not encountered any AI-related issues in any playthrough I remember. Therefore I dunno if this "fix" is really worth keeping, especially if it comes at such a cost.

    And yeah, I know what dprint is. If you are in dev mode, this spits out status messages so you know which code is executed - or not.

    The wisest course of action appears to be to undo all the nextthink AI changes and in return leave StartItem untouched. It's going to be more work, but anything else could just make it worse. As Seven indicated, there's no telling what might break if you mess with item spawns.

    And no worries: I am not angry for these corrections. In fact, they reminded me of an important lesson I had forgotten, unfortunately: Don't mess with stuff you don't understand.
    Last edited by NightFright; 09-04-2021, 07:05 AM.

    Leave a comment:


  • Seven
    replied

    Originally posted by NightFright
    Gotta Correct Myself

    It's not about compilation order of items.qc in progs.src. It has rather to do with adjustments to monster AI which also affect item spawns. By making them appear later, potential conflicts can be avoided.
    You are mixing up a lot of things. Please first understand things correctly before cross posting.
    Those changes does not affect monsters AI at all. We are far ealier in the process. We are in the initial map setup, where entities are set.

    What you did is adding different code changes from different people into the source without really knowing what they do and how they work.


    I want to help you.

    You did not reply to my first comment yet:
    Do you know what the dprint lines are for ?
    Those are only visible after enabling the developer messages in the console.
    Look through the code and search them. You will see that they have one purpose: to debug and find issues like the ones you are facing now.

    You will then quickly see that it is ALL about droptofloor(). That is the main function in the map starting process.
    If anything goes wrong with your entities, the developer console will tell you.

    You will also see that ALL entities are lifted up serveral Quake units. That is to be able to perform droptofloor().
    After reading this post, you should know why now.





    Originally posted by NightFright View Post
    I assume all this is about the nextthink changes I did to fix monsters sometimes not moving in monsters.qc. Since you wrote items share the same function(s) to START (hint with the sledgehammer)
    My goal was that you pay attention and go with a fine comb through the item starting process at map start.
    Of course I could have tell you the correct line number and the correct values to fix the issue.
    But as you know me for a while now, that would not help you in understanding what you are copy/pasting.
    Once you went through the process, I am sure you learned a lot and will understand Quakes gamecode better.
    ... and will hate me a little less hopefully.




    Originally posted by NightFright View Post
    my guess is you were referring to this fellow here in items.qc:

    void() StartItem =
    {
    self.nextthink = time + 0.2; // items start after other solids
    self.think = PlaceItem;
    };
    Thats the one.
    Everything is spawned at the beginning of the map (as described above).
    So, you have to pay attention what comes first and what follows after.

    You have to understand what "time" is here. time is global and is the same for every entitiy.
    Doing everything at the same time (means in the same frame !) would be wrong.
    The source code is well filled with hints and things to pay attention to.
    Important map solids (like doors etc.) comes first and so on.




    Originally posted by NightFright View Post
    If I change that to self.nextthink = time + 1 (instead of + 0.2, so a delay by a factor of x5), it's apparently not happening any more. Dunno if that value is too high, but I couldn't see any significant impact on gameplay after this, besides that fact that the silver key in HIP1M4 works all the time now. I tried like a dozen times on skill 1 at least to make sure.

    It could work with time + 0.7 already as well, though, considering the nextthink calculations in monsters.qc (time + 0.1 + random()*0.5 --> max possible is time + 0.6). time + 0.4 is definitely too low, I tried that. If I set the delay too high, I assume a visual effect would be that items pop into view after a map is started, which should be avoided. I am afraid that 1sec. is already way too much.
    Now we are talking !

    To take away your worries, I suggest you to choose a map, where you can see entities from player spawn point and experiment. How the delay will affect the visuals.
    I will not spoil your investigations, but you then know how exactly if it affects the visuals at all.


    Now that we have the visuals out of the way, we have to talk about dependencies.
    Imagine, an item is spawned on a moving platform:
    How would that affect each other when the platform is moving upwards while the items properties are still not set ?
    That is why you should keep delays as small as possible.


    By the way:
    You played Quake for endless hours already.
    How often did you encounter a monster that is not moving ?
    Now you should maybe overthink the fix by Lord Sméagol.
    Which is the root cause for your issue.

    Be aware that engines have changed with the years as well.
    And are capable of a lot more than in 1997.
    Using .ent files in that mod exclude the original engines anway, so...


    I am sure you will be able to fix your issue now.
    I hope you are not angry with me in the end and could take some knowledge and information out of this.
    The next mod will come shortly (I am sure) and it will be better now, because you became a better modder

    Enjoy your weekend,
    Seven

    Leave a comment:


  • LordKane
    replied
    Originally posted by Seven View Post
    No, I used the QuakeC nomenclature / wording / term.
    For God's sake, dont switch the progs.scr order. You will very quickly find out why when trying to compile.

    You made changes to the items code and other (monster) code that is used when the map starts.
    That is the culprit.
    Items are all the entities you see in a map excluding monsters and player: Keys, ammo, armor, runes, etc.
    They are all handled in items.qc. They all share the same functions to start.


    Usage of .ent files should really be avoided. At least for compat reasons.
    Not every engine can use them.





    Not really, if you tinkered with QuakeC for a while

    One thing you should know about Quake gamecode:
    It is ALL about think, nextthink, think and nextthink again.
    It is important to know what happens between these and what is executed each frame.

    Once you get the hang of it, it all becomes clear how simple the Quake gamecode is.
    ... and how limited in the same way.

    Have a nice weekend,
    Seven
    Yeah, I am sadly not a programmer so its all Cardassian to me, and I spent two years learning Klingon.
    But thats neat that its how that works, so thanks for the assistance I weirdly felt guilty about even finding this bug and at first I wasnt going to report it.
    but I am strange that way.

    Leave a comment:


  • NightFright
    replied
    OK, bear with me here, noob at work.

    I assume all this is about the nextthink changes I did to fix monsters sometimes not moving in monsters.qc. Since you wrote items share the same function(s) to START (hint with the sledgehammer), my guess is you were referring to this fellow here in items.qc:

    void() StartItem =
    {
    self.nextthink = time + 0.2; // items start after other solids
    self.think = PlaceItem;
    };


    If I change that to self.nextthink = time + 1 (instead of + 0.2, so a delay by a factor of x5), it's apparently not happening any more. Dunno if that value is too high, but I couldn't see any significant impact on gameplay after this, besides that fact that the silver key in HIP1M4 works all the time now. I tried like a dozen times on skill 1 at least to make sure.

    It could work with time + 0.7 already as well, though, considering the nextthink calculations in monsters.qc (time + 0.1 + random()*0.5 --> max possible is time + 0.6). time + 0.4 is definitely too low, I tried that. If I set the delay too high, I assume a visual effect would be that items pop into view after a map is started, which should be avoided. I am afraid that 1sec. is already way too much.
    Last edited by NightFright; 09-03-2021, 05:09 PM.

    Leave a comment:


  • Seven
    replied
    Originally posted by NightFright View Post
    Oh. I didn't think that could be a problem. It's really only about where in the progs.src compilation list items.qc is placed?
    No, I used the QuakeC nomenclature / wording / term.
    For God's sake, dont switch the progs.scr order. You will very quickly find out why when trying to compile.

    You made changes to the items code and other (monster) code that is used when the map starts.
    That is the culprit.
    Items are all the entities you see in a map excluding monsters and player: Keys, ammo, armor, runes, etc.
    They are all handled in items.qc. They all share the same functions to start.


    Usage of .ent files should really be avoided. At least for compat reasons.
    Not every engine can use them.




    Originally posted by LordKane View Post
    Amazing info.
    Not really, if you tinkered with QuakeC for a while

    One thing you should know about Quake gamecode:
    It is ALL about think, nextthink, think and nextthink again.
    It is important to know what happens between these and what is executed each frame.

    Once you get the hang of it, it all becomes clear how simple the Quake gamecode is.
    ... and how limited in the same way.

    Have a nice weekend,
    Seven

    Leave a comment:


  • LordKane
    replied
    Originally posted by Seven View Post
    Hello,

    At least basic understanding of how the Quake gamecode works should be there when tinkering with QuakeC

    If you ever wondered what those dprint messages in the source code mean, they are there to help you.
    Especially in situations like these.
    So, enable the developer console messages and you will see what happens.
    And yes, it has something to do with the small changes Nightfright made.

    The original source reminds you that Items should load last in order.
    Nightfright made them load too early and that is why things like this happen.
    Most probably other maps are affected as well.

    Your options to fix this:
    1.) Either remove the delay again
    2.) Or add an even higher delay to items

    Both ways will fix your issue.

    If mappers would be more sensible in placing / positioning stuff, things could be avoided.
    But they sometimes are in a rush and trust on original gamecode behaviour.

    DarkPlaces for example has several dedicated cvars to fix these things.
    Means, issues like this would not happen in DP. As it saves entities from falling out of the map.
    But QS and the like doesnt; so the gamecode must remain how it was when these maps have been build.

    Best wishes and have fun with QuakeC,
    Seven
    Amazing info.

    Leave a comment:


  • NightFright
    replied
    Oh. I didn't think that could be a problem. It's really only about where in the progs.src compilation list items.qc is placed? Wow. I knew order couldn't be random since some code requires other code to be loaded first, but I thought everything is ok if the compiler doesn't yield any warning or error.

    Strange, though - I don't recall changing load order of the source files compared to the original. Anyway, I will follow your advice and see if I get it working without the need of an ent file. Need to check if DoE has the same problem.

    Thanks a lot for the hint, Seven!
    Last edited by NightFright; 09-03-2021, 11:19 AM.

    Leave a comment:

Working...
X