Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: DaBrain on October 16, 2006, 07:26:45 am
-
My joystick is broken, so I have to use the mouse for now. It's not that bad, but there are some things that could be better.
Well, not everybody has a joystick anymore nowdays. This his why games like Freelancer improved their mouse controls.
Most basic thing: Support the wheel! My mouse doesn't have many buttons, so every single thing counts.
The wheel would be prefect for the throttle control.
No hard turns! That's the biggest problem imho. It's hard to turn. I can increase the sensitivity, but not without making it harder to aim.
This is just an idea, maybe there are other ways to fix this.
The cross is your mouse postion. You can't move it out of this ring. The closer you get the the edge of the ring, the faster the rotation in this direction will get. (exponential). In the the center part, the precision is very high, so the aiming will work perfectly.
(http://img89.imageshack.us/img89/825/mouseringideasv1.jpg)
I've no idea about the shape of this part of the code... I'm pretty sure my second suggestion will be problematic. But still consider it. It might just be the one missing bit to increase the userbase a lot.
-
Yes. Freelancery mouse control would be neat.
And I thought wheel works already...?
-
I use an old-school ball mouse, and I have to turn the sensitivity up just to get some of the... "heavier"... ships to turn. And even then, I'm not getting a fast-enough turn rate, even at maximum level (although it's tolerable/okay on the more agile ships like the Ulysses). I don't have too much of a problem in weapons aiming though.
Just felt that I should've pointed that out, even though I've sort of already learned to live with it... :nervous:
-
while ( !(post-3.6.9 == new pilot code == new input code == better joystick control == better mouse control
== mouse wheel support == more button support == freelancer-style mouse control) )
{
printf("!!! IF I HAVE TO REPEAT MYSELF ONE MORE TIME.... !!!\n");
repeat++;
if (repeat > 1) {
signal(SIGKILL, term_handler_EVERYONE);
exit(EXIT_SUCCESS);
}
}
-
The cross is your mouse postion. You can't move it out of this ring. The closer you get the the edge of the ring, the faster the rotation in this direction will get. (exponential). In the the center part, the precision is very high, so the aiming will work perfectly.
I feel this can be a good improvement. You would be using the mouse like if it were mounted in the top of a virtual joystick. I remember a very old helicopter simulator which worked really fine in this way. Even, as joysticks usually have ugly zero errors, some people will throw them away (despite of their extra buttons).
-
No hard turns! That's the biggest problem imho. It's hard to turn. I can increase the sensitivity, but not without making it harder to aim.
This is just an idea, maybe there are other ways to fix this.
The cross is your mouse postion. You can't move it out of this ring. The closer you get the the edge of the ring, the faster the rotation in this direction will get. (exponential). In the the center part, the precision is very high, so the aiming will work perfectly.
I agree.
I have a laptop with the mousestick... :hammer:
and to control the ship is even worse than with a mouse! But the precision on a slow target is good.
-
@taylor
I didn't want to request new stuff before 3.6.9. Just had this idea and thought it would be a good one.
I wasn't sure if there where any plans to work on something like that.
Yes. Freelancery mouse control would be neat.
And I thought wheel works already...?
Could you please check that. It doesn't work for me for sure.
-
Wait! Taylor, you're saying that 3.6.9 will have Freelancery mouse support??? Will this be in RC8 I guess??
-
Wait! Taylor, you're saying that 3.6.9 will have Freelancery mouse support??? Will this be in RC8 I guess??
post-3.6.9
as in this is MAYBE a 3.7.0 feature.
Please don't make taylor go insane. we need him for coding.
-
:lol:
I thought that meant post as in a forum post!
-
@taylor
I didn't want to request new stuff before 3.6.9. Just had this idea and thought it would be a good one.
I wasn't sure if there where any plans to work on something like that.
My point was that both features have already been coded. It's part of the (already complete) new mouse code, which is from the (already complete) new joystick code, which is part of the (already complete) new input handling code, which is part of the (not complete) new pilot file code, which is coming post-3.6.9. I've mentioned this more than a dozen times already, anytime someone brings up something about better joystick/mouse support.
Support for both was added since it has been requested about every month for over a year.
And I thought wheel works already...?
The current code only supports the first 3 mouse buttons, nothing else. Support for the wheel will arrive when the new pilot file code does.
-
you might be able to do it now with wmc's latest scripting build. theres a whole stack of phisics vars to play with. you could probibly throw something together to hold you off in the mean time.
-
:lol: taylor, that's got to be the most entertaining reply method I've seen all year. And it's also funny that it's not just some newb asking this time...
Poor taylor, he works so hard, but half of it is so awesome that it gets missed or flies over our heads. We should make a sticky of "Stuff Not to Ask Taylor About Again". :D
No hard turns! That's the biggest problem imho. It's hard to turn. I can increase the sensitivity, but not without making it harder to aim.
Agreed. I find I use a silly combination of the numpad and the mouse, which works pretty well all things considered. That is, I do that only when away from home and my joystick :p Though, the mouse is the ultimate for Maxim sniping...
I have a laptop with the mousestick... :hammer:
Ouch, well there goes the numpad idea for you :ick: I'm sorry...
-
Don't burn me. I've missed the posting taylor talked about the controls...
I remember the same situation with WMC. It's not easy to keep on track with the features.
-
Just ask a non-coder to name 10 new features in the engine... :nervous:
I have to think hard just to name few, and even those are old stuff like fighterbeams and some FRED functions. One just can't remember all this whitout spending time in making/using the features.
-
Well that wouldn't be a problem for me. I could just name all features I'm using. So I could easily name more than ten. ;)
-
(http://img89.imageshack.us/img89/825/mouseringideasv1.jpg)
i want those explosions.
-
I've forgotten most of the features I've implemented. Some of the more esoteric and minor ones, for instance. I don't think anyone really cares about the majority, although I think it would be interesting to dig through the commit logs sometime to see what features I implemented, but completely forgot about.
Of course the most major ones - hud_gauges.tbl and the lab GUI system - I hardly ever think about anymore, since they were discontinued before they ever really amounted to anything. (And in both cases, finishing them would take a _lot_ of work)
These days, I often find that I can't just implement things because the way that I want to do it would involve ripping out a major portion of the existing code and rewriting it to something more organized and expandable. A lot of the scripting stuff I have the problem of seeing something that could cause a major hackish situation in the future, but would require either a major redesign, or a painfully imperfect workaround to get the effect I'm hoping for. (Eg the two sound lists in sounds.tbl use many of the same functions, but are still stored separately in memory. Slapping those into scripting either means duplicating the functions for the different types of sounds, creating a 'generic sound' scripting object, or rewriting key portions of the highlevel sound code to make the whole thing make more sense, while still maintaining backwards compatibility with the TBL and the rest of the code. The fact that retail interface sounds are hardcoded is even more painful.)
-
The cross is your mouse postion. You can't move it out of this ring. The closer you get the the edge of the ring, the faster the rotation in this direction will get. (exponential). In the the center part, the precision is very high, so the aiming will work perfectly.
(http://img89.imageshack.us/img89/825/mouseringideasv1.jpg)
I've just realized... IMO the boundary should be a square rather than a circle.
The ships have two clearly diferent movements: x-axis for left-right turning and y-axis for up-down pulling. In this way if you are at '45ยบ', the ship doesn't just move to that direction (right and down). It pulls and it turns at the same time, which is somehow different.
In this situation the circle boundary means that if you are pulling up at max speed (mouse pointer in the bottom of the circle) you can't turn at all. With a square boundary, both movements would be independant. In fact, joysticks have a square behaviour rather than a circle one.
(Y-axis should be reversible as maybe some people prefer pulling up when moving the mouse forward/up, rather than pulling down).
-
Please no square. :shaking:
Of course your ship may not turn into all directions with the same speed, but the cricle is just the control the direction. You put the cusor to the edge of the circe, and the ship will start to turn as fast as possible into that direction.
i want those explosions.
They'll be in the SoL demo early next year.
-
Or you can get combustion and make your own.
-
Uhm... but they won't look anything like them...
-
Please no square. :shaking:
Of course your ship may not turn into all directions with the same speed, but the cricle is just the control the direction. You put the cusor to the edge of the circe, and the ship will start to turn as fast as possible into that direction.
I just prefer the Joystick/square emulation. Please notice that just now, when you use a joystick and you just turn left/right your ship has some aditional components (some twist and some moving pulling down). Look at the stars background or how still targets move in radar. So it's not a "flat" movement. But pulling up/down IS a flat movement. So they are different kind of movements not just different directions of turning.
With the circle behaviour, I don't know how you can make the ship move in the same way.
And I think the square behaviour is more intuitive, as I've said before, you would be just mounting the mouse in the top of a virtual joystick which always has the square one. One example: with the circle boundary, if you are pulling up at 100% and you move your mouse left the pointer would stay in the top/bottom of the circle, (there's no room for horizontal movement in it), and you won't turn at all. Do you think a normal user would expect this?
But this is just my opininion...
-
One example: with the circle boundary, if you are pulling up at 100% and you move your mouse left the pointer would stay in the top/bottom of the circle, (there's no room for horizontal movement in it), and you won't turn at all. Do you think a normal user would expect this?
The normal user would expect the direction of movement to correspond with the direction to the pointer. So if you move the mouse all the way to the top of the screen, then move it halfway to the right edge of the screen, the place where the pointer is would be on the line connecting the center of the circle and the pointer.
This can be done in either a square or a circle setup, but I feel it works better in the circle one.
-
theres no reason to have a pointer unless you will also slave turret commands to the mouse. you could probibly just use a setup similar to privateer 2 or elite. i think it would be less distracting.
-
theres no reason to have a pointer unless you will also slave turret commands to the mouse. you could probibly just use a setup similar to privateer 2 or elite. i think it would be less distracting.
I disagree. It'll make non-joystick flight easier, so you won't have to do the slide-pickup mouse move. I think it should be for both cockpit and chase views.
-
theres no reason to have a pointer unless you will also slave turret commands to the mouse. you could probibly just use a setup similar to privateer 2 or elite. i think it would be less distracting.
I disagree. It'll make non-joystick flight easier, so you won't have to do the slide-pickup mouse move. I think it should be for both cockpit and chase views.
you completely misunderstd me. flight sim style mouse = good feature, mouse pointer on screen == distracting. the only reason the mouse pointer worked in freelancer is because it aimed your guns. a simple roll|yaw+pitch rate gauge is suffietient.
-
you completely misunderstd me. flight sim style mouse = good feature, mouse pointer on screen == distracting. the only reason the mouse pointer worked in freelancer is because it aimed your guns. a simple roll|yaw+pitch rate gauge is suffietient.
Ok, I'm now thoroughly confused. Are you saying that having the drag-pickup-drop method be the only one and the one included in the game be the only one, or are you referring to some other method? If the circle-pointer method bothers you, then I'd say stick to the drag-pickup-drop, and let others use the new way, because I doubt they'd completely replace the old method with the new code. If you're talking about some other method that I'm not too clear on, then I think that might be vialble. I don't see why we can't develop yours and the circle-pointer method. I think I'd prefer the circle-pointer to anything else, personally, but only in first person perspective. You just have to remember that the reticule is where you're firing and not the pointer.
-
Ok, I'm now thoroughly confused. Are you saying that having the drag-pickup-drop method be the only one and the one included in the game be the only one, or are you referring to some other method? If the circle-pointer method bothers you, then I'd say stick to the drag-pickup-drop, and let others use the new way, because I doubt they'd completely replace the old method with the new code. If you're talking about some other method that I'm not too clear on, then I think that might be vialble. I don't see why we can't develop yours and the circle-pointer method. I think I'd prefer the circle-pointer to anything else, personally, but only in first person perspective. You just have to remember that the reticule is where you're firing and not the pointer.
*sigh*
He's saying he loves the circle-pointer idea. He thinks it's the best idea in the world. He just thinks that we shouldn't clutter up the HUD by actually DRAWING the circle and pointer on the screen.
-
the freespace hud is both a blessing and a curse. its a blessing as it gives you all the information you can possibly need as effieteintly as possible. its a curse because you cant add anything to it without cluttering your screen. a privateer 2 style yaw/pitch gauge would look better and would blend into the existing hud elements alot better.
-
My last post about this...
It's a pity I don't remember the name the old chopper sim I played with the built-in joystick emulation mouse control, I mean, my explained square behaviour, (I played the game in my first PC and it was a 386SX with 2 MB of RAM ...) . But it was simply great. And it had a pointer over the screen to show you the position of your "joystick". At the begining it was a little annoying seeing a pointer running over the screen, but when you got used to it, it was just another extra HUD info.
Nevertheless the pointer it's not absolutely necessary. It's just an aid because mice can't have "autocenter" function or force feeling like joysticks. ;)
I haven't played Freelancer so I don't exactly know how it works but I am feeling that the circle behaviour that other people is explaining is just a way to show a square-behaviour code in a "prettier" way. Keep in mind that if you really code this kind of control your horizontal and vertical movements are linked as I said in previous posts. So if you can turn when you are pulling up/down at 100%, (as I suppose it is desired by everyone), YOU DON'T HAVE A CIRCLE BEHAVIOUR despite what you get "painted" in the HUD.
-
the script i wrote for turret control had mouse emulation. it had a big square and a little square. the little square was your deadzone and the big one was your field of motion. i only had the script draw theese for debuging though. anyway it would convert screen coords into a number from -100 to 100. if youre in the dead zone you return a 0. i could have written it better so as not to waste the dead zone. but i still trying to recode all my scripts to work in the new system.
-
Well, from what I remember, Freelancer didn't acutally have a circle, it just had the pointer. Now the pointer functioned as a targeting reticule as well, but I see you'r point about the circle. I think we have two ways of doing it. Drawing an imaginary circle that the player can't see, but is the limit to how far the pointer can go. The second is the yaw, pitch gadge, but I think that might be a little more difficult to see in exectution.
-
Unless I'm reading this wrong, I think the whole "square/circle" argument comes down to whether or not a mouse player would be able to push both the X and Y axes to their limit at the same time, which any joystick user can obviously do. In other words, your standard joystick, being a "square" example, has four "corners" for limits; you can see these in the standard Windows game controller calibration screen. In each of those corners, both the X and Y axes are at 100% motion; translated to in-game, this would allow your fighter/turret/whatever to move most effectively in those directions. With a "circle" model of motion, these "corners" do not exist; when attempting to move equally in the X and Y directions, instead of getting the 100% generated by a joystick, you'd be getting (100/squareroot(2))%, via simple geometry. This produces a limit on how fast you can actually move the reticle and could put the mouser at a disadvantage.
-
Hmmm, yes, but I think you can still do it with a circle. When the cursor is at the edge of a circle, it is at maximum turn in the vector from the origin of that point on the circle. So, a cursor in the top left corner would correspond to a cursor on the edge of a circle at 45 degrees left of straight up. Either method would work, I just kinda felt that the circle method makes more sense. But that's to our eyes. For a computer code, the square method might work better. Either way, I wouldn't want the box or the circle actually visible, but rather hidden, but the cursor would still be there. The cursor simply would not be able to move past the edge of either the circle or the box.
-
I find I use a silly combination of the numpad and the mouse, which works pretty well all things considered.
:lol: same here.