These are chat archives for ZaneDubya/UltimaXNA

17th
Sep 2015
Zane Wagner
@ZaneDubya
Sep 17 2015 02:23
ugh, this stupid pet name change business.
I cannot find the appropriate flag that enables it.
It's not in packet 0x11, despite documentation stating otherwise. :(
Zane Wagner
@ZaneDubya
Sep 17 2015 02:40
Ugh, I MUST be wrong.
But why is the flag ALWAYS 0x00 when I receive it?
There is no other equivalent flag that I can see. Rubbish.
Zane Wagner
@ZaneDubya
Sep 17 2015 14:28
Haha, figured it out.
Too tired last night to properly bugfix. This morning, the first thing I found out was that the client was only receiving the 0x11 for the player, and I was able to quickly figure out that we weren't sending the proper query packet that the legacy client sends when you drag a mobile health tracking gump off of a mobile.
Wonder how many other packets we're not sending :( I haven't really changed the xna client's protocol wrt sending packets on given commands since 2010...
Zane Wagner
@ZaneDubya
Sep 17 2015 14:43
Milestone 0.7 includes 40 bugs and 30 features. Only 1 bug left to go!
I had to
Zane Wagner
@ZaneDubya
Sep 17 2015 16:14
haha
I now remember why I saved this issue for last: it's proving really difficult to solve.
In short: we receive wm_char, which gives us the keycode in what I think is code page 1033. But other users can be using other keyboard layouts.
I don't know how to translate the wm_char keycode to another codepage. @jeffboulanger , do you have any experience with this?
Zane Wagner
@ZaneDubya
Sep 17 2015 19:07
Ok, done!
Feels good.
Jeff Boulanger
@jeffboulanger
Sep 17 2015 19:41
figured it out?
Zane Wagner
@ZaneDubya
Sep 17 2015 19:45
yup
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:15
nice
@ZaneDubya I think input needs to be changed, the service and whatnot is very confusing. Should have it broken up to a few subsystems within the service.
  1. Hotkeys (basically your built in functions, Alt+o = options, Alt+j = journal, etc)
If nothing hits for 1, next you check macros
nothing still, passed to your UI manager
nothing still, passed to anyone else monitoring
You should be able to add macros, or Hotheys with simple functions to the Input service
AddHotkey(Keys.J, alt:true, () => showJournal());
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:21
for Macros you should be able to register a list of macros by name to specific functions, something like
AddMacro("Cast Spell", (spellIndex) => player.CastSpell(spellIndex));
then, something like, AddMacroHotkey("Cast Spell", Keys.F1, alt:false, ctrl: false, shift: false, spellIndex)
within options, you can control the spell index with a drop down with key:value as spellIndex:name
Might be slighly more complex since you need to be able to map spellIndex to spell only macros, but thats solvable.
Once you have input, the client will start to become a lot more usable
Maybe an enum for the different Macro types, rather than strings
Zane Wagner
@ZaneDubya
Sep 17 2015 20:32
It would be easy to add hotkeys as a separate system and have it check input events before anything else.
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:32
they need to work with each other though
Zane Wagner
@ZaneDubya
Sep 17 2015 20:33
Ah, the hotkeys would just soak up input events before anyone else got to look at them
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:33
meaning, you dont want a hotkey to fire, when an lets say, alt+j is hit for journal
there has to be an order to things
Zane Wagner
@ZaneDubya
Sep 17 2015 20:33
Once an input event IsHandled = true, then no other request for input will return that event.
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:34
well thats not even true
like, you can set a macrokey to 1234567890
and it will still type
i wonder if everything is a macro in classic client
is journal setable to something else?
its been so long
can you setup a macro to Alt+O
and watch your macro fire, and options open?
Zane Wagner
@ZaneDubya
Sep 17 2015 20:35
There are only four methods to understand in InputManager though
Not hard to understand
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:35
if thats the case, i guess it could be seperate
i mean in the classic client
Zane Wagner
@ZaneDubya
Sep 17 2015 20:35
public methods etc.
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:35
inputmanager is way overly complex imo
Zane Wagner
@ZaneDubya
Sep 17 2015 20:36
again, only four methods.
Don't see how its complex.
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:36
input should just be sliced off the input thread per frame
ya i see those methods, none of which are necessary imo
like the confusion is
    public List<InputEventMouse> GetMouseEvents()
    public bool HandleKeyboardEvent(KeyboardEvent type, WinKeys key, bool shift, bool alt, bool ctrl)
not really sure why i would need mouse events
it should be event based
i guess is why its confusing
thats how it was setup originally, event out to all subscribers
now things have to ask and responde
rather than receive and just make said reception as handled
its more controlled with subscriptions
forinstance
with the current system, if someone handles a keyboard event
no one else will ever be able to be informed that it was handled
where as, the proper way would be to event out
and all receivers can still use the action if they want to, even if its been handled
if you dont wanna use it, you check the flag if(e.Handled) return;
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:42
What I believe should occur is All of these
        m_WndProc = new WndProc(handle);
        m_WndProc.MouseWheel += onMouseWheel;
        m_WndProc.MouseMove += onMouseMove;
        m_WndProc.MouseUp += onMouseUp;
        m_WndProc.MouseDown += onMouseDown;
        m_WndProc.KeyDown += onKeyDown;
        m_WndProc.KeyUp += onKeyUp;
        m_WndProc.KeyChar += onKeyChar;
Zane Wagner
@ZaneDubya
Sep 17 2015 20:42
GetMouseEvents gets all mouse events in that frame.
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:42
no
it gets unhandled events
which is wrong
anyway
Zane Wagner
@ZaneDubya
Sep 17 2015 20:42
Seems like a minor change.
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:42
the wired up events to WndProc should get queued
then each frame, Update should call Slice
Zane Wagner
@ZaneDubya
Sep 17 2015 20:43
HandleKeyboardEvent checks to see if an unhandled keyboard event with the passed parameters occured in that frame.
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:43
simular to Network
all the sliced events should get handed out in an event handler
to anyone subscribed
in those subscriptions, they can choose to set the event args to handled or not
and they can also check if its already been handled, and respond accordingly
Should be simular to
        public void Slice()
        {
            lock (m_QueuedPackets)
            {
                foreach (QueuedPacket i in m_QueuedPackets)
                {
                    LogPacket(i.PacketBuffer, i.Name, i.RealLength);
                    InvokeHandler(i.PacketHandler, i.PacketBuffer, i.RealLength);
                }
                m_QueuedPackets.Clear();
            }
        }
from Network
NetworkClient
Also NetworkClient a really bad lock flaw
now that im looking at it
;)
Jeff Boulanger
@jeffboulanger
Sep 17 2015 20:48
NetworkClient should contain 2 packet queues, a working queue, and a regular queue. When you slice, you lock, swap the queues, then process the working queue. This lets the netsock continue to fill up the queue while you are processing stuff you've received
Zane Wagner
@ZaneDubya
Sep 17 2015 20:48
Gotcha! Well if you can fix it, please submit a pull request. if you can't submit an issue. Thanks!