skizzosjt

damn nice work! the only one I'm not crazy about is the Streets of Rage one, which still looks great overall, but the word "collection" is a bit funny looking in my opinion crooked like that. You fit collection into all these other logos themes well, but that one looks forced or out of place I suppose

oh geeze yup I didn't zoom in a read the fine print 🤦‍♂️ listed as parent rom based off the file name. I don't know enough about that game to know if you gotta get the BIOS or what it is that is missing. to find what you're missing, google is your pal....wink wink

you're looking right at the solution. you're missing 4 files, seems you have an incomplete ROM or have a clone version w/o the parent, something like that.

NO!!! that was all explaining that the idea of using phony do nothing hotkeys is NOT going to work for what you want to achieve, which is blocking inputs while still executing the rest of your script.....as I say that.......I bet you could simply launch a separate script like you did with the BoxMin one! If you used the concept I went off by placing phony WinMinimize lines, JOE makes a much better point below to use a RETURN instead.....despite me knowing exactly what return does my mind didn't get to that conclusion lol. You could in your steam launcher script put in a line to run a separate new script, I'll refer to as "BlockInputScript" for now. In BlockInputScript you can place bunch of hotkeys with return on them. One of your buttons for ex: "1Joy3::Return" would force it to do nothing. You would want BlockInputScript to launch in your steam launcher script whenever you want the blocking inputs to start, and you can in the steam launcher script tell BlockInputScript to terminate when you want the inputs to stop being blocked. This allows your steam launcher script to continue executing as it normally does, while allowing the fake do nothing hotkeys to work as intended So my last posts were pointing out these work when isolated in my test scripts but it's going to screw up the flow of execution when integrated with your script. Thankfully from you mentioning the new idea you had to make a separate script to minimize BB, you provided the idea to do the same thing to get blocking inputs to work. having multiple separate scripts run simultaneously creates a pseudo muti-threaded execution of AHK, that meaning they can operate independently of each other. I think you just helped yourself and didn't even know it lol. You wouldn't even need to use any context sensitive lines in BlockInputScript. This will suffice. I just tested this in with bigger scripts of mine (with different keys obviously, I've been using j, k l) and it works as I expected it to. PUT THIS IN SOME SEPARATE SCRIPT LIKE "BLOCKINPUTSCRIPT" 1Joy3::Return 2Joy3::Return $1::Return $v::Return THIS IS A MOCK UP OF YOUR STEAM LAUNCHER SCRIPT CODE HERE BLAH BLAH ;NO INPUT BLOCKING YET Run, BLOCKINPUTSCRIPT.AHK ;JOYPAD BUTTONS ARE NOW BLOCKED MORE STEAM LAUNCHING CODE BLAH BLAH ;BLOCKINPUTSCRIPT IS TERMINATED WITH THIS METHOD TO ALLOW INPUTS TO WORK DetectHiddenWindows, on SetTitleMatchMode, 2 WinClose, BLOCKINPUTSCRIPT between your and joe's feedback I think this is finally a solution that will work for your use case, rather than only work as an isolated test. if you're happy with the outcome that's what matters. I'd personally go the route we're mentioning with blocking inputs via a separate hotkey script rather than minimizing the window but I cannot argue against a it's not broken so don't try and fix it mentality either. but I'm wondering, why does this even matter? you're saying hitting a button during booting of a game is creating problems for you then? because that sounds like have(/had) something funny going on, that shouldn't be creating any problems. It does, as you've reiterated what I went through. I get tunnel vision and didn't take a moment to think through how it would interact with his script. none of this will work for what Sbaby wanted to do, despite these ideas working OK when they are isolated as test scripts, the problems arise when they are integrated in with more code.

