Bit of help with Boris

[khalil]

Kay, I'm working on making a patch where if you kill boris enough he'll stay dead. The problem is, I'm not sure where to initialize the variable for how many times he can reappear before he stays dead. I can't put it in monster_die because it'll get reset every time that function gets called, but I'm not sure where else I could put it. (This part of the code is a bit beyond me.)

[DracheReborn]

Well if you look at the Natasha code, it looks like similar info is stored in a mons->props? Maybe you could abuse the same field.

[khalil]

I tried doing that, but I've never seen a variable assigned or accessed via -> before. I haven't the faintest idea as to what it does, and my google-fu is weak.

[DracheReborn]

Oh.

That just means mons is a pointer to a class, and props is a member of mons. These two are equivalent:

  Code:

mons->props
*mons.props


This page might be of interest:
http://www.tutorialspoint.com/cplusplus ... _class.htm

[khalil]

Thanks. I mostly code in java and python, although out of those I prefer python.

[Cedor]

Thanks. I mostly code in java and python, although out of those I prefer python.

They you miss all the pleasure (andfor most pain) to play with the memory :p

[moocowmoocow]

Why do you hate Boris? What did he ever do to you?

[khalil]

The idea is that if he can be killed permanently with enough effort and follows the player from level to level if not permakilled, than there'll actually be a reason to kill Boris.

[reaver]

I'd probably make this a softer cap. If Boris is killed than his chance of reappearing should drop, but it should never actually reach 0. Of course, this would require making Boris reappear when you run away from him first.

[khalil]

I'm working on the running away bit, but changing his chances of appearing after being killed would require somehow changing the weighting of his vault.

[reaver]

I'm working on the running away bit, but changing his chances of appearing after being killed would require somehow changing the weighting of his vault.

Which would be trivial with lua.

[khalil]

@reaver
I also feel a hard cap would be easier to balance. He shows up the average number of time he currently shows up (assuming you kill him every time you see him) and then he's dead forever.
And the fact that I know nothing about lua has nothing to do with that fact.

[reaver]

I also feel a hard cap would be easier to balance. He shows up the average number of time he currently shows up (assuming you kill him every time you see him) and then he's dead forever.
And the fact that I know nothing about lua has nothing to do with that fact.

It's also a lot easier to see tic tac toe is balanced than to see that Chess or StarCraft is balanced (or unbalanced). If you can say with completely certainty that something is "balanced" then it's probably too shallow for any serious play. (Also: hard cap == spoiler)

If you only care about Boris appear on average the same number of times as now, that can easily be calculated too. (Using series IIRC?)

Seriously, I'll contribute the code and the numbers to make the cap soft if you put in the persistent variable, decide how often you want Boris to appear and convince the dev team this is a good idea (because it is, as I said, trivial)

[johlstei]

Oh.

That just means mons is a pointer to a class, and props is a member of mons. These two are equivalent:

  Code:

mons->props
*mons.props


It's even worse than that. If you don't use the arrow, the syntax is even more awkward. The . binds tighter than the *, so the bottom statement parses as:

  Code:

 *(mons.props)


This will fail if mons is a pointer, since it doesn't have any members. So, if you want to avoid the arrow, you'd have to make the order of operations explicit like this:

  Code:

(*mons).props


This is much uglier than just using the arrow.