Question: Saving to .sav files etc..

ID:171049
 
Nov 19 2004, 7:43 pm
This is annoying, I have a small problem with a proc that saves a list (in this case, a mute list). It's simple, not hard, but I screwed something up, thanks to my newbness. If someone would have time to help, it would be greatly appreciated.


Code:
mob
    proc
        SaveMute_List()
            var/savefile/F = new("/lists/mute_list.sav")
            var/list/Mute_List = list() << Mute_List


Error: Line 65: error:Mute_List: compile failed (possible infinite cross-reference loop)

1 error, 0 warnings (double-click on an error to jump to it)

Specific Line:

            var/list/Mute_List = list() << Mute_List


Thank you for any help and your time.



--Lenox

Nov 19 2004, 8:41 pm
F is the file that you want to save to, right? Just look at the operator as a pointer.

Target << Arrow (the information to send)

The muted players would start from the list and go to the file, but in your line you have it starting from the list and going to... the same list re-created? O.o

Seriously, that line has been giving me a headache for a while. You're defining a list, and then trying to create it with list() and send itself into itself. I'm sorry, but I can't think of a better explanation as to why it's wrong. Hopefully, I can help you get it right. =)

I'm guessing you already have the list of muted people defined somewhere else, but you started grabbing for straws when you couldn't get it to work. So all you have to do is use that savefile variable you made as the target, and the list as the arrow.

F << list_of_muted_people
Nov 19 2004, 9:15 pm
In response to YMIHere
YMIHere wrote:
F is the file that you want to save to, right? Just look at the operator as a pointer.

Target << Arrow (the information to send)

The muted players would start from the list and go to the file, but in your line you have it starting from the list and going to... the same list re-created? O.o

Seriously, that line has been giving me a headache for a while. You're defining a list, and then trying to create it with list() and send itself into itself. I'm sorry, but I can't think of a better explanation as to why it's wrong. Hopefully, I can help you get it right. =)

I'm guessing you already have the list of muted people defined somewhere else, but you started grabbing for straws when you couldn't get it to work. So all you have to do is use that savefile variable you made as the target, and the list as the arrow.

F << list_of_muted_people


This is much clearer, Thank you.

I took your advice, but flipped it around..
so it went like this:
list_of_muted_people >> F
Evidently, it hates it when you do:
F << list_of_muted_people.

So, now I just need to make my mute command. Thank you VERY much for helping me, and sorry for any troubles.
(I wasn't sure, because 50% of some of these people who ask questions seem to get yelled at o_O)

Edit: Woot, i'm making progress :)
Nov 19 2004, 9:50 pm
In response to Lenox
Lenox wrote:
I took your advice, but flipped it around..
so it went like this:
list_of_muted_people >> F
Evidently, it hates it when you do:
F << list_of_muted_people.

That frightens me. I've always had the file on the left, and I don't think you can do it the other way around. =\

Do you have the list of muted players defined? "list_of_muted_people" is supposed to be replaced with the actual variable name for your list.

So, now I just need to make my mute command.

That shouldn't be too hard if you think about it in small steps. Allow the administrator to pick any player in the world, add that player's key to your muted list, and then just check if a players key is in the muted list before they are allowed to use communication verbs. =)

Thank you VERY much for helping me, and sorry for any troubles.
(I wasn't sure, because 50% of some of these people who ask questions seem to get yelled at o_O)

You're very welcome. Most of us do want to help people through the learning process. =)
Nov 19 2004, 10:43 pm
In response to YMIHere
I made the mute verb, I made an unmute verb, they both work, and I think i'm going to put out a library with this new way of muting ( I have yet to see a lib that saves the list to a .sav and such )

and yeah, flipping it around worked, I defined
var/global/list/Mute_List=list()

So, I'm proud of myself, I just coded(in my OWN code) a library that handles all of this. (with help from you ^_^)
Nov 19 2004, 10:54 pm
In response to Lenox
Lenox wrote:
I made the mute verb, I made an unmute verb, they both work, and I think i'm going to put out a library with this new way of muting ( I have yet to see a lib that saves the list to a .sav and such )

I wouldn't put out a library just yet, but if you decide to be sure to run it by some of the more experienced programmers here. =)

and yeah, flipping it around worked, I defined
var/global/list/Mute_List=list()

Just a note, if you didn't define it under a certain datum that global part isn't needed (won't hurt either).
  //  Under a datum
mob
  var/global/list/Mute_List=list() // All mobs have this list, but it is the same.

  //  Not under a datum
var/global/list/Mute_List=list() // It's already global because there is only one.


So, I'm proud of myself, I just coded(in my OWN code) a library that handles all of this. (with help from you ^_^)

You should be, it took me forever to figure out savefiles. =)
Nov 19 2004, 11:06 pm
In response to YMIHere
Well, now I ran into another problem. My say() verb doesn't work right.

Maybe you can help, somewhat? lol.
If you could, I'd appreciate it..

here's the code...

mob
    verb 
         say(msg as text)                           //Say verb, a must.
            if(muted == 1)                           //if muted == True
                src << "I'm sorry, you are muted."  //Say "You are muted."
                return                              //Return
            else                                    //If they aren't muted
                oview() << "[src] : [msg]"          //say to oview()
                src << "[src] : [msg]"              //confirm it by saying it to self

/sigh.
thats my Say() verb.
It's probably my definition of Muted...

var/global/list/Mute_List = list()  
var/global/muted = 0


I could try to release a library for this version of Mute(), if it wasn't jacked up.

Nov 19 2004, 11:27 pm
In response to Lenox
I would just check if their name was in the list.

mob
    verb 
         say(msg as text)
            if(Mute_List.Find(key)) //If they are in the muted list.
                src << "Shaddap!"   //Say "You are muted."
                //Return is useless here, as it won't go into the else clause anyway.
            else            //If they aren't muted
                oview() << "[src] : [msg]"  //say to oview()
                src << "[src] : [msg]"      //confirm it by saying it to self
                // Might as well just output to view() and kill two birds with one stone. =)


You current problem is the definition of muted (or so it seems, I can't tell for sure without knowing what exactly goes wrong). You're defining it as a global variable in two ways, one being the global type, second being that it doesn't belong to any specific datum. If your were going to do it like that (which I don't recommend, since you have a list of keys anyway) you would need it as a mob variable.

mob
  var/muted  // Not global, so it can be different on all mobs.


Then you could mute certain mobs, not all of them at once. If you did it that way and allowed people to have more than one character, they could just switch characters to get out of the mute (because it would only be saved on that mob). You've already built this nice list and a way to save it, now milk it for all it's worth. =)