hmm what I tested does "work" (it works, but not really how we would want it to, explained throughout this post). Irregardless, it sounds like you have gone some other route to achieve the goal....good! but I now see a few problems with that method we have been talking about, and it's a good learning experience. first off, you gotta understand what hotkeys do and how they operate. they execute the code on the same line they are on, OR, if nothing is on the same line, everything below it until something that would stop the thread, like a return or exit, goto, gosub etc. So look at your script closer, each time you would click one of those buttons you would literally be re-executing your script. An example I made to prove this theory if I hit key j it will type out 1 as expected. but if I type out k, since no code is on the same line it executes below and goes to the next hotkey, l, which is doing the same thing with nothing on the same line, so it keeps executing lines up to it would one of the several commands (not sure if command is the right term) such as return tells it to stop. in this ex it stops once it gets to a hotkey with code on the same line, this being the 2nd instance of j. this means if I hit k....sure it does "nothing"......except start executing the rest of the fucking script! that's obviously not "nothing"! hitting k I can hear the soundbeep, and it goes into the next j hotkey that types out 4 instead. meaning despite declaring k first with nothing, hitting k will actually type out 4 in this example script. so this is a pretty flawed method to achieve the goal It would be better to put some actual commands there that pertain to doing nothing. For example, tell the hotkeys to minimize a window that doesn't actually exist. This would work better then the first handful of suggestions. Use a WinTitle that is "fake". I didn't see the problem with keeping them blank right away because the test script I made was just a test, it had no other code in it to run....but as I looked it over again it dawned on me this approach is problematic. So that's how I ended up trying this other test with phony commands on the same line as the hotkey instead of leaving the hotkeys blank. But now as I stare at this test.....still will not work for your use case. if you hit one of those phony hotkeys it will bring the script to that line and stop at the next....stopping execution of your script. which obviously is not desired. I say at this point, this whole idea needs to be abandoned. if we thought better about this, likely woulda saved wasting time trying this lol oh well that's all part of the learning experience

Great details and thanks for the help!

your post helped me figure out something new here. hope this helps you too! I've tried minimizing Big Box in the past, out of pure curiosity reasons, and I never was successful. Even Windows built in function like Win + M which minimizes every window that exists doesn't do it. That just removes focus from Big Box, but it's still always visible. However, after seeing you were using WinMinimize I thought to myself "no way those commands work" and tried it to see what happens.....and it worked in my scenario! my first scenario......not all scenarios are created equal! I assigned it "WinMinimize ahk_exe BigBox.exe" to a hotkey and it works.......if you are just navigating through Big Box, (options, platforms, games, etc.) It only takes one line, no need to duplicate them either. It does NOT work during the startup sequence when the startup themes are displayed! You see a quick flash back and forth between Big Box and the startup theme when I try it at those points so Big Box doesn't minimize at this point of use. So I don't think it is possible to minimize Big Box during the startup. This is a catch 22.....if startup themes are enabled, the very moment you click play the startup theme sequence will begin. So I found it isn't possible to even use an additional app script with this command telling it to launch prior to the main app. Basically you need to not use startup themes if you wanted to minimize Big Box. If you don't use startup themes the command WinMinimize works whether it is included in your main script or an additional app script. That will work for you. Tried an experiment also with using ControlSend to send keys to Big Box when it was minimized and it kinda, sorta, sometimes, worked. Seems like Big Box is "suspended" when minimized, evident that all videos stop playing...or err....usually stop playing. But, this plan of mine worked when I could still hear the videos playing when Big Box was minimized....I don't know why sometimes this happens as it seems somewhat related to if other windows are open and if I click the mouse or alt+tab prior to using the hotkey....I'm not finding the exact pattern to make that work with any sort of real consistency You're not a programmer? Welcome to the club, population you and myself lol! it's ok to not get it right away, I sure don't always get things immediately. The best thing I can recommend is you should try working on LITTLE BITS of script at a time to fully understand how they work, THEN start piecing stuff together to make the whole script. In this example you should be playing around with context sensitive hotkeys, then once you have your "eureka moment" you can start using your newly gained knowledge to add it into bigger scripts like the launcher you made. But here's what you could try specifically. Try declaring them a 2nd time with the 2nd/newer window, like this for ex. This was suggestion #3. Since you're destroying MySplash with line "SplashImage,1:off" it invalidates your context sensitive hotkeys. One of the ways to keep the do nothing hotkeys doing nothing is to then create them again but tied to another window that exists. The 2nd popup you're making is called Splash2, so use that in the same exact way as you did MySplash I do not think you need all those extra braces { btw. The context sensitive lines #If-blahblah work as such any hotkeys that are declared after those lines run, the hotkeys are tied to the context sensitive line until the script exits or if there is another context sensitive line ran, which is what were doing here. Because normally you cannot declare the same hotkey more than once in a script otherwise! (how would AHK to know which hotkey to run if that was the case? that is when you get the error "Error: Duplicate Hotkey" when attempting to run a bad script like that) For example, this below works fine. If I had notepad open, or this exact webpage I'm typing on now because its title is "Auto Hokey Scripts" has "Hotkey" in the name, it makes all those keys do nothing. If I close my internet browser, they still do nothing because notepad is open. So now if I close notepad also, both windows are now closed, and now the keys j, k, and l will type out as normal. Trialing stuff in a small scale like this is how I learn, so it's why I recommend you give it a shot too. Everyone learns at their own pace and their own methods, but it's how I learn new stuff about the AHK language. I gotta understand the small bits before I go stuffing them into a several hundred line script edit: might have worded the above wrong. for example, if I made the first j hotkey type 7 instead, and the 2nd j hotkey type 8 instead. when both windows (my browser and notepad) are open AHK defaults to executing the first hotkey that would be ran. which makes sense. this means I would type 7 if hitting j and both notepad and browser are open. if I close browser, 7 will still type out from the j key. but if I close notepad instead and the browser is still open, now j will type out 8. so in this case when we're using multiple windows for the same context sensitive hotkey, which ever one is activated first in the scripts auto execution sequence will run. for ones to run below it, the first one would need to be invalidated by closing the context window

