ID:140636
 
Code:
        EndGameA()
world << "2"
//usr.verbs -= typesof(/mob)
world << "The game has ended! The attackers have won!"
if (usr.team == "Attackers")
usr.str += 1
usr.hp += 1
usr.kingkill += 1
usr.gameswon += 1
//victory = 1
world << "You will all be logged out, then the world will reboot. Please come back for the next match."
playernum = 0
usr.Logout()
world.Reboot()

obj
king
//hp = 1000
hp = 50
density = 1
icon = 'guard.dmi'
Del()
world << "3"
world.EndGameA()
world << "1"
..()


obj
proc
DeathCheck()
if (src.hp == 0 || src.hp <= 0)
del(src)


Problem description:
When i kill the king ingame there are no messages, my connection just fails.
Perhaps you should try removing the <code>Logout()</code> procedure from <code>Endgame()</code>.
In response to Calus CoRPS
Okay, thanks.
Don't use usr in your EndGame proc. There is no usr in that proc. In fact, the only procs where usr is - to my knowledge - appropriate, are several built-in procs such as atom/DblClick().
Also, you're doing world.somecustomproc(), that must mean you've defined a new proc under world? You can't do that, you know. If you need to define those procs under "nothing" (global procs) and that also means you can't put "something." before that proc.

//wrong:

world/proc/myproc()

//right:

proc/myproc()


So you'll probably want to do things with mobs and objects and stuff in your proc, then you'll need to define an argument variable in your global proc like so:

proc/myproc(var/mob/M)
if(istype(M, /list))
for(var/mob/mobby in M)
mobby << "blah"
else
M << "blah" // sorry, I can't come up with anything more original, I'm not exactly a poet


Then if you want to call that proc...

// do NOT do this:

mob/verb/someverb()
src.myproc()

// you will need to call it like this:

mob/verb/someverb()
myproc(src) // the var/mob/M in myproc() will refer to src
In response to Nielz
Nielz wrote:
Also, you're doing world.somecustomproc(), that must mean you've defined a new proc under world? You can't do that,

Had that been the case, he would've complained about his code not compiling, however his issue is a problem at runtime.
You actually can declare new procs on /world, unlike vars. Of course, there is no particular benefit in doing so over using a global proc -- perhaps the contrary is correct, since a global proc is easier to use and likely a little bit faster -- although the fact in a /world proc you can refer to the /world object by src (which includes Dream Maker's auto-completion for src-properties) instead of the global var world could be seen as convenient:
world/proc/AlwaysHost()
while(!port)
OpenPort(1234)

(The above uses the shortcut and is compiled as src.port and src.OpenPort(), src being equivalent to world)
In response to Kaioken
Ah, but that's a little confusing then because the 'world' entry in the reference explicitly mentions that defining new vars and procs under world/ is not possible?

http://www.byond.com/docs/ref/info.html#/world

Should they adjust this entry?
In response to Nielz
Nielz wrote:
Should they adjust this entry?

That's right. There are occasionally inconsistencies or minor mistakes in the Reference, such as this one. Declaring procs on /world is a pretty 'gotcha' quirk anyway - why procs and not vars? Of course, although it's an extraneous niche feature that doesn't really offer much in particular, the documentation should still be correct about it.
In response to Kaioken
Oh and speaking of the ref, I've also noticed another small issue: at system_type it says that it can have two values; MS_WINDOWS and UNIX, and well, in windows, it actually outputs MS_Windows, in stead of MS_WINDOWS. This may cause a little inconvenience when some one creates a proc that checks for the operating system in their programme for which ever reason...
In response to Nielz
There's no problem there. Just like the Reference says, the values are the constants MS_WINDOWS (which would expand to the text string "MS_Windows" you mentioned) and UNIX. MS_WINDOWS is not a text string, hence no quotes around it; it's a constant, which would be either a constant global variable, or a preprocessor macro (created with #define) - you can look those up for more info.
Other built-in constants are TRUE for 1 and FALSE for 0 (which might be slightly misleading as those values aren't the only ones that are true/false), and the possible values of gender, as explained in its Ref entry.
In response to Kaioken
I see... So I should be doing if(world.system_type == MS_WINDOWS) rather than if(world.system_type == "MS_WINDOWS"), then. Okay, thanks for explaining.