Script Command : setmobdata / getmobdata

Emistry

Emistry

Support Leaders
Messages
526
Points
0
Location
Malaysia
Github
Emistry
Emulator
I believe these 2 commands is a must for Hercules in the near future, at least some similar script command need to be developed and added into the Hercules emulator.

This is because I have seen official server to released some contents that might required the uses of these script command.

For example:

  • Faceworm Nest Memorial Dungeon
  • Toy Factory Memorial Dungeon
  • etc.


There 2 quests I noticed that it required the script to be able to alter the data of the summoned monsters.

Faceworm Nest Memorial Dungeon - the Boss MaxHP is affected by number of players who participate in the quest. 
 
Faceworm Boss MaxHP = Origial Boss MaxHP + ( 2,000,000 * no. of player );
NPC can "cast skill" to damage the Boss.
Faceworm Boss could change to another form ( probably another mob id but HP remain unchange I guess )
Click to expand...
for the Toy Factory, I not sure it can be category into the same script command or not, but it's also part of "alter monster data" i guess.

Boss Celine Kimi could be changed to "NPC" state when certain condition are meet.  
 
Ex: HP gap between real Kimi and fake Kimi more than 20% or distance is too far.
The Monster will be changed into NPC state where player cant attack the Monster.
Click to expand...

previously, the setmodata / getmobdata is implemented through the MobController script, but the MobController script so these setmobdata/getmobdaat was never officially added into the script.

I think it's time for Hercules to add these script commands.

* I know rAmod/eAmod have a script command for monster that work quite similar for setmobdata() but they dont have getmobdata() I believe.

So, but I think setmobdata / getmobdata would be better than having a custom monster script command to spawn a monster that have altered information.

Extra :

http://ea.dj-yhn.com/index.php?c=setmobdata

http://ea.dj-yhn.com/index.php?c=getmobdata

 
Last edited by a moderator:
I support this ...

(Specially the rA commit, probably merge it? Or make it even better if possible?)

 
Last edited by a moderator:
bump
default_wub.png


 
I 100% agree, this is defintely something we should have. Especially if it's going to be needed in the future.

 
oh someone link to me to this topic, I just found this

I always thought modify a monster's attribute is a custom feature

so I always thinking of writing it as plugin only

but rathena have it 1st

ok, upon closer inspection, I found that rathena way's of implementing them are less accurate

com'on, once the monster is spawned, modify the monster's str will not increase its atk

the same as increasing its agi will not make its flee higher

adding those stats, like vit will only make the stun duration decrease, and int make freeze duration decrease only

quite useless

and Oh My God ? setunitdata can modify all different types of things

but the way they write it, cannot use constants

this is bullshit

anyone who think this kind of modification is good enough to merge into hercules, please rethink again

I'm going to write a better one

*setmobdata/getmobdata

I already have a plugin, going to make it into patch soon because rathena already have it, I'll pull request for hercules soon

*setmoblook/getmoblook

I think the md->state.xxxx should go different script command with md->vd.xxxxx

so all md->vd.xxxxx will go into this script command

currently rathena mix them all together, but I think they should be separated

*mobevent <GID>, <type>, <event label>;

this is missing from rathena I think

this will make the current monster <GID> to run <event label> according to <type> happens

currently I can think of

MOBEVENT_ATTACK -> when monster attack an unit

MOBEVENT_DAMAGE -> when monster hit by anything

MOBEVENT_DETECT -> when monster sees an enemy

MOBEVENT_KILL -> when monster killed a unit

MOBEVENT_SKILL -> when monster cast a skill ( the skill cast adjusted in dbremob_skill_db.txt )

MOBEVENT_RANDOMWALK -> when monster finished a random walk

MOBEVENT_SUMMONSLAVE -> when monster summon slaves

MOBEVENT_LOOT -> when monster loots an item

MOBEVENT_EMOTION -> when monster doing an emotion

MOBEVENT_TRANSFORM -> when monster transform into another monster (eg: pupa)

... maybe more

example:

mobevent .@id, MOBEVENT_DETECT, strnpcinfo(0)+"::OnDetect";when the monster detect an enemy, it will run that npc OnDetect: labelit will return $@mob_detect_id variable, GID of the unit

.

the rest, I think can follow rathena, but hercules version will have a complete list of constants

I prefer to have a script full with constants, it will increase readability

.

I'm going to mark this one as rejected, and propose a better system like I stated

and when I do it, I'll do little by little, system by system

I also don't like aleos always put everything into 1 single patch and make big release

this will make others harder to find the code

 
Last edited by a moderator:
Aeromesi said:
I'm curious @@AnnieRuru, you  helped make the getmobinfo and setmobinfo for Hercules, are these other commands like this one and other missing ones in rAthena too complex for you to help us out? D:
Click to expand...
I believe, We never needed it, thus is not there

 
setmobdata and getmobdata was made by [Lance], was in eathena all the while until ultramage took it out

https://eathena.ws/board/Eathena-Mob-Controller-System-t194375.html

and I noticed rathena copy almost all the fields in that patch

I always knew that patch isn't complete, that's why I trying to rewrite that patch

at that time, mob controller system isn't needed, was considered custom

but right now, this is official, as newer instance script might want to use it, thus its needed to be merged

and nah ... I was just inactive at that time, it isn't just me can write it, many people also can write them

 
like I said, I'll do this very very slowly

so today I submit this ... the 1st one of that ... awesome yet inaccurate ... system from rathena

https://github.com/HerculesWS/Hercules/pull/871

and immediately, now you see, their getunittype is flawed

their getunittype return values are

0 - Monster 1 - Homunculus 2 - Pet 3 - Mercenary 4 - Elemental 5 - NPCI have no idea how they use this valueYet ? why PC type is not included ?? omfg ...

if Haru permit my pull request, then ours will follow the types from existing *getmapxy

then can do like this

Code: 
OnPCDieEvent:	if ( !killerrid ) end;	getmapxy .@map$, .@x, .@y, getunittype(killerrid), killerrid;	dispbottom .@map$ +" "+ .@x +" "+ .@y;	end;
 
I hope this will be pushed through. It's a good function to be implemented most importantly in making events and instances.

 
You must log in or register to reply here.
Back
Top