Ind

This will be handled in https://github.com/HerculesWS/Hercules/issues/246 so I'll mark as approved

This was implemented some time ago (not sure when; would reference the commit otherwise) /* heres the thing we got the feature set up however we're still discussing how to best define the ids, * so while we discuss, for a small period of time, the list is hardcoded (yes officially only those 2 use it, * thus why we're unsure on how to best place the setting) */ /* temp, will not be hardcoded for long thudu. */ if( it->nameid == 7782 || it->nameid == 7783 ) /* for when not hardcoded: add a check on mvp bonus drop as well */ clif->item_drop_announce(mvp_sd, it->nameid, md->name);its missing a criteria (or source/file) to determine what items are to be announced when dropped -- currently only those 2 are there because in the aegis file only those 2 are in it.I'll be moving it into the dev discussion forum

I wonder if it'd make sense to have this in the upcoming mob_db redesign? or its better off on its own file?

what'd be the criteria to judge whether it has valuable items though? (perhaps Mhalicot's "can't delete when invent not empty" would be more practical?) however by the lack of support I'd say it'd be more fitting to a plugin perhaps

humm I wonder would this be implemented in "autobonus" fashion?

colormes needs to be modified (or a new version since we rely on that for hardcoded things)

since normal commands are, its only consistent for them to be too. Approved

could you elaborate? what does feature this entail, and what'd those "monster controls" be?

duplicate (actually the other was a duplicate of this one since this one is older) http://herc.ws/board/topic/4186-party-commands/

not officially no, it'd take one to duck the existent message packets and use one that allows you to send any message (then you can format that to your liking, i.e. include timestamps), given the lack of support for the suggestion I'm moving it to rejected

this has been proposed a number of times throughout time and there are many issues involved that make it hardly practical, besides those already presented in this thread, for example many regional servers have misused (or split) the first few episodes which causes a number of users recollect how things were in episode x y or z differently from those on other regional servers, which'd flood us with "this episode didn't have y", "this episode had x" reports which'd be very troublesome and take a great amount of research from us in order to assert the validity.

I remember trying to fix this some 1 year ago, if I recall properly I remember asserting it not to be fixable -- because the client doesn't do anything when I tell it to remove that pneumas animation

anyone knows if the data is now present in kRO by default?

I think that maybe the reason behind SC_INCALLSTATUS vs AddParamTime was that it'd take 1 timer instead of 6 with the same duration, I have no argument against AddAttrTolerace

I agree on all points except performance, as the formatting is more elaborate it is slower to parse than the previous however we are already have the weapons to fight that -- with the HCache http://herc.ws/board/topic/1389-hcache-item-packages-update/ while HCache is currently being used for item_packages.conf it can be used to make itemdb reading faster than it was before if we prioritise it (or if someone makes a pull request with it)

Michieru has been working (and mostly done I hear) on a super-mega-ultra-plus-hyper-uber long skill update, with the exception whereas rathena's update relies on 2011 data Michieru is constructing the update on 2013 data.

this can be a bit troublesome, while map server can take care of fixing it on /w easily char servers awareness of online characters, which is used to show the online count on "select char server" window, would require some modifications here and there on inter-server packets.

job_db1 overhaul is intended (we have a "centralise" job data discussion which entails this along other job stuff including those messy job names in messages.conf) I'd agree.

I do apologise for my laziness on reading the 4 pages to find out whats up, with that being said: whats really left here? I thought this suggestion had been implemented a while ago

I personally like it but the lack of support makes me wonder whether its worth to put it in the core, perhaps a plugin would do best? (I wouldn't mind coding the plugin myself)

Totally agree, if the syntax changes there won't be backwards compatibility I do think so too.

that rathena branch is kept for reference (merge commits up to that point referenced commits in it), there is no intention to update it. As for merging, we are aware of some features we're lagging behind on them, Michieru has prepared a NPC update which should be out soon, for example.

makes sense to me, i agree.

I think it used to be like that at some point in time, I recall some years ago during eathena you had to for example type @storeall twice because on the first call storage data was not yet present (it'd request it on the first call i think). doing it like that (taking it away from char status) would also expand the storage size limits as my fix to the storagelist packet some time ago allows -- e.g. storages could go up to 32k in size.

interesting, I'll check with fellow colleagues to hear their thoughts