ID:101578
 
BYOND Version:475
Operating System:Windows 7 Ultimate
Web Browser:Firefox 3.6.8
Applies to:Dream Seeker
Status: Unverified

Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
Descriptive Problem Summary:

Numbered Steps to Reproduce Problem:

Code Snippet (if applicable) to Reproduce Problem:
mob
verb
Save()
var/savefile/F = new("[usr.key].sav")
F["test"] << "test"


Expected Results:
Your file saves
Actual Results:
runtime error: bad output
proc name: Save (/mob/verb/Save)
source file: Save File.dm,6
usr: Darker Legends (/mob)
src: Darker Legends (/mob)
call stack:
Darker Legends (/mob): Save()

Does the problem occur:
Every time? Or how often?Always
In other games?Yes
In other user accounts?Yes
On other computers?Yes

When does the problem NOT occur?
When I press it again

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds:
None known
The snippet you provided does work in 475, so there has to be more to this report. Since you did not fill out most of the template, though, we have nothing else to work with--including any information on whether this also occurred in previous versions.

Based on my investigations in the code, I find that "bad output" can occur if it can't write the value to the savefile. One of the reasons for this is if the file is in a read-only mode or if it was locked. If you have multiple routines accessing the same savefile at once, there's your problem right there. Beyond that you need to make sure you have disk access to write to the file, and that the file is not marked as read-only. If none of those measures work, you will have to provide a demo project that reliably creates the issue.
It could be my windows 7. I have some weird issue with it and have been unable to resolve it. Because sometimes when i compile it says Cannot write main.dm
Yeah, it sounds like you're going to need to get your file permissions fixed. Make sure you have full write access to that directory.
The weird thing is i do have full access and i own the files this is weird
http://www.byond.com/members/ DreamMakers?command=view_tracker_issue&tracker_issue=2088

Comment #4.

And Lummox, The bug fixes itself after a complete removal of byond from the system and a full install of it again. It works maybe 1 day then goes back to bad output. I am running windows XP on full admin, this problem is showing up on my end, and has been for nearly a week. It happened on Version 474 as well as 475, But does not happen immediately.
Player
proc
Save(mob/m)
var/nosave[] = list(
"type","parent_type","tag","desc","suffix","icon","icon_state","overlays",
"underlays","visibility","luminosity","opacity","density","layer",
"mouse_over_pointer","mouse_drag_pointer","mouse_drop_pointer","mouse_drop_zone",
"verbs","vars","invisibility","infra_luminosity","pixel_x","pixel_y",
"mouse_opacity","pixel_z","loc","sight","client","group","ckey","key","see_in_dark",
"see_invisible","see_infrared","pixel_step_size","animate_movement","screen_loc","icon")
var/savefile/F = new("playerfile/[m.name]")
for(var/v in m.vars)
if(!(v in nosave))
F["[v]"]<<m.vars[v]
It's not clear these issues are the same, but regardless I need something to test. Without a reliable test case we have nothing to work with.
mob/verb/test()
var
rannum=rand(1,1000)
savefile/F = new("savefile[rannum]")
F["rnum"]<<rannum

There's a simple test case. It happens randomly, but once it starts, there's no stopping it unless you reinstall Byond or restart your computer.
Something more concrete would be best, but I'd like more information to go on at a minimum. "Random" also doesn't tell us if it takes a few hundred tries to happen or it happens instantly. Do you click your verb frequently or does it work if you do it at a slower pace? Are you able to delete or rename the files afterward? Are you able to create new files in the directory?
Out of curiosity, what kind of antivirus software are you running?
Well, I'm not really sure how to put it as anything other than random. It has happened once every other day for me. The file's that are created when the bug does occur is deletable (And probably re-nameable as well) Yet I havnt had the bug yet today, so I cannot say for sure. My save code (to call) on #5 is
var/Player/p = new/Player
p.Save(src)

And, when it was a verb before, it would only create the Bad Output error the first time you tried to save and creates an empty file. If you were to press save again, it would save perfectly and write the info.
Oh, not sure of how much help this will be, but when I did have the bug I believe it was yesterday, I created a new line to display what variable was being saved at the time, and the only thing it showed was
"level
Error: Bad Output
"

As if something never completed after attempting to save the first var and or broke out of the for() loop.


Edit: Happened again

http://www.vyklou.com/asd.PNG
Two issues I'm seeing in your code: You didn't output the value of the var, which might be relevant to the problem, and also your filename is based on an unsanitized copy of the mob's name, which could conceivably contain bogus characters.
Lummox, the name I tested with is clearly visible. -.- Sdf is all alpha characters, the value of the variable was 1. and it's a BYOND bug, No matter how much you hate to be proved wrong, it's there. If need be, I'll record a video from a to z, but it shouldn't be that hard to explain to a developer when all of the information (except the value of level) was given, I'll go ahead and rerun the code displaying the level and show you again Just to satisfy you.
http://www.vyklou.com/a.avi
If that doesn't solve questions, I don't know what will.
I'm not saying it's not a BYOND bug, just that code issues can muddy the waters. And the .png file you posted does not, as far as I can see, say what the name actually was.
usr: Sdf (/mob/Player/)

Sdf (/mob/player/) SaveS()


:3 (I think that's how the runtime error thing works, It's always shown the name for me anyways. Not 100% sure since I don't work on the generation of it. x3)
I get a "bad output" runtime error when I attempt to save a list to a new savefile for the first time.

I'm not very well practiced with DM savefiles so it could just be something I'm doing wrong, but it's worth mentioning.

The order of events I perceive is:
  • SavefileProc()
  • Runtime Error
  • SavefileProc()
  • Everything runs smoothly.
  • Delete the Savefile in Windows without Reboot.
  • SavefileProc()
  • Everything runs smoothly.
  • Delete the Savefile in Windows then Reboot.
  • SavefileProc()
  • Runtime Error.


Attempting to make an empty savefile in Windows (renaming a text file) will also cause the runtime to occur on first execution.

Snippet:
cluster
var
id = null

New()
clusters += src
src.id = clusters.len

var
list
clusters = new/list

proc
CreateCluster()
var/cluster/C = new
return C.id

SaveClusters()
var/savefile/S = new("clusters.sav")
S << clusters

ReloadClusters()
var/savefile/S = new("clusters.sav")
S >> clusters

mob
verb
Create()
for(var/A = 1 to 10) CreateCluster()

ShowClusters()
for(var/cluster/C in clusters)
world << C.id

Save_Clusters()
SaveClusters()

Load_Clusters()
ReloadClusters()


(Snippet is the entirety of the project minus a DEBUG definition.)

BYOND Version: 475.1080
OS: Windows 7 Ultimate x64
Applies To: Dream Seeker.
While I didn't try the rebooting portion (since it should be possible to trigger the problem before that point according to your notes), I did try the rest and failed to reproduce any kind of bug. (However your code isn't complete; there is no CreateCluster() proc, so I substituted new/cluster instead.) I tried saving, loading, doing both with multiple instances running, creating an empty savefile, loading from or saving into the empty savefile, etc. The only runtime error I ever encountered was that after loading from the empty file, new/cluster couldn't add properly to the list because the code didn't account for the loaded list being null; this was expected.

Since OS seems to be a factor here, what OS are you running?
I assume he's running windows 7 as I've been unable to reproduce this on any other OS
Page: 1 2