ID:1300021
 
BYOND Version:499
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 21.0
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
1. No matter what I do, when opening a previous project in Dream Maker folders of icons are automatically opened as well. With a lot of icons this is a pain in the butt and didn't happen a few versions ago. Also sets off my OCD.

2. I don't know how or what they are, but sometimes shortcuts are made when opening a project. There will be a small old school windows looking icon in your file list on the left. And when you open the project it will prompt you as if you're going to open a specific file. This is super annoying. One time it would not go away until I deleted the file it pertained to. Today I just hit refresh and it went away and hasn't popped up again. If you right click and hit delete shortcut can go to a folder or a specific file so deleting it is bad. Not sure how or what causes it, like I said randomly when opening project.

3. while() changed in update? Hangs tied together procs. I had a simple burn system that would burn around users that now stops working when they are burned (even though it is meant to continue doing damage itself). This recently changed in the past update or 2. Code snippet below

Numbered Steps to Reproduce Problem:
1 & 2 No idea

Code Snippet (if applicable) to Reproduce Problem:
To Problem 3: (simplified)
proc/Fire_Move()
while(blah) M.Damage("Fire")
proc/Damage("Fire")
src.hp - damage
if(technique=="Fire") src.Burn()
proc/Burn()
while(burned) M.Damage("Burn")


Expected Results:
This USED to do burn damage AND continue to do the main damage. No coding was changed.
Actual Results:
But NOW, the original procedure hangs until the burn is over. The person won't be damaged again via the constant "Fire Move" until the burn limit has ended. Not sure if there was a better way for me to make this, but now the only way to get it to work as intended seems to be not using while() which brings back infinite loops. I've temporarily changed it to looping and limiting the burn time so that it can't infinite loop, but it is intended to be an infinite loop as the burn time is able to be refreshed, so I really need the while() version to work.

Does the problem occur:
Every time? Or how often? Explained Above
In other games? N/A
In other user accounts? N/A
On other computers? N/A

When does the problem NOT occur?
N/A

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.)
Like I said yes, but I can't remember what version was fine. Bug 1#2 are from like 498 I believe, and bug #3 I didn't realize til 499 but no one reported it so it might've been a version or 2 before as well.

Workarounds:
Pretty much explained above.

Sorry if any of these are reported or anything, I glanced over the forum and admittedly don't come here often, but today I felt like it.
I'd suggest posting the coding issue (with a larger snippet) in Dev help.
VcentG wrote:
2. I don't know how or what they are, but sometimes shortcuts are made when opening a project. There will be a small old school windows looking icon in your file list on the left. And when you open the project it will prompt you as if you're going to open a specific file. This is super annoying. One time it would not go away until I deleted the file it pertained to. Today I just hit refresh and it went away and hasn't popped up again. If you right click and hit delete shortcut can go to a folder or a specific file so deleting it is bad. Not sure how or what causes it, like I said randomly when opening project.

I don't quite follow what you mean by this. Some more details and maybe some screenshots would help.

3. while() changed in update? Hangs tied together procs. I had a simple burn system that would burn around users that now stops working when they are burned (even though it is meant to continue doing damage itself). This recently changed in the past update or 2. Code snippet below

while() did not change in the update. Perhaps it's possible something else that's in your while loop changed, but it's extremely unlikely. I'd lay odds the problem is that your code itself changed, and you now have an infinite loop or deep recursion. Your code snippet is too simplified, so the problem has likely been removed from there, but it does point to the possibility of a recursion.
In response to Lummox JR
Lummox JR wrote:
I don't quite follow what you mean by this. Some more details and maybe some screenshots would help.

If it happens again I'll be able to take a real screenshot, but basically what happens is this.
http://i.imgur.com/xkEvHzO.png
That isn't the actual problem, it's basically a recreation of it. It's a small windows shortcut looking icon like that and it automatically prompts an open or save (I think it's blank so I don't know what it is). And if you right click to delete it, in that picture it would probably delete Test.dm as if its a shortcut for Test.dm file.

while() did not change in the update. Perhaps it's possible something else that's in your while loop changed, but it's extremely unlikely. I'd lay odds the problem is that your code itself changed, and you now have an infinite loop or deep recursion. Your code snippet is too simplified, so the problem has likely been removed from there, but it does point to the possibility of a recursion.

My code hasn't changed (trust me I have people complaining about the lack of updates XD). The code is basically that in essence, the only things missing would be obvious stuff such as src.hp -= damage or src.burn -= 0 or the damage numbers showing up. But it is directly linked to the while() because taking out while makes it work perfectly normal. I've written this small code to show you the error through text. As you can see in the code, it should be spamming the text "Ouch" as the main fire move is still hitting. However, it hangs on the while in the Burning() proc

mob/var/burn = 0
mob/verb

Fire()
while(1)
src.Damage("Fire")
sleep(2)
mob/proc
Burning()
if(src.burn) return
src.burn = 50
while(src.burn>=1)
src.burn--
src.Damage("Burn")
sleep(5)

Damage(var/tech)
if(tech=="Burn") src << "BURNING"
else
src << "OUCH"
if(tech=="Fire") src.Burning()


