I've been searching for a while to a gump that shows you the "buff" spells such bless, protection, magic reflection and so that you have actived.
The gump would appear when you logon, you cant close it but you can move it. it shows the icon of each buff spell you have actived, and each icon would be named: "Spell name: Time left".
Any idea about how to start?
Buff Status Bar
Re: Buff Status Bar
I think what you are looking for the the buff/debuff packethook.
Do a search in this forum. I have it working for v5 clients on 097. Some of the code has been published in here, but you might need to do some of it for yourself - different script sets etc.
Do a search in this forum. I have it working for v5 clients on 097. Some of the code has been published in here, but you might need to do some of it for yourself - different script sets etc.
Re: Buff Status Bar
I was thinking about a gump and not a packet, cause i use v2.0.0 or v4 clients...
Re: Buff Status Bar
That is going to make it very hard indeed. As far as I know no dynamic gumps can be scripted; you are limited to gumps the client supports such as buy/sell, status etc, and on v5 the buff/debuff gumps.
Re: Buff Status Bar
Define dynamic gump.OldnGrey wrote:That is going to make it very hard indeed. As far as I know no dynamic gumps can be scripted; you are limited to gumps the client supports such as buy/sell, status etc, and on v5 the buff/debuff gumps.
You can script, as an example, a gump that is refreshed every second. Server side closing and re-sending does the magic, what else could be needed?
Re: Buff Status Bar
If you are going to destroy and recreate the gump with older clients, then I'd suggest you limit it to 5 second updates.
And if scripted, maybe have it save the screen location too so it doesn't put a moved gump back to the origin again. I was surprised recently to see the v5 client has some sort of gump location memory unlike earlier clients. I haven't investigated it though. V5 clients have a few gump handling improvements that I haven't seen documented elsewhere. Are you sure you won't convert to v5 clients?
How it works for v5 clients is that the client itself updates the timer tooltip countdown every 5 seconds on the buff/debuff gumps. The only server packets are the createbuff gump and the closebuff gump. You can't mimic that of course, but it shows what they were thinking when they designed it.
And if scripted, maybe have it save the screen location too so it doesn't put a moved gump back to the origin again. I was surprised recently to see the v5 client has some sort of gump location memory unlike earlier clients. I haven't investigated it though. V5 clients have a few gump handling improvements that I haven't seen documented elsewhere. Are you sure you won't convert to v5 clients?
How it works for v5 clients is that the client itself updates the timer tooltip countdown every 5 seconds on the buff/debuff gumps. The only server packets are the createbuff gump and the closebuff gump. You can't mimic that of course, but it shows what they were thinking when they designed it.
Re: Buff Status Bar
Umm now translate to v5 clients its a bit annoying using patch, cause it will auto patch to v6...
Well, if I use v5 client.. what should I do to activate it?
Well, if I use v5 client.. what should I do to activate it?
Re: Buff Status Bar
Actually, you can patch to 5.0.9.1 and then stop it from patching any further.
Get a UOML client which will be at 4.0.11. Then let it go off to OSI to patch up.
Then watch it like a hawk!
As soon as it starts downloading 6.0.0.0, keep hitting the cancel button until it stops. While it's downloading the patch it's safe to stop it, the only time you don't want to stop it is if it's actually applying the patch.
Then when you have 5.0.9.1 in all its glory, you can make a backup. For your players, they will need UOML not patched with OSI and you can supply the changed files to bring them up to 5.0.9.1.
A lot of us are facing the same problems. OSI patched into the 6.0.x.x starts to have problems. The trick is to ask your players to install UOML and NOT patch it except from you.
Anyway, good luck with your efforts.
Supporting v5 client is a little more involved than a simple reply off the top of my head. All I can say is that it's well worth it as you play around with servspecopt.cfg and UOFeatureEnable=0x20.
At logon I run a little script like this to enable the client to run later features:
Get a UOML client which will be at 4.0.11. Then let it go off to OSI to patch up.
Then watch it like a hawk!
As soon as it starts downloading 6.0.0.0, keep hitting the cancel button until it stops. While it's downloading the patch it's safe to stop it, the only time you don't want to stop it is if it's actually applying the patch.
Then when you have 5.0.9.1 in all its glory, you can make a backup. For your players, they will need UOML not patched with OSI and you can supply the changed files to bring them up to 5.0.9.1.
A lot of us are facing the same problems. OSI patched into the 6.0.x.x starts to have problems. The trick is to ask your players to install UOML and NOT patch it except from you.
Anyway, good luck with your efforts.
Supporting v5 client is a little more involved than a simple reply off the top of my head. All I can say is that it's well worth it as you play around with servspecopt.cfg and UOFeatureEnable=0x20.
At logon I run a little script like this to enable the client to run later features:
Code: Select all
program setup_client(character)
var client := 0;
while ( !client )
sleep(2);
client := character.clientversion;
endwhile
// Set uo_expansion based on client version
var acctref := FindAccount(character.acctname);
if ( character.clientversion[1, 1] == "4" )
acctref.set_uo_expansion("AOS");
elseif ( character.clientversion[1, 1] == "5" )
acctref.set_uo_expansion("ML");
elseif ( character.clientversion[1, 1] == "6" )
acctref.set_uo_expansion("ML");
else
acctref.set_uo_expansion("T2A");
endif
endprogramRe: Buff Status Bar
Well, the patching problem i meant was for players xD
Umm enablind that feature wont make the buff/debuff gump to work, i have to write a packet script every time a buff/debuff spell is casted over a player, no?
Umm enablind that feature wont make the buff/debuff gump to work, i have to write a packet script every time a buff/debuff spell is casted over a player, no?
Re: Buff Status Bar
Well, theres no need to enable that feature.. but this packet needs scritps xDDD
So, I need to send the packet when a buff/debuff spell is casted over a player, and when the spell ends...
Im using custom scripts, but based on 095 distro.. ive read about timed scripts of 097 distro.. do i really need them? and how do they work?
So, I need to send the packet when a buff/debuff spell is casted over a player, and when the spell ends...
Im using custom scripts, but based on 095 distro.. ive read about timed scripts of 097 distro.. do i really need them? and how do they work?
Re: Buff Status Bar
Take a look at:
http://forums.polserver.com/viewtopic.p ... cket#p9844. The function TS_DFPacket can be used to turn on or off the gump for each buff. The function quoted in that post has fixed clilocs and icons. You'd have to modify it to look up the correct ones based on the name of the buff.
If you want to use this sort of thing inside the WoD scripts, look for dotempmods.inc.
Turning on a gump:
As an example, in the function DoTempMod, just after SetObjProperty(who, "#mods", allmods);
add in a call to a function: SetBuffGump(who, stat, amt, duration);
Turning off a gump:
In the function UndoTheMod, use lines like TS_DFPacket(who, "Weakness", 0);
(0 is used to turn off the gump)
I wrote a little function called SetBuffGump to handle turning on the gump. I won't repeat the whole function, but for "Weakness" it would be:
The link earlier to TS_DFPacket makes references to icons and clilocs. I ended up writing a cfg file to find the clilocs and icons to use. For "Weakness" the values might be:
icon 1042
cliloc1 1027988
cliloc2 1060485
Note: those cliloc entries might well be my own when I edited my cliloc.enu file.
Once you figure out that all you have to do is send a packet to turn on the buff's gump, and then another packet to turn off the buff's gump, the rest is detail. After that all you really have to do is refresh the gumps when you reconnect or logon and the mods haven't worn off.
I hope it helps. I'd publish the details of what I do, but it's so customised for my shard that it wouldn't be much help I don't think.
http://forums.polserver.com/viewtopic.p ... cket#p9844. The function TS_DFPacket can be used to turn on or off the gump for each buff. The function quoted in that post has fixed clilocs and icons. You'd have to modify it to look up the correct ones based on the name of the buff.
If you want to use this sort of thing inside the WoD scripts, look for dotempmods.inc.
Turning on a gump:
As an example, in the function DoTempMod, just after SetObjProperty(who, "#mods", allmods);
add in a call to a function: SetBuffGump(who, stat, amt, duration);
Turning off a gump:
In the function UndoTheMod, use lines like TS_DFPacket(who, "Weakness", 0);
(0 is used to turn off the gump)
I wrote a little function called SetBuffGump to handle turning on the gump. I won't repeat the whole function, but for "Weakness" it would be:
Code: Select all
function SetBuffGump(byref who, stat, amt, duration)
case ( stat )
"cstr":
TS_DFPacket(who, "Weakness", 1, duration, CStr(amt));
default:
return 1;
endcase
return 1;
endfunctionicon 1042
cliloc1 1027988
cliloc2 1060485
Note: those cliloc entries might well be my own when I edited my cliloc.enu file.
Once you figure out that all you have to do is send a packet to turn on the buff's gump, and then another packet to turn off the buff's gump, the rest is detail. After that all you really have to do is refresh the gumps when you reconnect or logon and the mods haven't worn off.
I hope it helps. I'd publish the details of what I do, but it's so customised for my shard that it wouldn't be much help I don't think.
Re: Buff Status Bar
Ok, thanks man 