Land Protector Border

Originally posted by [b]Protimus[/b]
This is a very old problem!

I already have the fix in brAthena... and I will send the code in rAthena tomorrow.

Originally posted by [b]Ghost[/b]
Update plox

Originally posted by [b]Protimus[/b]
Fixed in [url="http://sourceforge.net/apps/trac/rathena/changeset/15523"]r15523[/url]

Originally posted by [b]Wildcard[/b]
Reverted those changes in [url="http://sourceforge.net/apps/trac/rathena/changeset/15649"]r15649[/url], since the issue runs deeper than this, and the fix does not cover scenarios where ganbantein is involved (reported by our user Ghost via IRC). This issue, along various others, will require rewriting Storm Gust to its official form (10x10 tiles of 3x3 frost novals pulsing 11 times*).

Related links:
http://forums.irowiki.org/showthread.php?t=41947
http://forum.lumina-ro.com/index.php?topic=10924.0

*numbers arbitrary

Originally posted by [b]benzanaz[/b]
like this link [url="http://forum.lumina-ro.com/index.php?topic=10924.0"]http://forum.lumina-ro.com/index.php?topic=10924.0[/url]

how to fix into this issue?

Originally posted by [b]KeiKun[/b]
bump~

Originally posted by [b]benzanaz[/b]
someone can fix it please

Originally posted by [b]benzanaz[/b]
still wait XD

Originally posted by [b]benzanaz[/b]
still wait... bump

Originally posted by [b]Ind[/b]
benzanaz that lumina bug isn't related to this one at all

Originally posted by [b]benzanaz[/b]
@Ind thank for replay me

i'm worry about the LP do not work perfectly like official (aegis)
inside bug report of lumina-ro is already fixed it,Yes i wanna know how?
the question is how long for rathena to resolve LP bug?

thank you all

Originally posted by [b]benzanaz[/b]
sorry for twice post my internet is laged

Originally posted by [b]benzanaz[/b]
bump

Originally posted by [b]Hobbix[/b]
bump

UP~

Re-uploading the screenshots: Photo by Ghost
[img]http://i.imgur.com/l5gFPro.jpg[/img]
[img]http://i.imgur.com/jF2d4nh.jpg[/img]

Ganbantein skill too..
[img]http://i.imgur.com/fxkT2OG.jpg[/img]

Up~

So this is not an issue with land protector but rather storm gust not having the splash effect, correct? Are there other skills that are missing the splash effect, like if one of meteor storms meteors hits next to lp is it officially supposed to hit the people standing on the first 3 lines of LP cells?

We tested on an old aegis. MS also splashes onto LP if it hits on edge. I have SG and MS working now.

- Save center cell of unitgroup to group->cux and group->cuy[code=auto:0] group->state.guildaura = ( skill_id >= GD_LEADERSHIP && skill_id <= GD_HAWKEYES )?1:0; group->item_id = req_item; group->cux = x; group->cuy = y; [/code]

- reduced SG to 3x3 and init a unit group on each cell in 9x9 area[code=auto:0] case WZ_STORMGUST: { int i; int j; for(i=0;i<9;i++) for(j=0;j<9;j++) skill->unitsetting(src,skill_id,skill_lv,x-4+i,y-4+j,0); } break; [/code]

- Use the group->cux and group->cuy to determine if SG or MS should hit instead of targets cell.[code=auto:0] // This enables SG and MS to splash onto LP [GrumpyPanda] if (group->skill_id == WZ_METEOR || group->skill_id == WZ_STORMGUST){ if(map->getcell(bl->m, group->cux, group->cuy, CELL_CHKLANDPROTECTOR)) return 0; else{ // Do nothing } } else if( !(skill->get_inf2(group->skill_id)&(INF2_SONG_DANCE|INF2_TRAP|INF2_NOLP)) && map->getcell(bl->m, bl->x, bl->y, CELL_CHKLANDPROTECTOR) ) return 0; //AoE skills are ineffective. [Skotlex] [/code]

This requires changing MAX_SKILLUNITGROUP to something a lot bigger, a single SG takes 81 unitgroups now. I set mine to 810 for now.

Needed to add a check for walls when initializing the 9x9 SG
[code=auto:0] case WZ_STORMGUST: { int i; int j; for(i=0;i<9;i++) for(j=0;j<9;j++) if(path->search_long(NULL,src->m,x-4+i,y-4+j,x,y,CELL_CHKWALL) ) skill->unitsetting(src,skill_id,skill_lv,x-4+i,y-4+j,0); } break; [/code]
If this ever gets fixed could prolly think about making a conf option, people are so used to the incorrect LP and might prefer it.