glad you got it worked out and I see you clarified what I found too, Retro Console BB. But I'm hoping you could clarify further, I noticed there are at least two different versions of this custom theme, and I'm not 100% clear if one or the other offers the same layout you were utilizing in your video. I'm going to hazard a guess you are using something like "text view" (I'm sure that is not the right term, but hope it gets my point across) because all the game titles are simple text rather than game specific logos like the "wheels" used in many themes. I like the icons used particularly also. Do you know which one specifically you are using? There is a 2.1.4 version, and a 3.0.6 version If I had to guess, yours looks closer to the photos shown in 2.1.4 2.1.4 link for reference 3.0.6 link for reference When I looked at the newer one, 3.0.6 I don't see any photos on that page that look similar to your theme. For ex, I do not want themes looking like this one shows where the layout mimics the appearance of the console as a bezel. So I'm asking because maybe the newest one still has all the same support for the appearance that was used in 2.1.4 but maybe it just isn't showcased in the thumbnail images the creator uploaded to the download page. I dont' want a theme that looks like this But I DO want a theme that looks like this. Which I think looks like the one in your video Long winded way to say, "Can you please tell me exactly which version of the theme you're using?" LOL I'm just trying to avoid downloading the wrong one

OK so all that confirms the script is doing what you told it to do then. You tied the context sensitive hotkeys to a window (MySplash) that shows up for a moment and then is "destroyed" just a few lines later when "Splashimage,1,off " is ran. The only time those "do nothing hotkeys" will work as you intend them to is between creating them and the time it takes Splash2 window to appear, which is before any game is launching, hence why you're inputs are still being detected while the game boots. That Splashimage off command destroys the window which the context sensitive hotkeys that are supposed to be blocking joypad inputs are dependent on. So they will not work anymore, meaning your inputs WILL be detected. This comes down to needing to design the script structure better so it suits your needs. There are options to get it done. A couple being the context sensitive hotkeys need to be tied to another window that exists during the whole duration you're are trying to block inputs. Or you could leave the current MySpalsh window existing for a longer period of time. Or you can tie them to the current MySplash window as you currently are but when MySplash is destroyed, create the hotkeys again but tie them in context to "Splash2" window existing, etc. You will have to experiment to see what method works best for you, I'm sure there are other ways to achieve the goal beyond what I just mentioned also. To clarify, I wasn't saying you need to remove that line, I was pointing out I think that it is the main culprit of why the do nothing hotkeys aren't working as you intended. Which you have confirmed this is the case. It's the culprit, how you go about fixing it will be up to you but now you know why it's doing what it's doing.

