SoF support

[Andrew80k]

Would it be possible to get a SoF support forum going? That way we can segregate the SoF issues from normal Titanium issues? Just a thought.

Anyway, I'm converting my server to SoF and I'm having a Buff issue. I keep getting a struct size mismatch. It's expecting 32 and got 36 though I see from the log that it is loading the SoF patch, where I presume the structs are coming from. It's in the SpellBuffFade_Struct that I'm getting the error. Basically my buffs are cast and land but immediately fade. This is when I get this error. Did I miss something somewhere?

[trevius]

I don't think an entire SoF support section is really needed, though it might not hurt to have one temporarily while the major stuff is getting worked out.

Yeah, there are still many minor struct issues with some of the non-critical systems. Buffs are still actually working, they just appear to fade on the client. If you zone, they should show up again I think. But, you cannot click them off. This is a known issue and is tracked in the SoF development thread here:

http://www.eqemulator.net/forums/showthread.php?t=27429

Really, it probably wouldn't be too hard to get it corrected, so maybe I can take a look at it tonight and get it fixed quickly and update the SVN if so. We are aware of many of the lower priority problems, but I personally have been focusing on the ones that are listed as higher priority, because they are higher priority

We are basically just knocking one thing out at a time. I haven't put an update up in the past few days mainly because I have been trying to work on stuff like AAs and Grouping that aren't functional at all yet in SoF and are critical to using the client. I have made a little progress on grouping, but I still need to figure out the group update packet structure before it starts working. It seems like they may have completely changed how group updates work, so that might take a while to finish.

Really, the best solution for reporting issues with SoF may be for me to create a thread in the bug reports section of the forums where I keep the first post updated with the current status of bugs and update any new ones that people report in that thread. I will get that thread started now actually.

Here is the link to the new Bug Report thread for SoF:

http://www.eqemulator.net/forums/sho...424#post165424

[Andrew80k]

thanks. I took a quick look at the structs and it looks ok. It's 36 bytes, which is what the client sends, but for some reason, the server appears to be using the titanium struct.

[Andrew80k]

Updating a single bug thread might be a lot of work. I think it would be better to have a SoF development section that could be used to track this, at least until the server for that client is mature enough.

[trevius]

I am pretty good at keeping track of things and making sure they are updated regularly. If an admin wants to add a temporary section for it, that is fine too, but I think things would be just fine using a single thread or 2 for it.

When I created the SoF_struct.h file, most of it was a direct copy from the Titanium one. Then, I went through and updated all of the structs I could find to match with what ShowEQ showed for them and still tried to match what Titanium showed where I could so that it would be a logical blend of the 2 that would hopefully work.

If the SoF struct is correct and it is expecting the Titanium struct, the simple explanation is that we only need to create an encode/decode for that packet. It should be pretty easy for me to do that later. I have a basic write-up wiki page on how to do encode/decode for this type of stuff if you wanted to take a stab at it.

Here is the wiki page for encode/decode:
http://www.eqemulator.net/wiki/wikka...a=EncodeDecode

[Andrew80k]

gotcha. that's what I was looking for yesterday when I was fooling around with it.

[trevius]

Andrew80k, or anyone else that wants to try it, here are the encodes/decodes for buff related structures. Simply add these to the files listed (anywhere in the file near where the other similar encode/decode is) and then recompile and test if it works:

SoF_ops.h

E(OP_Buff)
D(OP_Buff)

SoF.cpp

ENCODE(OP_Buff) {
        ENCODE_LENGTH_EXACT(SpellBuffFade_Struct);
        SETUP_DIRECT_ENCODE(SpellBuffFade_Struct, structs::SpellBuffFade_Struct);
        OUT(slot);
        OUT(level);
        OUT(effect);
        OUT(spellid);
        OUT(duration);
//	OUT(playerId); // Global ID of Player that cast the buff - This isn't set to be used yet
        OUT(slotid);
        OUT(bufffade);
        FINISH_ENCODE();
}

