InputMapper - Now supporting more devices and plugins.

[RedShadow]

To my knowledge this makes referring to your program as open source incorrect by definition, which you do in this thread.

I have read your posts and the first thing that surprised me was you mentioning the program was open source. I mean, I thought this fork was a closed source based on open source libs and stuff.

I would be interested in looking at the source as well, outta curiosity. But nowhere do I see a mention of "open source" nor is there a license.txt file or something.

Now about the security issue + salts that have to stay private: isn't it possible to put those data in a separate assembly, and keep its code private? We won't have a 'full' open source code then, but that way, the rest of the code could be open to the public.

DS4Tool isn't spellchecked properly which is unacceptable for adware IMO. First w in "Start with Windows" isn't capitalized and "Setings", seriously?

I reported those typos during the French translation. However, the 1.5 coding came up right after, and updating the 1.4 strings became less of a priority; I guess.

Also the program hinders screensavers when controller is started for no reason.

I never used a screensaver so far, so yeah this could be a problem/bug. I think this is because DS4Tools hooks on the keyboard events or something, which prevents screensaver.
What you can do in the meantime, is using the auto-disconnect feature. Maybe that will solve the issue.

When the program is stopped, LED always starts shining with bright white light, while I like it always being off and I set it the profile accordingly.

Correct me if I am wrong, but that's the standard DS4 behavior when plugged using USB, and when the battery is full. When plugged in USB and charging, mine is glowing red/orange. When closing the program and using Bluetooth the pad shuts off completely.
Anyway, this has nothing to do with DS4Tools; you said it yourself: the program is closed.

As a feature request, you should make a pop-up window appear when the profile is edited and user tries to go to another tab without saving changes.

I think this has been 'solved' in the 1.5 version -- which is a RC right now. Now it saves every time you leave a tab, I think.

You should definitely try the 1.5 version available there: http://1drv.ms/1qYPuq2

And finally, please be polite.
I have no idea why you seem so pïssed off bro. Remember that what is being done here is the work of a single man that chose to host the builds on his own server; hence the ads for the server cost.
The tool works and definitely provides awesome features that the previous forks didn't have. You should be totally grateful man.

Report what's wrong in a constructive manner, so it's a win/win for everyone.

Enjoy the 1.5 bro.

[jhebbel]

I have read your posts and the first thing that surprised me was you mentioning the program was open source. I mean, I thought this fork was a closed source based on open source libs and stuff.

I would be interested in looking at the source as well, outta curiosity. But nowhere do I see a mention of "open source" nor is there a license.txt file or something.

The early 1.4 builds were open source and it was mentioned a couple times in passing but not actually in any EULA or app description. This is simply because the early builds were based off of and essentially a continuation of Scarlet crushes original work which was released under EULA, but once I dumped his code and wrote my own stuff library by library it got to the point where I was no longer restricted by the GPL requirements

Now about the security issue + salts that have to stay private: isn't it possible to put those data in a separate assembly, and keep its code private? We won't have a 'full' open source code then, but that way, the rest of the code could be open to the public.

Its probably 50% a security concern, 30% GIT setup is an absolute nightmare to post code (see my earlier rants in the early stages in InhexSTEERs thread) and 20% Paranoia that is common in all developers, not to mention there is a considerable number of methods and classes that I grabbe out of my collection that iv written over the years that are part of actual enterprise licensed software that I developed under the DSDCS brand so Im not entire sure what the legality is of that, or if I should even be including them in my app at all (many clients are anal about using the same code across multiple projects). Additionally when you consider there would be absolutely nothing to stop someone from taking all the code i've been working on for a couple months, removing ad and donations requests and republishing under their own name thus making my fork completely trivial. Its happened many many time and with the tens of thousands of users that DS4W now has I have no doubt it would be entirely likely that there is 1 person that would do exactly that.

As far as putting the more "confidential" parts of the code in a separate library i'm not entirely sure how that would avoid the issue, or I'm misunderstanding

But all of the above aside, if a developer were to come up to me and say the were working on their own branch or from scratch distro and wanted to know how I did something say like macros... I would have no problem at all zipping up the entire macro class library from my latest version and sending it to them.

I reported those typos during the French translation. However, the 1.5 coding came up right after, and updating the 1.4 strings became less of a priority; I guess.

