Announcement

Collapse

Welcome to the all new QuakeOne.com!!

Welcome to the all new QuakeOne.com! The web site has been moved to a brand new web host, and the site software (vBulletin) has been upgraded to the most recent version. All previous data, including users and posts, has been converted over to the new version of the site.

We are still in the process of updating the site look and feel. We hope to have this updated shortly. In the meantime we have simply launched the site with the default software templates so as to not keep the site down any longer.

Until we get the site back up and running as it was before, please use http://servers.quakeone.com to find game server stats.

If you find any issues with anything on QuakeOne.com, please let us know in the Site Feedback Forum.

Thanks for your patience!

-Solecord
See more
See less

stuffcmds question (SpecialBomb's QC Questions, again)

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

  • stuffcmds question (SpecialBomb's QC Questions, again)

    So, I am aware of the stuffcmds function and what it does. What I don't know is what commands are valid that I can send to it. Currently, I know that bf and v_cshift work, but what else is there? I wanted to use the play command to attempt to play certain sounds locally to certain players, which others can't hear. I just don't know what is allowed and what isn't.

  • #2
    Stuffcmds is basically like entering a command to the console. Which means any command or cvar can be sent, if I'm not mistaken. I'm not entirely certain what the difference between stuffcmd and localcmd is, but I know it has something to do with client / server relationship.

    I'm sure spike will be along shortly to give a better answer and correct whatever I said wrong.
    'Replacement Player Models' Project

    Comment


    • #3
      stuffcmd sends to a client entity, localcmd sends a command to the server. This is an important distinction if you wanted to change the gravity, for example.

      There really isn't a limit to what you can stuffcmd. It's exactly like the player typed in a command into the console. You could do "bind mouse1 kill" so that the player kills themself on mouse click even after they leave the server (until they rebind it manually). You can even run into issues where some commands exist on one client (say, Darkplaces) and not on another.

      Comment


      • #4
        the list of what you can do via stuffcmd is limited by how considerate the modder is.
        for instance, binding random keys is a spiteful act if the user doesn't want to kill themselves every time they try firing, for instance... Changing cvars is generally wrong too as they'll linger even if the player connects to a different server afterwards, they're especially malicious if they'll get saved into the user's config.

        That said, sometimes its the only way to achieve something, so what other choice do you have?
        Just try to avoid doing anything that'll linger.

        It is common for multiplayer mods to send aliases via stuffcmds. This is generally a more friendly way to deal with bindings (instead of documenting impulse numbers), but still requires the player to be aware of it (most clients have some aliaslist or something command that shows what's available).

        But yes, you can potentially send ANY console command to clients via stuffcmd. A favourite is the unbindall command, but there's other commands that can require the user to reinstall quake, or worse. Some clients try to limit what servers may do, but as a general rule you can send whatever you want, there is no definitive list. If the client has it as a command/cvar/alias/potato then you can try to use it, for malice or otherwise. Just please try not to be too evil.

        The other thing to avoid is resending the same thing all the frikkin time. That sort of thing just bloats network packets, so don't do it. I've seen mods for DP do this a lot, combined with big long cvar names, and thus resulting in players actually getting kicked due to overflows.
        Some Game Thing

        Comment


        • #5
          @Just please try not to be too evil.

          Or be cleverly evil. Make a mod called "Stuff You". Stay away from binding things to kill and instead bind things to other annoying ideas that aren't necessarily obvious. Like having the next/prev weapon skip ahead/back 2 weapons instead of one or putting some "just long enough" wait on the jump command..

          I don't know if that last one is possible but, I know I have seen the word wait in a cfg so, there is probably something annoying there.

          If it's possible, some kind of way listen for the window close event and change the persons cfg back. Then when they open it again change it back to the sucky thing . This way they will go nutz trying to figure out what's wrong. While you are at it, have your progs overwrite all the other progs so, no matter what they play it keeps changing their config back and forth.

          Use the file i/o qc class to store a date for like 30 days in the future in some hidden file. As long as the current date is less than that date your mod runs fine but, once it is more than that date it's starts doing all kinds of subtle and hard to track nonsense (like the stuff I said above).

          Speckle the mean code all over your entire source and simply refer to everything like it is something else.
          Last edited by MadGypsy; 06-30-2017, 10:53 PM.
          X_Michael

          Comment


          • #6
            @Zop

            Thanks for the explanation, I had a feeling it was along those lines.

            @SB

            Any cvars you alter, you may want to include in an autoexec that resets them to your default. That way, if a player disconnects shortly after having a cvar changed, it will revert to normal next time they launch the game. Be aware that you can fully comment your autoexec (although I believe it only recognizes '//', and you can't have semicolons anywhere), so you can write comments about the cvars you are defaulting in there, and why. Veteran players will always look in an autoexec, and will understand why you are 'forcing' them to use your settings if you have good comments.

            Also keep in mind that not every Quake player is familiar with cvars and commands like modders are, so the more basic the better. In other words, you don't want to default the mouse sensitivity, because they'll wonder why they have to change it every time they load the game. It should be things that no one would normally alter themselves.
            'Replacement Player Models' Project

            Comment


            • #7
              example:

              stuffcmd("play doors/drclos4\n")


              don't include the .wav
              www.quakeone.com/qrack | www.quakeone.com/cax| http://en.twitch.tv/sputnikutah

              Comment


              • #8
                Okay, so literally anything.

                I remember Cobalt saying to me something like "In darkplaces, some commands can't be sent through stuffcmd," so it just depends on the server and client.

                Next problem, rook told me how to do my sound thing, but then I realized that it does not directly play, but plays at the location of the player when he used the play command. Is there a way get direct audio played? Darkplaces has play2, but not everyone uses darkplaces.

                Comment


                • #9
                  The problem is that you want a sound to be played at a certain location? You should be able to do this normally in quakec.

                  Comment


                  • #10
                    No, I think he wants a sound to play only on a specific client's computer. I don't think there's a way of doing that without CSQC (i.e. DP/FTE).
                    'Replacement Player Models' Project

                    Comment


                    • #11
                      The "play" command broadcasts a sound at the player's location?? As in, I can make it sound like I'm firing and exploding rockets when I'm not?

                      In any case, there is a way to send a sound to a client via WriteBytes, but you'd have to know the order the sounds were precached to have a chance at doing it correctly.

                      Comment


                      • #12
                        the problem with the play command is that, depending on client, it plays the sound at your current position...
                        which means it gets quiet fairly quickly as you move away, and blatently plays at different volumes on different speakers if you're still close.

                        some engines fixed it (which of course results in different behaviour), some engines added a more useful play2 command that solves the problem without behaviour differences.

                        some mods use writebytes to send sound effects (xonotic being one example). this requires that they know how the svc actually works. it also requires that they know the precache index of the sound file (possible if you have a fixed order inside worldspawn), so that's kinda messy.
                        in fte, you can use dimension_see+dimension_send and filter by players that way, allowing for unicast/multicast sounds.
                        Some Game Thing

                        Comment


                        • #13
                          Well, then I am fucked with the sound problem. I could go about doing a writebyte, but its really damn hard to know what all of the SVCs do.

                          Comment

                          Working...
                          X