looks like you already tried what I would have suggested, using context hotkeys with something like #IfWinExist. I'm surprised that wouldn't get the job done. But I would use #IfWinNotExist and the context would be a WinTitle format of the game, you couldn't use ahk_exe gameoverlayui.exe since it creates no window! The hotkeys being linked to nothing would do nothing during the boot, and once the game window appears the context hotkey is now invalid and the joypad sends inputs as intended. Not seeing anything super obvious right away. Using this method works for me, so should for you too then...right? I used different keys since I don't have a dinput joypad but worked fine using keyboard keys. I tested with Notepad and the game Streets of Rage 4, having those context sensitive hotkeys only enable if those windows existed. That splashimage should work, but why doesn't it work already? Does "MySplash" close when "Splash2" opens? If so, I think that's your problem.... Looks closer.........BINGO....I think it does... here on line 53! Wouldn't this make those context sensitive hotkey invalid as soon as this line runs? SplashImage,1:off

Yes, create a "playlist" and add the games you want to see in that particular playlist. You can also create playlists that auto generate off a bunch of different parameters, one for ex is recently played

Scroll up to the top of this page and click on Premium and then Get Premium With Big Box to get yourself familiar with what the differences are. It's going to be subjective (this looks nicer than that), and objective (what do you want out of your frontend) reasons for making a decision to stay on LB or upgrade to BB. There are some more functions available in BB, and it has more customization for making a clean frontend experience that many enthusiasts prefer especially when putting their systems in an arcade cab

Edit Game > Startup/Pause > Override Default Startup Screen Settings Then click click Customize to adjust to your liking Startup themes are totally optional. No need for scripting because there is already a feature that lets you customize these settings down to as fined tuned as the per game level. In your case you could try turning up the delay time on the slider so the startup screen displays longer for the games that take more time to startup, or turn them off completely if that is all you're after.

there is a built in feature....have a look in the tools menu. With that said, setup a hotkey for it and you're all set. For ex below making the home key the hotkey. Making it go to other platforms when in a platform sounds tricky. If you wanted to select random games from the entire library I'd suggest you go into the category "All" and use the hotkey there Home:: Send {LCtrl down}{LAlt down}{q down}{q up}{LAlt up}{LCtrl up} *Edit* Apologies...I had LB open and tested this there and it works. But using that designated key combo doesn't seem to part of BB. So I went looking for a BB equivalent assuming there was one. Doesn't appear to be an exact 1:1 equivalent. BUT, there is under BB options > Keyboard Mappings you will find a setting called "Spin Wheel While Pressed" so you can assign that to any key you want, press it and does exactly what it says, spins the wheel. Kinda neat, it keeps momentum going briefly after release, much like it has a natural deceleration. So this could be used to randomly select anything in BB, categories, playlists, platforms, or games.

