Hello!
I have a new suggestion. Okay, basically i have made a script with Autohotkey that first starts a specific DxWnd.ini and afterwards the game.exe. Command Lines in DxWnd are already great and very helpful, but what i missing here is an option for no Tray Icon at all. You have already the Batch Command /q to have DxWnd in a Quiet Mode which is perfect. And when the game exits, the script automaticly makes the /E command so that it exits DxWnd. All in all it´s just missing a completly Tray Icon Hide to really function as a Quiet Function.
Can this please be added?
Thank you very much.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason behind the choice of running in the icon tray is to provide a comfortable way to terminate DxWnd in case something went wrong.
The problem is that only one instance of the DxWnd process can run at a time, so there is a lock semaphore to prevent multiple runs. But if for any reason the DxWnd.exe process stays alive and hidden, the only way to start another DxWnd session would be to kill the previous instance with task manager or by command prompt using DxWnd.exe /e.
I can do the change you requested, if you have scripts to run DxWnd I guess you could also handle its termination.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello again. :)
I don´t want to rush you, gho. But i just wanted to know in which possibility there will it be to hide the Tray Icon? Will it be from a Command Line, will it be an Option inside DxWnd to permanent hiding the icon or will it be both ways? When it will be an Command Line, do you already know which command you will using for it?
Personally i would prefer the option inside DxWnd Method over the others.
I just need to know so i can finish my Autohotkey Script for launching Games.
Last edit: Kataah 2018-05-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was trying both options, though because of a series of personal troubles I had really no time to go much further. The option in the DxWnd GUI should be somehow possible, I recall it was a side effect of a change I tried some month ago and I should remember what I did in that situation.
Even more interesting, the possibility to use a dedicated command line tool. The idea is to take DxWnd.exe and wipe away everything (code, resources etc.) is related to the GUI.
The good news is that either ways the usage won't be much different: in the GUI case you'll have to use the usual /T flag plus some more to hide the icon in the tray. In the command line case you'll have pretty much the same syntax, but a different executable (I thought "dxwndd.exe for DxWnd daemon could be appropriate).
But as I said unfortunately in this period I really have little time and no focus on these matters. I hope a better time will come soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made a happy experiment, this one (a very small change in the DxWnd.exe GUI) seems to work. I have no time to test it thoroughfully, you may do it.
Use the attached DxWnd.exe as usual, with /R:n option, and add a /x last option. This should make the icon tray invisible. But if you don't run in transient mode DxWnd.exe will stay running after the game termmination, so you'll have to run DxWnd.exe /e to kill it afterwards.
This reminds me that both the new /x and old /e options should find some space in the html help.
It´s all working.
The termination at the end is no problem. My Autohotkey Script is waiting for Games Process and then after it, it kills the DxWnd Process automatic.
So right now i´m using
dxwnd.exe -c:".\Ini\Test.ini" /x /q /h
before a game starts. All is working okay. Thank you.
PS: Will this "/x" also the final command for that icon hiding command? Again, just asking so i can finish the script. :)
Last edit: Kataah 2018-05-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes. All better values were used already.
I have a few ideas, but tyhese should not affect your scripts:
1) make the /x option to auto-kill an existing DxWnd program (maybe only when idle!)
2) test if the transient mode still works with /x option (I hope so...)
P.s. your script example is ok only when the game does not require early hooking, otherwise you should run the game from DxWnd, that is use the /r:n option.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2018-05-05
Last edit: Anonymous 2018-05-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What exactly do you mean with "early hooking"? I have some games where the DxWnd hooking fails and i do not know why. If i start DxWnd itself before launching the script, it works. So i thought to myself that maybe the game starts too early/fast to be hooked in DxWnd. So i added as a test a 3 seconds timer in my script between DxWnd Start and the game Start.
But strangely this didn´t helped (it also didn´t get hooked)?!?
With that thing above in which you said that i should run the game from inside DxWnd could also not be the solution. Because the game will be hooked too if i run the game directly when i click the games exe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use the "early hooking" term to shorten the two possible hook flags either "Debugger mode" or "Inject suspended process".
These two modes have in common the hooking at the very beginning of the game run, while the default hook "SetWindowsHook" only takes place later on when the game opens the first window. Usually the game opens a window quite soon, so there's no big difference, but sometimes in between the game start and the window open something crytical may happen (like checking for Windows version, or available free memory just to make two examples) so the game may crash before DxWnd has a chance to fix things. So, this is why these two modes are called "early": they make the hooking happen before, but the price to pay is that they work only when the game is run (that is, executed) by DxWnd itself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry in advance.
I understand somewhat what you want to describe here, but still don´t get it completly. But please don´t be mad at me. :)
I explain why this early hooking doesn´t make sence to me.
Before i used the game with the command line to launch DxWnd before, i actually had DxWnd always running in the background. The games in it where configed like this:
Name:
Juiced
Path:
*\Juiced.exe
So, you see that i always had the relative exename for the games No real Path or something. I know, this could be bad for a program with a similar exe name, but since i had not this case yet. Anyways, whenever i launched the game "Juiced" from a normal shortcut (lnk) in the explorer, DxWnd immideatly saw the process and did it´s stuff to make the game windowed. This all works flawlessy because the names were relative and so i could start my game anywhere and it would still be hooked.
Maybe you saw the other thread from me that i reached the limit of Game Entrys in DxWnd. This lead me to having a Autohotkey script which launches DxWnd 10 seconds BEFORE the game exe launches.
So in the end this should be the same situation as i had it in the method before. Except that DxWnd is not running all the time in the background, and only launching before the game. And this 10 seconds is not enough for the early hooking?
PS: Did you mean something else with your post above that i should add some other flaggs?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think we have 2 different issues. Let's try to keep them apart.
1) asterisked names are ok as long as you don't run the game by DxWnd and use default hooking. Since this is exactly what you do, it is not a problem. I was only warning you that someday you may find a game that will require a different setting and this won't work with your frontend. It's not a problem today.
2) You said "Except that DxWnd is not running all the time in the background". This is weird, and 10 seconds are plenty of time for DxWnd to startup, so I guess there must be some error that crashes DxWnd after its launch. If you set "debug mode" in Global Settings panel (or edit dxwnd.ini and add a line with "debug=1" in [window] section) and DxWnd runs in a folder with write permission you could find some log in the dxwnd.log file in the DxWnd folder (not the game folder!).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can´t see any problems or errors in the log. I even made sure that DxWnd will not be killed from the script. Instead i exited it like normal to be sure to have a clean log.
Here, i attached a simplified version of my AHK-Script. I hope you can read the AHK Language.
Maybe you find something that´s weird. But i know that the script is okay, because with other games the DxWnd hooking works flawlessy. I even tested that with a 10 seconds timer before starting the game to give DxWnd enough time. But you will see.
I attaching the AHK Script and the Game config that´s for the script.
sorry for revive this, but I downloaded and I'm getting this error:
ORDINAL NOT FOUND. THE ORDINAL 12COULD NOT BE LOCATED IN THE DYNAMIC LINK LIBRARY dxwmd.exe
any idea? thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the message should refer to the dynamic link library dxwnd.dll, isn't it?
The entry #12 was added to the library many releases ago to provide dynamic support to custom renderers. The message almost surely means that a newer DxWnd.exe executable is trying to link with a very old dxwnd.dll dynamic library. Check in your file system, probably you will find some old dxwnd.dll that shouldn't be there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
I have a new suggestion. Okay, basically i have made a script with Autohotkey that first starts a specific DxWnd.ini and afterwards the game.exe. Command Lines in DxWnd are already great and very helpful, but what i missing here is an option for no Tray Icon at all. You have already the Batch Command /q to have DxWnd in a Quiet Mode which is perfect. And when the game exits, the script automaticly makes the /E command so that it exits DxWnd. All in all it´s just missing a completly Tray Icon Hide to really function as a Quiet Function.
Can this please be added?
Thank you very much.
The reason behind the choice of running in the icon tray is to provide a comfortable way to terminate DxWnd in case something went wrong.
The problem is that only one instance of the DxWnd process can run at a time, so there is a lock semaphore to prevent multiple runs. But if for any reason the DxWnd.exe process stays alive and hidden, the only way to start another DxWnd session would be to kill the previous instance with task manager or by command prompt using DxWnd.exe /e.
I can do the change you requested, if you have scripts to run DxWnd I guess you could also handle its termination.
That would be great if you could implent this.
Hello again. :)
I don´t want to rush you, gho. But i just wanted to know in which possibility there will it be to hide the Tray Icon? Will it be from a Command Line, will it be an Option inside DxWnd to permanent hiding the icon or will it be both ways? When it will be an Command Line, do you already know which command you will using for it?
Personally i would prefer the option inside DxWnd Method over the others.
I just need to know so i can finish my Autohotkey Script for launching Games.
Last edit: Kataah 2018-05-01
I was trying both options, though because of a series of personal troubles I had really no time to go much further. The option in the DxWnd GUI should be somehow possible, I recall it was a side effect of a change I tried some month ago and I should remember what I did in that situation.
Even more interesting, the possibility to use a dedicated command line tool. The idea is to take DxWnd.exe and wipe away everything (code, resources etc.) is related to the GUI.
The good news is that either ways the usage won't be much different: in the GUI case you'll have to use the usual /T flag plus some more to hide the icon in the tray. In the command line case you'll have pretty much the same syntax, but a different executable (I thought "dxwndd.exe for DxWnd daemon could be appropriate).
But as I said unfortunately in this period I really have little time and no focus on these matters. I hope a better time will come soon.
I made a happy experiment, this one (a very small change in the DxWnd.exe GUI) seems to work. I have no time to test it thoroughfully, you may do it.
Use the attached DxWnd.exe as usual, with /R:n option, and add a /x last option. This should make the icon tray invisible. But if you don't run in transient mode DxWnd.exe will stay running after the game termmination, so you'll have to run DxWnd.exe /e to kill it afterwards.
This reminds me that both the new /x and old /e options should find some space in the html help.
Last edit: gho 2018-05-01
It´s all working.
The termination at the end is no problem. My Autohotkey Script is waiting for Games Process and then after it, it kills the DxWnd Process automatic.
So right now i´m using
dxwnd.exe -c:".\Ini\Test.ini" /x /q /h
before a game starts. All is working okay. Thank you.
PS: Will this "/x" also the final command for that icon hiding command? Again, just asking so i can finish the script. :)
Last edit: Kataah 2018-05-01
Yes. All better values were used already.
I have a few ideas, but tyhese should not affect your scripts:
1) make the /x option to auto-kill an existing DxWnd program (maybe only when idle!)
2) test if the transient mode still works with /x option (I hope so...)
P.s. your script example is ok only when the game does not require early hooking, otherwise you should run the game from DxWnd, that is use the /r:n option.
Last edit: Anonymous 2018-05-05
What exactly do you mean with "early hooking"? I have some games where the DxWnd hooking fails and i do not know why. If i start DxWnd itself before launching the script, it works. So i thought to myself that maybe the game starts too early/fast to be hooked in DxWnd. So i added as a test a 3 seconds timer in my script between DxWnd Start and the game Start.
But strangely this didn´t helped (it also didn´t get hooked)?!?
With that thing above in which you said that i should run the game from inside DxWnd could also not be the solution. Because the game will be hooked too if i run the game directly when i click the games exe.
I use the "early hooking" term to shorten the two possible hook flags either "Debugger mode" or "Inject suspended process".
These two modes have in common the hooking at the very beginning of the game run, while the default hook "SetWindowsHook" only takes place later on when the game opens the first window. Usually the game opens a window quite soon, so there's no big difference, but sometimes in between the game start and the window open something crytical may happen (like checking for Windows version, or available free memory just to make two examples) so the game may crash before DxWnd has a chance to fix things. So, this is why these two modes are called "early": they make the hooking happen before, but the price to pay is that they work only when the game is run (that is, executed) by DxWnd itself.
Sorry in advance.
I understand somewhat what you want to describe here, but still don´t get it completly. But please don´t be mad at me. :)
I explain why this early hooking doesn´t make sence to me.
Before i used the game with the command line to launch DxWnd before, i actually had DxWnd always running in the background. The games in it where configed like this:
Name:
Juiced
Path:
*\Juiced.exe
So, you see that i always had the relative exename for the games No real Path or something. I know, this could be bad for a program with a similar exe name, but since i had not this case yet. Anyways, whenever i launched the game "Juiced" from a normal shortcut (lnk) in the explorer, DxWnd immideatly saw the process and did it´s stuff to make the game windowed. This all works flawlessy because the names were relative and so i could start my game anywhere and it would still be hooked.
Maybe you saw the other thread from me that i reached the limit of Game Entrys in DxWnd. This lead me to having a Autohotkey script which launches DxWnd 10 seconds BEFORE the game exe launches.
So in the end this should be the same situation as i had it in the method before. Except that DxWnd is not running all the time in the background, and only launching before the game. And this 10 seconds is not enough for the early hooking?
PS: Did you mean something else with your post above that i should add some other flaggs?
I think we have 2 different issues. Let's try to keep them apart.
1) asterisked names are ok as long as you don't run the game by DxWnd and use default hooking. Since this is exactly what you do, it is not a problem. I was only warning you that someday you may find a game that will require a different setting and this won't work with your frontend. It's not a problem today.
2) You said "Except that DxWnd is not running all the time in the background". This is weird, and 10 seconds are plenty of time for DxWnd to startup, so I guess there must be some error that crashes DxWnd after its launch. If you set "debug mode" in Global Settings panel (or edit dxwnd.ini and add a line with "debug=1" in [window] section) and DxWnd runs in a folder with write permission you could find some log in the dxwnd.log file in the DxWnd folder (not the game folder!).
This is so strange.
The only thing that´s in the log is this here:
Init ClearType=1
Init FontSmoothing=1
Init FontSmoothingContrast=1200
Init FontSmoothingOrientation=1
Init FontSmoothingType=2
Init StickyKeys=2
Init ToggleKeys=2
Init FilterKeys=2:0:0:0:0
joystick initial deadzone = 5%
I can´t see any problems or errors in the log. I even made sure that DxWnd will not be killed from the script. Instead i exited it like normal to be sure to have a clean log.
Here, i attached a simplified version of my AHK-Script. I hope you can read the AHK Language.
Maybe you find something that´s weird. But i know that the script is okay, because with other games the DxWnd hooking works flawlessy. I even tested that with a 10 seconds timer before starting the game to give DxWnd enough time. But you will see.
I attaching the AHK Script and the Game config that´s for the script.
Last edit: Kataah 2018-05-11
sorry for revive this, but I downloaded and I'm getting this error:
ORDINAL NOT FOUND. THE ORDINAL 12COULD NOT BE LOCATED IN THE DYNAMIC LINK LIBRARY dxwmd.exe
any idea? thanks!
I think the message should refer to the dynamic link library dxwnd.dll, isn't it?
The entry #12 was added to the library many releases ago to provide dynamic support to custom renderers. The message almost surely means that a newer DxWnd.exe executable is trying to link with a very old dxwnd.dll dynamic library. Check in your file system, probably you will find some old dxwnd.dll that shouldn't be there.
ok, I was using an old dxwnd version, updated to the last one which is working perfect without explorer.exe, with /r /x /T