Ind

nope, still broken D: clif_skill_delunit (ZC_SKILL_DISAPPEAR) is unable to delete pneuma, so the visual effect remains even after the server has deleted it because of landprotector.

hmmm O__O I reproduced...perhaps they fixed it when the pneuma effect was changed, I'll give it a try with the unit deletion stuff

ohoho as i understand that kills the proposal, indeed

mapindex_name2id didn't work on plugins before so I'd be safe to say the plugin didn't fully work before the update either.... Replace if( HPMi->addCommand != NULL ) {//link our '@sample' command HPMi->addCommand("mapmoblist",ACMD_A(mapmoblist)); }with addAtcommand("mapmoblist",mapmoblist);//link our '@mapmoblist' commandandmapindex_name2idwithmapindex->name2idas for this stuff battle = GET_SYMBOL("battle");you'll need to add map/mapindex/mob as well (and their includes)

To use the disabled_skills info, it'd be like (just drafted) int i, type; for(i = 0; i < map->list[sd->bl.m].zone->disabled_skills_count; i++) { if( (type = status->skill2sc(map->list[sd->bl.m].zone->disabled_skills[i]->nameid) ) && sd->sc.data[type] ) { status_change_end(&sd->bl, type, INVALID_TIMER); } }I think what I'm proposing would be more like a bugfix than related to this suggestion, since without it if you have assumptio blocked in prontera you can get inside with the effect by casting it before warping... wouldn't it be confusing to users to maintain the icon? (I'd say it'd be interesting however since it'd mean once you leave the map/zone the effect would resume)

ooh thats a very good idea, haven't thought of that

kinda, for example HPMi->addCommand was replaced with something else, also its missing hpmdatacheck include...I could be of more help if you could provide the compiling errors

Rejecting due to lack of support/interest, also seems more fitting to be a plugin

(there are too many tables I'll post individually on each whenever I have time/the patience to research) ItemLog I think its overly redundant (as in saves data that is provided elsewhere and thus just duplicates them). We have index, no idea whats Ver/SID, we have action/logtime, I find ip unnecessary/wasteful (if you want the ip you can check whoever logged in on that account at such time with loginlogs, if you find that action tiresome you can write your control panel to mix the two data when looking at picklogs), no idea whats eventx/y, I don't see why it needs srcAccountID/srcAccountName/srcCharName/srcJobType (same for destination) while the char id from both parties is enough to retrieve all such data from other tables (again if you find the action tiresome you can have your control panel link the data for you), ItemName I find wasteful (you can cross with your item db to figure the name or have your control panel do that), I don't see the point of price while there is zeny log (and the action of such item in picklog would be as purchased, then just need to lookup the timestamp in zenylog -- again if its a tiresome operation your control panel can be set to do it for you), with that in mind, same for auctionID, ItemBuyCash too, same for zeny, no idea whats DestZeny for, don't see the point of storing ItemHireExpireDate (expire_time) on itemlogs -- to begin with expire_time items are not tradeable and if you wanna log when someone got them whats the point? their duration is set wherever they're obtained, no idea whats bizType.

does it really need a new table? can't we share picklog? (with a new type)

I see...I think we can manage that, something like if ( itemskill == GD_EMERGENCYCALL ) { switch( level ) { case 1: limit = 7; ... } }

I see your point, given there hasn't been support I'll check with fellow developers

interesting...I wonder, would it be the same result if instead of a removed_status column we instead checked what status are inflicted by a skill and then cancel these on warp? e.g. MG_ENERGYCOAT is blocked in prontera, so if you warp in prontera with SC_ENERGYCOAT it cancels it -- item-inflicted status would still the proposed column however since there is current way to tell what status a disabled_item inflicts

Moving into the development forum

Flagging as approved since its set to happen

I have a 2006-08-14 working xray I can send you if you want (I don't remember whats diffed into it however, and I don't have one without being diffed), I used it recently to test 2006-compatibility on Hercules so I can at least say its working.

Approved, will be in the repo within minutes

Its hardly feasible the actions are many and logging them even if with a single player online would be catastrophic (picture 50 monsters in a map moving and doing stuff even while the player is sitting still, that alone could result in some ~100 queries a second depending on how often the monsters walk, consider that 1 cell - 1 action, so moving 7 cells - logging 7 actions), the gdb data is as best as it can get in my opinion.

Question is this necessary anymore? now that there is: // Limits use of blank (transparent) pixels in guild emblems to a set// percentage of the total.// Official servers do not enforce this technically to date, but some disallow// use of blank emblems in their rules. (Note 2)// A value of 100 (allowing 100% blank pixels) disables this check.// NOTE: Enabling this option slightly degrades performance.client_emblem_max_blank_percent: 100

I think it has been implemented already, isn't it 'mob_boss'?

Like http://herc.ws/board/topic/2498-add-another-class-type-for-rebellion-supernovice-ex-kagerouoboro/ this feature will be achievable once https://github.com/HerculesWS/Hercules/issues/246 is performed, so I'm marking it as approved

Due to the lack of support I'm rejecting it

Also keep in mind that players are used to expect autotraders in online counts, so those unaware that they are not counted will believe the server has less players than it actually does.

I'd so much like those, I hate it when I'm debugging stuff with quests and I need to logout only so I can delete the quests from the sql table, but interest has been nonee D: I'll see with fellow colleagues what they think

I wonder if theres a point to it? I'm under the impression we could have the items use GD_EMERGENCYCALL and just tell the client that the user is casting GD_ITEMEMERGENCYCALL instead (otherwise we'd be duplicating GD_EMERGENCYCALL code only so that GD_ITEMEMERGENCYCALL is the id sent to the client, and we can mimic that without duplicating I believe)