Ok, I've gone through... not this whole forum, but the last 2 pages. I have skimmed through stuff- yes, I might have missed something.
I don't have a lot of time for coding right now, but what I can do is try to make things easier and more efficient for the ones who are.
I am assigning a personal "priority" to each - you may disagree, and so might the other devs, but it's where I feel they go. Not on a huge amount of reflection, mind you. Green low, Blue medium, Red high.
UO.em:
GetGlobalPropertyNames() - just return a list of names. It's medium because it's probably pretty easy.
CheckLosAt accept char or item; or, CheckLosBetween(x1,y1,z1,x2,y2,z2,realm) - pretty straightforward
Book methodscripts:
Add character as a param- allows locking books to specific people, char-centered sounds, animations
cfgfile.em:
** GetConfigPropertyNames(cfgelemref)
GetConfigElemType(cfgElemRef)
General:
Speed normalization- anti-speedhack
Update login for new clients - see below
Use IDs > 1023 in MULs - this shouldn't be too difficult
Combat:
* ApplyDamage returning real damage done
way to return the wait time until player's next swing
Items:
Destroyscript should call Unequipscript - unless there's a compelling reason why not?
Give dragged items an item.GetGottenBy() method - (which would return a charref), to parallel the char.GetGottenItem() method (which returns an itemref)
NPCs
Move purchasing of items out of core - see http://forums.polserver.com/ftopic1965.php - seems like a good idea, probably hard though
Methodscripts - see http://forums.polserver.com/ftopic27.php
Verbose errors if they fail to move - tell us what stopped them, possibly add a forcemove option
boats.cfg:
Allow non-default z
Gumps:
CloseGump( character, gump_id ) - close the gump and return something to the waiting script
Methodscripts:
Clean them up some - http://forums.polserver.com/ftopic2043.php - currently if a method is called any previously running methods on that Object die
Escript:
Allow counter declaration in for loops - such as: for (var i := 5; i > 0; i -= 1)
Systems
Expand regen bounds - for those who would like more than 300 hp/min
Datafiles
Create a "don't save me" property/flag, similar to GProps "#" - Not sure this is possible but if can be done at all it should be relatively simple.
Allow Integers as propnames - Not a big deal with CStr and CInt, but I don't see why they need to be forbidden. (Another dev may well tell me, though.
elemref.Delete() - allow deletion of an element without going through datafile.em.
--
New client login info:
I will add to this post as people continue to post in this forum. Feel free to use this thread to discuss the merits of the suggested features.With client 2.48.0.3+ (KR) and 6.0.5.0+ (2D) there comes a change in handling the login packets. It would be nice if the pol core could handle that in the future.
Some information, if needed:
Quote:
OK, my dear ladies and gentlemen, i want to say that NO NEW encryption was implemented in 6.0.5.0 patch. NO NEW packets were added in this patch. It was just a game for children and you're faked Smile
How UO works before this patch: client sends seed (4 bytes, really local IP-address) and then sends packets for login server stage authorization.
How UO works after this patch: client sends seed (same 4 bytes), THEN SENDS 17 NEW BYTES, after this sends packets for login server state authorization. That's all! It's very simple, really? OK, now for these 17 cursed bytes
First byte is random value, usually it's last byte of seed, because first byte of seed is really new byte and our IP begins from second byte.
Next 16 bytes is client version - 00 00 00 06 00 00 00 00 00 00 00 05 00 00 00 00
So, all we need is to expand seed buffer for new clients.
Edit:
* Done and checked into core
** Redundant with existing systems