Skip to content
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Donate
Collapse

Plutonium

  1. Home
  2. BO2 Modding Support & Discussion
  3. [Support] Randomize what perk perk-a-cola machines give

[Support] Randomize what perk perk-a-cola machines give

Scheduled Pinned Locked Moved BO2 Modding Support & Discussion
9 Posts 6 Posters 858 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • RED PANDAundefined Offline
    RED PANDAundefined Offline
    RED PANDA
    wrote on last edited by Mr. Android
    #1

    is it possible to make a script where each game Juggernog will get switched with a random perk? For example one game Juggernog will be quick revive and quick revive will be Juggernog and then when the server rotates map for Juggernog to be speed cola and speed cola to be Juggernog? I hope i worded this well enough for people to get it.

    1 Reply Last reply
    0
    • Xerxesundefined Offline
      Xerxesundefined Offline
      Xerxes Plutonium Staff
      wrote on last edited by
      #2

      It most definitely is possible, after all thats how nuketown does it.

      RED PANDAundefined 1 Reply Last reply
      0
      • RED PANDAundefined Offline
        RED PANDAundefined Offline
        RED PANDA
        replied to Xerxes on last edited by
        #3

        Xerxes oki thx for telling me i need to make this april fools script quickly now

        luigistyleundefined Xerxesundefined 2 Replies Last reply
        0
        • luigistyleundefined Offline
          luigistyleundefined Offline
          luigistyle Plutonium Staff
          replied to RED PANDA on last edited by
          #4

          RED PANDA
          lol, good luck

          1 Reply Last reply
          0
          • Ox_undefined Offline
            Ox_undefined Offline
            Ox_
            wrote on last edited by Ox_
            #5

            After taking a quick look, I'm seeing four ways you could do this.

            You could patch e.g. the vending_trigger_post_think() function, which is one the functions that will run when you purchase a perk, in _zm_perks.gsc, but that would require some doing. You'd have to fix all the decompilation errors in that gsc and then recompile it. Could be pretty easy, but could also be that it's straight up missing some code and you'd have to fill it in yourself.
            This approach would surely give you the most control, and you could customize anything and everything about it. If this happens to be one of those gscs that doesn't have terrible decompilation errors, this is a really good approach.

            Another way, which already seems pretty good, would be changing the perks that are associated with the perk machine triggers. This way you wouldn't have to recompile the _zm_perks gsc.
            This is the beginning of the vending_trigger_think() function, which is holds the logic for each perk machine's trigger.

            vending_trigger_think()
            {
            	self endon( "death" );
            	wait 0.01;
            	perk = self.script_noteworthy;
            	...
            

            The function is owned by each perk machine's trigger, so self is the trigger.
            So what you could do is just change the value of trigger's script_noteworthy.
            Without doing any testing, I think it'd be done with just doing this:
            (jugger to speedcola)

            foreach (trigger in getentarray("zombie_vending", "targetname"))
            	if (trigger.script_noteworthy == "specialty_armorvest")
            		trigger.script_noteworthy = "specialty_fastreload";
            

            Though, you'd need to get that to run before the init() in _zm_perks, which might not be that easy.
            But in that case, could of course just notify the desired trigger with a "death", and then restart the desired trigger's logic function (vending_trigger_think())

            However, this approach would come with the downside(?) of your hud saying speed cola when you're standing next to the jugger machine. Basically the machine acts exactly like the speed cola machine.

            And then the third approach I could quickly think of:
            In the vending_trigger_post_think() function, which is the function that runs after you make a perk purchase, there is a very helpful little line of code:

            vending_trigger_post_think( player, perk )
            {
            	player endon( "disconnect" );
            	player endon( "end_game" );
            
            	...
            	
            	if ( isDefined( level.perk_bought_func ) )
            	{
            		player [[ level.perk_bought_func ]]( perk );
            	}
            	
            	...
            }
            

            A globally defined function that runs after you buy (and finished drinking) the perk.
            Now that's lucky.
            Be very easy to add your own custom logic onto that function. And in your case, I guess your desired custom logic would be removing the purchased perk and replacing it with another perk.
            And on top of that, you can add whatever else custom logic as well.

            I'd consider this the best approach, since you won't have to deal with recompiling the _zm_perks gsc, and you can basically still have a lot of control over what actually happens upon buying the perk by just removing it and then doing whatever.

            The fourth way, is basically a duplicate of the above, with the downside of not having a direct way to tell what perk the player just bought.
            Players are notified with a "burp" (this occurs in the aforementioned vending_trigger_post_think() function) upon finishing drinking a perk bottle. So could listen for that notification and then do the same as above, remove the perk that was just bought and replace it whatever else. You'd just have to create your own custom logic for determining that perk was just bought.

            Most definitely not a bad approach, but I don't really see any reason to do this, since the previous approach I suggested just straight up passes the name of perk to the level.perk_bought_func function.

            So yeah, there most definitely are way more ways of doing this. This is just what I could see after taking a quick glance at the _zm_perks gsc.
            Though, I don't think it can get any better than using the globally defined level.perk_bought_func function. At least for the usage you seem to be after.

            Mr. Androidundefined 1 Reply Last reply
            1
            • Xerxesundefined Offline
              Xerxesundefined Offline
              Xerxes Plutonium Staff
              replied to RED PANDA on last edited by
              #6

              RED PANDA I took a quick look at it, try get all perk machine entities by getting all zm_perk_machine ents and try to replace the script_noteworthy field.

              1 Reply Last reply
              0
              • Mr. Androidundefined Offline
                Mr. Androidundefined Offline
                Mr. Android Plutonium Admin
                replied to Ox_ on last edited by
                #7

                Ox_ Solid reply by the way.

                1 Reply Last reply
                0
                • RealAxysundefined Offline
                  RealAxysundefined Offline
                  RealAxys
                  wrote on last edited by
                  #8

                  I know this is an old thread, but would it be at all possible to say set up where a perk machine would give you its normal perk the first time then every time after give you a random perk?

                  1 Reply Last reply
                  0
                  • Xerxesundefined Offline
                    Xerxesundefined Offline
                    Xerxes Plutonium Staff
                    wrote on last edited by Xerxes
                    #9

                    If you mean per map you could track which machines a player already used on the player entity and then just add a check for that in the vending logic.
                    Otherwise you have to track that somewhere externally like a file or db

                    1 Reply Last reply
                    1

                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Recent
                    • Tags
                    • Popular
                    • Users
                    • Groups
                    • Donate