+- SphereCommunity (https://forum.spherecommunity.net)
+-- Forum: General Discussion (/Forum-General-Discussion)
+--- Forum: UO/Sphere Discussion (/Forum-UO-Sphere-Discussion)
+--- Thread: New Features Request (/Thread-New-Features-Request)
RE: New Features Request - RanXerox - 05-25-2013 08:21 AM
Okay, thanks for the explanation. Is there anything preventing you from using SPELLEFFECT instead of RESURRECT?
RE: New Features Request - Ben - 05-28-2013 08:19 PM
Why not just override the default RESURRECT functions with a scripted one that uses the casting version? Then you don't have to deal with nasty workarounds in all your scripts. You would still be using the same function name.
RE: New Features Request - Coruja - 08-26-2013 08:32 AM
Quote:13-07-2006, Nazghulfor ages all we got is this, it's 2 basic values but not the entire system. My ideia is finish this engine and get it fully working - and hardcoded.
- Added: CURFOLLOWER, MAXFOLLOWER with no built-in functionality. These variables
change values on a status gump.
Why hardcoded if it can be done using scripts? Because the idea is make it working for everyone just setting simple properties on chars/npcs, without needing a much more complex scripted engine which will need many tags, events, funcions, etc. I can make a custom script myself on my server, but the idea is make it working for the entire community, not just for me.
The engine is simple and can be easily made
------------------------------------------------
The basics / Whats needed:
1)
2)
3) new CONTROLSLOTS property on NPCs (to determine how many CURFOLLOWER slots will raise/decrease). If not set on NPC, it wont use any slot.
4) OPTIONAL: new CURFOLLOWER.0, CURFOLLOWER.1 [...] returning pet UID [read-only]. Not really needed, but will be a huge improvement to allow ppl create custom scripts like a custom dialog showing all pets the player has, a custom spell/function to run on all pets of this player, etc. It's like a reverse <OWNER> function.
The fully working engine:
1) counter will raise when:
-unshrink some creature (@DClick on t_figurine)
-summon a creature using some spell (@Start on spells)
-get a pet transfered to you
-buy a pet on a npc (animal trainer, etc)
-retrieve a pet stabled on NPC
2) counter will decrease when:
-pet get removed (@Destroy)(this already includes pet die/shrink/stable I think)
-pet get untamed (@PetDesert, "all release" command or when owner attack it)
-pet get transfered to someone
3) prevent the actions (on 1) if it would exceed the MAXFOLLOWER limit
RE: New Features Request - Rattlehead - 08-26-2013 10:03 AM
agreed coruja, this would be nice to have.
RE: New Features Request - Coruja - 08-28-2013 12:42 PM
today I noticed that EF_PetSlots still exists on .ini
I thought it had been removed, but still here (incomplete) with the message "incomplete, do not use until this warning is removed"
so there's not much left to do, half of the "structure" is already there, we only need add the CONTROLSLOTS property on NPCs and implement the raise/decrease functionality
RE: New Features Request - Khaos - 09-11-2013 12:14 PM
So remind me later to start providing soft code scripts to do most of what is being said here... sounds on drop.. completely doable. Color overrides I am getting extreme to run some of my ideas now. I will look at the rest after I eat and get a nap in; but yeah. Minus razor at the moment from what I did read... I could script a good bit of this.
I am going to make a point in here I did in IRC. Tag's are your friend. Do not listen to what they used to tell you where they are bad and eat soooo many bytes. It costs more in memory to have one item in your world than it does to have a handful of tags.
As I explained in irc you could significantly remove tons of lag and memory usage just by scripting up a good vendor system using no items in its boxes... just generate buy lists with tags and sell lists to store information via tags.
Coruja I will look into controlslots and curfollowers I will look into as well. If resurrect wasn't fixed... I can script that fix too for you coruja -_-. I don't know how I feel about changing the hardcode to do the same thing. One is a spell and the other isn't.
RE: New Features Request - Rattlehead - 09-12-2013 09:38 AM
(09-11-2013 12:14 PM)Khaos Wrote: I am going to make a point in here I did in IRC. Tag's are your friend. Do not listen to what they used to tell you where they are bad and eat soooo many bytes. It costs more in memory to have one item in your world than it does to have a handful of tags.
but i assume it would still be a good idea and save some resources by using the unused slots for info in items first? ex. using more's for info that are not being used by something else rather than leaving them unused and using tags.
hopefully i made sense.
RE: New Features Request - Khaos - 09-13-2013 01:11 PM
Oh I understand that and it really depends. This comes back to an old argument of what else might be calling for those values. Though I don't plan on changing any hardcode to change this behavior in old code... it could happen (unlikely). Plus, when my pc is running (HDD is locked up from chkdsk and might be a bad windows file; ie I have to buy a new HDD to back mine up too and reformat) I am going to see how much code is being processed checking a MORE value and what it takes to store it. A tag is literally a byte per alphanumeric character you use. This can be really low in resource use.
Like I made a statement about vendors and like 500 of each item (even 50 is a lot). I can use one tag with 3 arguments in it. ItemID, Value, and Amount... and just that one line freed up 500 items. That is a lot of free memory and way less items. So even if you attached 50 tags to every player.. it still is not going to be as harsh on your server as 500 items in a vendor box for each item on a vendor.... on every vendor.
I would still use things like more and blank placeholders as such if you want. It might be easier just to remember a tag though when scripting without using a reference. I think that is more personal use. As I said, more could change in the hardcode one day... but most likely not. Again, preference.
If that does end up happening (using those empty slots for something else) I would give the community a weeks prior notice to get ready for it. I dont see it happening on my end though.
We can also look at small things as well with this. If you go the tag route; use small and conventional tag naming. tag0.reflectphysicaldamage=<value> uses more bytes that tag.reflectphysdam=<value> which also uses more bytes that tag0.rpd=<value>.
These are just small things to consider. I remember when I wasn't on the dev team; we were always told this was bad practice. If anyone remembers; Naz and I went round to round over things like this. Sometimes Naz was right; sometimes I could make a point or post one script and prove my point. Tags were never bad. They were bad back in the day with low rate PC hosts, buggy servers with memory leaks, and just limited usage of them. Now there is so many ways to take advantage of them; I suggest for people to reconsider their use. A tag is like making a definition or class in the hardcode. We do it with all programming. So why not use it to your advantage in softcoding? It could save you a lot of memory and create some really nice systems for yourself.
RE: New Features Request - XuN - 09-13-2013 05:12 PM
It really depends on what and where are you scripting, if you are coding on a character I wouldn't access an item since tags are accessed faster than searching for an item and it's value/tag/whatever, I remember 55x times when you had to do 'try tag.value<blah>' to store dynamic tags, I disliked a lot, and tried to always use items with it's default values but, nowadays, its really easy to work with tags. I don't know how many values an item really have but it's still better having thes values x2 in tags than one item with all this values filled at your needs IMO.
BTW these tests sounds very interesting.
RE: New Features Request - darksun84 - 09-13-2013 05:45 PM
What about LIST ? i currently use it for recording players feats (LIST.feats_<uid>)