Is SG or other AoE spell suppose to have a loop check for the duration of the skill?

How about this scenario:

SG was casted, LP was casted = SG deleted.
Deluge was casted, and SG is still in effect, however SG was deleted by LP.
It renders SG not working.

[quote name="Poison" timestamp="1402310288"]
Is SG or other AoE spell suppose to have a loop check for the duration of the skill?

How about this scenario:

SG was casted, LP was casted = SG deleted.
Deluge was casted, and SG is still in effect, however SG was deleted by LP.
It renders SG not working.[/quote]

Need some aegis testing with that.
Imo LP shouldn't kill the skill units, ganbantein does that. LP just makes land targeted magic skills ineffective on the area.
atm its set to kill all exept traps/dances/songs on cast, but I feel like its done for no reason. (if you cast LP first,then SG, then remove LP the SG will damage the target even atm)

Some people were asking for a diff so here it is [url="http://pastebin.com/TPpESqM7"]http://pastebin.com/TPpESqM7[/url]
I don't really make diffs ever so no idea if its any good.

Up~

Bump!

UP~

~ Up ~

Up~

Border of Land Protector is 'Fake' for some offensive AOE skills

Sanctuary:
[img]http://i.imgur.com/lMIbexi.jpg[/img]

Magnus:
[img]http://i.imgur.com/tZXOrPa.jpg[/img]

Ganbantein Border:
[img]http://i.imgur.com/fxkT2OG.jpg[/img]

Skills that are [b]working[/b] on Land Protector border:
Storm Gust
Meteor Storm
Lord of Vermilion
Sanctuary
Magnus
Bomb (Demonstration)



If you want to check something with me regarding skills if working at the border of LP just reply to this topic.

Up~

Can I bump this again? :P

Bump?

Oh, so it seems the border doesnt really have lp effect at all. sanctuary, lov etc dont have splash. I guess SG also hits on 2nd line of cells because it has that 3x3 splash.

What happens if you ganbantein the middle and then cast sactuary, does the new inner border also have the same behaviour for non splash skills or is it the initial outer border only. Splashing skills like SG/MS will work of course even on the inner border, but what about sanctuary/lov? Just wondering cause those cells are initially blocking aoe unlike the outer border.

What happens when another sage casts LP that covers the border of the other LP, is the border removed or is it treated like there was no lp on the border?

Not true actually. All the skills Kyeme listed do have splash. For example Sanctuary also heals me one cell next to it.

Sanctuary(and lov? and pretty much everything ground aoe) are also 3x3 splash for each cell exactly like SG? Has it always been like that? Thought it was SG only that had the known "wrong implementation".

so pretty much there should be no check at all wheter the target player is on LP cell (how it is currently checked), just a check for each cell of the skill whether it is allowed to initialize on said cell or not?

Sanctuary splash is actually already implemented correctly (doing 3x3 splash). I tested around with this already.

The code in fact already seems to have the correct structure for skills:
- each unit group has multiple units setup as splash or alternatively as "special" (like Sanctuary)
- each unit of a unit group has a splash range