yes, sorry I didn't elaborate any further because kiinkyfoxx did such a thorough job 👍 I had nothing of value to add other than to say "mine works OK". But since you're still having trouble, I'll add what I can For yuzu, I see a small change I doubt is the cause but pointing it out. I do NOT have "Attempt to hide console window on startup/shutdown" in the Yuzu emulator details tab in LB. But again, this shouldn't matter because If I toggle these settings I cannot recreate your issue. Still on yuzu.....Seeing how I can get this to work with less settings, did you try turning this stuff off too? a 5 second slider time is what I use for the delay. When I enable these settings it seems it is hiding the window that shows the shaders compiling so puts a black screen up during that portion should the start screen already faded out. So again not so sure this is helpful, because I didn't totally recreate the issue. Even putting a silly long delay of 30 secs yuzu should be launching into exclusive fullscreen which will take over the display and steal focus. Therefore cutting off the startup screen prematurely from it's user setting.....just like the notes are described by the developers in LB. the "-f" parameter is what launches yuzu as fullscreen, but it doesn't designate exclusive or borderless, that is done in the emulator. When I entered 30 secs yuzu still displayed the game in ~10 secs which is on par with the time it takes my system to compile the shaders and launch the game normally, working exactly as intended as the devs describe in the LB notes. Are you using EXCLUSIVE fullscreen here in yuzu? borderless fullscreen can cause problems like this. I got stuck on a black screen after the startup screen faded out using it, and if I clicked the mouse, the shutdown screen appears and does it fade out and now the game window visible. Sooooo sorta sounds like the same problem you're having? I hope this is the culprit, it would totally explain the problem if this fixes it! Does seem like the smoking gun if you will I'm not finding a smoking gun for RPCS3 quite yet though. Doing our due diligence we should check the equivalent setting in RPCS3 here. It should be off....but I'll admit this didn't recreate the issue if I enabled it just now. My startup and shutdown screens worked the same prefect way with this on or off....but to be clear off is better, exclusive fullscreen is superior. I got the other screens too, some other settings are used, but I don't think they come into play with your issue (hiding the mouse settings for example shouldn't impact this). The fact you can "get control" back from hitting escape means the emulator is running in the background so you are exiting it as intended through your exit hot key (which you should change the same exact script you had in yuzu. don't close emulators via the process command since it is the equivalent of nuking them through task managers end task. so ONLY use that as an absolute last resort to close an emulator. RCPS3 works fine with the script you have in yuzu). Otherwise....sorry....I'm not finding anything else yet that sticks out that causes your issue with RPCS3. I think I've scrutinized every setting you and KiinkyFoxx shared. If I didn't share my specific settings, it's because they were the same as shared by kiinkyfoxx. I tried to only point out my differences. By the way, sorry to go off on the tangent as you're looking for help, but I really like the theme you are using here, your favorite as you described, but I didn't catch the name of the theme? Can you please tell me which theme this is? Nvm....I shoulda used the search function before asking, it was easy to find!

I'm not using the fullscreen parameter and I am using DX, looks like it was the default being the top most in the list. I'll try Vulkan since I got an AMD GPU, they seem to usually pair well together on emulators. I do have Render to Main window checked. Drum roll please......🥁 Sweet, it works! 🎉 Now my problem is I cannot recreate the issue lmao because I wanted to figure out what change fixed it. Render API change doesn't matter, works with DX and Vulkan. I did my silly setup to hide GUI flashes and not get stuck on a blackscreen, but this looks even smoother at start up, immaculate actually....as intended of course. No reasonable explanation from me on wtf I did wrong initially to make the normal fullscreen parameters not work. I could have sworn I tried all this stuff without success hence why I wouldn't have used these intended developer designed methods, but glad they are working now after your advice. Either way, thanks for the help again Overlord!