Yea, 1.4 is pretty much the bastard child not getting any attention anymore, if anybody spots any in 1.5 tho be sure to holler.

I never used a screensaver so far, so yeah this could be a problem/bug. I think this is because DS4Tools hooks on the keyboard events or something, which prevents screensaver.

I don't have this issue, but I rarely ever use my controller in a other than default config unless im testing something or filming a how to (which I need to get back to doing)

What you can do in the meantime, is using the auto-disconnect feature. Maybe that will solve the issue.


Correct me if I am wrong, but that's the standard DS4 behavior when plugged using USB, and when the battery is full. When plugged in USB and charging, mine is glowing red/orange. When closing the program and using Bluetooth the pad shuts off completely.
Anyway, this has nothing to do with DS4Tools; you said it yourself: the program is closed.

it is for the most part but it was an odd request that I received earlier that when DS4 was forcefully removed the DS4 would take it upon itself to turn whit (this is what you refer to as the normal condition) but earlier versions as well as SC's and Inhex's versions when the application was stopped gracefully the last thing it would do is turn off the controller lightbar (though this did not always mean the controller was actually off)

The white light is probably a good thing because it is an indication that even though the controller is disconnected, it might actually still be on.

I think this has been 'solved' in the 1.5 version -- which is a RC right now. Now it saves every time you leave a tab, I think.

You should definitely try the 1.5 version available there: http://1drv.ms/1qYPuq2

there is still a save button, didn't want to overload the live update that happens behind the scenes too much as well as back up the file queue with locking requests.

And finally, please be polite.
I have no idea why you seem so pïssed off bro. Remember that what is being done here is the work of a single man that chose to host the builds on his own server; hence the ads for the server cost.
The tool works and definitely provides awesome features that the previous forks didn't have. You should be totally grateful man.

Report what's wrong in a constructive manner, so it's a win/win for everyone.

Enjoy the 1.5 bro.

well put

[jhebbel]

Crash.log:

Prosessen får ikke tilgang til filen E:\Appdata\Roaming\DS4Windows\Profiles\Desktop.xml fordi den brukes av en annen prosess. (Void WinIOError(Int32, System.String) in mscorlib) []
ved System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
ved System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
ved System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
ved DS4Control.ProfileHandler.LoadProfile.GetByName(String ProfileName)
ved DS4Control.BackingStore.LoadProfile(Int32 device)
ved DS4Control.Global.ProfileUpdate(Object sender, String ProfileName)
ved DS4Control.Global.ProfileUpdatedEvent(Object sender, FileSystemEventArgs e)
ved System.IO.FileSystemWatcher.OnChanged(FileSystemEventArgs e)
ved System.IO.FileSystemWatcher.NotifyFileSystemEventArgs(Int32 action, String name)
ved System.IO.FileSystemWatcher.CompletionStatusChanged(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* overlappedPointer)
ved System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

19.09.2014 15:33:18> DS4Windows.exe Information: 0 : Starting...
19.09.2014 15:33:18> DS4Windows.exe Information: 0 : Searching for controllers....
19.09.2014 15:33:18> DS4Windows.exe Information: 0 : Using Exclusive Mode
19.09.2014 15:33:18> A4:15:66:6E:FB:BE device start
19.09.2014 15:33:19> DS4Windows.exe Information: 0 : Found Controller: A4:15:66:6E:FB:BE (BT)
19.09.2014 15:33:19> DS4Windows.exe Information: 0 : Controller 1 is using Profile "[Default]"
19.09.2014 15:33:19> A4:15:66:6E:FB:BE power subsystem octet: 0x07
19.09.2014 15:33:33> Saving
19.09.2014 15:35:30> Saving

Looks like a file locking issue, ill up the attempt count and see if that fixes in todays release.

[RedShadow]

As far as putting the more "confidential" parts of the code in a separate library i'm not entirely sure how that would avoid the issue, or I'm misunderstanding

Yeah, I meant to put all the sensitive stuff into a specific assembly, and hence in a separate .cs file. This one (or those) won't be pushed into the public GIT branch.

Or, you could even go further and create a separate project in Visual Studio that would host only those sensitive parts. That way it's easier to manage GIT too, as the sensitive files are not physically in the same project, and so, not in the same folder sub-structure.
That was just an idea.