For example take a look at Santuary:
70,0x83, , [color=#008000]-1[/color], [color=#0000ff]1[/color],1000,all, 0x018 //PR_SANCTUARY

The [color=#008000]green[/color] number is the layout, -1 means special since it's a cross and no square. The [color=#0000ff]blue[/color] number means the splash effect of each unit. 1 = 3x3.

Basically to fix it, these steps are needed:
1. Test for every skill how far it can splash into land protector to determine the official splash range.
2. Update skill_unit_db.txt to have layout and range specified for each skill correctly according to tests in #1.
3. Update Land Protector to only protect from [color=#008000]units[/color] being placed but not from [color=#0000ff]splash damage[/color] of units outside land protector.
4. Restructure code so you can define knockback effect per-unit rather than per-unitgroup.

Yeh I was also meddling around with them. This way its easy to fix the lp behavior.
I had no idea there was separate splash and layout already implemented, I wonder why sg for example was set to 0 layout and huge splash by default even though its a known bug. Also found out when testing sanctuary and realized it was splashing on hercules.

Removed the old damage protection and just added a land protector cell check before initializing units. everything seems to work just fine so far.

Why would you change it so knockback can be defined per unit though? Knockback seemed to be working like before, sanctuary and SG at least. Official SG knockback behavior implementation or maybe some renewal skill?

Well I wouldn't call it "easy" but "easier".

The basic way is as you said, just remove all the LP damage protect code and check it during placement already and just not place the unit at all (it also saves a lot of performance, no point in having units that are unable to deal damage anyway).

The hard part comes when it comes to testing all the skills in regards of how they should work against a wall and against icewall and how far their splash area actually is.

Also it could be that we might need a larger layout than 11x11 (max at the moment).
[quote]
Why would you change it so knockback can be defined per unit though? Knockback seemed to be working like before, sanctuary and SG at least. Official SG knockback behavior implementation or maybe some renewal skill?[/quote]
I did some tests yesterday and actually the knockback direction is already per-unit rather than per-unitgroup.

We mainly need it for SG, not sure if it's relevant for other skills. Right now we simply defined SG's knockback as "random direction" but on officials it's more like "Away from unit center", but when there are multiple SG units any of the units next to the target can determine the direction, so it's seemingly random. It gets relevant at the "border" however. If you are standing at the SG border you should always be knocked to the outside according to my current information. Also if you remove the center of SG with Ganbantein, SG will become a "suck into the center" effect.

That will be super hard to implement because right now we process all units from south-west to north-east, which means the knockback will always be "NE" when there are multiple SG cells around the target, rather than it being random. I need to look into that more... maybe it could be done by simply creating the units in a random order so they have a random order in the unit database.

If it gets too complicated I guess I'll ignore that for now and fix it after LP was fixed.

Actually, nevermind, I just tested on official servers and it REALLY always knocks back to the NE when in the middle of SG even on official servers! Lol! How wrong our implementation is.

I fixed this on rAthena now, should be fairly easy to merge I think:
[url="https://github.com/rathena/rathena/commit/e7e8b54"]https://github.com/rathena/rathena/commit/e7e8b54[/url]

Ye lotsa testing for the splashes will be needed to correct database. I was told even songs/dances give the effect one cell before entering area on iRO.

However, this was mentioned in the thread already.
What happens officially when you cast SG on LP and then immediately remove the LP? If the SG units are active after that then this implementation would be wrong and they should still be initialized even though they will initially be deactive on LP.


///////
Going slightly off topic with this SG talk xP
regarding SG knockback you could check SG cells around target and then add the opposite direction to allowed direction list then take a random out of that.
you had a nice illustration on rA boards or somewhere about the knockback directions and heres some pseudocode on what I was thinking. not home so cant test though. Also not sure if there is some simple way to check if theres a unit of type A on cell x,y already implemented.
[code=auto:0] count, i = 0 dir[8] = { } opp_dir = {7, 8, 1, 6, 2, 5, 4, 3} // Opposite directions of cells in the order we check them for each cell around target{ // Order = SW, S, SE , W, E, NW, N, NE if SG unit in cell{ dir[ count ] = opp_dir[i] count ++ } i++ } knockback direction = dir[ rand(count) ] [/code]

LP removes the units completely so it won't deal damage even if you remove LP. You can see that clearly with skills that have single units visible like Sanctuary and Crimson Fire Formation. You can see that it's "cut off".

And since "NE" SG knockback is official no reason to implement complicated algorithm for it.

Read through the commit.
Shouldn't the check be in skill_unitsetting and not initilize the unit on LP cell at all? Thats how I personally did it when meddling around. If its done in skill_unit_onplace / sub_onplace like that its only checking if the unit is on LP and making it not deal damage but the unit was still initialized on LP, its only triggered when something is in units splash range. Would also be better performance wise if those units dont get initialized at all, like you said?


Yeh, didn't see you posted that the NE is official. Was based on that illustration of yours. Ill prolly try to do something for myself though, I prefer that way.

It is done in skill_unitsetting, it goes via the skill_cell_overlap check (as it should be).[code=auto:0] map_foreachincell(skill_cell_overlap,src->m,ux,uy,BL_SKILL,skill_id, &alive, src);[/code]
There are a lot of unnecessary checks now, but I decided to keep them in as they improve the performance a little.

The damage checks could be completely removed, but I just wanted to be on the safe side in case something doesn't get removed properly or fast enough.

ah, those extra checks got me confused and I missed that. but yeah I agree its a good idea to keep them just to be secure.

[color=rgb(40,40,40)][font=helvetica, arial, sans-serif][size=3]Fixed in [/size][/font][/color][url="https://github.com/HerculesWS/Hercules/commit/26cdd53ef2d633e6b7d886bb720e645d85d08e43"]https://github.com/HerculesWS/Hercules/commit/26cdd53ef2d633e6b7d886bb720e645d85d08e43[/url]
[color=rgb(40,40,40)][font=helvetica, arial, sans-serif][size=3]Special Thanks to Playtester and GrumpyLittlePanda [/size][/font][/color]