learning curve must be lowered
Moderator: POL Developer
learning curve must be lowered
While it doesn't matter for an experienced programmer, I think POL must have its learning curve lowered.
-1) on_doubleclick script explained at the second line of README file. If doesn't exist, the core creates it.
0) The documentation MUST reflect POL's event driven model instead of being an extensive EScript reference. The newbie has no slightest idea why thy should learn the script - we should give them the idea why. Doesn't have to be reworked, just a paragraph explaining the ideology would do.
1) Folders nightmare must end with scripts and config folders removed and servers.cfg placed in POL's root renamed to shard.cfg (becase why plural is not obvious).
2) use directive needs to be removed making every Core function automatically available.
3) "Distro" renamed to something that would convey its meaning and silently included into every distribution.
4) program directive must be explained in the first line of the README. Most people get it wrong.
5) servopts, combat.*local.cfg and uoclient.cfg merged back to the pol.cfg with all of the "expert" tweaking options given some sane defaults and just left off.
6) The very notion of a Core hook along exported directive removed with every current core hook placed to pol/pkg/core. I.e combat hook becomes pol/pkg/core/combat.src. Akin to scripts/misc/ which are essentially core hooks...
7) in fact pkg folder must be renamed to scripts with the old meaning scripts folders removed from the core and the documentation.
Config files to be fully R/W and dot access to config elements removed to suppress the confusion.
9) struct datatype removed from the core and array renamed into list giving it list::remove(object) // removes an object from a list.
10) think on the way to join on/canremove and inserts back into one giving it only 2 parameters: container and item.
11) Distro's gumps package embeded into core.
12) Storage system simplified to 2 API calls MAXIMUM.
..) Skills and regen rates should be Real datatype with rates expressed per minute.
...) Integer objtypes removed! from the core as it only used to create a coding terror by hardcore noobs. And aseparate call to create something non-existant in itemdesc.cfg but available in tiledata.
....) Have len() return error for anything but String. With < > <= => operators to create exception when used with uncomparable datatypes. That would save many lives! Thats the mother of all Chaos!
-) ecompile should have no options and just compile every script needs compiling (update option). It also begs to support all the cpu cores.
--) send_event to always send a dictionary containing sender and controller.
---) Sacrifice the flexibility for ease of use wherever possible. Yes, exterminate!
x) The most demanded feature .isa(POLCLASS_PLAYER) should see the light! Scripters tend have about 20 ways of doing it with 19 of these being essentially wrong.
This is rant or whatever it means. Itsn't not a demand or a way to start a flame. In fact, just disregard this message totally.
-1) on_doubleclick script explained at the second line of README file. If doesn't exist, the core creates it.
0) The documentation MUST reflect POL's event driven model instead of being an extensive EScript reference. The newbie has no slightest idea why thy should learn the script - we should give them the idea why. Doesn't have to be reworked, just a paragraph explaining the ideology would do.
1) Folders nightmare must end with scripts and config folders removed and servers.cfg placed in POL's root renamed to shard.cfg (becase why plural is not obvious).
2) use directive needs to be removed making every Core function automatically available.
3) "Distro" renamed to something that would convey its meaning and silently included into every distribution.
4) program directive must be explained in the first line of the README. Most people get it wrong.
5) servopts, combat.*local.cfg and uoclient.cfg merged back to the pol.cfg with all of the "expert" tweaking options given some sane defaults and just left off.
6) The very notion of a Core hook along exported directive removed with every current core hook placed to pol/pkg/core. I.e combat hook becomes pol/pkg/core/combat.src. Akin to scripts/misc/ which are essentially core hooks...
7) in fact pkg folder must be renamed to scripts with the old meaning scripts folders removed from the core and the documentation.
Config files to be fully R/W and dot access to config elements removed to suppress the confusion.
9) struct datatype removed from the core and array renamed into list giving it list::remove(object) // removes an object from a list.
10) think on the way to join on/canremove and inserts back into one giving it only 2 parameters: container and item.
11) Distro's gumps package embeded into core.
12) Storage system simplified to 2 API calls MAXIMUM.
..) Skills and regen rates should be Real datatype with rates expressed per minute.
...) Integer objtypes removed! from the core as it only used to create a coding terror by hardcore noobs. And aseparate call to create something non-existant in itemdesc.cfg but available in tiledata.
....) Have len() return error for anything but String. With < > <= => operators to create exception when used with uncomparable datatypes. That would save many lives! Thats the mother of all Chaos!
-) ecompile should have no options and just compile every script needs compiling (update option). It also begs to support all the cpu cores.
--) send_event to always send a dictionary containing sender and controller.
---) Sacrifice the flexibility for ease of use wherever possible. Yes, exterminate!
x) The most demanded feature .isa(POLCLASS_PLAYER) should see the light! Scripters tend have about 20 ways of doing it with 19 of these being essentially wrong.
This is rant or whatever it means. Itsn't not a demand or a way to start a flame. In fact, just disregard this message totally.
Re: learning curve must be lowered
Not all good, not all bad. But this is extremely important stuff to make it easier for new comers indeed.
Re: learning curve must be lowered
The idea to make it more easy for new people to Pol is good, but most of these ideas will remove alot of the customizable stuff in Pol so I dont really agree with most of them
-
- New User
- Posts: 19
- Joined: Wed Sep 15, 2010 9:47 pm
Re: learning curve must be lowered
Maybe a couple of guides that are a little less theoretic than Racalac's would do the trick. The Gump tutorial is a good example, as it covers a limited subject and explains how to make it compile. I think it´s a better solution than amputating the core.
By the way, when I was learning how to script I think the two more difficult things to learn where packethooks and events. Not because those are difficult subjects, but because all reference to them is kind of vague, and learning was a mix of reading posts, documentation and trying to figure out what the scripts from the distro did. In fact, the trauma made me write a tutorial about packethooks to the other scripters of my shard, so they didn´t have to live that hell. Maybe one day I´ll translate it from Spanish...
By the way, when I was learning how to script I think the two more difficult things to learn where packethooks and events. Not because those are difficult subjects, but because all reference to them is kind of vague, and learning was a mix of reading posts, documentation and trying to figure out what the scripts from the distro did. In fact, the trauma made me write a tutorial about packethooks to the other scripters of my shard, so they didn´t have to live that hell. Maybe one day I´ll translate it from Spanish...
Re: learning curve must be lowered
I think that packet-hooks are not truly essential to the shard programming (though I use it heavily). The events on the other hand are and I think they need to be thoroughly documented.
Re: learning curve must be lowered
Hey Polytropon, would you care to share your guide? I'm brazillian, but I can speak a good amount of spanish, and maybe I could spare your work of translating it!
I will understand if you want to do it yourself though
I will understand if you want to do it yourself though
Re: learning curve must be lowered
When I think of it we should make something like Pol Tutorial Foundation=) I wanted to write a POL programming book once, but there is so many people who disagree with my programming approach I no longer know it it would even be helpful.
Re: learning curve must be lowered
Ive kinda wanted to make guides too... that explain concepts.
First start with stuff that can be done with runecl.exe, most people can skip it as it covers syntax and general programming.
Cover how to make a text command.
Areas of focus I can see being really beneficial to POL:
Move onto how to read config files; how ::filename :*:filename and filename are all different, particularly with memory usage and accessing information.
-- This would help make it so people don't need to place redundant cprops on things.
Cover how events work. When they should be used. They're not just an AI thing.
- This would help with people who like to have scripts read/set cprops to look for triggers. Events would be the better way to do it.
Cover how to use method scripts and why they are so useful.
First start with stuff that can be done with runecl.exe, most people can skip it as it covers syntax and general programming.
Cover how to make a text command.
Areas of focus I can see being really beneficial to POL:
Move onto how to read config files; how ::filename :*:filename and filename are all different, particularly with memory usage and accessing information.
-- This would help make it so people don't need to place redundant cprops on things.
Cover how events work. When they should be used. They're not just an AI thing.
- This would help with people who like to have scripts read/set cprops to look for triggers. Events would be the better way to do it.
Cover how to use method scripts and why they are so useful.
Re: learning curve must be lowered
I would LOVE to see all this material, Austin.
I really hope this could be done some day. I'm just a complete newbie at POL, I can barely make simple scripts, something like this would help A LOT.
I really hope this could be done some day. I'm just a complete newbie at POL, I can barely make simple scripts, something like this would help A LOT.
Re: learning curve must be lowered
Of course I agree with trying to make POL easier for newer people to grasp and having guides that ease you in more with useful information instead of trying to teach you the whole language before seeing any results. But the points you're making are just screaming inexperience. Things you say aren't necessary are way more than necessary, you just don't have a use for them because you don't know how or where to use them. There's always going to be a learning curve because the more advanced stuff gives those who have the experience and knowledge of these features the flexibility to do even more with them.
Re: learning curve must be lowered
Here is a start:
http://forums.polserver.com/viewtopic.php?f=45&t=3540
The epiphany is hopefully presented in the last post.
http://forums.polserver.com/viewtopic.php?f=45&t=3540
The epiphany is hopefully presented in the last post.
-
- New User
- Posts: 19
- Joined: Wed Sep 15, 2010 9:47 pm
Re: learning curve must be lowered
I translated the guided and posted it in the new forum. However, if you prefer to read it in Spanish please PM me and I will try to make it a simpler spanish-version (following the Protocol of Cultural Integration of Mercosur )Pachacuti wrote:Hey Polytropon, would you care to share your guide? I'm brazillian, but I can speak a good amount of spanish, and maybe I could spare your work of translating it!
I will understand if you want to do it yourself though
Re: learning curve must be lowered
Don't worry about it, the english version is just fine, thanks!
I'd love to help making the POL community increase, is there anything I could do at the moment? I'm not really experienced, but I can do some basic stuff...
I'd love to help making the POL community increase, is there anything I could do at the moment? I'm not really experienced, but I can do some basic stuff...
Re: learning curve must be lowered
Guides is one thing to make the community grow ( Should make a separate forum for eScript and Pol Guides and there could be UO guides aswell.
For Edwards it should be nice to get an installer for the latest Distro, because SVN is not the easiest approach for everyone.
These 2 things I think should help Pol to get more users, and ofcourse similar to RunUO a shard run by the latest Distro should be a good approach too to show people what can be done by Pol. ( Maybe Edwards should want to put up his shard as a "Distro" shard )
For Edwards it should be nice to get an installer for the latest Distro, because SVN is not the easiest approach for everyone.
These 2 things I think should help Pol to get more users, and ofcourse similar to RunUO a shard run by the latest Distro should be a good approach too to show people what can be done by Pol. ( Maybe Edwards should want to put up his shard as a "Distro" shard )
Re: learning curve must be lowered
Hey Austin,
Love the new guides forum!
Please post one describing the use of runecl.exe. I remember asking one of the devs a long time ago what that was used for. I can't remember the response I received but I do remember it left me more confused than before I asked. Although, with me that isn't hard to do.
*grins*
Love the new guides forum!
Please post one describing the use of runecl.exe. I remember asking one of the devs a long time ago what that was used for. I can't remember the response I received but I do remember it left me more confused than before I asked. Although, with me that isn't hard to do.
*grins*