+- 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 - Mordaunt - 05-02-2013 10:21 PM
The thing with this is....
There is also a "new feature request" option over on the bug tracker.
I'm not sure which is supposed to be the preferred method of submitting these.
RE: New Features Request - Rattlehead - 05-02-2013 11:46 PM
seems easier to do it here, as more ppl use the forums, plus its hard to hold a decent conversation on the bug tracker
RE: New Features Request - Coruja - 05-05-2013 06:19 PM
I've got a new suggestion: DB.EXECUTEB (or DB.EXECUTEBACKGROUND, but it's too big for a function name lol)
because using DB.EXECUTE will cause sphere to stop everything on the whole server until the SQL return a response, so if you use DB.EXECUTE with a huge SQL command, it will "freeze" the sphere causing lag on all players
example:
Code:
[FUNCTION UpdateKarma]
ON=@KarmaChange
DB.EXECUTE "UPDATE accounts SET karma='<KARMA>' WHERE uid='<UID>' LIMIT 1"
[FUNCTION UpdateKarmaAllPlayers]
FORCHARS 500 //update logout accounts too
TRIGGER @KarmaChange
ENDFOR-UpdateKarmaAllPlayers: using this function, sphere will freeze for 1~60 seconds depending how many players it will update. Again, no problem updating 3~6 players but will freeze the entire server for more than 60 seconds if used on 5000 accounts
the DB.EXECUTEB will be a great solution for this, since the EXECUTE will run on background and sphere does't need to wait for a SQL response, so we can execute much more SQL commands without any lag
------------------------------------
(05-02-2013 10:21 PM)Mordaunt Wrote: The thing with this is....I think it's better create a new forum section named "New Feature Request" under "Sphere .56b" forum
There is also a "new feature request" option over on the bug tracker.
I'm not sure which is supposed to be the preferred method of submitting these.
RE: New Features Request - Ben - 05-06-2013 12:20 AM
Please do a little research before suggesting something that's already there.
http://wiki.sphere.torfo.org/index.php/AEXECUTE
http://wiki.sphere.torfo.org/index.php/AQUERY
RE: New Features Request - Coruja - 05-06-2013 05:56 PM
thx, I totally forgot about these functions, will take a look tomorrow
btw I researched here (http://wiki.sphere.torfo.org/index.php/Using_MySQL) before posting but I don't found nothing, AEXECUTE and AQUERY is not documented there and nor on nightly changelog :/
RE: New Features Request - Ultima One - 05-10-2013 10:22 AM
Didnt know of them either.. will help me greatly
Thanks Ben 
RE: New Features Request - Rizz - 05-19-2013 08:59 PM
A command to kick the "not logged in" connections
RE: New Features Request - Coruja - 05-23-2013 02:58 AM
(05-19-2013 08:59 PM)Rizz Wrote: A command to kick the "not logged in" connectionsI have no idea why you want do this, but I think a not logged in client have it's own active socket too, so you can manage it using some SOCKET functions (I never tried, maybe even doesnt exists functions like this) or play with this .ini setting:
Code:
// Disconnect inactive socket in x min
DeadSocketTime=5I got a new feature request, @Resurrect (or @CharResurrect, whatever)
it seems quite self explanatory, will run everytime -before- a player got resurrected
-return 0: allow resurrect (default)
-return 1: deny
I'm suggesting this because actually the only way we can get this partially working is using a horrible workaround on @Success of spell 59 (s_resurrect). It works for a basic resurrect when players or NPCs healer cast s_resurrect spell, but doesnt work using "resurrect 1" function since it's not a spell and doesn't call @Success. So in this case there's no way to handle it and this new trigger will be the key to get it working
RE: New Features Request - RanXerox - 05-23-2013 04:40 AM
If you want to prevent GMs from using the built-in RESURRECT function... then move it to a higher PLEVEL.
If there are conditions in your code where a built-in RESURRECT function should be prevented, use an IF statement.
RE: New Features Request - Coruja - 05-25-2013 04:59 AM
but that's not the point :/
theres "2 types" of resurrect with different functionalities, I just wanna integrated all on a single trigger that works for both, not prevent one type to be used
on my server we use the normal "cast" resurrect (where the resurrect confirmation dialog appears) and theres the "forced" resurrect too (function RESURRECT 1) which we use on scripts (automated quests, systems, etc) where the player -will- be resurrected without any confirmation. No problem resurrecting, because both will resurrect fine. The problem is about how sphere handle both resurrect styles (triggers)
Using a real situation example, I use a realtime SQL paperdoll to show it on the website, when the player dies it must update corpse color to 0 and make it ghost style (works fine with @Death), but when it resurrects the body must be updated again to the correct body and color but this is only possible using the "casted" resurrect (@Success on spell 59). For RESURRECT 1 functions I must create a horrible workaround calling a horrible function every time I use RESURRECT 1 and it's a pain for who uses a lot of them in different script files. So, everything is a horrible workaround because half of the code is wrote on a workaround (@Success on spell 59) and the other half is wrote manually on another workaround. Theres workarounds everywhere and thats not good. Thats why a simple @Resurrect will save tons of ugly workarounds, making everything works perfectly on a single trigger