It really is as simple as I showed.
The code issue sounds like you're not properly spawning your loops.
The code issue is right there in my reply, so feel free to show its error.
When you're calling procedures that act as background loops - you don't want them to stop other code from executing - so you'd want to spawn the loop.
Yes but the problem is if you spawn a loop, it will cause infinite loops to proc, because it ticks enough times for that to happen. How the burn is set up it can be refreshed each time they are burned, so it ticks on and on. It wouldn't really be an infinite loop as the burner would run out of mana and the burnee would eventually die, but it would cause the error before the burn ended.

So basically while() is the only safe way to do an "infinite" loop that I know of.
You can literally spawn those loops, it's fine:

    Burning()
if(src.burn) return
src.burn = 50
spawn()
while(src && src.burn>=1)
src.burn--
src.Damage("Burn")
sleep(5)


For example.
Yeah, what Stephen said. spawn() is used to make the loops into a fake second thread; so you can execute the loop /and/ other code at the same time. It wouldn't do anything to cause an infinite loop, unless you're doing something wrong in your program.
Ah okay that works. I thought you meant something else when you said spawn() them.

And so the mystery will die now. But I swear I didn't change any of the code so I have no clue why this issue is popping up now.

Anyway I guess this thread is done until my #2 issue happens again, which I wouldn't count on its pretty few and far between.
The sleep() effectively acts as a spawn in that it will hand off control to any other waiting procs. I believe the issue you were seeing was that because the loop in Burning() is being called by Damage(), Damage() was waiting for Burning() to return before moving on. The spawn() eliminates that by forcing the loop to happen on its own time while returning right away from the proc.
Alright the shortcut issue keeps happening to me. Seems to be like whenever I open up my project maybe once every few hours to a day. So still pretty random. But luckily if I close the project and then reopen it doesn't happen again for some time.

Here's a picture of how it actually looks. The left side is what happens IMMEDIATELY when opening the project, you can see the little windows icon on the left. And it opens up the box to open a file, but it doesn't say "open" or "save" so I have no idea what it's doing really. It really seems to just be a shortcut. And the right side is when I try to delete it, it seems to be tied to the /Icons/ folder itself so I really don't want to delete it XD. Just a weird issue. But it's very docile now so maybe some patch has changed it because the first time I got it it was AGGRESSIVE and happened every time I opened the game files.

http://i.imgur.com/3aIU44x.png

No idea what causes it or if its specific to this project because this is the only project I open on a regular basis so even if I open another one I don't know if it's after the time required for the bug to happen again.
The next time it happens, without closing anything, try opening your [PROJECT].int file in a text editor and see if there's anything unexpected listed under the WINDOW property (which should display the list of last opened files).

Also, what do you mean by "opens up the box to open a file, but it doesn't say 'open' or 'save'"? In your latest screenshot it just looks like there's just a regular Explorer window.
I guess it is a normal explorer window, but it opens because of that thing. It's like some kind of auto opening shortcut to whatever folder or icon it sets itself to.

Also when I open the .int file there is no WINDOW property. It looks like this:

// BEGIN_INTERNALS
/*
MAP_ICON_TYPE: 0
LAST_COMPILE_VERSION: 499.1187
PACKAGE_RSC_NAME: C:\Users\VcentG\Desktop\SIDE GAMES\Bleach\Bleach_rsc.zip
PACKAGE_DME_DEMO:
PACKAGE_DME_CLEANCHECK: OFF
PACKAGE_TYPE: 0
PACKAGE_DMB_HUB:
PACKAGE_RSC_CLEANCHECK: OFF
PACKAGE_DMB_CLEANCHECK: OFF
PACKAGE_DME_START:
DIR: Icons\Zans\Mirokumaru
PACKAGE_DME_NAME: C:\Users\VcentG\Desktop\SIDE GAMES\Bleach\Bleach_src.zip
PACKAGE_DME_INFO:
LAST_COMPILE_TIME: 1372902588
PACKAGE_DMB_NAME: C:\Users\VcentG\Desktop\Bleach 3.59.zip
AUTO_FILE_DIR: OFF
PACKAGE_DMB_INFO:
*/

// END_INTERNALS


It's kind of weird that the package name and stuff is in the SIDE GAMES folder since I moved it out? Perhaps something like that is the problem and it's sticking in some way? Also not sure why the DIR is set to that icon, when I opened the project and did this it was open to a .dm file, so no clue why 1 icon in my game is set to the DIR.
It looks like DIR is the list of directories to show as "expanded" in Dream Maker's File tab. The PACKAGE_*_NAME properties are just the last locations you packaged the files to. I don't think either are the source of your problem.

Also, did you open the file right after the problem occurred? Or is it not happening at the moment?
I opened it as soon as the problem occured. As soon as I woke up and saw your message I opened the project and it happened so I opened the .int as you said and that's what was in it. I didn't close the explorer folder that it made open or anything. Just straight to the .int.
Oh, whoops. Looks like the WINDOW property is wiped as soon as you open Dream Maker and the windows load. You'll have to open the INT first to see the WINDOW property, and then open the DME to see if that value causes the problem.
Okay now when I open the .int under WINDOW I get a bunch of files. Some .dm some .dmi. Nothing that specifically says \Icons\. Should I just wipe the stuff under WINDOW and see if the problem comes back?
I think it's worth a shot