But yeah, corporate code stuff inside your own project... I had the same problem, actually my own personal project libs reused into a corp project lol. But I didn't tell anyone
I have no idea how to deal with that.

So, lets make things clear:
DS4Windows, your fork, will not be Open Source. A least, not anytime soon.

The only parts that are open source are the ones from the early 1.4 versions, as the code was so similar to the old forks -- which were under GPL -- that these files/piece of code had to be GPLed as well and public.

Which is not the case anymore, so many modifications have been made to these parts that they are considered totally new and unrelated; thus they aint under GPL anymore.

[jhebbel]

Yeah, I meant to put all the sensitive stuff into a specific assembly, and hence in a separate .cs file. This one (or those) won't be pushed into the public GIT branch.

Or, you could even go further and create a separate project in Visual Studio that would host only those sensitive parts. That way it's easier to manage GIT too, as the sensitive files are not physically in the same project, and so, not in the same folder sub-structure.
That was just an idea.

But yeah, corporate code stuff inside your own project... I had the same problem, actually my own personal project libs reused into a corp project lol. But I didn't tell anyone
I have no idea how to deal with that.

So, lets make things clear:
DS4Windows, your fork, will not be Open Source. A least, not anytime soon.

The only parts that are open source are the ones from the early 1.4 versions, as the code was so similar to the old forks -- which were under GPL -- that these files/piece of code had to be GPLed as well and public.

Which is not the case anymore, so many modifications have been made to these parts that they are considered totally new and unrelated; thus they aint under GPL anymore.

Correct for the most part, though I don't use the term anymore, I do still kinds of consider it open source as if people want parts of it I have no problem giving it to them. Even the GPL states the code does not have to be internet accessible, just available upon request, to be clear this is not GPL though just using it as a comparison.

The SCP Virtual bus drivers are however still fully GPL and unchanged by me and can be accessed from SC's thread.

[roli]

Looks like a file locking issue, ill up the attempt count and see if that fixes in todays release.

Okay thanks

[GeneralFailer]

The early 1.4 builds were open source and it was mentioned a couple times in passing but not actually in any EULA or app description.

There is literally no EULA though. I'd understand if it was only missing in the installation folder, but even installer of RC version just says "Your license agreement should go here!". With all the past statements all this becomes very confusing.

it is for the most part but it was an odd request that I received earlier that when DS4 was forcefully removed the DS4 would take it upon itself to turn whit (this is what you refer to as the normal condition) but earlier versions as well as SC's and Inhex's versions when the application was stopped gracefully the last thing it would do is turn off the controller lightbar (though this did not always mean the controller was actually off)

The white light is probably a good thing because it is an indication that even though the controller is disconnected, it might actually still be on.

You should really consider to make this optional. The light can be very annoying to some people.

When you stop supporting the old versions you should at least put the link for a newer one marked as unstable in the original post to avoid confusion and dublicate bug reports.
1.5 seems to be really buggy so far for a release candidate. The biggest problem so far is that it completely ignores disabling lightbar. Also "Start With Windows" now has too much capitalized w's, typo "Enabe Web Service", Tools and Help menus don't work at all.

[roli]

@jhebbel how long do you think it will be until the official 1.5 release? Is the only thing that you're missing macro's?

[jhebbel]

@jhebbel how long do you think it will be until the official 1.5 release? Is the only thing that you're missing macro's?

Macros and a couple localization bugs as you have been pointing out, otherwise 1.5 is ready to go I think.

[jesalvein]

There is literally no EULA though. I'd understand if it was only missing in the installation folder, but even installer of RC version just says "Your license agreement should go here!". With all the past statements all this becomes very confusing.
You should really consider to make this optional. The light can be very annoying to some people.

When you stop supporting the old versions you should at least put the link for a newer one marked as unstable in the original post to avoid confusion and dublicate bug reports.
1.5 seems to be really buggy so far for a release candidate. The biggest problem so far is that it completely ignores disabling lightbar. Also "Start With Windows" now has too much capitalized w's, typo "Enabe Web Service", Tools and Help menus don't work at all.

Does it wrap Ds4 entries to xinput, or not ?