Jump to content
dgeesio

Mouse acceleration = NO!

Recommended Posts

Sigh... in the end, pointless thread is pointless. If the Devs wanted the mouse acceleration gone, it would be.

 

That argument doesn't work. I'm sure the devs want all the other bugs gone too.

  • Like 3

Share this post


Link to post
Share on other sites

The major problem is that the acceleration in it's current state is inversely-proportional and moves your cursor faster the slower you move your hand. Wrong and counter-intuitve.

A minor bit of properly-implemented positive acceleration I could just about live with. But would prefer disable acceleration option.

Share this post


Link to post
Share on other sites

That argument doesn't work. I'm sure the devs want all the other bugs gone too.

How is mouse acceleration a bug?

Share this post


Link to post
Share on other sites

Sigh... in the end, pointless thread is pointless. If the Devs wanted the mouse acceleration gone, it would be.

whats pointless about it ? cause you think its pointless?

  • Like 1

Share this post


Link to post
Share on other sites

Sigh... in the end, pointless thread is pointless. If the Devs wanted the mouse acceleration gone, it would be.

 

It isn't a pointless thread, it is letting them know that we want it gone, even if they do not. How will they know if they have the controls right without players stating whether it is good or not?

 

Personally, I feel there are bigger fish to fry than trying to work on detailed mouse movement that players would prefer gone anyway. I'm not going to complain if they come up with a truly realistic movement system (though I don't think it is possible with a mouse and keyboard). However, if I move just like a real person, but have no vehicles, zombies that work right, base building mechanics, or any number of other things, I would be pretty disappointed.

 

But to be clear, as I've stated multiple times, I'm not ready to leave the "it's alpha" behind for at least a few more months. Development takes time and generally builds from very few patches, to a constant stream of patches with features.

 

So my comments are just a "I'd rather them not waste time with something that I don't want and don't believe will work the way they want it to work in the end".

Share this post


Link to post
Share on other sites

Development takes time and generally builds from very few patches, to a constant stream of patches with features.

 

That's actually the exact opposite of how development works.

Share this post


Link to post
Share on other sites

That's actually the exact opposite of how development works.

 

I've been doing this for two decades. Yes, it is how development works if you are working Agile and only releasing at stable points.

Share this post


Link to post
Share on other sites

I've been doing this for two decades. Yes, it is how development works if you are working Agile and only releasing at stable points.

Oh sorry I didn't know you'd been wrongly assuming facts on subjects you clearly have no knowledge of for multiple decades now

Share this post


Link to post
Share on other sites

Oh sorry I didn't know you'd been wrongly assuming facts on subjects you clearly have no knowledge of for multiple decades now

 

When you begin a development project, particularly one where you have multiple branches of the code-base, you run development of features over iterations or sprints. The results of these sprints are often only small features that can be seen end-to-end (a player can see on stable) and cumulative work that is held out of the stable branch as it isn't ready for player consumption. As you run these parallel threads of development, they all get closer and closer to done, so once these start being stable enough for merging in to the stable branch, you get dependent features merging in more quickly, and eventually get a nice pace of features being pushed out.

 

A development shop pushing out huge amounts of features right at the beginning and tapering down, as you suggested, is one that is going completely market driven and pushing to be the first out, not focusing on a stable and finished product. It happens, sometimes makes business sense, but isn't how you develop an off-the-shelf purchase-once product. That sort of development usually requires a recurring revenue model to sustain the continuous stabilizing patches that need to be produced after release.

Share this post


Link to post
Share on other sites

I think its a weird Bug. Some experience extremely pain-In-the-arse controls, for other it works pretty fine. Probably has to do with Different mouses and bad sensitivity confoguration from the devs side. I personally tried everything and nothing helped.

Share this post


Link to post
Share on other sites

Oh sorry I didn't know you'd been wrongly assuming facts on subjects you clearly have no knowledge of for multiple decades now

 

hahahaha, so now you're specialist about developing too? how much specializations do you have? first you tell an army veteran that he know nothing about handling guns, now you tell someone that's been working on developing for two decades that he knows nothing about developing.

 

You must be the new einstein, dude, seriously!  :rolleyes:

Share this post


Link to post
Share on other sites

It is a 3rd person shooter at heart so obviously first person view is half-assed and feels like a console port.

Share this post


Link to post
Share on other sites

When you begin a development project, particularly one where you have multiple branches of the code-base, you run development of features over iterations or sprints. The results of these sprints are often only small features that can be seen end-to-end (a player can see on stable) and cumulative work that is held out of the stable branch as it isn't ready for player consumption. As you run these parallel threads of development, they all get closer and closer to done, so once these start being stable enough for merging in to the stable branch, you get dependent features merging in more quickly, and eventually get a nice pace of features being pushed out.

 

A development shop pushing out huge amounts of features right at the beginning and tapering down, as you suggested, is one that is going completely market driven and pushing to be the first out, not focusing on a stable and finished product. It happens, sometimes makes business sense, but isn't how you develop an off-the-shelf purchase-once product. That sort of development usually requires a recurring revenue model to sustain the continuous stabilizing patches that need to be produced after release.

 