meh it's what I had in my script. must have been some experiment I did and never reverted back to something not so nonsensical.... after you're now pointing it out this is totally unnecessary. thanks! I set this one up when I was still on free version of LB and if I remember right was an attempt by me to hide a couple random flashing windows during start and shutdown. Little more difficult without the features behind the paywall. I tried using "normal" settings now, and these screens pop back up again . for ex this is at launch...black screen with two white screen areas, this happens even with batch parameter on either the nogui or standard exe version. To clarify, the game window pop ups momentarily after seeing this so just want to make sure no one thinks this is one of those stuck on a black screen problems. just a brief flash of this screen. and on shutdown I see a fullscreen flash of the "nogui" screen....(how ironic 🤦‍♂️) if using the nogui version and selecting games to launch in fullscreen. but if selecting the standard exe, I don't see the GUI flash at shutdown as long as the -batch parameter is included. this is what I see flash after game shutdowns, but prior to shutdown screen appearing when using nogui version OK so I know I'm talking about startup and shutdown screens, but this is related to hiding the GUI. What I've found I had to do was use standard version rather than the nogui version, additionally, I need to start in windowed mode. Starting in fullscreen must be turned off. I then use this in emulators running script to make it go into fullscreen at launch. A normal send command works too FYI. I was doing even more silly shit that I deemed unnecessary during my initial experiment months ago like using a shortcut link, telling that to launch the emulator minimized, and using control send to send those keys to the right part of the window so it would actual toggle fullscreen since send only goes to an active window, and I was trying to send it to a minimized window. So I just left that in, it's not harming anything being more specific where the keys are sent. It's the "classNN" title of the window section that is the actual game area. WinWait, ahk_exe duckstation-qt-x64-ReleaseLTCG.exe ControlSend, Qt610QWindowIcon5, {RAlt down}{Enter down}{Enter up}{RAlt up} And I think this is more or less default setup in the emulator "Hide All Windows that are not in Exclusive Fullscreen Mode" option I think could be optional. Investigating just now, it looks like if it is off all it does is not hide the standard exe game selection window, but causes no other screen pop up flashes, and you never actually see this GUI window at startup or shutdown (as long as "-batch" parameter is used) Am I overthinking all this? Any chance you have a less complex method to avoid the couple pop up screen flashes (aka hiding the GUI) and still get startup and shutdown screens working? To clarify, this setup works perfectly for me, but I'd always appreciate a simpler approach when/if one exists

For duckstation, batch does work exactly as intended hiding the GUI. I just tested for a sanity check. as to using a key press to exit, you will want to reassign the exit key in the emulator and then setup a hotkey so it triggers that emulator exit key (or just hit the exit key you assigned in duckstation). I made it End in duckstation and then made escape a hotkey to end for ex: $Esc::End I use PCSX2 1.6 for the need to have light gun support so idk about 1.7 but I can vouch for 1.6 working as intended also.

I'll 2nd this works perfectly fine without any special convoluted setup requirements. Just normal enabling the options. Though I wouldn't agree you need to check "hide all windows that are not fullscreen" or "aggressive start up window hiding" or turning the slider up to a very long delay since I am not using those settings.

OK that is good news! Should be as easy as letting it download the most up-to-date metadata and update your MAME/Arcade library metadata. Fingers crossed! 🤞

Sorry, when I said "whole library" I should have said whole MAME/Arcade library. I didn't mean to reimport your entire LB library of likely many platforms lol. oh boy, that's interesting. you're problem isn't exactly lining up with a scenario I can wrap my head around now. this doesn't make sense to me at this moment. to explain, if things like description and genre were populated it pulled in data from the database and it should have the database ID# in the top right of the game edit window. if that is there it should have pulled in ALL metadata, I don't think there are options to have it only populate certain fields so that is why I think this problem sounds bizarre. do you see that database ID# being filled in, and the link takes you to the correct game webpage?

keep in mind you can always copy those backup archives to another folder to keep a true forever backup. you don't have to leave them in the default backup folder where they will get get cycled out with newer backup versions the more you open/close the program. So on 2nd thought, why the hell did the ROM's import and assign a "title" as the file name instead of the game title? It suggests you did not "scrape" the ROM's against the correct platform, therefore would not populate metadata and therefore leaves the ROM's file name as the title and more or less everything else blank. Is this what in fact happened, all metadata was empty basically besides the title field, which was populated by the file name? If so, please try re-importing again and be sure you are scraping using the intended platform which would be Arcade. If you wanted you could test with just a single ROM and if that is all it was to fix you up then do your whole library.

try seeing what is in Launchbox\Backups. when you made the accident you should have reverted then. hopefully you didn't open/close the program so many times it cycled out a save that would have your library in the good state.

