Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds UDT_MOBID for getunitdata & setunitdata, which retrieves actual mob id #2382

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bWolfie
Copy link
Contributor

@bWolfie bWolfie commented Feb 21, 2019

Pull Request Prelude

Changes Proposed

Adds UDT_MOBID for getunitdata() and setunitdata.

This is necessary because getunitdata(<Mob GID>, UDT_CLASS) retrieves the Sprite ID for BL_MOB. Which means if you use it on a mob which was generated using db\mob_avail.txt, then you will not get the actual Monster ID.

Issues addressed:
N/A

@HerculesWSAPI
Copy link
Contributor

This change is Reviewable

@AnnieRuru
Copy link
Contributor

AnnieRuru commented Feb 21, 2019

actually I was rewriting the hercules unit controller system
stable...AnnieRuru:34-setunitdata
and this fall in 1 of my TODO list

about this issue,
case UDT_CLASS: script_pushint(st, md->vd->class); break;
it should return md->class as you said
http://upaste.me/ed6c2196382229bc7#LC281
and should have another UDT_SPRITEID to return md->vd->class

after all, my original intention is to have setmobddata and setmoblook separated
http://herc.ws/board/topic/8974-script-command-setmobdata-getmobdata/?do=findComment&comment=65553

*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

although now I also convince ... yeah having all in 1 might be better

yes, I am totally revamp this unit controller system ...

@bWolfie
Copy link
Contributor Author

bWolfie commented Feb 21, 2019

One more thing which is missing is unable to retrieve the the NPC is attached to. I.e. if you want to kill monsters using killmonster(), you can't retrieve the "Npc::OnEvent" for the mob.

@AnnieRuru
Copy link
Contributor

I never encounter this problem, so its probably your bad scripting method
should place each group into separated event labels
and if you want to kill all monsters in the map, there are *killmonsterall and *killmonster with "All" flag

custom, so I make a plugin

#include "common/hercules.h"
#include "map/mob.h"
#include "map/script.h"
#include "common/HPMDataCheck.h"

HPExport struct hplugin_info pinfo = {
	"getmonsterlabel",
	SERVER_TYPE_MAP,
	"0.1",
	HPM_VERSION,
};

BUILDIN(getmonsterlabel) {
	struct mob_data *md = map->id2md( script_getnum(st,2) );
	if ( !md ) {
		ShowWarning( "buildin_getmonsterlabel: Error in finding object GID or target GID is not a monster.\n" );
		return false;
	}
	script_pushconststr( st, md->npc_event );
	return true;
}

HPExport void plugin_init(void) {
	addScriptCommand( "getmonsterlabel", "i", getmonsterlabel );
}

and get the script done as ...

prontera,155,185,5	script	qwer	1_F_MARIA,{
	monster "this", -1,-1, "--ja--", PORING, 10, strnpcinfo(NPC_NAME)+"::Onaaa";
	monster "this", -1,-1, "--ja--", POPORING, 10, strnpcinfo(NPC_NAME)+"::Onbbb";
	end;
Onaaa:
Onbbb:
	end;
}

prontera,160,185,5	script	asdf	1_F_MARIA,{
	.@count = getunits( BL_MOB, .@mobid, false, strnpcinfo(NPC_MAP) );
	for ( .@i = 0; .@i < .@count; ++.@i ) {
//		sscanf getmonsterlabel(.@mobid[.@i]), "%s::%s", .@npc_name$, .@label$; // f*cking sscanf doesn't work
//		if ( .@npc_name$ == "qwer" ) // alright, let's use regular expression
		if ( getmonsterlabel(.@mobid[.@i]) ~= "([^:]*)::([A-Za-z_]*)" )
			if ( $@regexmatch$[1] == "qwer" )
				unitkill .@mobid[.@i];
	}
	end;
}

by the way this question should be asked on the forum ....

@AnnieRuru AnnieRuru added type:enhancement Issue describes an enhancement or feature that should be implemented component:core:scriptengine Affecting the script engine or the script commands status:on-hold The issue was put on hold until another issue is solved or a feature is implemented labels Feb 26, 2019
@Emistry Emistry added the component:documentation Affecting the documentation in the doc/ folder label Feb 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component:core:scriptengine Affecting the script engine or the script commands component:documentation Affecting the documentation in the doc/ folder status:on-hold The issue was put on hold until another issue is solved or a feature is implemented type:enhancement Issue describes an enhancement or feature that should be implemented
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants