Stop creating new Game folders please

[Joe35car]

On the next update can you please remove this function. It just slows down LB and creates empty game folders for systems.

 

Thanks

[Retro808]

12 hours ago, Joe35car said:

On the next update can you please remove this function. It just slows down LB and creates empty game folders for systems.

 

Thanks

Likely not. It is part of the new rom scanning feature. I deleted your other post as it did not need to be in 2 places. To prevent it you would need to turn off the new autoscan feature. 

[Joe35car]

There should be an option for people to turn this off. I deleted the game folders again and closed and opened LB and they weren't created this time. Why would this happen? Hopefully it will stop created dummy game folders.

Edited March 15 by Joe35car

[C-Beats]

If you disable the auto-rom import feature those empty folders are removed and won't be created on startup (if you're referring to the folders for platforms you haven't actually imported).

[Fursphere]

From an objective point of view, what is the justification for creating 175 empty folders (Just checked my own installs) on the customers personal computer that will most likely never be used? 

Is there a reason they can't they be created 'as needed' when they will be used?

[Retro808]

15 minutes ago, Fursphere said:

From an objective point of view, what is the justification for creating 175 empty folders (Just checked my own installs) on the customers personal computer that will most likely never be used? 

Is there a reason they can't they be created 'as needed' when they will be used?

It is likely to ensure the folders are the more common names and to ensure that if the user just drops the roms in the correct folder names the feature will work off the bat without the need for the users to set anything up as in alter folder name or edit default folder path. 

[Fursphere]

That makes sense.   In that case, you should probably just auto-populate all of that with every install, and disconnect them from the auto-import feature. 

Or even make it an option on install?  "Auto populate game folders with well known naming convention" (yes/no) or something.  That way the behavior is clearer to the user as to the intent behind it.

I have my entire game library completely outside of LB, so all those folders aren't relevant to me.  Although with the auto-import feature and naming conventions I may reconsider that.  I'll have to give that some thought. 

[Alfie Wilmott]

Well mate if youre so mad about it just go to Options > Automated Imports and untick the only option for it

[Retro808]

15 hours ago, Fursphere said:

That makes sense.   In that case, you should probably just auto-populate all of that with every install, and disconnect them from the auto-import feature. 

Or even make it an option on install?  "Auto populate game folders with well known naming convention" (yes/no) or something.  That way the behavior is clearer to the user as to the intent behind it.

I have my entire game library completely outside of LB, so all those folders aren't relevant to me.  Although with the auto-import feature and naming conventions I may reconsider that.  I'll have to give that some thought. 

I understand your point and I am sure the devs do as well. However, somewhere something has to give and in my experience working with the team they are striving to make LB as beginner/user friendly as possible while still allowing LB to be flexible for the power user. The empty folders take up no real space, so for the sake of making it easy on new users and entry level users it make sense to have the folders created and ready to use. For the time being, while this new feature is being developed and evolves, the folders are not an option that can be turned off unless you turn off auto imports. Please continue to provide sound, constructive feedback. Just remember not all of our users have the depth and breadth of knowledge in emulation. 

[Fursphere]

Emtpy folders do take up space, just not enough to mater with today's drive capacities.    (I wrote a script that looped and ate up like 500 Mbs worth of disk space in hidden folders when I was a teenager many many years ago...  lol)

Its all good.  I was just trying to understand the thought process behind how we got here.  Thanks for the background.

[Joe35car]

If you want to make this user friendly for new people how about auto generating default command-line parameters for associated MAME systems. Example Atari 2600 would be a2600 -cart. Or Sam Coupe samcoupe -ab \nBOOT\n -autoboot_delay 3 -flop1. Or make a list and post on the website all the default command lines for people to copy and paste. Importing games is the easy part. It's little things like this that people have trouble with.

 

 

Edited March 17 by Joe35car

[JoeViking245]

54 minutes ago, Joe35car said:

If you want to make this user friendly for new people how about auto generating default command-line parameters for associated MAME systems. Example Atari 2600 would be a2600 -cart. Or Sam Coupe samcoupe -ab \nBOOT\n -autoboot_delay 3 -flop1. Or make a list and post on the website all the default command lines for people to copy and paste. Importing games is the easy part. It's little things like this that people have trouble with.

Getting a bit off this thread's topic.

Akin a BitBucket feature request, one can find a bit of those parameters here and also here.

[C-Beats]

@Fursphere Folders are added for you so that users know where to put the files. Otherwise they'd have to know our naming convention and potentially stop and think what we use. It also is a good way to show which systems that feature works on since it doesn't work on all the platforms in our DB. As @Alfie Wilmott stated, if you turn off the feature we delete those folders for you. You can still use the manual Scan for Added games tools from that point on if you need to sync a folder like the new system does. It's just more manual/granular.

[Light Sock]

It's a good idea but I'm not  sure I need this and it shouldn't be opt-in after the update. I was annoyed as well by this feature since it's adding back DLCs I have manually deleted from LB import but kept in my folder in case they would be needed in the future. Some DLCs must be installed in the emulator virtual HDD. I found this  topic yesterday and was able to deactivate that option and delete the Games folder since my game library is on my NAS like many users. Unfortunately deactivating this option can cause crashes if you deleted the Games folder. It happened to me when un-checking the Show Videos option in Visuals > Game Details.

