Slogan
--------------
"POL - Providing mature development for 7 years...
Not sure what happened after that though.. now the drinkers have it... "
Remove all depreciated stat advancement code from the core. Scripts now handle this anyway. -- COMPLETED
Targeting needs to be revamped. Especially handling of "kill" packet sent to client instead of killing the request in core when a new cursor request is called over an existing. Should fix some issues with calling multiple cursors without client sending a result. -- COMPLETED WITH TARGET CANCELING COMMAND AND ALSO REVAMP OF TARGET SYSTEM.
Target handling needs better response if it recieves a target reply for an invalid sequence handler (invalid cursor ID). -- COMPLETED VIA ONLY ALLOWING 1 TARGET ABILITY. NEW ONES WILL RETURN ERROR ABOUT EXISTING.
Rewrite .EM support for better handling. Create and reorganize them into files such as attributes.em, map.em, etc etc. -- COMPLETED
Clean up code by double checking all functions for use.
Fix error reports and instances of weapon.cfg and wepndesc.cfg in core messages. This file no longer used by core. -- COMPLETED
Fix error reports and instances of armor.cfg and armrdesc.cfg in core messages. This file no longer used by core. -- COMPLETED
Remove MoveItem*/MoveCharacter* functions that was depreciated by the new MoveObjectToLocation function in 096. -- COMPLETED
Research possibility of more stat packet support for AOS? -- COMPLETED
Check into core supporting the other resistances but not be required. AR is still one of the resistances in AOS+. -- MOVED TO 098
Luck/Followers can be totally ignored in AOS statbar if core supported. Damage might be considered to be included in the packet. -- MOVED TO 098
Allow config files to be at the root of a package or in its /config/ subdirectory. Similarly to how include files work. -- COMPLETED
Deprecate the need for skills.cfg. Keep necessary information in attributes.cfg and have uoskills.cfg point to the attributes (instead of skills.cfg) -- COMPLETED
Multi Walkon script support. Should remember it only needs checked when first walking onto a multi/component, and no release their reference for it, until they walk off it.
Rework sending items to client when they are on a multi (and not a component of the multi). OSI handles this laggish issue by not sending items (Mobs and their equipped items they send though) until the player has walked onto the multi or one of it's components. Helps blackholing and saves bandwidth.
Implement 0xD1 Packet from client (Logout Status)
It was reported a long time ago, about SetWarMode() for players not updating the client correctly. Look into this possibility, and fix it, if possible via packets. -- NOT VALID, NO ISSUE
NPC.allignment for npcs. Return string. If it cannot be done without saving to npcs.txt, then have it based off hue for faster access. -- COMPLETED
Fix? clientinfo member on linux cores.
Remove known Memory Leaks (cfg and ecl-file handling).
Fix? Issue with timeout not working under linux cores (Inactivity timeout).
FindSubstance()'s makeinuse ability needs to add to the reserved list efficiently. Related internal functions need to check this list also. Defeats the purpose of noninuse, BUT, it should work if the same script is the one that reserved it anyway, right?
Progress on custom housing.
Fix SFOBS not seeing mutlis any longer.
Check insertscript not recieving existing stack info correctly via the moveItemToContainer core command. Didn't Racalac say something about this was intended anyway?
Rewrite MenuItem() and AddMenuItem to accept and use color entry for the packet.. -- COMPLETED
Add 3DParticle Effect for supporting new spell graphics, etc, without user relying on special packet functions to make it.
OpenWebsite() function. -- COMPLETED
Cliloc Send functions. -- COMPLETED
Support for new gump packets.
Optimize out the unused config files required by core, and no-longer-used/needed core internal spell abilities.
Add polsys.em command IncRev() to increase revision via script. Allows scripts to force updates for custom changes involving tooltip hooks. TO cover things such as race, graphic, hidden, concealed, etc that we do not auto increv() in core cuz no basic/standard need. -- COMPLETED VIA INCREVISION()
Rewrite IncRev() commands to also resend the object cache request to client. -- COMPLETED
097 Coregina Roadmap
Moderator: POL Developer
097 Coregina Roadmap
This post hopefully won't be updated to badly, but, this is the current roadmap we have set up (subject to change without notice).
Last edited by MuadDib on Wed Sep 06, 2006 2:23 pm, edited 2 times in total.
Re: 097 Coregina Roadmap
If you intend to make it like OSI, please consider making it optional.MuadDib wrote: Rework sending items to client when they are on a multi (and not a component of the multi). OSI handles this laggish issue by not sending items (Mobs and their equipped items they send though) until the player has walked onto the multi or one of it's components. Helps blackholing and saves bandwidth.
We're happy with the way it is right now, and since there are multis
with flat roofs or balconies, it is very well possible that the player can
(and should) see decoration from outside, and that is what I would
prefer.
Xandros
I thought about it, but atm unsure. This goes for the multi change (on/off), and the = assignment.
Firstly, we wish to get 097 done as fast as possible, without sacrificing quality in the release. Second, we want to try to concentrate on fixes and optimization really. I know a lot of the roadmap does not seem to fit those 2 categories, but that is the "published" roadmap. When I say "clean out some unused code", that means a ton of crap needs to go, hehe.
The change with targeting, should help clarify some things with the reason. Also, the target cancel change should fix script issues it can cause.
On the multi change, for items being sent... Besides bandwidth aide, and blackhole fixes, it also helps cuz the same system is to be used with multi walk-on scripts. But as far as make it configurable, I am unsure. Cuz that means having two entirely different systems just for sending items in range. Unsure how that will affect core performance yet. And, that may end up being something left for 098 (the item sent part).
Far as the stuff we are NOT doing in the 097 roadmap....... that doesn't mean we don't plan on ever adding them. Let's face it, 096 ended up being dragged out WAY WAY WAY too long, just to keep adding stuff. Give us time, it can be done, but at the best pace we can give ourselves.
Hope this info helps. If not, just flame away all-the-while 097 gets done faster than expected
Firstly, we wish to get 097 done as fast as possible, without sacrificing quality in the release. Second, we want to try to concentrate on fixes and optimization really. I know a lot of the roadmap does not seem to fit those 2 categories, but that is the "published" roadmap. When I say "clean out some unused code", that means a ton of crap needs to go, hehe.
The change with targeting, should help clarify some things with the reason. Also, the target cancel change should fix script issues it can cause.
On the multi change, for items being sent... Besides bandwidth aide, and blackhole fixes, it also helps cuz the same system is to be used with multi walk-on scripts. But as far as make it configurable, I am unsure. Cuz that means having two entirely different systems just for sending items in range. Unsure how that will affect core performance yet. And, that may end up being something left for 098 (the item sent part).
Far as the stuff we are NOT doing in the 097 roadmap....... that doesn't mean we don't plan on ever adding them. Let's face it, 096 ended up being dragged out WAY WAY WAY too long, just to keep adding stuff. Give us time, it can be done, but at the best pace we can give ourselves.
Hope this info helps. If not, just flame away all-the-while 097 gets done faster than expected
Ok... in case you come to the conclusion that an option is not reasonable,MuadDib wrote: On the multi change, for items being sent... Besides bandwidth aide, and blackhole fixes, it also helps cuz the same system is to be used with multi walk-on scripts. But as far as make it configurable, I am unsure. Cuz that means having two entirely different systems just for sending items in range. Unsure how that will affect core performance yet. And, that may end up being something left for 098 (the item sent part).
just count me in on the "leave it as it is" side. One of the things I hate
most is when OSI changes things to send less data, which often leaves us
less choice in how we want to display things (just think vendor menu).
And last but not least, when POL97 will be released in about 4 years,
bandwidth will be a much smaller issue anyway.
Xandros
I understand you worrying Yukiko, but moving := to = will make it easier for newcomers and I didn't say change it now, rather have a version to deprecate it and change it in 098, not a minor version such as 096.4 or 097.2.
I read your reply on http://forums.polserver.com/viewtopic.php?t=491 and I don't think its a matter of fixing, rather a matter of making it consistent with the rest of the programming world.
I agree that eScript should not be afraid to break consistency when it will make it easier for the end user and preferably more verbose/cleaner, but I don't see the point of := over =.
Edit:
Although this may sound corny POL is actually still in beta thus the lack of 1 release (although its more than stable), so API changes/breaking should be tolerated by end users as all the devs do is strive for the better end result (always hearing what the users have to say along the way )
I read your reply on http://forums.polserver.com/viewtopic.php?t=491 and I don't think its a matter of fixing, rather a matter of making it consistent with the rest of the programming world.
I agree that eScript should not be afraid to break consistency when it will make it easier for the end user and preferably more verbose/cleaner, but I don't see the point of := over =.
Edit:
Although this may sound corny POL is actually still in beta thus the lack of 1 release (although its more than stable), so API changes/breaking should be tolerated by end users as all the devs do is strive for the better end result (always hearing what the users have to say along the way )
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Melanius it isn't just the ':=' issue as I stated. If it was just one change that wouldn't be a problem. But you read my post about that so I'll forgo any redundant posting here.
Let's face it. Programming/scripting will always require some learning curve. I'll be the first to admit that eScripts for loop is more cryptic than I like but I certainly don't want to see us go to the BASIC for syntax which is something like this:
or our if syntax go to :
Those two examples are definitely easier to understand from a newbie frame of reference.
My 13 year old son learned eScript almost entirely on his own with very little questions asked of me. So it is possible to learn. Oh and he had no prior programming experience at all. I think eScript is simple enough. What needs to happen is the Distro scripts need to be made more readable by commenting them better and reducing the number of includes that get included in an include inside an include ad nauseum. I have seen what is happening with Distro now and I think it is definitely a major improvement. The best thing that happened to POL besides the core development was the nice docs Rac did for the ems scripts and all that. Once you update that for POL 96 I think you have a very good system for learning to script.
Anyway, I know POL will go whatever way it goes. I just don't see the need to change things that are working fine. Every change, no matter how small, is just one more thing we have to search out and change in our scripts. Ever wonder how many times the ':=' appears in the 95 Distro scriptbase? I do but don't have a program to do a count on multiple files but I bet it's a lot.
Just something to think about.
Let's face it. Programming/scripting will always require some learning curve. I'll be the first to admit that eScripts for loop is more cryptic than I like but I certainly don't want to see us go to the BASIC for syntax which is something like this:
Code: Select all
For x = 1 to 100; step 2
Do stuff
Next
Code: Select all
If x= 20 Then do this
else do that
My 13 year old son learned eScript almost entirely on his own with very little questions asked of me. So it is possible to learn. Oh and he had no prior programming experience at all. I think eScript is simple enough. What needs to happen is the Distro scripts need to be made more readable by commenting them better and reducing the number of includes that get included in an include inside an include ad nauseum. I have seen what is happening with Distro now and I think it is definitely a major improvement. The best thing that happened to POL besides the core development was the nice docs Rac did for the ems scripts and all that. Once you update that for POL 96 I think you have a very good system for learning to script.
Anyway, I know POL will go whatever way it goes. I just don't see the need to change things that are working fine. Every change, no matter how small, is just one more thing we have to search out and change in our scripts. Ever wonder how many times the ':=' appears in the 95 Distro scriptbase? I do but don't have a program to do a count on multiple files but I bet it's a lot.
Just something to think about.
Yukiko, I think you missed my point entirely here.
I understand your concern but I tried to explain you the reasons to think out of the POL box.
If the main issue is moving a scriptbase from := to = I can assure you it can be done with a simple regex python/perl script way too easy, there's nothing to think on that matter.
Anyway, its too early to be worried on this. Lets enjoy 096 release
Muad, sorry for hijacking the topic!
I understand your concern but I tried to explain you the reasons to think out of the POL box.
If the main issue is moving a scriptbase from := to = I can assure you it can be done with a simple regex python/perl script way too easy, there's nothing to think on that matter.
Anyway, its too early to be worried on this. Lets enjoy 096 release
Muad, sorry for hijacking the topic!
-
- Grandmaster Poster
- Posts: 104
- Joined: Fri Feb 03, 2006 6:32 am
- Location: Austria
- Contact:
I disagree here - sure pol096 took a long time, but I think it's fine, and it's good not to have too many releases. Anyone really badly needing a new feature, can d/l the beta anyway.MuadDib wrote:Far as the stuff we are NOT doing in the 097 roadmap....... that doesn't mean we don't plan on ever adding them. Let's face it, 096 ended up being dragged out WAY WAY WAY too long, just to keep adding stuff. Give us time, it can be done, but at the best pace we can give ourselves.
Hope this info helps. If not, just flame away all-the-while 097 gets done faster than expected
Upgrading a shard to a new server release is a huge project, I currently estimate multiple months for us to handle the upgrade. There's tons of scripts that need adapting (not to mention making use of the new features), but worse there's lots of time we've gotta test it. If you push out versions too fast, we might not be able to cope anymore, which in turn causes shards to remain stuck on outdated versions.
Doing "addons" where only new features are addedd is another thing, but any new version that requires changes to existing commands, is a huge issue and it's definetely easier for me to touch a file for 10 changes at a time than having to touch (and test) it once for each.
So no, I'm perfectly fine as is and I think you guys are doing a great job the way you handle releases and beta's. No need to change that.
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Sorry Mel to have drug out the discussion on the ':=' thing. The idea wasn't about ':=' specifically. It was about making unnecessary changes to things that are working as they are. But 'nuf said on that.
I agree with Firedancer to a point. I also agree with Maud that POL 96 too a very long time to emerge from the cocoon. I don't mind the changes as long as they are necessary but I think the subversion releases will be a better way to go. Unlike Firedancer I prefer having the script changes come in small manageable packages. Ofcourse I am the only scripter for my shard. I don't have a team to hand things off to. Maybe it's easier to handle ten at a time with more hands at the keyboard.
Anyway, I will be a faithful POL user no matter what til either the devs stop developing it or I quit hosting my shard or the Lord comes to take me away.
*smiles*
I agree with Firedancer to a point. I also agree with Maud that POL 96 too a very long time to emerge from the cocoon. I don't mind the changes as long as they are necessary but I think the subversion releases will be a better way to go. Unlike Firedancer I prefer having the script changes come in small manageable packages. Ofcourse I am the only scripter for my shard. I don't have a team to hand things off to. Maybe it's easier to handle ten at a time with more hands at the keyboard.
Anyway, I will be a faithful POL user no matter what til either the devs stop developing it or I quit hosting my shard or the Lord comes to take me away.
*smiles*
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Oh yes Maud since we are on the subject (loosely) of things going into 97, can we add weoght being an r/w member? Is that even possible since weight is defined in itemdesc files can it be changed? I know colour can so I would asume weight can but since weight has dynamic influence on characters in a way that colour doesn't I am not sure.
Well yeah, 3 years of development are a bit too much for a project of this scope.
But now that things are back on track, I think we can follow the path of big projects in maintaining 2 branches (don't mind the naming used below)
Stable: 096, Development: 097.
API/ABI breaking and introduction of new features happens in the 097 branch, while important bug fixes and weaknesses are fixed on 097 and back-ported on the 096 branch, which can have micro releases in the form of 096.1, 2, 3, .., 10 etc
But now that things are back on track, I think we can follow the path of big projects in maintaining 2 branches (don't mind the naming used below)
Stable: 096, Development: 097.
API/ABI breaking and introduction of new features happens in the 097 branch, while important bug fixes and weaknesses are fixed on 097 and back-ported on the 096 branch, which can have micro releases in the form of 096.1, 2, 3, .., 10 etc
For the record, I -really- like the idea of updating the POL core in this manner. Not that I think anyone would disagree with it... hehe... but a project as complex as this, done by the generous volunteer folks like you all in your spare time, is bound to have issues that need to be worked on here or there. It's great to know that 096 will be tweaked bug-wise, but remain stable feature-wise, and that 097 can be developed separately.
-
- Grandmaster Poster
- Posts: 104
- Joined: Fri Feb 03, 2006 6:32 am
- Location: Austria
- Contact:
Another thing, while on the 097 discussion. Is it better to make speed a r/w property, or is it better to use a delay mod?
Reason im asking: If you want to change a weapon into a "swift" weapon, permanently, would you need to set a delay mod on the weapon, on the user of the weapon, or would you ultimately be able to just change the speed of the weapon, since it is a permanent speed change anyway? The way I see it, delay mods are fine for temporary mods, but for permanent mods it would be nicer to be able to change damage and speed directly.
Reason im asking: If you want to change a weapon into a "swift" weapon, permanently, would you need to set a delay mod on the weapon, on the user of the weapon, or would you ultimately be able to just change the speed of the weapon, since it is a permanent speed change anyway? The way I see it, delay mods are fine for temporary mods, but for permanent mods it would be nicer to be able to change damage and speed directly.
Heres where we stand so far on what has been completed.
So far the core has already gone from 2.14 megabytes to 2.12 thats 0.2 megs of less crashing potential. :lol:
So far the core has already gone from 2.14 megabytes to 2.12 thats 0.2 megs of less crashing potential. :lol:
Code: Select all
MuadDib
Remove all stat advancement code from the core. This has been depreciated for
a long while, but left in for some odd reason? The following is a start:
AdvanceStatsDueToSkillUse( USKILLID skillid ) -- COMPLETED
unsigned short get_str_points( USKILLID skillid ); -- COMPLETED
unsigned short get_int_points( USKILLID skillid ); -- COMPLETED
unsigned short get_dex_points( USKILLID skillid ); -- COMPLETED
unsigned short SkillHandlerElem::StatAdv::get_points() const --COMPLETED
unsigned short get_points() const; -- COMPLETED
StatAdv(); and it's related functions -- COMPLETED
StatAdv stradv; and related -- COMPLETED
StatAdv intadv; and related -- COMPLETED
StatAdv dexadv; and related -- COMPLETED
MuadDib & Shinigami
Targeting needs to be revamped. Especially handling of "kill" packet sent to
client instead of killing the request in core when a new cursor request is called
over an existing. -- COMPLETED
MuadDib
Remove void unload_skill_scripts(), depreciated and unused. --COMPLETED
Remove void load_zones(), depreciated and unused. --COMPLETED
MuadDib
Fix error reports and instances of weapon.cfg and wepndesc.cfg in core messages. --COMPLETED
Fix error reports and instances of armor.cfg and armrdesc.cfg in core messages. --COMPLETED
MuadDib
Remove MoveItem*/MoveCharacter* functions that was depreciated by the new
MoveObjectToLocation function in 096. --COMPLETED
MuadDib
Check into possibility of changing send_full_statmsg and similar to be able
to handle AOS support. -- COMPLETED
Austin
Allow config files to be at the root of a package or in its /config/ subdirectory.
Similarly to how include files work. --COMPLETED
Austin
Deprecate the need for skills.cfg. Keep necessary information in attributes.cfg and have
uoskills.cfg point to the attributes (instead of skills.cfg) --COMPLETED
Austin
Remove built in commands and give script access needed to replace .set, .armor and .privs
--COMPLETED