Before anyone drops a "use the search function first", I hope you provide a link because I have scoured over 200 posts trying to find the answer to this question and its either not there, or EXTREMELY well hidden.
So...ADB worked fine for me on Windows 7 x64, untill I had to uninstall and reinstall some drivers when helping a buddy root his g1.
Now, ADB doesn't work. Whenever I try to run an adb command, even just to list devices, I get this error:
Code:
* daemon not running. starting it now *
CreateProcess failure, error 2
* failed to start daemon *
error: cannot connect to daemon
I have scoured Google, and I haven't found a single post that is android related (there are similair errors on android forums, just not this one) and am sorrily stumped. If anyone can help, I'd be ever so grateful.
This definitely sounds driver related although I'm not sure how you can "roll back" drivers in 7. I've heard that 7 pretty much keeps every driver you've ever used around and for whatever reason it's using an older ADB driver. I'd put money on me being wrong though.
if you are using a 1.5 image, use the drivers from the 1.5 SDK. If you are still on the RC builds, use the drivers in the 1.0 SDK.
win32 error code 2 means: 2 The system cannot find the file specified. ERROR_FILE_NOT_FOUND
and from the source code this is after a call to CreateProcess() and the file name is given by GetModuleFileName(), so it seems that the latter failed in a strange way.
What's the full path to your adb.exe?
billc.cn said:
win32 error code 2 means: 2 The system cannot find the file specified. ERROR_FILE_NOT_FOUND
and from the source code this is after a call to CreateProcess() and the file name is given by GetModuleFileName(), so it seems that the latter failed in a strange way.
What's the full path to your adb.exe?
Click to expand...
Click to collapse
D:\G1\android\tools\adb.exe
No spaces or odd characters. Like I said this worked fine for a month or so before I started ****ing with the drivers. I havent moved anything, my PATH and CLASSPATH are pointed correctly to the right directory. I also have a copy of adb in my /system32 directory (along with we .dll file it needs) so I can run it from wherever at a cmd prompt.
it might have something to do with wow64 messing the path up (it may rewrite system32 to syswow64). try launching the program under D:\G1\android\tools\ path. even if GetModuleFileName() failed, system should still be able to find adb.exe if you're under that path. also check file permissions and antivirus...
you can also try the command "adb fork-server server" in the path that contains adb. (you'll have to leave that console open)
Hi all,
I had built my own Nook-color on a Ubuntu machine before and I finally get around to have a VM based on the latest Ubuntu 14.02.
I followed most of the instructions here: http://wiki.cyanogenmod.org/w/Build_for_ovation.
When I get to the ./get-prebuilts, I got an error that the file doesn't exist, and this maybe my issue. I ignored this error and continue down the path.
Now when I do the "./extract-files.sh' part, I am getting the "device not found' errors.
I have the device plugged in, and when it does, the VM popped up the device folder (SD etc.), so I assume at least the device was recognized by the system.
If I ran "adb devices", it shows a empty list, so what gone wrong? (My HD+ has the adb enable and the icon showed up on the top left corner.
I'd searched the forum and found no solution related to mine.
Any help is appreciated.
Instead of extracting prebuilts (requires adb), add the Muppets proprietary vendor to your local_manifests (or just download and place in vendor/bn).
https://github.com/TheMuppets/proprietary_vendor_bn
Thanks Jon.
Actually I already have those files in the folder.
After searching the net for answer, I finally found the problem. It is that the usb's ini file in the ~/.android folder is empty, I need to add the BN's vendor id (x2080) to it. I also need to set its ANDROID_SDK_HOME to the PATH.
My problem doesn't stop me from making the build, but it will prevent me from using the adb for debugging down the line.
Hello everyone, I found a recovery tool on the open spaces of the Chinese Internet. This tool is for NE2210 only. It's in Chinese, but I don't think there should be any problems using it. Write who used.
Unbrick
The Msm tool is missing the FTLibBase.dll file it wont work. Just to let you know.
Canuck Knarf said:
The Msm tool is missing the FTLibBase.dll file it wont work. Just to let you know.
Click to expand...
Click to collapse
what is the file responsible for FTLibBase.dll ??
For me. I'm using win 11 and the Msm tools will not open .??? Maybe it a win 11 thing. It starts to open but then errors pop up missing the dill file . Did you install it by an exe file.
I want to try it ...lol...I have one more boot loop / dead battery 10 plus pro
I have been trying this fast boot command to get battery up enough to load boot file, vender_boot and vbmeta file. But after it dose a factory wipe ...kills battery wont reboot.
Using this command i started out with 6708 volts of battery took running command in fastboot 30 minutes to get to 6762 volts. So command dose work .
@Echo off
:start
fastboot getvar battery-voltage
fastboot reboot-bootloader
ping /n 6 localhost >nul
goto start
I need the command to just keep repeating by itself...i can leave it sit there for hours...Can you help ?
Canuck Knarf said:
For me. I'm using win 11 and the Msm tools will not open .??? Maybe it a win 11 thing. It starts to open but then errors pop up missing the dill file . Did you install it by an exe file.
Click to expand...
Click to collapse
I have w11, program starts normal, but not connected server.(((
VovaHouse said:
what is the file responsible for FTLibBase.dll ??
Click to expand...
Click to collapse
Can't you replace this file with OnePlus 9 pro msm tool i don't know where it's for but as long you get the msm tool work then it shouldn't be a problem ain't it ?
bir çözüm buldun mu? Aynı hata bende de var
Did you find a solution? i have the same error
Buyukturk said:
Did you find a solution? i have the same error
Click to expand...
Click to collapse
yeah....MSM and pay
Canuck Knarf said:
yeah....MSM and pay
Click to expand...
Click to collapse
unfortunately i couldn't find it
Canuck Knarf said:
evet.... MSM ve ödeme
Click to expand...
Click to collapse
nasıl çözdün bana yardımcı olurmusun
Buyukturk said:
unfortunately i couldn't find it
Click to expand...
Click to collapse
You can find it in the www
Prob is the msm Tool need a auth. (Acc)
DO NOT BUY ONEPLUS 10 PRO THEY DO NOT PROVIDE ANY TOOLS FROM UNBRICK
DO NOT BUY ONEPLUS 10 PRO THEY DO NOT PROVIDE ANY TOOLS FROM UNBRICK
Sorry for the delayed absence .... lol.. its been a trivial one. But I have been working DILIGENTLY on Oneplus Tools, and ONLY Oneplus Tools... (CanuckKnarf can verify this...)
Ok without breaking "responsible disclosure" guidelines... I can hopefully either clear up some of the chatter ive read up til now, as well as provide some important info which may inspire someone here with a new avenue as to how to attack this thing head on.
Let me start with the most recent statements about the missing files first.
If you have Windows (doesnt matter which version) and you have been running ANY of the official builds of the MSM Tool... (Official releases show an icon like pictured here
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
#1
unofficial (repacked for whatever reason) look like this:
#2
Now while there is no inherent threat to either version... the ones of the LATTER style, MAY OR MAY NOT run, when attempting to execute them. This is because the person who packaged it, MIGHT NOT have been doing so from the actual applications data folder in windows. Allow me to explain:
When you run #1 , that file unpacks itself and generates a folder inside your "/users/appdata/local/" folder and its usually along the lines of "OPPO Flash Tool Series 4.1" .... or a variant of that. IN THIS FOLDER is the actual files for which your MSMTOOL loads all of its config, dll, and other run codes from.
--Now this folder might not be generated if you are already running from a complete msmtool build. a complete build should have several dll's, several folders, and the actual program that is being called, 'FTGUIDev.exe" <-- This is your flash loader! .. This is the Alpha and the Omega so to speak of the MSM TOOL... #2, is the MSM equivalent of a Windows Installer REPACK. I have seen these range from 4mb all the way up to 9gb ... this is because some authors choose to repack the EXACT FW build that is to be used with it! (*** Important note!*** The version of the MSM Tool you are using plays a definitive roll as to whether you have a successful flash, or a fail!. OPPO HAS PLAYED THE SNEAKY ROLE AGAIN, AND IN CERTAIN RELEASES OF THE OTA FW FILES THAT ARE DISTRIBUTED, THEY MAKE A SMALL CHANGE TO ONE OR MORE FILES, WHICH WILL THROW OFF THE FIRMWARE INTEGRITY CHECK!.... BUT INSTEAD OF THE ERROR READING "INTEGRITY FAIL", YOU WILL GET .... PHONE MISMATCH... INVALID HANDLE.... VALIDATION FAIL... OR MAYBE FAIL INTEGRITY.... <----- These errors USED to have individual meaning, but OPPO choose to use them to provide misdirection as to what actually occurred. (( I have found a way to FORGE a passing INTEGRITY CHECK... but i cant disclose that yet, sry)) So now they do not want you to actually have the identifier as to what exactly went wrong that blocked your flash... the validation check is INSTANT... the whole 15 second pause is purely for dramatical effect. The very moment your phone connects in the msmtool and it hits 3%, it has already either PASSED or FAILED the AUTH SIGN requirement... which is LIGHT YEARS down the line from the Integrity Check.
Anyways my point is: If you go to you "appdata/local" msm folder, you shouold be able to pull ANY DLL that is being requested by your programs. The entire library is is locked exclusively to the GENERATION of flash tool available... ie version 4.1 folder will have DLL's for any 4.1.x.x msmtool ... same with version 5.1 => 5.1.x.x. While this is not a perfect science... it is a start, so if you run into any MSM tools that you download and are not able to run, it is because you dont have a full build from that series already installed on your machine. When these guys repack, they might not understand that by NOT packing up all the files DIRECTLY from that Appdata folder, and including ALL of the other folders, they are handicapping those who download them. Easier explanation to offer is this: Beatbreakee has been running Flash Tool v 4.1.7.2 on his machine, and it is the full build being launched from the APPDATA folder... CHRIS has been running 4.1.5.1 and its from an alternate location that DOES have the proper dll files, but they are already registered in his system from usage, and he does not realize that the alternate location is merely a shadow copy and that actual file is linking to his appdata folder.: A new HACKED msm tool comes out, but its a repack and lets say 4.2.0.1 (this is all fake... dont go looking for this hacked version , it dont exist) .... Now the repack is missing some vital DLL files, much like some of you are experiencing. The reason SOME can load and SOME cannot, is because they may have ran a FULL tool from the generation that the repack comes from.... if you have, then windows has already registered the correct DLL files, so it will load like normal.... if you HAVE NOT, you will get missing DLL errors. BUT BEWARE... There is a HIDDEN verification that is of the actual msmtool itself. It will cause you to fail , if the check does not pass, and when altering any portion of the msmtool, i have seen EVERY mod fail this check.
Oppo is smart... they placed PLAIN TEXT files that give the exact FILENAME, CRC, and SIG data for EVERY file that MSM will interact with INCLUDING ITSELF. But these plain text files are backdoor checked by encrypted SIGNED verification files, that check for any modifications to the plain text or xml files. If you alter one of the files or replace it... IT FAILS INSTANTLY... sha doesnt match... if you touch one of the SIG checker files it fails... MSMTool knows the SIG checkers, SIG... kinda a DOUBLE check... but they did this on purpose because they knew ppl would take the bait, and by doing so, thinking they will circumvent the CHECKS... they are actually making the checks work PERFECTLY. The ONLY way around this is through SOMEONE , who is great with DLL and EXE files... and can physically REMOVE or PATCH OUT the 2 checks for the application, as well as the fw integrity. Both validations work to ensure the OTHERS security as well... so if you bypass one validation, the other will fail you for "No validation" of the other file! (make any sense?) They watch each other when getting validated to see if any funny business is going on... any "Malarkey" and they will fail themselves to protect the package. You need to Remove, or patch out BOTH of these checks, which is slightly above my pay grade. If you can remove both of those, and it works, you will be able to have an MSM Tool that can have its config altered to remove model match, project id, and much more, as well as a tool that will accept ANY fw package as long as its in the correct structure. (That is where my info stops because saying more will put me in violation for now) ....
The SECOND bit of info is this:
The 'AUTH SIGN' is not a file generated from any server.... the connection to the server is simply to have it send a PING response back to the application from your phone. That is literally ALL the AUTH SIGN is... now its far more complex than im making it sound because i have yet to generate a valid AUTH but i am working on it. IT COMES from an APK Intent on your phone.... ( a hint is its one of the hidden QTI apk's) .... this apk responds to the PING request, with all of the info that is required as the AUTH .... Now dont get this confused with the MSM AUTH from the application.... The AUTH i am discussing is the one that says "YES" or "NO" when you ask the app to flash your fw.. An invalid response will trigger a NO... because the PING is an IRL stamp that cant be captured and replayed, as its literally specific to the millisecond... But again it is YOUR PHONE that is generating it.... so the MSM TOOL requires an AUTHENTICATED login, before it will communicate to the OPPO server, and tell it to send a PING request to your phone, which then gets sent via USB to your computer. What we have to do is figure out HOW to generate that PING request ourselves.... If we can somehow open a secondary command window, and freeze the process as soon as it requests the AUTH SIGN... then have the command to request the PING, already typed and ready to go in that second window.... and UNFREEZE at the exact same time as we send the command... we should be able to generate the request before the MSM Tool can revalidate itself, which it does before it makes the request. As long as the request is completed BEFORE the OFFICIAL request is made by the server, then it should ignore any other response.... 1st come 1st served.
Thats really all i can say... but sorry to all of you who have wondered if OPPO has made me disappear , or sent a wetwork agent after me... lol
I am just working round the clock on this as well as my normal life.... so i will be sporadic, but as i make breakthroughs i will update... so i hope SOME of that clears SOME things up.. but i leave you with this:
{ "d:193] [E2DBA579] [COM5] <COMMAND> <?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n<data>\n<getsigndata value=\"ping\" />\n</data>\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> INFO: Calling handler for getsigndata\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> WARN: format error, i=0\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> ERROR: cannot get oplusreserve1/opporeserve1. i" }
Its the actual full data from the application attempting to get the AUTH SIGN.... maybe looking over it you might find some insight.
***back to the caves.... see yall in a bit!****
(and btw.. if you attempt to bypass the LOGIN, you will automatically fail the SW integrity check... you need to find a way to REMOVE this completely, and not with a hex editor... the actual instruction must be removed, and then the subsequent request must be removed again from the actual FLASH function called during the AUTH SIGN request, because IT checks for the valid login again. Remove both and you will have an MSM TOOL with a blank slate. The tools themselves are NOT bundled with the individual FW digest data... they simply follow the instructions given in the packages. If you know what files you can and cannot alter, plus you replace the CRC in the checker file, with the NEW valid crc for the edited file, and you make sure to change the metadata of the files you altered , so that they match again with the other files besides them, you can FOOL the Package validation... <--- a key point in being able to flash altered firmware!... Package Validation Fail = Flash Fail!... Stay Vigilant"
beatbreakee said:
Sorry for the delayed absence .... lol.. its been a trivial one. But I have been working DILIGENTLY on Oneplus Tools, and ONLY Oneplus Tools... (CanuckKnarf can verify this...)
Ok without breaking "responsible disclosure" guidelines... I can hopefully either clear up some of the chatter ive read up til now, as well as provide some important info which may inspire someone here with a new avenue as to how to attack this thing head on.
Let me start with the most recent statements about the missing files first.
If you have Windows (doesnt matter which version) and you have been running ANY of the official builds of the MSM Tool... (Official releases show an icon like pictured here View attachment 5855327 #1
unofficial (repacked for whatever reason) look like this: View attachment 5855329 #2
Now while there is no inherent threat to either version... the ones of the LATTER style, MAY OR MAY NOT run, when attempting to execute them. This is because the person who packaged it, MIGHT NOT have been doing so from the actual applications data folder in windows. Allow me to explain:
When you run #1 , that file unpacks itself and generates a folder inside your "/users/appdata/local/" folder and its usually along the lines of "OPPO Flash Tool Series 4.1" .... or a variant of that. IN THIS FOLDER is the actual files for which your MSMTOOL loads all of its config, dll, and other run codes from.
--Now this folder might not be generated if you are already running from a complete msmtool build. a complete build should have several dll's, several folders, and the actual program that is being called, 'FTGUIDev.exe" <-- This is your flash loader! .. This is the Alpha and the Omega so to speak of the MSM TOOL... #2, is the MSM equivalent of a Windows Installer REPACK. I have seen these range from 4mb all the way up to 9gb ... this is because some authors choose to repack the EXACT FW build that is to be used with it! (*** Important note!*** The version of the MSM Tool you are using plays a definitive roll as to whether you have a successful flash, or a fail!. OPPO HAS PLAYED THE SNEAKY ROLE AGAIN, AND IN CERTAIN RELEASES OF THE OTA FW FILES THAT ARE DISTRIBUTED, THEY MAKE A SMALL CHANGE TO ONE OR MORE FILES, WHICH WILL THROW OFF THE FIRMWARE INTEGRITY CHECK!.... BUT INSTEAD OF THE ERROR READING "INTEGRITY FAIL", YOU WILL GET .... PHONE MISMATCH... INVALID HANDLE.... VALIDATION FAIL... OR MAYBE FAIL INTEGRITY.... <----- These errors USED to have individual meaning, but OPPO choose to use them to provide misdirection as to what actually occurred. (( I have found a way to FORGE a passing INTEGRITY CHECK... but i cant disclose that yet, sry)) So now they do not want you to actually have the identifier as to what exactly went wrong that blocked your flash... the validation check is INSTANT... the whole 15 second pause is purely for dramatical effect. The very moment your phone connects in the msmtool and it hits 3%, it has already either PASSED or FAILED the AUTH SIGN requirement... which is LIGHT YEARS down the line from the Integrity Check.
Anyways my point is: If you go to you "appdata/local" msm folder, you shouold be able to pull ANY DLL that is being requested by your programs. The entire library is is locked exclusively to the GENERATION of flash tool available... ie version 4.1 folder will have DLL's for any 4.1.x.x msmtool ... same with version 5.1 => 5.1.x.x. While this is not a perfect science... it is a start, so if you run into any MSM tools that you download and are not able to run, it is because you dont have a full build from that series already installed on your machine. When these guys repack, they might not understand that by NOT packing up all the files DIRECTLY from that Appdata folder, and including ALL of the other folders, they are handicapping those who download them. Easier explanation to offer is this: Beatbreakee has been running Flash Tool v 4.1.7.2 on his machine, and it is the full build being launched from the APPDATA folder... CHRIS has been running 4.1.5.1 and its from an alternate location that DOES have the proper dll files, but they are already registered in his system from usage, and he does not realize that the alternate location is merely a shadow copy and that actual file is linking to his appdata folder.: A new HACKED msm tool comes out, but its a repack and lets say 4.2.0.1 (this is all fake... dont go looking for this hacked version , it dont exist) .... Now the repack is missing some vital DLL files, much like some of you are experiencing. The reason SOME can load and SOME cannot, is because they may have ran a FULL tool from the generation that the repack comes from.... if you have, then windows has already registered the correct DLL files, so it will load like normal.... if you HAVE NOT, you will get missing DLL errors. BUT BEWARE... There is a HIDDEN verification that is of the actual msmtool itself. It will cause you to fail , if the check does not pass, and when altering any portion of the msmtool, i have seen EVERY mod fail this check.
Oppo is smart... they placed PLAIN TEXT files that give the exact FILENAME, CRC, and SIG data for EVERY file that MSM will interact with INCLUDING ITSELF. But these plain text files are backdoor checked by encrypted SIGNED verification files, that check for any modifications to the plain text or xml files. If you alter one of the files or replace it... IT FAILS INSTANTLY... sha doesnt match... if you touch one of the SIG checker files it fails... MSMTool knows the SIG checkers, SIG... kinda a DOUBLE check... but they did this on purpose because they knew ppl would take the bait, and by doing so, thinking they will circumvent the CHECKS... they are actually making the checks work PERFECTLY. The ONLY way around this is through SOMEONE , who is great with DLL and EXE files... and can physically REMOVE or PATCH OUT the 2 checks for the application, as well as the fw integrity. Both validations work to ensure the OTHERS security as well... so if you bypass one validation, the other will fail you for "No validation" of the other file! (make any sense?) They watch each other when getting validated to see if any funny business is going on... any "Malarkey" and they will fail themselves to protect the package. You need to Remove, or patch out BOTH of these checks, which is slightly above my pay grade. If you can remove both of those, and it works, you will be able to have an MSM Tool that can have its config altered to remove model match, project id, and much more, as well as a tool that will accept ANY fw package as long as its in the correct structure. (That is where my info stops because saying more will put me in violation for now) ....
The SECOND bit of info is this:
The 'AUTH SIGN' is not a file generated from any server.... the connection to the server is simply to have it send a PING response back to the application from your phone. That is literally ALL the AUTH SIGN is... now its far more complex than im making it sound because i have yet to generate a valid AUTH but i am working on it. IT COMES from an APK Intent on your phone.... ( a hint is its one of the hidden QTI apk's) .... this apk responds to the PING request, with all of the info that is required as the AUTH .... Now dont get this confused with the MSM AUTH from the application.... The AUTH i am discussing is the one that says "YES" or "NO" when you ask the app to flash your fw.. An invalid response will trigger a NO... because the PING is an IRL stamp that cant be captured and replayed, as its literally specific to the millisecond... But again it is YOUR PHONE that is generating it.... so the MSM TOOL requires an AUTHENTICATED login, before it will communicate to the OPPO server, and tell it to send a PING request to your phone, which then gets sent via USB to your computer. What we have to do is figure out HOW to generate that PING request ourselves.... If we can somehow open a secondary command window, and freeze the process as soon as it requests the AUTH SIGN... then have the command to request the PING, already typed and ready to go in that second window.... and UNFREEZE at the exact same time as we send the command... we should be able to generate the request before the MSM Tool can revalidate itself, which it does before it makes the request. As long as the request is completed BEFORE the OFFICIAL request is made by the server, then it should ignore any other response.... 1st come 1st served.
Thats really all i can say... but sorry to all of you who have wondered if OPPO has made me disappear , or sent a wetwork agent after me... lol
I am just working round the clock on this as well as my normal life.... so i will be sporadic, but as i make breakthroughs i will update... so i hope SOME of that clears SOME things up.. but i leave you with this:
{ "d:193] [E2DBA579] [COM5] <COMMAND> <?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n<data>\n<getsigndata value=\"ping\" />\n</data>\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> INFO: Calling handler for getsigndata\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> WARN: format error, i=0\n[2023/03/06 07:24:12][0x34c4][QCFirehose::resolveLogs:55] [E2DBA579] [COM5] <DEVICE LOG> ERROR: cannot get oplusreserve1/opporeserve1. i" }
Its the actual full data from the application attempting to get the AUTH SIGN.... maybe looking over it you might find some insight.
***back to the caves.... see yall in a bit!****
(and btw.. if you attempt to bypass the LOGIN, you will automatically fail the SW integrity check... you need to find a way to REMOVE this completely, and not with a hex editor... the actual instruction must be removed, and then the subsequent request must be removed again from the actual FLASH function called during the AUTH SIGN request, because IT checks for the valid login again. Remove both and you will have an MSM TOOL with a blank slate. The tools themselves are NOT bundled with the individual FW digest data... they simply follow the instructions given in the packages. If you know what files you can and cannot alter, plus you replace the CRC in the checker file, with the NEW valid crc for the edited file, and you make sure to change the metadata of the files you altered , so that they match again with the other files besides them, you can FOOL the Package validation... <--- a key point in being able to flash altered firmware!... Package Validation Fail = Flash Fail!... Stay Vigilant"
Click to expand...
Click to collapse
Thanks for all of the work you have been putting in! I will not give up hope lol, sorry I'm not a dev smart enough to help but I wish everyone luck...
beatbreakee said:
-snip-
Click to expand...
Click to collapse
Glad to see you still around, I was definitely in the boat of thinking someone shut ya down for good. Keep it up man, I'm sure as we rally we'll get there eventually.