Variables/list/for equivalents in area scripting?

[Nylo]

I've got a section of code I'd like to integrate into an area, and I'm wondering if it's possible to code directly or indirectly with the the limited area scripting.

It takes a function,

Code: Select all

def pcInRoom(vnum):

which returns the number of PCs in the room as a list. Then it's sorted through with

Code: Select all

def mobDifficulty(cRoom, difficulty=0):
     for occupant in pcInRoom(cRoom):
          difficulty = difficulty + getLevel(occupant)
     return difficulty

This is just concept code, I still need to refine the difficulty algorithm. The result is then used to select from a list of monsters;

Code: Select all

diff = mobDifficulty(10000, 100)
if diff < 125:
  mSpawn(1000, 120) #(mobile vnum, room vnum)
elif diff < 150:
  mSpawn(1001, 120)
...
else:
 mSpawn(1010, 120)

I'm thinking this is something that would have to be hardcoded, but if there's a way to do solely in area code, I figure someone here would know!

[Solaghar]

You'd probably have to do something like this... this is just a simple demonstration...

Code: Select all

greet_prog 100~
if level($n) > 40
  mpmload MOB1 (a tough mob)
  mpmload MOB1
  mpmload MOB1
else
  if level($n) > 30
    mpmload MOB1
    mpmload MOB1
  else
    if level($n) > 20
      mpmload MOB1
    else
      mpmload MOB2 (an easier mob)
    endif
  endif
endif

Since it would trigger independently for each person who entered the room there'd be no need to add all their combined strength together to compare it to a list. You could also do it by having an invisible mob set qbits on itself.

greet_prog 100~
if level($n) > 40
mpadd self questr 0 10 4
nextstep
else
if level($n) > 30
mpadd self questr 0 10 3
nextstep
endif
endif
~
intercept_prog nextstep~
if questr(areavnum,0,10,self) > 3
mpmload MOB1
else
mpmload MOB2
endif

So essentially each person who enters adds a number to the qbit of the mob. Then it triggers a checking program on itself that checks its qbits and could load a mob based on the 'difficulty' of the players in the room. You'd have to add some checks for the mob in the room on the nextstep to ensure that it wouldn't trigger multiple times for each person who entered but the result would be about the same and you could use it to trigger one big monster rather than say, multiple groups of the same monster.

[Nylo]

I don't have a lot of experience with this yet, but it looks like it's checking the level of each person, and either spawning one mobile for each, or spawning one based on the level of the first person to trigger the script. Am I reading that right?

If so, that's not quite the idea I was looking for - what mine does is check the level of each one, add them to a variable, and based on that variable chooses which one to spawn. The program you give would serve the same function if there was just one player, but when a group goes through it has a much different effect.

If the triggering pc is level 50, it spawns the high level mob. But if it's a party of 50's, it still spawns that mob, correct? This one would, instead, spawn a different one based on both the level of the party and the size of the party. For example, with the given algorithm, a group of two level 50s would get the same creature as a group of five level 20s would.

Of course it's quite possible I'm not understanding the way the script executes.

What I want to do might very well not be possible in area code - if not, that's fine, I'll plan it a bit differently.

[Solaghar]

Then you want to use something like the thing that tracks qbits, my second example. A qbit can stand for whatever you want it to stand for. So you have an invisible mob that adds a qbit for the level of everyone who enters the room. Say it adds 1 qbit for every 10 levels. So you have two level 50s come in, your invisible mob would have 10 bits set on him. Then you have a delayed reaction greeting program, just a pause of one second and it triggers the mob loading program. if the qbits on itself > 9, load a tough mob, 8, load a different mob, 7, 6, 5, you could set a different mob for each possibility. So now the invis mob checks its own qbits. If its qbits are 10, load big tough mob. If two level 10s come in, it has a qbit of 2. Load a small, easy mob. It'd be a pretty simple program, just like I posted above...

[Nylo]

I see it now, yeah. mpmadd instead of mpmset. That looks like it should fit perfectly, thank you!

[Solaghar]

No prob! I'm heading to sleep now but if you want tomorrow I can code up an actual working model for you, or if you do it I can at least check it over for you if you post it, or throw it up on the test port and see if it works!