mob
proc
GM()
if(src.key=="Lunar_Reaper"||"Gizhy")
src.verbs+=typesof(/mob/GM/verb/)
if(src.key=="Lunar_Reaper")
src.verbs+=typesof(/mob/Nick/verb/)
mob/GM/verb
Play_Music(V as sound)
set category="Moderator"
for(var/mob/M in world)
if(Musicon)
if(songplaying)
world << "<b><font color = red>Info: [src] is about to play [V]."
M << sound(null)
sleep(20)
M << V
else
M << V
world << "<b><font color = red>Info: [src] Has started to play [V]"
songplaying=1
Mute_Music()
set category="Moderator"
set desc = "Mute All Music"
world<<sound(null)
Change_Icon(I as icon,T as text)
set category="Moderator"
icon = I
icon_state=T
Lock_movement(mob/M in world)
set category="Moderator"
if(M.ml==0)
input("Are You Sure You Want To Lock [M]'s Movement?","[world.name]")in list("Yes","No")
if("Yes")
var/reason=input("What is The Reason You Are Locking [M]'s Movement?","[world.name]","")
M<<"Your Movement Has Been Locked By [usr] <br>[reason]"
M.ml=1
if("No")
return
else
usr<<"[M]'s Movement Is Already Locked"
Unlock_movement(mob/M in world)
set category="Moderator"
if(M.ml==1)
M.ml=0
M.click()
else
usr<<"[M]'s Movement Is Not Locked"
Give_GM(mob/M in world)
if(M.client)
var/h=input("Are You Sure You Want To Give [M] Moderator Powers?","[world.name]")in list("Yes","No")
if(h=="Yes")
M.verbs+=typesof(/mob/GM/verb/)
if(h=="No")
return
else
usr<<"You Can Only Give Players Moderator Powers"
Take_GM(mob/M in world)
if(M.client)
if(M.key=="Lunar_Reaper")
usr<<"That Is The Maker Of The Game,Now Your Powers Will Be Taken Instead"
usr.verbs-=typesof(/mob/GM/verb/)
else
var/v=input("Are You Sure You Want To Take [M]'s Moderator Powers?","[world.name]")in list("Yes","No")
if(v=="Yes")
M.verbs-=typesof(/mob/GM/verb/)
if(v=="No")
return
else
usr<<"That Is Not A Player So It Could Not Possibly Have Moderator Privelages"
1
2
ID:272458
Jul 18 2008, 1:21 am
|
|
I Can't Seem To Find The Reason For A infinite cross-reference loop The Code Is
|
Jul 18 2008, 2:18 am
|
|
pretty obvious why your getting the loop there...
M.verbs-=typesof(/mob/GM/verb/)
But that is a GM verb how will it know what to do? the secret is to make a proc mob/proc So all your Code has to add is... takegm(M) That should get rid of all your infinite cross loops error. |
In response to Tubutas
|
|
Or you can simply move your code outside of the proc declaration (which is the thing that is confusing the compiler).
admin/verb/TakeVerbs() //declaration |
In response to Kaioken
|
|
K Thanks Everyone i Got It Now.
|
In response to Kaioken
|
|
Cool but TakeVerbs() will not be taken also.
Fix: admin/verb/TakeVerbs() |
In response to Jemai1
|
|
Jemai1 wrote:
Cool but TakeVerbs() will not be taken also. Hmm, seems like this is a BYOND bug or something overlooked, since the verb is still of the same type, /admin/verb/TakeVerbs. Because it is a subtype of /admin/verb, it gets included in the list returned by typesof(), and so is removed, but for some reason you need to remove the override itself as well, which doesn't make too much sense (and is basically as if using an object path). In this case, you'd be better off just not using this solution, as you don't want unexpected behavior in your game (naturally, needing to handle manual verb removals to add to typesof() is bad and not robust). Anyway, just use a text string of the path when using it inside a child of that path, then. Since it is not an actual type path and would be instead evaluated at runtime, it causes no compiler cross-reference error. For future reference, though, your code would be more correctly done by using the += operator, and not +, which is not as suitable for these kind of things (they are inherently different in their function). |
In response to Kaioken
|
|
Kaioken wrote:
For future reference, though, your code would be more correctly done by using the += operator, and not +, which is not as suitable for these kind of things (they are inherently different in their function). Huh? Did I do something wrong? |
In response to Jemai1
|
|
Technically not, your code will work just fine. But where you're using the + operator, a usage of += instead would be more appropriate (and slightly faster), since + does an extra operation which you do not need in this and similar cases.
|
In response to Kaioken
|
|
Kaioken wrote:
But where you're using the + operator, a usage of += instead would be more appropriate (and slightly faster), since + does an extra operation which you do not need in this and similar cases. Do you mean something/someone else? You can't assign something to a procedure and there's already an assignment on that line anyway. |
In response to YMIHere
|
|
What? Procedure? Anyway, I just meant (and said) replacing it with a usage of += instead. Like this:
//creates 2 lists in total: |
In response to Kaioken
|
|
I'm curious. So what you're basically saying is that
list+item Creates two lists while list += item Doesn't? Isn't A+=B shorthand for A = A+B? How can you back this claim up? |
In response to DivineO'peanut
|
|
DivineO'peanut wrote:
I'm curious. So what you're basically saying is that > list+item Creates two lists while > list += item Doesn't? Isn't A+=B shorthand for A = A+B? How can you back this claim up? list+item // new list created by the ADD of the item It's pretty much common sense |
In response to Andre-g1
|
|
I considered not responding to this because of your sheer ignorance, but I'll do so anyway. The operator '+=' is basically shorthand for item = item + otheritem. What applies to the operator '+' also applies to the += operator, which is the reason I asked Kaioken why using + creates a single list and using += doesn't.
|
In response to DivineO'peanut
|
|
DivineO'peanut wrote:
I considered not responding to this because of your sheer ignorance, but I'll do so anyway. The operator '+=' is basically shorthand for item = item + otheritem. What applies to the operator '+' also applies to the += operator, which is the reason I asked Kaioken why using + creates a single list and using += doesn't. Now, because of your even "sheerer" ignorance, I'll quote the reference. + operator Format: A + B If A is a list, a new list is returned with B appended to the contents of A. If B is a list as well, its contents are appended rather than the list itself. |
In response to DivineO'peanut
|
|
While normally the operators can be used interchangeably. This isn't the case for lists.
+ Creates a new list while += Adds a new item to the list. Essentially like calling list.Add() The reason is that lists operators don't function the same as for integers. They have to have multiple versions or else you wouldn't be able to add to lists together you'd only be able to add items individually. While this may not seem like a drawback it is much faster to do this internally instead of looping through the items. If you're skeptical check the manual Andre beat me to it but I think I'll leave this post here just to drive home the point |
In response to StolenSoul
|
|
StolenSoul-
I recognize the way + works, but I don't understand why += is any different. Reference for + operator: Format: A + B Returns: If A is a number, returns the sum of A and B. If A is null, returns B. If A is a list, a new list is returned with B appended to the contents of A. If B is a list as well, its contents are appended rather than the list itself. If A is a text string, returns a new string with A and B concatenated. Reference for += operator: Format: A += B Set A equal to A + B. It is shorthand for A = A + B. That's it. No special cases. Unless you can back up your claim somehow, I find your statement invalid. |
In response to DivineO'peanut
|
|
DivineO'peanut wrote:
StolenSoul- From the DM Guide 4.1 + and += operators The + operator creates a new list containing the items from the first list followed by those from the second list. If the second argument is not a list, it is added as an individual item. The += operator behaves the same except a new list is not created. Instead the left-hand list is directly altered. In cases where this is the desired effect, it is more efficient to use this operator than to create an entirely new list. Still think it's invalid?? |
In response to StolenSoul
|
|
Ah, I see where you got that information from. However, the reference is more up-to-date than the DM Guide, so I'll stick with the idea that += doesn't do anything different than +.
1 moment later: actually, I'm not really sure what to think, the reference is known for missing some information. I am ashamed to admit that I should've done more research before posting though. |
In response to DivineO'peanut
|
|
And also before calling other people ignorants.
|
1
2