dev

You are retrieving player:counter var, but adding to player:counter var

I see the problem

The count was over 200 when I was testing it 😉

Keep going, you need to do it more than 100 times... or reduce that 100 number 🤣

This is literally the example from the docs

{{ setVar (add "player:counter:" player.steamId) (add 1 (getVar (add "player:counter:" player.steamId))) }};

So this build works fine, but... it doesn't help with what I want to do. I think the reason for this is that CSMM doesn't even detect a disconnection if the server is only offline briefly, which is what happens for our servers, since we have a system that automatically restarts it if it goes down. Either that or the hooks aren't working. 🙂

getVar

gets the value of the variable. You have

{{getVar "player:counter:" player.steamId}}

which is invalid syntax. Also

player:counter:

will be treated as a plain string in the variable name.

no dice so far 🤔

How do we go about using the player:counter in a conditional statement?

I was thinking something like ```{{ setVar (add "player:counter:" player.steamId) (add 1 (getVar (add "player:counter:" player.steamId))) }};

{{#if (gt player:counter 100)}}

say "TEST"

{{/if}}```

Cool, I have some idea's 👊

Yep should be ^^

Oh it's live on my instance also?

everywhere :)

So I have finally got some time to look into these persistent variables 😉

Is this live on staging @User 22055452 ?

Yeah I know ;) just very convinced now it's a great idea haha

Hehe :p Wont be anytime soon I'm afraid

Man trying to use Handlebars for error handling makes me reallllyyy want that script idea you have in your head lol

Set it up yesterday, will be running it on our test server over the weekend

Nice! Looking forward to trying that out!

There's premade Discord notifications available, or you can add a hook to the events

You can use docker tag

pr-1075

to try it out ^^

@User 28294624 👀

So dynamically loaded :p

setVar test 1

Then a different hook:

setVar test 2
t = getVar test

print(t)

That should print 2

Persistent variable wouldnt get passed during startup though, you'll be able to load them in dynamically

Totally

Sure is! Actually I'm sure if there's a way to populate an object with data on the processing host, you can just as easily send it arguments and persistent variables the same way you send it the data.

But it's a fun excuse for me to play around with Firecracker haha

🙂

Yep, lots of stuff to figure out :p

Yeah that would be awesome. All I meant was that if that

data

object contained the same memory map as what the Handlebars built-in variables do, that would make it easy. Also though the custom variables thing may be hard to pull off, particularly the persistent variables.

Persistent vars would be

getVar("test")

and

setVar("test", 1)

etc

execCmd

would be a function provided by CSMM

In my head, what you would write instead of current handlebars would be

function main(data) {
  for (const onlinePlayer of data.onlinePlayers) {
    if (onlinePlayer.level > 100) {
      execCmd(`say "Wow ${onlinePlayer.name} is level ${onlinePlayer.level}, what a beast"`);
    }
  }
}

That's probably ok depending on what the API looks like. If there are objects served up for the same things Handlebars can get to, those code snips should be very easy to write.

Yeah it could totally be a toggle and support both systems. Would have to be a server-wide thing though cause of how the settings in CSMM work right now

Well butter my biscuits, if you could offer both (Handlebars for people who don't know how to write code, Firecracker for people who do) or combine them so you could use both a single script somehow, that would be awesome saucem possum

Powered by https://firecracker-microvm.github.io/

(Made by Amazon, they use it a lot in AWS to let people run arbitrary code on their servers)

Remote code execution as a feature... 🤔

What if you could write any code you wanted in there? Javascript or python for example

I'm kind of considering a bit of an overhaul to the handlebars system

I thought the EOS system would've been better integrated by now

Dunno how long alloc Will stay quiet

Yeh true and I might have to go for it

Could be a temp workaround

Lcp is cpm

To me allocs = vanilla lol

Woops :p

Lkp is allocs

vanilla commands like lkp dont even return that eos id <.<