Having trouble finding the 0.97 version of shilskill.src
Having trouble finding the 0.97 version of shilskill.src
As I understand it the function CheckSkill simply passes the parameters on to an exported syshook for skill gain. Now I knew where that was in POL 0.95 Distro but I can't find a syshook in POL 0.97 Distro that corresponds to shilskill. I thought it would be in the Attributes package but I didn't see it. Where might I find it?
Ah hah!
Look for SkillCheck (ie skillCheck.inc)
Reason?
Because CheckSkill used skillid as a parameter and in order to banish skillids it was necessary to create another function and use it instead of CheckSkill. However, exporting checkskill using attributes was apparently ill-advised because the core wanted and expected skillid. Thus the new name. I hope that makes sense.
Does it work? Yep. I converted my shard to use my own version of SkillCheck and was able to totally banish skillid from my shard. (Because you now have no maxskillid to worry about, you can have more than 52 skills - even with v2 clients. It DOESN'T CRASH the client)
Look for SkillCheck (ie skillCheck.inc)
Reason?
Because CheckSkill used skillid as a parameter and in order to banish skillids it was necessary to create another function and use it instead of CheckSkill. However, exporting checkskill using attributes was apparently ill-advised because the core wanted and expected skillid. Thus the new name. I hope that makes sense.
Does it work? Yep. I converted my shard to use my own version of SkillCheck and was able to totally banish skillid from my shard. (Because you now have no maxskillid to worry about, you can have more than 52 skills - even with v2 clients. It DOESN'T CRASH the client)
I thought according to the docs on CheckSkill that it took either an attributeid (string literal) or a skillid (integer) and simply passed it along to the exported function. I wasn't aware that it did not accept strings.
Oh and yes you can add as many skills as you like to clients prior to version 5. However, unless EA changed things in their last client patch, version 5 clients do not display anything beyond 55 skills in the skill scroll.
Oh and yes you can add as many skills as you like to clients prior to version 5. However, unless EA changed things in their last client patch, version 5 clients do not display anything beyond 55 skills in the skill scroll.
I took out the old checkskill export and had no trouble.
checkskill is in uo.em of course and I don't even know if the core uses it any more. I certainly can't see anything now - the last one seems to have been magery. I certainly make no calls to it. checkskill function takes skillid. The other things wrapped around the old attributes.inc added attributes and that's all worth scrapping to use just skillcheck.
Oh, and I had no idea the client skillwindow had limitations on maxskillid - I haven't used the client to report skills for a LONG time
097 makes is more interesting - there are still a couple of places you need to define a skillid - this is for the benefit of the macros, the skill advancement messages and skill window, and I suspect that's all. I've been watching Austin removing cfg files for a while now and I think I see the direction he's heading. uoskills.cfg and attributes.cfg are interesting!
checkskill is in uo.em of course and I don't even know if the core uses it any more. I certainly can't see anything now - the last one seems to have been magery. I certainly make no calls to it. checkskill function takes skillid. The other things wrapped around the old attributes.inc added attributes and that's all worth scrapping to use just skillcheck.
Oh, and I had no idea the client skillwindow had limitations on maxskillid - I haven't used the client to report skills for a LONG time
097 makes is more interesting - there are still a couple of places you need to define a skillid - this is for the benefit of the macros, the skill advancement messages and skill window, and I suspect that's all. I've been watching Austin removing cfg files for a while now and I think I see the direction he's heading. uoskills.cfg and attributes.cfg are interesting!
Well, I am using the 0.95 attributes include but am slowly skillids to attributeids. I huess I'll just take the exported code and rescript it to use attribs and call it skillcheck. Then change all calls to CheckSkill to SkillCheck This will probably be easier than trying to marry the POL 0.97 skill system to the POL 0.95 scripts.
attributes_ex.inc helps too
Code: Select all
/*
* AP_SkillIdToAttributeName(skill_number)
*
* Purpose
* Gets the name of the attribute that is associated with a skill number.
* uoskills.cfg -> Attributes.cfg
*
* Parameters
* skill_number: Skill ID to convert
*
* Return value
* Returns a string.
*
*/
Code: Select all
/*
* AP_AttributeNameToSkillId(attribute_name)
*
* Purpose
* Gets the skill number (ID) that an attribute name is associated with.
* Attributes.cfg -> uoskills.cfg
*
* Parameters
* attribute_name: Attribute name to convert.
*
* Return value
* Returns an integer.
*
*/
Those functions replace the old ones in attributes.inc which were called
GetSkillIDByAttributeID and GetAttributeIDBySkillID
After you convert to attributes you don't even need the 097 distro ones any more. My scripts now only has one function that needs to know skillids. (The old WoD magic item system used cprops to store the skillid on magic items. I convert these to attributes when they are equipped or itemid'd.)
My original aim was to remove skillid totally. Apart from converting old magic items, the only place that needs them now is skills.cfg (now uoskills.cfg). (see Austin's functions above)
The 097 distro has inspired a lot of changes on my shard already and I'm grateful to those who work on it; it's a source of fresh ideas that never grow stale. I'd still recommend devs to move towards the core scripts found in the distro. It will help enormously in the future when we are looking to build up a library of scripts that we can share.
GetSkillIDByAttributeID and GetAttributeIDBySkillID
After you convert to attributes you don't even need the 097 distro ones any more. My scripts now only has one function that needs to know skillids. (The old WoD magic item system used cprops to store the skillid on magic items. I convert these to attributes when they are equipped or itemid'd.)
My original aim was to remove skillid totally. Apart from converting old magic items, the only place that needs them now is skills.cfg (now uoskills.cfg). (see Austin's functions above)
The 097 distro has inspired a lot of changes on my shard already and I'm grateful to those who work on it; it's a source of fresh ideas that never grow stale. I'd still recommend devs to move towards the core scripts found in the distro. It will help enormously in the future when we are looking to build up a library of scripts that we can share.
Same for me O'nG but I am loth to actually use the attributes package from 0.97. Instead I am converting the 0.95 Distro to be "attribute ID compliant" rather than "skill ID bound" as it was. In fact alot of that conversion was started in the 0.95 Distro. It was never finished however. So I am attempting to complete the conversion.
On a slightly different note, I have to admit that WoD had a lot of nifty things that should have been standard fare in the Distro long ago.
Anyway, time to get ready for that four letter word - W O R K.
Have fun and as always, don't do anyhting you wouldn't do.
*grins*
On a slightly different note, I have to admit that WoD had a lot of nifty things that should have been standard fare in the Distro long ago.
Anyway, time to get ready for that four letter word - W O R K.
Have fun and as always, don't do anyhting you wouldn't do.
*grins*
Funny thing is, the more I study the distro the more changes I make to my own scripts to streamline things. And the more changes I make the closer they end up to the distro as I understand more of how they are doing things.
It worried me initially that I was going to end up with a hybrid of WoD, 095 distro, and 097 distro. But then I realised I was heading towards the 097 distro and making lots of little testable steps was a lot easier on the players than a massive re-write.
It worried me initially that I was going to end up with a hybrid of WoD, 095 distro, and 097 distro. But then I realised I was heading towards the 097 distro and making lots of little testable steps was a lot easier on the players than a massive re-write.
I am too but some things are probably not going to go "Distro" in the near future, one is NPCs using AI Brain. There are so many custom NPC AI scripts on my shard (as there are in the WoD scripts) that I am not looking forward to converting to AI Brain.
I do have Austin's gumps, accounts, and a number of the "Distro attributes independant" packages on my shard. Maybe some day I'llk convert to Distro attributes package too but not for now.
I am still trying to get the spawner from Distro 0.97 to work on my shard too.
I do have Austin's gumps, accounts, and a number of the "Distro attributes independant" packages on my shard. Maybe some day I'llk convert to Distro attributes package too but not for now.
I am still trying to get the spawner from Distro 0.97 to work on my shard too.
Oh, the distro spawner..... you are ahead of me on that one. I didn't use the distro one.
I'm still using the manage.src gumps from Sanctuary modified to open a different datafile for each realm via a few parameters passed to the main function. Surprisingly it seems to work almost just fine and I can edit the regions separately. (I had already done the groundwork on that by splitting my spawner into monsters and domestics region datafiles to cut down the size, so adding 3 more files was relatively easy selectable by a simple frontend realm chooser. I am actually debugging the gumps right now.)
It was a real thrill to stand in Ilshenar for the first time on my test shard, and then to get each system to extend across realms. After the spawner all I have left to do are the search functions - at the moment all the searches (like boats, houses for sale and items) are restricted to _DEFAULT_REALM.
BrainAI is my next project. It offers a lot of advantages, but there is a lot of work too. Enabling different nerves to customize each creature looks interesting, but on the down side, so many things get checked in monsters in combat that I am not really looking forward to it. The AI used in WoD is incredibly deep and I expect a headache and a few decisions.
I'm still using the manage.src gumps from Sanctuary modified to open a different datafile for each realm via a few parameters passed to the main function. Surprisingly it seems to work almost just fine and I can edit the regions separately. (I had already done the groundwork on that by splitting my spawner into monsters and domestics region datafiles to cut down the size, so adding 3 more files was relatively easy selectable by a simple frontend realm chooser. I am actually debugging the gumps right now.)
It was a real thrill to stand in Ilshenar for the first time on my test shard, and then to get each system to extend across realms. After the spawner all I have left to do are the search functions - at the moment all the searches (like boats, houses for sale and items) are restricted to _DEFAULT_REALM.
BrainAI is my next project. It offers a lot of advantages, but there is a lot of work too. Enabling different nerves to customize each creature looks interesting, but on the down side, so many things get checked in monsters in combat that I am not really looking forward to it. The AI used in WoD is incredibly deep and I expect a headache and a few decisions.
You have e-mail
The admin command "manage.src" itself is quick and dirty - just to prove it's possible.
It's only role is to pass the correct parameters to the "RegionSpawns.src" command which builds the gumps.
The spawner itself runs at startup from the regspawner.src script. One other thing that might puzzle you - I have _DEFAULT_REALM set to "britannia_alt" in uo.em so I can play in a pushthrough environment.
Don't judge the scripting quality too harshly, I only got it working today
The admin command "manage.src" itself is quick and dirty - just to prove it's possible.
It's only role is to pass the correct parameters to the "RegionSpawns.src" command which builds the gumps.
The spawner itself runs at startup from the regspawner.src script. One other thing that might puzzle you - I have _DEFAULT_REALM set to "britannia_alt" in uo.em so I can play in a pushthrough environment.
Don't judge the scripting quality too harshly, I only got it working today