DECODE(OP_Buff) {
        DECODE_LENGTH_ATLEAST(structs::SpellBuffFade_Struct);
        SETUP_DIRECT_DECODE(SpellBuffFade_Struct, structs::SpellBuffFade_Struct);
        IN(slot);
        IN(level);
        IN(effect);
        IN(spellid);
        IN(duration);
//	IN(playerId); // Global ID of Player that cast the buff - This isn't set to be used yet
        IN(slotid);
        IN(bufffade);
        FINISH_DIRECT_DECODE();
}

If the SoF structures I have set in the SoF_structs.h file are correct, these encodes/decodes should probably work to fix all current buff related issues in SoF. If no one is able to try it and confirm if it fixed it or not before I get home, I will be testing it myself later. If this works when I test it, I will get it updated on the SVN ASAP.

I am sure there are probably a few more encode/decode structure issues like this from the structures I modified for SoF based on what the ShowEQ structs were set to. By adding in the proper encodes/decodes, I think it should be able to knock out most of the smaller issues like this pretty quickly. I am not 100% sure that both OP_Buff and OP_BuffFadeMsg need both an encode and a decode, but it doesn't hurt to have both set that way. I would have to check how they are sent on Titanium and/or EQLive to see for sure if both are needed like that.

[Andrew80k]

I made a little progress I think. I got the size mismatch errors to go away, but the buff still fades as soon as it is cast, and unfortunately, it really does fade. But I think that is actually progress. I'll continue to fool with it until I figure it out.

[trevius]

You tried the changes I posted and that still happens? I will play with it when I get home. I imagine it shouldn't be hard to get this working properly.

[Andrew80k]

Working on this now. I got it compiled and installed, starting the server. Will get back to you in a few.

[Andrew80k]

Originally Posted by trevius

You tried the changes I posted and that still happens? I will play with it when I get home. I imagine it shouldn't be hard to get this working properly.

No mine were a bit different and I had actually come up with what I thought was wrong with my initial foray into this. I was coding it similar to what you have now when you posted.

[Andrew80k]

Originally Posted by Andrew80k

No mine were a bit different and I had actually come up with what I thought was wrong with my initial foray into this. I was coding it similar to what you have now when you posted.

Now outbound is the wrong size. I'll fool with it some more tomorrow if you don't fix it tonight.

[trevius]

I got the encode/decodes working fine, but for some reason, the client thinks that the duration should be 0 still. We are working on figuring out why, but nothing solid yet. May be something to do with the new blocked buffs stuff that was introduced shortly after Titanium came out.

Also, I edited the encode/decodes that I posted earlier in this thread. I had them all wrong. The BuffFade_Struct is actually for OP_Buff, which was a little misleading. The OP_BuffFadeMSG actually has it's own struct and is only for sending the spell wear off messages to the client similar to a special, formatted, or common message packet.

[Andrew80k]

Originally Posted by trevius

I got the encode/decodes working fine, but for some reason, the client thinks that the duration should be 0 still. We are working on figuring out why, but nothing solid yet. May be something to do with the new blocked buffs stuff that was introduced shortly after Titanium came out.

Also, I edited the encode/decodes that I posted earlier in this thread. I had them all wrong. The BuffFade_Struct is actually for OP_Buff, which was a little misleading. The OP_BuffFadeMSG actually has it's own struct and is only for sending the spell wear off messages to the client similar to a special, formatted, or common message packet.

Yeah I figured out the OP_Buff stuff. I haven't had time to work on it much. I was thinking that the blocked buffs was going to give us some problems when the structure changed. The decodes seemed to work ok for me, but the encodes that I have aren't correct. Did you post your changes to the svn yet? That might get me closer. I know you have other higher priority things going, so if you want I'll just keep fooling with this as I have time.

[trevius]

BTW, the new buff encode and decode have been added to the SVN. They still aren't working for duration just yet, but we are still looking into why. The buff duration is a really odd issue that I just can understand yet.

Here are some notes about what we have seen or theorized about so far:

1. we have considered that maybe character level is being seen properly by the client as far as buffs are concerned. The reason for thinking this is that it seems that the duration formulas are yielding odd results for what the client shows for the buff duration. So far, all spells that use duration formula 11 (defined in the spells file/table) have a duration of 9 minutes in SoF. I think formula 10 may also have 9 minutes duration. Then, I think it is formulas 8 and 9 that both have a duration of 1 minute. All other formulas seem to have 0 duration when the buff is cast. I think if we knew what the actual formula is (it may be in the source code somewhere I am not seeing), we could figure out what would cause those durations for those formula types. Once we know what would cause it, we could probably find the solution easier.