I got no secrets so never feel afraid to ask for sharing from me! I really just went off what you and others shared already. What I did do that is a little different that I don't think anyone brought up yet was the incorporation of an ini file. Here's the AHK Steam Launcher template script, which is really the scripting method shared about how to get startup and shutdown screens working well! The main takeaway is using an ini file to pull in variables, rather than make a butt load of game specific scripts. IniRead, exe, C:\Users\Scott\Desktop\Steam Database.ini, %1%, exe SteamID = %1% Run, steam://rungameid/%SteamID% WinWait, ahk_exe %exe% SetWinDelay, 3000 WinActivate, ahk_exe %exe% WinSet, Bottom, , LaunchBox Game Startup Sleep, 500 WinSet, Bottom, , LaunchBox BigBox WinSet, Bottom, , LaunchBox WinWaitClose, ahk_exe %exe% SetWinDelay, -1 WinActivate, LaunchBox Game Startup WinSet, AlwaysOnTop, on, LaunchBox Game Startup ExitApp Emulator Setup for this. Personally my experience is I cannot get variables to be passed if I put the actual script file as the application (like what you and many others do on here I have noticed). I seem to need to put the AHK exe as the app, and then either have the individual script launched via the command lines or as a ROM file. (the key is having the exe as the app for me) But nevertheless it doesn't matter really because I can still just put the script in the command lines even when extra variables or parameters were required. Here is the associated ini file. The TOP portion is when I was using "%gameid%" variable. So that is what that long string of randomness is, these are the "ID" #'s that are in the platform's XML file for the individual game. At the time, the template script would have had one additional line for the ini which was pulling in the SteamID key since I was not yet using the dummy files The BOTTOM portion is when I started trying using the "dummy file" method for the ROM file, the method you detailed. This would not need any LB/BB specific variables used like %gameid% since we are creating a game specific variable, the SteamID, through naming the dummy ROM file as such [cf71371c-b6c8-4c07-b151-9a4302336254] SteamID = 1203710 Title = UnMetal exe = unmetal.exe [7ec62344-b6b3-4718-b587-bf1c5e1dfb24] SteamID = 609110 Title = Blazing Chrome exe = Blazing Chrome.exe [c50e2993-621b-48f7-bf34-cf7fcd83d74c] SteamID = 1361510 Title = Teenage Mutant Ninja Turtles: Shredder's Revenge exe = TMNT.exe [fea789b4-8b3a-4858-9270-5b9b1d38b8d3] SteamID = 1244950 Title = Battletoads exe = Battletoads.exe ########################################### [1203710] Title = UnMetal exe = unmetal.exe [609110] Title = Blazing Chrome exe = Blazing Chrome.exe [1361510] Title = Teenage Mutant Ninja Turtles: Shredder's Revenge exe = TMNT.exe [1244950] Title = Battletoads exe = Battletoads.exe Technically I am not using the "Title" key for anything in my script. It's just there so I know wtf game "cf71371c-b6c8-4c07-b151-9a4302336254" or "1203710" is without having to cross reference to other files If you're familiar with RocketLauncher the bottom part is literally 1:1 what you do in their PCLauncher module's "SteamID" ini file. So this hopefully walks you through seeing why I wanted the ini file. It gives the ability to control game specific windows during the launch and shutdown sequences, which I applied the games exe into the %exe% variable. Don't forget that Overlord said we need to check "Hide All Windows that are not in Exclusive Fullscreen Mode", this is critical also for this whole plan to work as intended.

did you happen to try each side of your screen? it looks like you might have only tried top and the right hand side. give the left hand side a shot if you not yet. I too was only working with one side and the top, though I tried bottom too, it wasn't until I put it on the right hand side it worked for me. Maybe in your case you need the left hand side? your situation sounds super similar with stuff rendering at a much smaller resolution than the screen with the marquee displaying also. the thread I made to help troubleshoot this and what was the final solution for me is here: