097 Coregina Roadmap

MuadDib · **Posted:** Fri Jun 09, 2006 5:15 pm

This post hopefully won't be updated to badly, but, this is the current roadmap we have set up (subject to change without notice).

Quote:

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

Tomi · **Joined:** Tue Feb 21, 2006 5:08 pm **Posts:** 30

Many nice feature updates there but...

what about speedhack prevention ?
what about support for osi encrypted clients ?
what about Movemode A (air) for npc ?

Guest · **Posted:** Sat Jun 10, 2006 1:59 am

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.

If you intend to make it like OSI, please consider making it optional.
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

Marilla · **Posted:** Sat Jun 10, 2006 6:34 am

I, again, agree with Xandros. I like the looks of everything there, but I would definitely vote for making the 'only-see-items-when-in-the-house' thing optional. Of course, it seems a normal thing that you guys do often make such things configurable, which is great, but just to make sure!

melanius · **Posted:** Sat Jun 10, 2006 7:43 am

Since 095 deprecated the equal sign for equality and switched to == for it, maybe we should consider using = to deprecate := for assignment.

MuadDib · **Posted:** Sat Jun 10, 2006 8:10 am

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

Xandros · **Joined:** Fri Feb 17, 2006 12:25 pm **Posts:** 76

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

Ok... in case you come to the conclusion that an option is not reasonable,
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. :wink:

Xandros

tekproxy · **Posted:** Sun Jun 11, 2006 6:29 am

First, I should get an award, because I didn't create a "When is 097 going to be out?" thread, and secondly, good job guys! 096 is finally out woo hoo! 097 roadmap looks very nice.

Yukiko · **Posted:** Mon Jun 12, 2006 8:46 pm

Please!!!
Let's not go to '=' for assignment. That will cause confusion I think. Besides if you do that it will add to the length of upgrading that will be required from scripts that are based on earlier POL versions.

I am perfectly happy with the operators as they are right now.

MuadDib · **Posted:** Mon Jun 12, 2006 10:46 pm

While I like the idea of = personally.... it's just that, personally. Let's face it, escript is about "ease of use". And yes Yu, in my opinion, it might add to confusion. Who knows. But just one person's opinion.

melanius · **Posted:** Tue Jun 13, 2006 2:34 am

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

)

Yukiko · **Posted:** Tue Jun 13, 2006 8:08 pm

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:

Code:

For x = 1 to 100; step 2
   Do stuff
Next

or our if syntax go to :

Code:

If x= 20 Then do this
else do that

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.

melanius · **Posted:** Wed Jun 14, 2006 1:13 am

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!

Aeros · **Joined:** Mon Apr 24, 2006 10:56 am **Posts:** 69

Or even UltraEdit's "replace in files" function

MuadDib · **Posted:** Wed Jun 14, 2006 8:15 am

Let's remember, the roadmap is only a guide for us developers. Already there has been things not on it, go in. And things on it, might be held off. Who knows.

Firedancer · **Posted:** Wed Jun 14, 2006 9:56 am

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

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.

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.

Yukiko · **Posted:** Wed Jun 14, 2006 11:11 am

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*

Yukiko · **Posted:** Wed Jun 14, 2006 11:17 am

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.

MuadDib · **Posted:** Wed Jun 14, 2006 1:26 pm

For now, no. Not something to be put in anytime soon.

melanius · **Posted:** Wed Jun 14, 2006 1:35 pm

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

Marilla · **Posted:** Wed Jun 14, 2006 2:01 pm

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.

Firedancer · **Posted:** Wed Jun 14, 2006 2:14 pm

MuadDib wrote:

For now, no. Not something to be put in anytime soon.

damn. tough luck really.

Aeros · **Joined:** Mon Apr 24, 2006 10:56 am **Posts:** 69

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.

Austin · **Posted:** Fri Jun 16, 2006 1:48 am

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:

Code:

    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

killingdjef · **Posted:** Sat Jul 01, 2006 8:48 pm

Austin wrote:

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:

Isn't that 0,02 megs?

PenUltima Online

097 Coregina Roadmap

Who is online