2. If you zone while a buff icon is still on you, after zoning, it will show the correct duration. Buffs are set in the player profile while zoning, so that is handled differently than buffing without zoning.

3. If you cast a spell that buffs with a 0 duration, and then cast it again before the icon fades (using #cast), the buff will show up like normal and last for the normal duration. Not quite sure yet why this happens, but it may help to figure out what the cause of the 0 duration is.

4. Oddly, sometimes buffs seem to just work fine for an unknown reason, and then just stop working again. I think this one may be the most important thing to look at. So far, the only explaination I could figure out as to the cause of this is the sequence field in the OP_Action and OP_Damage related structures. Oddly enough, this field is not understood in Titanium, but Titanium knows that the sequence field for Action and Damage both need to match. It sets this field by getting the client's heading and then multiplying that by 2. Don't ask me why! After looking at the packets from Live, it appears that the sequence field is actually a float. So, I set it as a float in the SoF structs. I then tried logging in and casting buffs, then rotating slightly and casting them again. Eventually, I got to a heading that allowed me to buff most buffs and show the correct duration for them. Though, the ones with duration 8, 9, 10 and 11 still showed the 9 minute or 1 minute durations like they were showing before. Next, I turned a bit more to change my heading and was no longer able to get buffs to stick. This makes me think that we need to understand exactly what that sequence field is supposed to be sending, or at least a way to trick it. I tried forcing it to examples I was seeing from Live, but that didn't work at all. Live seems to use the same value in the sequence field for all buffs done in a zone. If you relog or zone again, I think that it changes slightly. Some of the observed values I saw from live were floats of 87.75 and 66.75. More testing is probably required.

In summary, buff duration is still in the works. I am sure we will figure it out eventually. This just seems odd. I haven't found any evidence that blocked buffs has anything to do with this. I imagine blocked buffs are all handled server-side anyway.

EDIT: Just found buff duration formulas. Now to see what would cause the durations we have seen so far:

int CalcBuffDuration_formula(int level, int formula, int duration)
{
	int i;	// temp variable

	switch(formula)
	{
		case 0:	// not a buff
			return 0;

		case 1:	// solar: 2/7/04
			i = (int)ceil(level / 2.0f);
			return i < duration ? (i < 1 ? 1 : i) : duration;

		case 2:	// solar: 2/7/04
			i = (int)ceil(duration / 5.0f * 3);
			return i < duration ? (i < 1 ? 1 : i) : duration;

		case 3:	// solar: 2/7/04
			i = level * 30;
			return i < duration ? (i < 1 ? 1 : i) : duration;

		case 4:	// only used by 'LowerElement'
			return ((duration != 0) ? duration : 50);

		case 5:	// solar: 2/7/04
			i = duration;
			return i < 3 ? (i < 1 ? 1 : i) : 3;

		case 6:	// solar: 2/7/04
			i = (int)ceil(level / 2.0f);
			return i < duration ? (i < 1 ? 1 : i) : duration;

		case 7:	// solar: 2/7/04
			i = level;
			return (duration == 0) ? (i < 1 ? 1 : i) : duration;

		case 8:	// solar: 2/7/04
			i = level + 10;
			return i < duration ? (i < 1 ? 1 : i) : duration;

		case 9:	// solar: 2/7/04
			i = level * 2 + 10;
			return i < duration ? (i < 1 ? 1 : i) : duration;

		case 10:	// solar: 2/7/04
			i = level * 3 + 10;
			return i < duration ? (i < 1 ? 1 : i) : duration;

		case 11:	// solar: confirmed 2/7/04
			return duration;

		case 12:	// solar: 2/7/04
			return duration;

		case 50:	// solar: lucy says this is unlimited?
			return 72000;	// 5 days

		case 3600:
			return duration ? duration : 3600;

		default:
			LogFile->write(EQEMuLog::Debug, "CalcBuffDuration_formula: unknown formula %d", formula);
			return 0;
	}
}