+- SphereCommunity (https://forum.spherecommunity.net)
+-- Forum: Sphere 0.56d (/Forum-Sphere-0-56d)
+--- Forum: General Help (/Forum-General-Help)
+--- Thread: EC basic support (/Thread-EC-basic-support)
RE: EC basic support - Feeh - 03-17-2014 09:10 AM
(03-17-2014 07:35 AM)karma Wrote: Great! It works with EC! Many thanks Xun!
Do you (or anyone) know if RunUO has better packet support or should i create a trial account on EA?
(03-17-2014 07:59 AM)XuN Wrote: AFAIK RUO has support to almost all packets.
RunUO currenctly support every classic client packet from 3.0.6 to the newest (but not the new movement F0/F1) (also support 3.0.5 and older, but does need core mod to not send OPL packets)
There is a guy on RunUO that is working on EC client.
Once you get basic support, you get everything. There are about 15 packets that are slightly different from classic client. The main changes are the slot-based containers, character creation, some macro requests and status info
If anyone is interest on seeing what changed in terms of packets:
http://www.runuo.com/community/threads/enhanced-client-custom-gumps.535621/#post-3981943
RE: EC basic support - XuN - 03-17-2014 07:32 PM
Well, some of you are softcoding these packets (and speedhack control) and helping a lot in the proccess so i'm more interested on the rest of the packets, i've sent yesterday the new animation's packet and i'm checking out now the boats packets so step by step we can improve Sphere, any help with packets will be more than wellcome
RE: EC basic support - karma - 03-18-2014 12:38 AM
For the "dclick and equip weapon" bug: when dclicking the weapon from ground it seems to be equipped but it remains on the ground, as said previously. Dragging it on the paperdoll instead of dclicking result in the appropriate behavior, making the weapon disappear from ground. Analyzing the traffic, it seems to me that, after dclicking the object, the packet F3 (world object) is not sent (in the other situations it is), maybe is it to cause the bug?
Also, i noticed that saying things with RUO sends the unicode packet, instead of the ascii one sent by Sphere.
SAYU Sphere command shows a violet-purple sysmessage, and, while the language of the RUO unicode message shown by SpyUO is ENG, the language of the Sphere unicode message is not shown, it's a blank string, so may the error lie here? May the language specified in the packet be invalid?
@Feeh, do you know how to say colored things or show colored effects (like with the EFFECT function in Sphere) in game with RUO? Just to make some tests
RE: EC basic support - Feeh - 03-18-2014 02:53 AM
(03-18-2014 12:38 AM)karma Wrote: Also, i noticed that saying things with RUO sends the unicode packet, instead of the ascii one sent by Sphere.RunUO does use the unicode packet by default, it also supports the ascii one, but you kinda have to force it.
SAYU command Sphere shows a violet-purple sysmessage, and, while the language of the RUO unicode message shown by SpyUO is ENG, the language of the Sphere unicode message is not shown, it's a blank string, so may the error lie here? May the language specified in the packet be invalid?
@Feeh, do you know how to say colored things or show colored effects (like the EFFECT function in Sphere) in game with RUO? Just to make some tests
The language should be used by the client's internal translator, which seems to be removed from the game (RunUO send ENG\0 and Sphere send \0\0\0\0 // there is no invalid language, here I get PTB\0 )
About the messagle color, RunUO send it 0x3b2 hued by default and (AFAIK) sphere send the 0 hue . Either check your client options for some violet-hued message or it may be a internal sphere glitch
Since RunUO does not have any (script/code)-parser, you cannot use .effect/.say command in RunUO as you do with Sphere. The best you can do is create those commands & test em OR if you are used to C# and RunUO coding style, you can create the parser to call the code (time consuming)
(03-17-2014 07:32 PM)XuN Wrote: Well, some of you are softcoding these packets (and speedhack control) and helping a lot in the proccess so i'm more interested on the rest of the packets, i've sent yesterday the new animation's packet and i'm checking out now the boats packets so step by step we can improve Sphere, any help with packets will be more than wellcomeThe new boat moving packet can be found in RunUO, I suggest you to look at RunUO source and see how they've implemented it. The boat control packets are not present, but it should not be any hard to implement them
If needed I can try to describe how these packets works on RunUO
RE: EC basic support - karma - 03-18-2014 03:03 AM
(03-18-2014 02:53 AM)Feeh Wrote: About the messagle color, RunUO send it 0x3b2 hued by default and (AFAIK) sphere send the 0 hue . Either check your client options for some violet-hued message or it may be a internal sphere glitchTherefore i'll try to compare in more detail the two packets sent.
Quote:Since RunUO does not have any (script/code)-parser, you cannot use .effect/.say command in RunUO as you do with Sphere. The best you can do is create those commands & test em OR if you are used to C# and RunUO coding style, you can create the parser to call the code (time consuming)I know a little about C# but nothing about RUO.. Can you link me a guide to write the simple command i need, or if it's a fast work can you write me the code (and the file where should i put it)? I think PMs are more appropiate for this things, unless XuN or others say it is ok.
RE: EC basic support - XuN - 03-18-2014 03:51 AM
For RUO code you should use PMs, there's no need on showing it here.
About EC and DClick items, theF3 packet may be the issue since it's a newer packet and i'm almost sure it's not used in the DClick() hardcoded function.
For Ascii/Unicode I don't feel like touching it right now, maybe Ben can take a look over it.
And for the color, is there a base packet for text? Any new one being used? Or just an old packet tricked to show color?
EC basic support - karma - 03-18-2014 06:45 AM
About the say/unicode/blahblah issue: i downloaded the latest sphere svn build and the text encoding for speech is not ascii anymore but unicode.
So, i looked for the differences from the speech (visualized correctly, in yellow) and the SAYU command related packets:
Speech ("test")
Code:
AE 00 3A 00 00 1F 64 03
DB 00 00 34 00 03 00 00
00 00 61 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
00 74 00 65 00 73 00 74
00 00SAYU (".sayu test")
Code:
AE 00 3A 00 00 1F 64 03
DB 03 03 B2 00 03 00 00
00 00 61 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
00 74 00 65 00 73 00 74
00 00The main differences i noticed are:
Speech -> "mode" byte: 00
Speech -> "color" word: 00 34
SAYU -> "color" word: 03 B2
SAYU -> "mode" byte: 03 which is, huh? i don't find it in the packet guide.
The modes which i found are:
(0x00 = say, 0x01 = system, 0x02 = emote, 0x06 = label, 0x07 = focus, 0x08 = whipser, 0x09 = yell, 0x10 = spell, 0x13 = guild, 0x14 = alliance, 0x15 = GM, 0xC0 = encoded commands)
Is this useful?
EDIT: a question, it might not be a problem but is just to have a clearer vision.
In order to have a visual effect, i use the c0 packet, and it works:
sendpacket 0c0 02 D(00) D(00) W(i_fire_column) W(<p.x>) W(<p.y>) B(<p.z>) w(0) w(0) b(0) 00 b(16) w(00) 00 00 d(04) d(1)
The last dword is the render (though i don't see this in any packet guide, if i don't write it the client would block), the penultimate dword is the color.
Why with spyuo i see the render as a byte instead of a dword?
Code:
C0 02 00 00 00 00 00 00
00 00 37 09 09 B9 02 0D
00 00 00 00 00 00 00 10
00 00 00 00 00 00 00 04
00 00 00 01sendpacket 0c0 02 D(00) D(00) W(i_fire_column) W(<p.x>) W(<p.y>) B(<p.z>) w(0) w(0) b(0) 00 b(16) w(00) 00 00 d(04) 01
treating the render as a byte, client freezes. Same happens omitting the render.
Re-EDIT: oh, nothing, it is just because the most significant byte is on the right
RE: EC basic support - XuN - 03-18-2014 07:41 AM
This 'problem' is related to the fact that sphere is only sending text, the client speech color is handled by client and not by server so there's no way to make sphere sending text with the color of your speec because its automatically handled by your client and not ever sent to the server.
And for the mode:
Code:
[DEFNAME talkmode_type]
// When client or server send a speech packet these have a type
// You can use them to send a packet or to check ARGN1 in the global speech hook
talkmode_system 0 // Normal system message. ( server -> client && client -> server )
talkmode_prompt 1 // Display as system prompt. ( server -> client )
talkmode_emote 2 // *smiles* at object. ( client -> server )
talkmode_say 3 // A chacter speaking. ( server -> client )
talkmode_obj 4 // At Object ( server -> client )
talkmode_nothing 5 // Does not display ( server -> client )
talkmode_item 6 // Text labeling an item. Preceeded by "You see" ( server -> client )
talkmode_noscroll 7 // As a status msg. Does not scroll ( server -> client )
talkmode_whisper 8 // ; only those close can here. ( client -> server )
talkmode_yell 9 // ! can be heard 2 screens away. ( client -> server )
talkmode_spell 10 // Used by spells ( server -> client )
talkmode_guild 13 // \ guild speech ( client -> server )
talkmode_alliance 14 // alliance speech ( client -> server )RE: EC basic support - karma - 03-18-2014 07:43 AM
And for the mode byte?
(I have edited the post above to add something few seconds ago lol)
EDIT: ok, but why with mode 00 the text is like speech, over the char, and with 03 it sends a sysmessage?
I can be wrong but this is what i found with spyuo and some testing
RE: EC basic support - XuN - 03-19-2014 09:13 AM
(03-18-2014 02:53 AM)Feeh Wrote: The new boat moving packet can be found in RunUO, I suggest you to look at RunUO source and see how they've implemented it. The boat control packets are not present, but it should not be any hard to implement them
If needed I can try to describe how these packets works on RunUO
Some help with this would be nice, at least a point on where should I look.