Hi guys, the past while I was trying to find good comparisons between these two models of dd's. Has anyone tested both ? I understand that the software for these aren't complete yet but is there any clear winner here ? thanks.
Mika, you need to revisit your GD forum membership policy and put some age restriction, as based on overwhelming negative response to that initiative there and your own poll result, it must be full of "old grumpy" individuals resisting "technical progress".
Next thing you know, they'll integrate Facebook/Google sign on for the online profiles and that's when you'll know someone's jumping the shark.
Why even host such a poll
Nice, now the community is just brainless parrots repeating whatever somebody else said with no ability to draw any conclusions on their own. Oh, yeah, they are also "old and grumpy", with all that stuff just "in their heads".I agree, it was a bad idea to do, and was partly done by myself due to the heated discussion where people seemed to be parrots and just repeating the bad opinions all over again.
It seems that it is not possible to get actual constructive feedback on any forum these days.
Hi all,
It seems the same people are going over the same discussion here as well, with people fearing that the new system is somehow worse to use than the current one, which it is not.
Firstly, I've been using the new online system for quite a while now. It is a breeze to use and certainly works well, but fine tuning needed....
On the general topic of sharing of profiles:
Reasons why we built the system, is that even if we have the template profiles in the software like they are in the existing version, people are continuing to ask, request and share profiles in forums, Facebook groups and sometimes even directly by email from us. So it is a very proven observation that Simucube users - and user of other wheel bases as well - have a natural need to try out settings, especially settings from other people.
- This is true even if they know what each and every filter slider / adjustment does.
- It is also true when the do not - they just want to have that profile that should feel good, and once they find such a profile and try it out, they are generally happy with it with maybe some minor adjustments.
- This is true even if we had managed to find the time to update the included profiles at the right pace, and finding that time has proven to be problematic. The template profiles we have in the software now, were just profiles that got substantial amount of likes on our own forum. The online system allows for one-click solution to users to do exactly that, without any manual steps at all. It makes daily usage of the product much easier for exactly those users who ask&post settings on the forums.
There was no good format to share the profiles. Sharing ini files is not exactly user friendly way to do it, and neither are screenshots.
Conclusion: Integrated easy to use system is required and will be well received by many.
Develoment based reasons:
The firmware code to manage profiles and the PC software code that manages the profiles are pretty much in need of a complete rewrite anyway. It is based on code that was written several years ago and it is overly complicated to maintain right now. The logical thing to do would be the cheapeast option - rewrite it exactly like it is now, but as a result it would not be at all visible to the user. Therefore, if we want to take the step to improve it, it is better to take a large step now than to make minor adjustment by staying "within the box". Building it as a modern web app has a drawback at the start - it has to live on a server/cloud somewhere. However, the world is going towards web technology based desktop software - that is, programs that are actually lightweight web servers running on your own computer. This kind of user interface design is certainly a very attractive option. Moving on to that kind of platform will necessitate a web app based profile management anyway. And while most known apps that have moved on to use this kind of development are Discord and Spotify, there is for example Visual Studio Code that has been made with the same application framework - so this web app based approach does not mean that the system will be somehow only online system requiring constant web connection after a few updates. And I must say we have no plans to go to new application framework right now, but it could be done in the future.
Conclusion: Improvement must be done, and sometimes taking a giant leap is better than a small one.
Ease of use
There are repeated requests from us to make the system easier to use. Not many people are seeing these on forums etc, because people are not using forums! This issue becomes evident in real-life sales situations where some potential customer now gets to see so many sliders and adjustments right away, while our competitors have just 3-4 sliders and simplified filters. At that point those potential customers do not know the details on how FFB can and should be adjusted to each driver's personal liking, and where a broader range off achievable feel, if one puts it that way, is a good thing and a major advantage of our product. Having industry leading FFB feel is something we intend to keep by adding features and more advanced FFB processing. We certainly want to make the Simucube 2 product easier to use, but we definitively do not want to take any features away from the advanced users. I consider myself an advanced user, and so far we haven't changed anything that would have changed my daily usage of the product in any way. Having an easy system to get a driver started by just a few mouse clicks is a major improvement.
On the topic of requiring Internet connection:
When we posted the announcement last week, the plan was to have the first closed beta, the public beta and the first release version built in such a way, that users would be able to fall back to use the old profile management system exactly as it is now. So there is no near-term fear of Simucube 2 going only online. We also have seen the amount of unsubstantiated fear that we would go to only online system after also stating that we would listen to the feedback and develop a fallback option.
However, if you see the above "Development based reasons" text, the fallback has to change to get rid of legacy code, so that we will not have to maintain two complete management systems. This means, that the fallback option, in the long term, is going to mean these things:
- No profiles stored on the device flash memory
- Cached profiles from the online system are stored on the PC, and new profiles to that cache can be created too while in the fallback offline mode. Both can be edited offline, but I do not see a good way to sync the edited online profiles back to the online system without adding complex management code.
These changes, compared to the current system where the profiles are stored in the device flash memory, are going to be almost 100% transparent to the user. However the focus is now to get the first public version to testing, and the end-state fallback solution, while designed in principal already, is not going to be developed right away. That fallback feature (offline store) would have to be redone anyway if we ever ditch the Qt application framework and C++ and switch to some other framework, so it is cost effective to design it to be quick to build without as much complex options as the current management system.
About misconceptions
Then, we were asked on our forum about a subscription system, and one from our company gave an honest answer on how it could be seen and in what kinds of situations it could really be a good thing. HOWEVER some people (who are also on this forum as well) wrongly read it to mean that we actually are planning or even implementing such a system. This is simply not true.
But fear of something new is natural to human being.
Feedback
We got very little feedback on actual system we showed in the crude screenshots. This was not intended as we'd like as much actual constructive feedback as possible, but it seems it is not possible via the forum thread that begins with people having unsubstantiated fears that do not relate to actual functionality of the system. We already got much better feedback on Facebook via private messages, but I'm willing to give forums another chance, thats why I joined here as well.
* Newcomers will have issues regardless. They want to learn and will ask and at some point we all get it.
* Settings are worthless without in game settings coming with them.
* A complete rewrite is always a mistake. It seems you want to learn that again, since you must be aware.
* You were going fully online in the 1st version, did you redecide based on valuable Facebook feedback?
That is true, and we are not somehow trying to remove that role from the community, be it on our forum, this forum, or otherwise.
I agree. This is why there is a field to write in in-game settings values when publishing the profile for others to use. Later on, we might read this from game files or such clever things - and storing game configurations is not really possible in the device flash memory, so another means to store profile data would be needed.....
No it is not. Moving stuff around and rewriting things does take a bit of time, but then it will pay back the time later via much easier development, and will enable us to more efficiently develop both the filters, and the firmware and PC-side software/drivers later. We are strengthening the development team right now, and a rewrite of some stuff at this point really is a necessary step.
No, it was put back on table to based on the community's valued feedback. However, did the community change to give actual constructive feedback regarding the new system when it was announced that their feedback was noted? no, and thats why the thread was closed.
There were some very good suggestions on how to retain existing functionality while giving optional non intrusive online access to community profiles or even make existing predefined profiles synced to the cloud.However, did the community change to give actual constructive feedback regarding the new system when it was announced that their feedback was noted? no, and thats why the thread was closed.
Are you saying that fallback method is some sort of local service running embedded tomcat? Disappointing and shortsighted, you are just shoehorning your always online solution instead of making offline primary as it should for a hardware device and use online as a secondary, non mandatory option.we just move the web app to run locally
first closed beta, the public beta and the first release version built in such a way, that users would be able to fall back to use the old profile management system exactly as it is now. So there is no near-term fear of Simucube 2 going only online.
the fallback option, in the long term, is going to mean these things:
- No profiles stored on the device flash memory
- Cached profiles from the online system are stored on the PC, and new profiles to that cache can be created too while in the fallback offline mode. Both can be edited offline, but I do not see a good way to sync the edited online profiles back to the online system without adding complex management code.
These changes, compared to the current system where the profiles are stored in the device flash memory, are going to be almost 100% transparent to the user.
You don’t need to. Pop up a disclaimer box and let users know that once a profile is edited offline, you’ll need to recreate it for online use.Andrew, I guess you didn't read my previous post about how the fallback...
Both can be edited offline, but I do not see a good way to sync the edited online profiles back to the online system without adding complex management code.
May be, when I read "web app running locally" some sort of local web container is the only thing that popped in my mind, how else can you run app in browser.Andrew, I guess you didn't read my previous post about how the fallback option will be in short term and in long term. The above was an option for the performance related improvement for the online-based profile management.