Land Protector Border

Needed to add a check for walls when initializing the 9x9 SG

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;

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.

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.

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 http://pastebin.com/TPpESqM7
I don't really make diffs ever so no idea if its any good.

Edited by GrumpyPanda, 10 June 2014 - 11:39 AM.

Up~

Bump!

UP~

~ Up ~

Up~

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

Sanctuary:


Magnus:


Ganbantein Border:


Skills that are working 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?  

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, , -1, 1,1000,all, 0x018 //PR_SANCTUARY

The green number is the layout, -1 means special since it's a cross and no square. The blue 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 units being placed but not from splash damage 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).

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?

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.

Edited by Playtester, 14 November 2014 - 08:55 AM.

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:
https://github.com/r.../commit/e7e8b54

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.

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) ]