Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
EC basic support
Author Message
Feeh
Sphere Developer
*****

Posts: 156
Likes Given: 6
Likes Received: 40 in 29 posts
Joined: Sep 2012
Reputation: 4



Post: #31
RE: EC basic support
(03-19-2014 09:13 AM)XuN Wrote:  Some help with this would be nice, at least a point on where should I look.

I'll send you a PM with some details of how these packets work and where to get some reference using RunUO code

Feeh/Epila - Nightly releases / SphereWiki / Github Issues / Sphere's GitHub
03-20-2014 03:59 AM
Find all posts by this user Like Post Quote this message in a reply
karma
Moderator
****

Posts: 178
Likes Given: 17
Likes Received: 32 in 29 posts
Joined: Jul 2012
Reputation: 3



Post: #32
EC basic support
I'm back guys Tongue
After some packet capturing and lots of tests i bring you some interesting infos.

Text, talkmodes and coloured text
SAYU don't work properly, as i stated previously. I'll show causes and solutions.

Unicode Speech: talkmodes do different things from the expected, which are described in sphere_defs. Let me be clearer.
Talkmode 0: the only one that admits/generates/whatever **coloured text**. It is considered as a system "speech" (not sysmessage, not speech/say). This is text shown upon the char, it isn't normal speech, but text that would show using .xsay blabla; not sure if i have explained well.
Talkmode 1: sysmessage. That's okay, it's what i expected.
Talkmode 2: not tested.
Talkmode 3: it is supposed to be the speech/say mode, but it shows a purple sysmessage, whatever colour i use.
Talkmode 4 (talkmode_obj): it's like saying something, with yellow text, whatever colour i use (colour decided by client i think).
Talkmode 5 (talkmode_nothing): a gray sysmessage.
Talkmode 6,7 (talkmode_item, talkmode_noscroll): same as 5.
Talkmode 8,9 (talkmode_whisper, talkmode_yell): same as 4.

Command + packet used for testing:
Code:
[function speech1]
SENDPACKET 0AE 00 0DC D(<UID>) 01 090 B(10) 03 00 00 03 00 00 00 00 052 06F 064 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 052 00 06F 00 079 00 061 00 06C 00 020 00 049 00 06E 00 076 00 065 00 073 00 074 00 069 00 067 00 061 00 074 00 069 00 06F 00 06E 00 03A 00 020 00 044 00 069 00 073 00 063 00 06F 00 076 00 065 00 072 00 020 00 077 00 068 00 061 00 074 00 027 00 073 00 020 00 06E 00 065 00 077 00 020 00 069 00 06E 00 020 00 04E 00 075 00 06A 00 065 00 06C 00 027 00 06D 00 020 00 061 00 06E 00 064 00 020 00 072 00 065 00 070 00 06F 00 072 00 074 00 020 00 076 00 069 00 061 00 020 00 074 00 068 00 065 00 020 00 075 00 073 00 075 00 061 00 06C 00 020 00 063 00 068 00 061 00 06E 00 06E 00 065 00 06C 00 073 00 00
In brackets, into B( ), is the talkmode.
The problem with SAYU is that uses talkmode 3, not 0, which is the only that can show coloured text.
Other talkmodes, such as 4,8,9, shall be used for player speech.

Other interesting thing: by altering the serial dword (the UID of the player) and putting FF FF FF FF, is possible to show the text in the top-left corner of the screen.
Currently server broadcasts (serv.b) use ASCII text packet which can only show over the player or in the journal/system box and cannot be coloured (i did several tests), in fact it shows as a gray sysmessage.
So i suggest to use Unicode text packet, with 0 talkmode and FF FF FF FF as serial, to show server broadcasts.
Example:
Code:
[function broadcast]
SENDPACKET 0AE 00 06A 0FF 0FF 0FF 0FF 0FF 0FF 00 B(03) B(0B2) 00 03 045 04E 055 00 053 079 073 074 065 06D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 054 00 068 00 061 00 074 00 020 00 069 00 073 00 020 00 06E 00 06F 00 074 00 020 00 061 00 020 00 076 00 061 00 06C 00 069 00 064 00 020 00 063 00 06F 00 06D 00 06D 00 061 00 06E 00 064 00 02E 00 00
B(03) and B(0B2) is the color word, and this color is a gray.

I did not do experiments on Graphic and Font words, but i think they are not so important.


Particle, standard and hued effects
What we know is that C0 (hued effect) and 70 (graphical effect, not hued) packets works in EC, BUT C0, which is supposed to show hued effects if i set a hue, still shows non-hued effects.
So i looked at the C7 packet, which is the particle effect packet.
Structure:
Quote:49 bytes