Don't waste your breath on him, he's a troll. You can explain things to him until your fingers are numb and he'll come up with some nonsensical dumbassery to further rile you up.

Share this post


Link to post
Share on other sites

Don't waste your breath on him, he's a troll. You can explain things to him until your fingers are numb and he'll come up with some nonsensical dumbassery to further rile you up.

 

Takes a lot more than that to rile me!

Share this post


Link to post
Share on other sites

When you begin a development project, particularly one where you have multiple branches of the code-base, you run development of features over iterations or sprints. The results of these sprints are often only small features that can be seen end-to-end (a player can see on stable) and cumulative work that is held out of the stable branch as it isn't ready for player consumption. As you run these parallel threads of development, they all get closer and closer to done, so once these start being stable enough for merging in to the stable branch, you get dependent features merging in more quickly, and eventually get a nice pace of features being pushed out.

 

A development shop pushing out huge amounts of features right at the beginning and tapering down, as you suggested, is one that is going completely market driven and pushing to be the first out, not focusing on a stable and finished product. It happens, sometimes makes business sense, but isn't how you develop an off-the-shelf purchase-once product. That sort of development usually requires a recurring revenue model to sustain the continuous stabilizing patches that need to be produced after release.

Are you a video game developer? That is not how videogames are developed; this isn't some piece of business software. You don't fix bugs then start coming out with features right before release as those features will cause more bugs or even undo the bug fixes you already have done. You also don't have multiple branches developing different features on different builds and then merge them together for a patch as that would be idiotic while developing a game as you need to know how things are going to work with other things before you release them not slam 10 different things together from 10 different versions and hope they work.

 

They are not focusing on creating a stable and finished product in early alpha development they are pushing as many features as they can and then trying to get them to work.

Edited by Weedz

Share this post


Link to post
Share on other sites

Are you a video game developer? That is not how videogames are developed; this isn't some piece of business software. You don't fix bugs then start coming out with features right before release as those features will cause more bugs or even undo the bug fixes you already have done. You also don't have multiple branches developing different features on different builds and then merge them together for a patch as that would be idiotic while developing a game as you need to know how things are going to work with other things before you release them not slam 10 different things together from 10 different versions and hope they work.

 

They are not focusing on creating a stable and finished product in early alpha development they are pushing as many features as they can and then trying to get them to work.

 

could you please show us a picture of your degree at programming and the places you worked on programming, please?

 

Cause a game is basically a program that follows the same pace as any other program, the only difference is that you have a design team working together with the developers.

 

Cause for me you're just vomiting bullshit here.

Edited by lipemr

Share this post


Link to post
Share on other sites

could you please show us a picture of your degree at programming and the places you worked on programming, please?

 

Cause a game is basically a program that follows the same pace as any other program, the only difference is that you have a design team working together with the developers.

 

Cause for me you're just vomiting bullshit here.

 

You don't need a degree to justify what he said, it's just logical.

Share this post


Link to post
Share on other sites

Posted Today, 07:04 AM

6dcffff6117c23a60656dafafd20d204_normal.

Dean Hall @rocket2guns

@TheMuncha Some small fixes made it into the latest build. but we have decided to redo mouse control from scratch as a high priority

View on Twitter

They have decided that it's broken, so the question is what will they replace it with?

Share this post


Link to post
Share on other sites

I use a controller, so can someone explain what mouse acceleration actually is? I've been posting here for two years and never bothered to ask haha.

Share this post


Link to post
Share on other sites

I use a controller, so can someone explain what mouse acceleration actually is? I've been posting here for two years and never bothered to ask haha.

 

Essentially mouse acceleration changes the speed of your characters movement based on the speed that you move your mouse. So with negative mouse acceleration, when you move the mouse slowly the character turns fast but when you quickly move the mouse the character barely moves at all.

 

Generally gamers want 1:1 movement so if you move the mouse between two points, it will always move/turn the character the same distance, regardless of the speed at which you moved the mouse.

  • Like 1

Share this post


Link to post
Share on other sites

Essentially mouse acceleration changes the speed of your characters movement based on the speed that you move your mouse. So with negative mouse acceleration, when you move the mouse slowly the character turns fast but when you quickly move the mouse the character barely moves at all.

 

Generally gamers want 1:1 movement so if you move the mouse between two points, it will always move/turn the character the same distance, regardless of the speed at which you moved the mouse.

 

Gotcha', thanks!

Share this post


Link to post
Share on other sites

Glad they are going to redo mouse control, hoping for 1:1 input, which as luck would have it, has to be the least work.

Share this post


Link to post
Share on other sites

"Some small fixes made it into the latest build. but we have decided to redo mouse control from scratch as a high priority"

 

redo mouse control from scratch

redo mouse control from scratch

redo mouse control from scratch

 

YAAAAAAAAAAAAAY!!!!

Edited by 27 others

Share this post


Link to post
Share on other sites

so it was worth the thread being done . thanks for listening. B)

Share this post


Link to post
Share on other sites

I honestly don't think they are going to make it raw mouse input, unless after redoing it they just say fuck it.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×