I can't tell if it's also related to my other post where I had 3 crashes when pressing play on a video snap in LB.

Hope this helps trouble shoot this issue.

(Inner Exception)

Could not find a part of the path 'G:\LaunchBox\Games'.

App:     LaunchBox
Version: 13.12
Theme:   Default
Type:    System.IO.DirectoryNotFoundException
Site:    IntPtr CreateDirectoryHandle(System.String, Boolean)
Source:  System.Private.CoreLib

   at System.IO.Enumeration.FileSystemEnumerator`1.CreateDirectoryHandle(String path, Boolean ignoreNotFound)
   at System.IO.Enumeration.FileSystemEnumerator`1.Init()
   at System.IO.Enumeration.FileSystemEnumerableFactory.UserDirectories(String directory, String expression, EnumerationOptions options)
   at System.IO.Directory.InternalEnumeratePaths(String path, String searchPattern, SearchTarget searchTarget, EnumerationOptions options)
   at System.IO.Directory.GetDirectories(String path, String searchPattern, EnumerationOptions enumerationOptions)
   at System.IO.Directory.GetDirectories(String path)
   at Unbroken.LaunchBox.Windows.Desktop.ViewModels.OptionsAutomatedImportsPageViewModel.PopConcreteSingleton(Object )
   at Unbroken.LaunchBox.Windows.Desktop.ViewModels.OptionsAutomatedImportsPageViewModel.Save()
   at ConnectionThread.ChangeTraversalStub(Object , ConnectionThread )
   at Unbroken.LaunchBox.Windows.Desktop.ViewModels.OptionsViewModel.VerifyObservableBroadcaster(IEnumerable`1 item)
   at ProcessProducer.ChangeTraversalStub(Object , IEnumerable`1 item, ProcessProducer )
   at Unbroken.LaunchBox.Windows.Desktop.ViewModels.OptionsViewModel.VerifyObservableBroadcaster(IEnumerable`1 item)
   at ProcessProducer.ChangeTraversalStub(Object , IEnumerable`1 item, ProcessProducer )
   at Unbroken.LaunchBox.Windows.Desktop.ViewModels.OptionsViewModel.Ok()


(Outer Exception)

Exception has been thrown by the target of an invocation.

App:     LaunchBox
Version: 13.12
Theme:   Default
Type:    System.Reflection.TargetInvocationException
Site:    System.Object InvokeMethod(System.Object, System.Span`1[System.Object] ByRef, System.Signature, Boolean, Boolean)
Source:  System.Private.CoreLib

   at System.RuntimeMethodHandle.InvokeMethod(Object target, Span`1& arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   at Caliburn.Micro.ActionMessage.<>c.<.cctor>b__33_0(ActionExecutionContext context)
   at Caliburn.Micro.ActionMessage.Invoke(Object eventArgs)
   at System.Windows.Interactivity.TriggerBase.InvokeActions(Object parameter)
   at System.Windows.Interactivity.EventTriggerBase.OnEvent(EventArgs eventArgs)
   at System.Windows.Interactivity.EventTriggerBase.OnEventImpl(Object sender, EventArgs eventArgs)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   at System.Windows.Controls.Primitives.ButtonBase.OnClick()
   at System.Windows.Controls.Button.OnClick()
   at System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs e)
   at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender, RoutedEventArgs args, RoutedEvent newEvent)
   at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
   at System.Windows.Input.InputManager.ProcessStagingArea()
   at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
   at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
   at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

Recent Log:

   2:26:09 PM Exception

 

4 hours ago, C-Beats said:

@Fursphere Folders are added for you so that users know where to put the files. Otherwise they'd have to know our naming convention and potentially stop and think what we use. It also is a good way to show which systems that feature works on since it doesn't work on all the platforms in our DB. As @Alfie Wilmott stated, if you turn off the feature we delete those folders for you. You can still use the manual Scan for Added games tools from that point on if you need to sync a folder like the new system does. It's just more manual/granular.

I understand the way it's done but it's unpractical for advanced users. I'm currently fine tuning my medias for all systems and it's very annoying to search for stuff when you must open dozens of empty folders. It would be really appreciated to disable this feature in the options and a purge button to delete all empty folders. This way when you want them you can toggle them on otherwise they can be deleted when needed.

[Whatscheiser]

Just to chime in on this... because I'm glad I put two and two together before I relaunched the application and gave auto-import a chance to do its thing.

 

I was editing one of my platforms and had need to change the file name of an .lnk file. I had LaunchBox open at the time so it prompted me with something like "A change was made in one of your game folders. Would you like LaunchBox to autoupdate ROM changes for you?" Which I'll admit did pique my interest so I clicked "Yes"... and then remembered the new feature and the "opt in" nature of it for existing installs. I checked, and sure enough the Auto-Import feature was enabled through that dialogue.

To me there isn't enough there indicating what a user is opting in to. It asked if I wanted it to monitor existing folders and update changes I make, which actually would be pretty cool. What it doesn't say is that it may also add things I didn't intend or create more game folders for systems I don't actually have. The prompt given to a user that isn't following all of the updates doesn't really paint the entire picture of what they are agreeing to.

 

Anyway, I didn't have any issues with it. Just wanted to point out how I could see it being an issue for folks who do not want the feature. I get pretty deep into the weeds customizing my libraries. The last thing I want is automation making changes I didn't intend to make.