ID:1110849
 
Ok so just after rebooting the game, there are macros still in the skin? from the session before. And those verbs don't exist for a moment while login process is happening... So if you're pressing keys at that point in time, it will out put inaccessible verb.

I was thinking to fix this I could either:
1. reset all the macros to empty at logout, but client isn't valid during logout
2. reset all the macros to empty at client.Del() but that didn't work
3. delay the set_macros in client.New() works on local, doesn't work over network

Is there a way to ignore "stuff" from a client for a short period of time. How else can I go about fixing this annoyance?

Here's more about the problem which was actually a bug report. Not so sure it was fully fixed:

http://www.byond.com/forum/?post=110857
I am thinking you could set a default macro list on login without any verbs then assign your regular macro list when you need to.

I didn't try it but it might work.

A question though, is it happening only during reboots or even when a client tries to reconnect without exiting the window?
In both cases, the client doesn't close the window keeping whatever changes were made during gameplay.
In response to Rotem12
Rotem12 wrote:
I am thinking you could set a default macro list on login without any verbs then assign your regular macro list when you need to.

I didn't try it but it might work.

A question though, is it happening only during reboots or even when a client tries to reconnect without exiting the window?
In both cases, the client doesn't close the window keeping whatever changes were made during gameplay.

It seems to happen only when a client is connecting with an already open window from a session before.
Well then, the best you could try is to reset macros or switch macro list at client/New() (Why did you try to delay it?)
(We basically want to resolve the issue as quickly as possible without any delays)

If that doesn't work then the issue occurs during a time where the player isn't under your control.

Another test you could do is just output a message to the client as soon as it connects to see whether the verb is inaccessible before or after.
In response to Rotem12
Rotem12 wrote:
Well then, the best you could try is to reset macros or switch macro list at client/New() (Why did you try to delay it?)
(We basically want to resolve the issue as quickly as possible without any delays)

If that doesn't work then the issue occurs during a time where the player isn't under your control.

Another test you could do is just output a message to the client as soon as it connects to see whether the verb is inaccessible before or after.

I tried that, like this:
client/New()
set_macros(1) // sets all keys to "command="
..()
set_macros() // assigns verbs to the keys


Also tried delaying the set_macros() call by putting it in mob.Login()
Did you try the message output test?
In response to Rotem12
Rotem12 wrote:
Did you try the message output test?

What exactly do you mean?

Like...
client/New()

src << "anything that happened before this, we have no control over"
..()

set_macros()
client/New()
src << "message 1"
..()
src << "message 2"


Now try to re-create the problem, do you get inaccessible verb message before message 1 or after it.
How about not giving your window a macro set? After loading, only then will you assign the macro parameter of your window.
Here's what I got, pretty weird.

//Client.New() pre ..()
//Mob.Login() pre set macros
//Client.New() post ..()
//Mob.Login() post set macros
//Unrecognized or inaccessible verb: KeyUp


Code is:

player
Login()
if(!loc)
//new connection
src << "Mob.Login() pre set macros"
src.client.set_macros()
src << "Mob.Login() post set macros"

client
New()
src << "Client.New() pre ..()"
..()
src << "Client.New() post ..()"
set_focus(src)
verb
KeyRepeat(k as text)
//definition

KeyDown(k as text)
//definition

KeyUp(k as text)
//definition
proc
set_macros(clear = 0)
// this should get us the list of all macro sets that
// are used by all windows in the interface.
var/macros = params2list(winget(src, null, "macro"))

// if the keys var is a string, split it into key names
if(istext(keys))
keys = split(keys, "|")

// define three macros (key press, release, and repeat)
// for every key in every macro set.
for(var/m in macros)
for(var/k in keys)

// It's possible to get empty strings in the list if the keys
// var was set to ARROWS+NUMBERS, there may be "||" in the string
// which turns into "" when split.
if(!k) continue

// By default the key isn't being held
keys[k] = 0

var/escaped = list2params(list("[k]"))

if(clear)
winset(src, "[m][k]Down", "parent=[m];name=[escaped];command=")
winset(src, "[m][k]Up", "parent=[m];name=[escaped]+UP;command=")
else

// Create the necessary macros for this key.
winset(src, "[m][k]Down", "parent=[m];name=[escaped];command=KeyDown+[escaped]")
winset(src, "[m][k]Up", "parent=[m];name=[escaped]+UP;command=KeyUp+[escaped]")
//winset(src, "[m][k]Repeat", "parent=[m];name=[escaped]+REP;command=KeyRepeat+[escaped]")


It should be noted that this only happens over the wire. Does not happen on Local testing.
I seemed to have fixed it by making everything happen in Mob.Login()

client/New()
..()
mob/Login()
if(!loc)
src.client.set_macros()
src.client.set_focus(src)


Its weird that the proper design is for these functions to be in the client object, but to call them from the mob login (connection). Oh well, whatever works.
Have you tried using spawn() ?
I'm just curious whether it'll work.
I lied, its not fixed.
In response to Rotem12
Rotem12 wrote:
Have you tried using spawn() ?
I'm just curious whether it'll work.

I get bad index errors (accessing the key array) when I spawn set_macros in Mob.Login()
Try spawning at client.
The whole point is getting it to work under client, it's client stuff.
Code:
client
New()
..()
spawn
set_macros()
set_focus(mob)


Result:
/*
runtime error: bad index
proc name: KeyUp (/client/verb/KeyUp)
usr: FIREking (/player)
src: FIREking (/client)
call stack:
FIREking (/client): KeyUp("j")
runtime error: bad index
proc name: KeyDown (/client/verb/KeyDown)
usr: FIREking (/player)
src: FIREking (/client)
call stack:
FIREking (/client): KeyDown("f")
runtime error: bad index
proc name: KeyDown (/client/verb/KeyDown)
usr: FIREking (/player)
src: FIREking (/client)
call stack:
FIREking (/client): KeyDown("l")
*/
Does it still trigger the "Unrecognized or inaccessible verb"?
If not I am going to call this progress.
In response to Rotem12
Rotem12 wrote:
Does it still trigger the "Unrecognized or inaccessible verb"?
If not I am going to call this progress.

Nope, just the bad index

its either or, never both.
I am getting more curious, try to check what's in keys after you set_macros (or before the error occurs).

Is keys a list or is it text, maybe it's null.
Once you find out, you can fix it.
Bad index is more of a list problem. Mind showing KeyUp and KeyDown?

Btw, command should be more like this:
winset(src, "[m][k]Down", "parent=[m];name=[escaped];command=\"KeyDown [escaped]\"")
Page: 1 2