learning curve must be lowered

Need to discuss something being done all wrong? Explain it!
Also home of flame-fest-fridays.

Moderator: POL Developer

Post Reply
User avatar
andenixa
Grandmaster Poster
Posts: 105
Joined: Tue Nov 09, 2010 1:33 am

learning curve must be lowered

Post by andenixa »

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.
8) 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.
User avatar
*Edwards
Forum Regular
Posts: 303
Joined: Fri Dec 28, 2007 11:19 pm
Location: Montreal, Canada

Re: learning curve must be lowered

Post by *Edwards »

Not all good, not all bad. But this is extremely important stuff to make it easier for new comers indeed.
Tomi
POL Developer
Posts: 478
Joined: Tue Feb 21, 2006 5:08 pm

Re: learning curve must be lowered

Post by Tomi »

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
Polytropon
New User
Posts: 19
Joined: Wed Sep 15, 2010 9:47 pm

Re: learning curve must be lowered

Post by Polytropon »

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...
User avatar
andenixa
Grandmaster Poster
Posts: 105
Joined: Tue Nov 09, 2010 1:33 am

Re: learning curve must be lowered

Post by andenixa »

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.
Pachacuti
Apprentice Poster
Posts: 51
Joined: Fri Jun 12, 2009 8:57 am

Re: learning curve must be lowered

Post by Pachacuti »

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 :D
User avatar
andenixa
Grandmaster Poster
Posts: 105
Joined: Tue Nov 09, 2010 1:33 am

Re: learning curve must be lowered

Post by andenixa »

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.
User avatar
Austin
Former Developer
Posts: 621
Joined: Wed Jan 25, 2006 2:30 am

Re: learning curve must be lowered

Post by Austin »

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.
Pachacuti
Apprentice Poster
Posts: 51
Joined: Fri Jun 12, 2009 8:57 am

Re: learning curve must be lowered

Post by Pachacuti »

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.
User avatar
CWO
POL Expert
Posts: 1158
Joined: Sat Feb 04, 2006 5:49 pm
Location: Chicago, IL USA

Re: learning curve must be lowered

Post by CWO »

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.
User avatar
Austin
Former Developer
Posts: 621
Joined: Wed Jan 25, 2006 2:30 am

Re: learning curve must be lowered

Post by Austin »

Here is a start:
http://forums.polserver.com/viewtopic.php?f=45&t=3540

The epiphany is hopefully presented in the last post.
Polytropon
New User
Posts: 19
Joined: Wed Sep 15, 2010 9:47 pm

Re: learning curve must be lowered

Post by Polytropon »

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 :D
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
Apprentice Poster
Posts: 51
Joined: Fri Jun 12, 2009 8:57 am

Re: learning curve must be lowered

Post by Pachacuti »

Don't worry about it, the english version is just fine, thanks! :D

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...
Tomi
POL Developer
Posts: 478
Joined: Tue Feb 21, 2006 5:08 pm

Re: learning curve must be lowered

Post by Tomi »

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 )
Yukiko
Distro Developer
Posts: 2825
Joined: Thu Feb 02, 2006 1:41 pm
Location: San Antonio, Texas
Contact:

Re: learning curve must be lowered

Post by Yukiko »

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*
Post Reply