byte ID (C7)
byte Type (0x00 = from source to destination, 0x01 = lightning strike, 0x02 = stay
with destination, 0x03 = stay with source)
dword Character Serial
dword Target Serial
word Object ID
word Source X
word Source Y
sbyte Source Z
word Destination X
word Destination Y
sbyte Destination Z
byte Speed
byte Duration
word 0x00
byte Fixed Direction (0x00 = No, 0x01 = Yes)
byte Explode (0x00 = No, 0x01 = Yes)
dword Hue
dword Render Mode
--From here is what i call "particle effect "data part"", above is the "normal/classic effect "data part""
word Effect ID
word Explode Effect ID
word Explode Sound
dword Serial
byte Type (0xFF or 0x03)
word 0x00

Very interestingly, this packet can be used both for normal (C0 and 70 packets) and particle effects.
Leaving "blank" the data which relates to a normal effect (same packet components of C0 and 70) (even if filling it won't do nothing, if you fill particle effect "data part") and filling the particle effect data part, it will show a particle effect.
In EA servers, the majority of spells use new particle effects.
Sadly, IDs of the old animation/item used for the old effect (Classic Client, or pre-KR clients) are not the same of the IDs of the particle effects. So, if 02347 is the ID for the particle effect of Pain Spike, the item with 02347 ID is a part of a serpent pillar. Yes, Pain Spike did not have an effect, so later i'll try other spells.

EDIT: tried also with magic arrow.
Old effect ID: 036E4
Particle effect ID: 0BBE
Particle effect Explode ID: 0FA6 (dunno what it is, probably the effect played when the first one is finished, imagine a second effect that occurs after the arrow hit the target: other analysis required)

Moreover, the IDs are not progressive, so this is a field to be explored.
Function used for testing particle effects:
Code:
[function parteffect]//for EC particle effects
//usage: parteffect <id>
IF !(<ARGN1>)
    ARGN1=1
ENDIF
SENDPACKET 0C7 03 D(<UID>) D(0) W(0) W(<P.X>) W(<P.Y>) B(<P.Z>) W(<P.X>) W(<P.Y>) B(<P.Z>) B(16) B(05) W(0) B(01) B(00) D(0) D(0) W(<ARGN1>) W(1) 0FF 0FF D(<UID>) 02 W(0)
It is in a very raw version, when i'll have some time i'll make it more complete, with a syntax similar to EFFECT.

On the other side, if i leave blank particle effect data part but i fill only the normal effect data part, i obtain a classic effect, like those with C0 and 70 packets.
Code:
[function eceffect] //for standard effects in EC (those dealt with EFFECT), but still cannot have hued effect
SENDPACKET 0C7 03 D(<UID>) D(0) W(i_fire_column) W(<P.X>) W(<P.Y>) B(<P.Z>) W(<P.X>) W(<P.Y>) B(<P.Z>) B(16) B(16) W(0) B(0) B(0) D(094) D(-1) W(0) W(00) 0FF 0FF D(<UID>) W(01) W(0)
Unfortunately, not even this solution shows a hued effect.
The only method, right now, to obtain a hued effect is to use the worldobject packet, simulating an object in the screen, which can be coloured. This is not very efficient, because it shows a motionless item, which disappears only if i walk away the previous area (even if i think i can remove it with another packet). Anyway, i'll have to move it along the screen manually sending lot of packets, which is not very comfortable to do, and, moreover, with a very bad result.

There is another problem with items/animations like i_fire_column, which literally look different if showed adding it or with EFFECT, but we'll talk about it another time, now i have to go Big Grin
Later i'll re-read this post to check bad grammar or illogic paragraphs
(This post was last modified: 04-20-2014 05:32 AM by karma.)
04-19-2014 11:04 PM
Find all posts by this user Like Post Quote this message in a reply
karma
Moderator
****

Posts: 178
Likes Given: 17
Likes Received: 32 in 29 posts
Joined: Jul 2012
Reputation: 3



Post: #33
EC basic support
About the bug that, after death, causes not the screen to fade to gray: this is related to the fact that the packet 2C (death status) is not sent, so even if you are a ghost the screen is lighted as you are still alive.


Other infos, maybe not so useful: changing "font" and "graphic" values in Unicode and ASCII text packets did not change anything (the font is the same, i begin to think that the EC has only 1 or 2 fonts, one for speech and another for sysmessages, and those are chosen automatically; they can be the same font with different dimensions, but they seem to be too different, one appears to be bold, but not the other).

With AOS tooltips enabled, i tried to show a message on an equipped weapon using both Unicode and ASCII text packets: with talkmodes 1-8, i did not succeed.
Same occurs with AOS tooltips disabled, so i think it is not longer possible to show this type of message.

Functions used for the test (used with TARGETF):
Code:
[function suni]
SRC.SENDPACKET 0AE 00 0DC D(<UID>) 01 090 B(0) 03 00 00 03 00 00 00 00 052 06F 064 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 052 00 06F 00 079 00 061 00 06C 00 020 00 049 00 06E 00 076 00 065 00 073 00 074 00 069 00 067 00 061 00 074 00 069 00 06F 00 06E 00 03A 00 020 00 044 00 069 00 073 00 063 00 06F 00 076 00 065 00 072 00 020 00 077 00 068 00 061 00 074 00 027 00 073 00 020 00 06E 00 065 00 077 00 020 00 069 00 06E 00 020 00 04E 00 075 00 06A 00 065 00 06C 00 027 00 06D 00 020 00 061 00 06E 00 064 00 020 00 072 00 065 00 070 00 06F 00 072 00 074 00 020 00 076 00 069 00 061 00 020 00 074 00 068 00 065 00 020 00 075 00 073 00 075 00 061 00 06C 00 020 00 063 00 068 00 061 00 06E 00 06E 00 065 00 06C 00 073 00 00

[function sascii]
SRC.SENDPACKET 01C 00 031 D(<UID>) 01 090 B(0) 03 0B2 00 01 061 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 074 065 073 074 00
(This post was last modified: 04-20-2014 10:32 AM by karma.)
04-20-2014 04:35 AM
Find all posts by this user Like Post Quote this message in a reply
karma
Moderator
****

Posts: 178
Likes Given: 17
Likes Received: 32 in 29 posts
Joined: Jul 2012
Reputation: 3



Post: #34
RE: EC basic support
If you want to test what i said for text, talkmodes etc, you can use the function i posted here: http://forum.spherecommunity.net/Thread-...8#pid15998
If you need something clarified or more analysis, just ask Big Grin
04-22-2014 10:42 PM
Find all posts by this user Like Post Quote this message in a reply
XuN
Sphere Developer
*****

Posts: 852
Likes Given: 102
Likes Received: 156 in 119 posts
Joined: Jul 2013
Reputation: 30



Post: #35
RE: EC basic support
Bump almost from death: Packet 0c7 (Effect Particle) is only making a difference in EC right? I canno't make it work in a different way in classic.
03-27-2015 03:40 AM
Find all posts by this user Like Post Quote this message in a reply
Coruja
Sphere Developer
*****

Posts: 987
Likes Given: 5
Likes Received: 226 in 187 posts
Joined: Jul 2012
Reputation: 7

Dimension Shard

Post: #36
RE: EC basic support
I hate deal with packets, but I can take a look if someone give me a guide about how edit loginserver on this client to use it on sphere

EDIT: finally I got my EC client 4.0.44.0 working (latest EC update from OSI), but yep, some features doesn't work correctly (containers grid are filled on a random order, blank spellbook/vendor gumps, etc). It's good to just walk around, but not stable to use it as definitive client
(This post was last modified: 03-27-2015 08:50 AM by Coruja.)
03-27-2015 08:16 AM
Find all posts by this user Like Post Quote this message in a reply
XuN
Sphere Developer
*****

Posts: 852
Likes Given: 102
Likes Received: 156 in 119 posts
Joined: Jul 2013
Reputation: 30



Post: #37
RE: EC basic support
I don't like packets either but they are much more easier to me in the source than with sendpacket/packet handlers, write* and read* makes life easy, the only you really need to invest is the packet structure which is usually added already in ruosi and the lenght which is not always.

What do you mean with random order? I thought it was working fine already, Grid location is set each time a content is added to a container setting to it the first free grid index found unless you drop the item in an specific grid, in which case, the item goes to that grid after some checks.
03-27-2015 05:56 PM
Find all posts by this user Like Post Quote this message in a reply
Coruja
Sphere Developer
*****

Posts: 987
Likes Given: 5
Likes Received: 226 in 187 posts
Joined: Jul 2012
Reputation: 7

Dimension Shard

Post: #38
RE: EC basic support
the gump display all items following correct "contgrid" value, but there's something making the contgrid value change to a random value, and this can make weird behaviors on the gump

idk whats happened, I got 5 items on backpack (contgrid 0-4) but after some time they randomly changed to contgrid 17-21. Maybe it's something related to the "restock" or "organizer" button on backpack gump, but it's just a minor issue

yesterday I spent some time trying to fix some vendor/spellbook gump packets (03c, 024, 074 / more info here), but no luck, they still empty. EC still have some small problems like this, but if we fix the spellbook and vendor gumps it will take a step further from alpha to beta Tongue
03-28-2015 04:26 AM
Find all posts by this user Like Post Quote this message in a reply
XuN
Sphere Developer
*****

Posts: 852
Likes Given: 102
Likes Received: 156 in 119 posts
Joined: Jul 2013
Reputation: 30



Post: #39
RE: EC basic support
Same here, spent some time on this with no luck. Didn't read this... seems interesting. I think it would be no deal when we finally discover what's up with these packets.
03-28-2015 06:19 AM
Find all posts by this user Like Post Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)