Code:Id post a snipet if I had one... but for reference
obj:var
Problem description:An issue has been plaguing me for a while and im deciding to ask for help, i normally try to figure things out and learn from mistakes, but this mistake isnt mine so I cant really find the exact cause.
What happens is items in the contents list(seems to generally be if you have more than one of said item) generate a mob at some point, litterally an object in the contents list is becoming a mob...i THINK its happening on log in or log out (personally i think its login where it re-equips all items that are worn) I have a feeling it has to do with a few line looking like src:var,
src being the item, however i dont exactly know where or how to even find this issue...the mobs being made are player mobs, which are only supposted to be for logged in clients.
ID:2265246
 Jul 2 2017, 10:28 pm
|
|
You're MOST PROBABLY using a src.owner = MOB or some other var that has a mob stored in it.
Change that! ;) OR turn that variable into a var/tmp so it doesn't get saved. | |
okay i think maybe this? players have a var that tracks who attacked them, the attacker proc is set like this.
AttackCheck(mob/M) src.Attacker=M Do you think thats saving them and loading them? | |
Possibly, since it likely isn't marked as tmp. Wherever that variable is defined, simply add tmp/ before it. That isn't the type of variable you'd ever need to save.
/mob/var/tmp/Attacker // This It's probably a good idea to always mark variable that don't need saved as tmp, whether they'd cause something like this or not. Here's a couple links to some helpful posts all about savefiles. | |
i know about tmp vars lol.
But the attacker var is intended to save the player that attacked...so I assume i'd have to go a different route such as saving and referencing the name of the attacker instead of the actual attacker. | |
In that case may I ask why you need to save the attacker? I'd think that should be temporary information. If there's a specific function you have in mind, there might be an easy work-around.
That's definitely the cause of this issue, though (or seems to be.) | |
Other things you should avoid saving with a mob include turf vars; if you save a turf, it will save everything on that turf.
And if you have equipment with an owner var that points to a mob (or even more dangerous, a var pointing to the original owner), and that equipment saves, then any vars it had pointing to mobs will save as well. | |
I'm thinking I have more than one thing generating mobs at this point....If a list is saved an loaded referencing a mob, could that also cause it?
| |
Anything that saves the ACTUAL mob could cause this issue with your savefiles.
Don't save the actual mob in a variable because It's gonna save EVERYTHING inside that mob aswell, so the variables, the lists, it's appearance etc...making your savefile much bigger than it should be. If you REALLY need to save a mob in a variable because you can't think of any other way of doing what you want, make that variable or list a /tmp. So it doesn't save everything and load it back next time. | |
Use a savefile editor to view your savefiles in text form. It will show you if there are other mobs being saved, and where.
| |
Thanks to those that answered, was really helpful.
I believe I fixed the issue, there was a var saving mobs, however it wasn't players exactly causing but npc. | |
If that's the case, to rectify, track down the item and mark the offending variable as tmp. That should solve the issue, as long as you're using BYOND's built in savefile functions.