Not really sure why this is on the front page, but hi!

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:

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.

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.


Edit:

* Done and checked into core
** Redundant with existing systems

Nice idea, thanks for the effort you (will) put into this.

--

Noticed this:
GetConfigPropertyNames(cfgelemref)

Couldn't find a thread about it, so, how exactly is it going to differ from ListConfigElemProps( element ) (http://docs.polserver.com/pol097/fullfu ... gElemProps)?

Have to say I like the proposed name better, but is there something else, too, that I did not realize?

Here is the thread which proposed it:
http://forums.polserver.com/ftopic1339.php

If that is how things already work, then I can check it off the list.

Boy, is my search ability weak or is it just the engine... But yeah, that's what it does.

Waiting for an update I am.

Any time now, right?

(Who told you this was a good idea)

Initial post updated, as part of my quest to catch up around here again.

Zomg weapon speed calculation hook?

I'm slow today- what do you mean exactly?

A script hook like attackhook that would be used to return the wait time in miliseconds for player's next swing. So we can factor our own ways to make players swing faster/slower based on different stats than the core uses.

As discussed/locked here(among other posts...);
http://forums.polserver.com/viewtopic.php?f=4&t=2039

You want to affect their swing time dynamically, it is already there my friends. Read up in core-changes for a new prop that affects swingspeed. .Delay? can't remember, been a while. If it doesn't work, TELL US, and provide proof and a way to test, not just complain hehehe.

By the way, no, I AM NOT DEAD! But I AM relocating to the Florida coastline for a new programming job in a month, so in a month or two should be back around more mates. Have fun.

Be careful of the hurricanes Maud.

or in the case of the last week or so... Tropical Storms...

Added : character.delay_mod [+-ms] for WeaponDelay
If (Delay!=0) use Delay(+delay_mod) to calculate next weapon swing.

Is this a temp prop(Doesn't save so when we have an equipscript modify it on restart it doesn't reapply the affect?)? And I'm not sure if it means that it will just use .delay_mod + weapon delay OR both of those + core delays(dex and shit). Haven't tested.

Quoting core-changes: If weapontemplate has a delay set, it will be used instead of the core's calculated speed (+ dex + whatever). Then, the actual swing delay can be modified using character.delay_mod (r/w). If weapon doesn't have a configured delay, modifying characters' delay_mod does nothing.

The value is not saved to data files.

Any suggestions on how to keep char.delay_mod properly updated for like say Dex bonus on speed?

I thought about modifying it when attackhook is called, but the first swing wouldn't be calculated after a change - Don't like that idea. Thought about a control script fired at logon to check for changes and make the modifications - Don't like that idea either, lol. Maybe using GetAttributeIntrinsicMod() hooks or in the GetMaximumVital hooks, probably seeing as how they're both called when the attributes are modified ...

Look to oldschool. Older distro and other scriptbases use to force a re-equip in the logon scripts of all worn items. Using that method it would reapply any temp mods made by a worn item. That would work in this case.

Now, another thing to consider. If you do it dex based, skill based, etc, you MUST have a method to recalc the delay setting for the prop in your attribute hooks. That way, when a skill (if you use skill), or a stat (if you use stat) increases it will apply the new prop settings correctly and it go into effect live. Not just when the item is re-equipped or logoff/logon.

(This is veering off track from the original topic, sorry.)

I noticed that POL already does that for us(Force reequip of all items on startup.) and using temp cprops/mods you don't really need to do any reequipping/unequipping. -- It took me forever to figure out that # before a cprop name makes it temp(Not found in docs, don't know if it's noted in distro either.).

Now for attribute hooks delay mods, like Dex;
150 base dex: -15MS
Total: -15MS +delay_mod = -15MS
+50 from bless: -5MS
Total: -20MS +delay_mod = -35MS
+50 from cunning: -5MS
Total: -25MS +delay_mod = -60MS

When it should only be -25MS total, looks like a temp prop to save each attributes effect on delay_mod to make the right adjustments when the attribute mod changes... my head wants to essplode, lol. Anyway.

(Highjacked from Justae)
EffectiveDex = (BaseDex + TempDexMod + InstrinsicDex) / 10
spd_div = (EffectiveDex + 100) * weaponspeed
clock_to_next_swing = (15,000,000 / spd_div) msecs

Is that the true formula? Before I start updating all my weapons, lol.

As an aside, I'm behind on updating this, but I haven't abandoned it or anything. Just a few suggestions came through when I was either in a hurry or I wasn't sure the merit of the suggestion, and so I procrastinated on adding them, and now I'm all behind.