Forums » Suggestions
Dude...
Sum of forces = mass *accel
thrust/mass =accel (same thing as you say)
Now I can understand why you would want to get rid of the "Rubber Band". But since we have a constant Mass and Constant Thrust the accel should be constant.
I don't see why you are trying to make all those nifty, but complicated formulas. Your formula ends up with pretty much the same Rubber Band... just at higher speeds.
And as far as I'm concerned the rubber band is fine by me :)
Sum of forces = mass *accel
thrust/mass =accel (same thing as you say)
Now I can understand why you would want to get rid of the "Rubber Band". But since we have a constant Mass and Constant Thrust the accel should be constant.
I don't see why you are trying to make all those nifty, but complicated formulas. Your formula ends up with pretty much the same Rubber Band... just at higher speeds.
And as far as I'm concerned the rubber band is fine by me :)
I made the nifty complicated formulas to further explain precicely what ideas I'm trying to get across above in terms that rigidly logical people like myself can understand. The equations are also for the benefit of the Devs who'd need to type such formulas to make the game run. The difference between this model and what we currently have is that there is no longer a self defined max speed. Your speed is based on whatever your ship can pull off, based on weight, it's engine's efficiency of thrust, and the energy you feed into it. Not some arbitrary number, such as 65m/s for most ships. This means that you'll be able to coast at larger numbers.
Also, currently if your quit boosting while above your ship's set speed limit, you quickly decelerate until your a little bit below the limit. Incarnate's suggestion of removing the top speed implies as such, and I approve enough to spend plenty of time thinking all these little details and suggestions out. The key to all this is that the devs can totally set what speeds are achievable at what energy levels. In fact I'm in the process of writing out new statistics of the same ships (Centaurion, and Atlas mostly) that would give roughly the same top speeds, and maneuverability, and what not.
Jim Kirk, I okay limiting the top speeds because they roughly mimic what happens when real vessels attain higher speeds. They pick up more mass, thus getting progressively more difficult to accelerate. My model just makes this happen at much quicker paces. So, that's why I find the smudge on reality acceptable. I hope you can too. =(
Also, currently if your quit boosting while above your ship's set speed limit, you quickly decelerate until your a little bit below the limit. Incarnate's suggestion of removing the top speed implies as such, and I approve enough to spend plenty of time thinking all these little details and suggestions out. The key to all this is that the devs can totally set what speeds are achievable at what energy levels. In fact I'm in the process of writing out new statistics of the same ships (Centaurion, and Atlas mostly) that would give roughly the same top speeds, and maneuverability, and what not.
Jim Kirk, I okay limiting the top speeds because they roughly mimic what happens when real vessels attain higher speeds. They pick up more mass, thus getting progressively more difficult to accelerate. My model just makes this happen at much quicker paces. So, that's why I find the smudge on reality acceptable. I hope you can too. =(
Jim Kirk, I okay limiting the top speeds because they roughly mimic what happens when real vessels attain higher speeds. They pick up more mass, thus getting progressively more difficult to accelerate.
[nitpick]Er... no, objects don't accrue mass as they accelerate. They require more energy to be put into the system to continue to accelerate at a constant rate, but that is not the same as gaining mass. Here's a better way to explain it...
Which situation, A or B, requires more energy to be put into the system, assuming the movement is along a single axis and there is no friction?
A: Object X of mass m starts at rest and accelerates at a given rate a from 0m/s to 10m/s.
B: Object X of mass m starts at a velocity of 10m/s and accelerates at the same constant rate a from 10m/s to 20m/s.
The answer is B. The reason why our acceleration drops off as we approach the ships' speed limits is because the ships supply a constant amount of energy towards movement in any direction, rather than scaling it up as you go. Note that the same is true if the object is being slowed down instead. Basically, where you say "In addition, I propose that the quicker speed you achieve, the more difficult it becomes to further increase your speed", you're just reiterating a law of physics that is already in effect in VO.
Also, mass != weight, despite what some of the unclean masses say. Mass is a static amount, and weight changes based on nearby gravity wells. Using these two words interchangeably confuses people who know the true definitions of these words when they try to understand what you are trying to explain.[/nitpick]
Glaring mistakes like that in statements about physics seem to attract the nitpicker in me, I'm not sure why... it might be the fact that physics is one of my favorite subjects in school...
[nitpick]Er... no, objects don't accrue mass as they accelerate. They require more energy to be put into the system to continue to accelerate at a constant rate, but that is not the same as gaining mass. Here's a better way to explain it...
Which situation, A or B, requires more energy to be put into the system, assuming the movement is along a single axis and there is no friction?
A: Object X of mass m starts at rest and accelerates at a given rate a from 0m/s to 10m/s.
B: Object X of mass m starts at a velocity of 10m/s and accelerates at the same constant rate a from 10m/s to 20m/s.
The answer is B. The reason why our acceleration drops off as we approach the ships' speed limits is because the ships supply a constant amount of energy towards movement in any direction, rather than scaling it up as you go. Note that the same is true if the object is being slowed down instead. Basically, where you say "In addition, I propose that the quicker speed you achieve, the more difficult it becomes to further increase your speed", you're just reiterating a law of physics that is already in effect in VO.
Also, mass != weight, despite what some of the unclean masses say. Mass is a static amount, and weight changes based on nearby gravity wells. Using these two words interchangeably confuses people who know the true definitions of these words when they try to understand what you are trying to explain.[/nitpick]
Glaring mistakes like that in statements about physics seem to attract the nitpicker in me, I'm not sure why... it might be the fact that physics is one of my favorite subjects in school...
> To Sum it all up.
There's always going to be a rubberband, WE (the players) are just asking for a much longer and skinnier one.
< Thank you and goodnight.
There's always going to be a rubberband, WE (the players) are just asking for a much longer and skinnier one.
< Thank you and goodnight.
Edit: Post probably nonproductive.
Since our resident genius suggested it, I thought I'd restate the blindingly obvious for Inc.
@ Inc. I do disagree with the effect of turbo acceleration on combat; your arguments, while factually correct in so far as they go, are some of the weakest stuff I've ever seen advanced to support a particular game mechanic I've seen on these boards. All the more obnoxious, you know that, given your experience. Turbo is used sparingly at best, and the small alteration in boost acceleration is barely relevant.
But more importantly, were I to concede (arguendo) that everything you say is a brilliant solution to this horrid problem (it's not): you still haven't explained why it was done as a cap. Nor can you, since a cap does what you want AND screws up the balance between ships in so far as chasing and turbo acceleration goes. I mean, you said it yourself: "given the fundamental importance of our flight model, I think it makes sense for me to be fairly conservative."
Since you somehow missed my "constructive suggestion" in every single post I've made on the topic of this idiotic alteration (numerous), here it is again:
REDUCE THE GODDAMN TOP SPEEDS RELATIVE TO EACH-OTHER, PROPORTIONALLY, SO THAT THE RATIO BETWEEN ANY TWO SHIPS IS UNCHANGED. AM I FINALLY MAKING MY CONSTRUCTIVE, POSITIVE, HAPPY HAPPY JOY JOY SUGGESTION CLEAR?
@ Inc. I do disagree with the effect of turbo acceleration on combat; your arguments, while factually correct in so far as they go, are some of the weakest stuff I've ever seen advanced to support a particular game mechanic I've seen on these boards. All the more obnoxious, you know that, given your experience. Turbo is used sparingly at best, and the small alteration in boost acceleration is barely relevant.
But more importantly, were I to concede (arguendo) that everything you say is a brilliant solution to this horrid problem (it's not): you still haven't explained why it was done as a cap. Nor can you, since a cap does what you want AND screws up the balance between ships in so far as chasing and turbo acceleration goes. I mean, you said it yourself: "given the fundamental importance of our flight model, I think it makes sense for me to be fairly conservative."
Since you somehow missed my "constructive suggestion" in every single post I've made on the topic of this idiotic alteration (numerous), here it is again:
REDUCE THE GODDAMN TOP SPEEDS RELATIVE TO EACH-OTHER, PROPORTIONALLY, SO THAT THE RATIO BETWEEN ANY TWO SHIPS IS UNCHANGED. AM I FINALLY MAKING MY CONSTRUCTIVE, POSITIVE, HAPPY HAPPY JOY JOY SUGGESTION CLEAR?
That's exciting, lecter. Except that I had pushed the top speeds of the light fighters much farther than the other ships, and scaled them back similarly. And I did tweak the heavier / slower ships at the same time (to a lesser extent and only a few of them). The point at the time was to re-establish an approximation of the relative balance scenario we had had *previous* to my making the mistake of increasing ship thrust too much, not find some new balance based on how you apparently think things should be (although I'm open to that, aside from your attitude). Had it been possible, I would have actually used the old numbers (for all the ships), but they weren't in CVS. As it was, I tried to approximate based on what I could remember.
You also might be in a better position to assess what's "barely relevant" if you were to test gameplay at high latencies, as I did. We lost Icarus and other distant-location vets over the speed issue, in which top speeds definitely played a part. It is the rapid *change* in speed that's toughest on high latency connections, and the turbo ramp-up is a big part of that.
Also, this has nothing to do with the thread topic. This thread is about reworking the flight model entirely, not punching a few new numbers into the object definitions. If that's what you want, fine, make a new topic and lay it out. And no, I did not see your many supposed relevant suggestions on the topic, and if I did, I don't remember them. In fact, it's possible that I may be subconciously inclined to skim your posts entirely, because they are often as confrontational and poorly chosen as this one.
I think my record on listening to the player base and suggestions, within the limits of my own workload and life, is well documented. If I don't implement your suggestion, it may have nothing to do with the suggestion, and more to do with my other responsibilities. There are lot and lots of great suggestions that fall by the wayside, and I go back and re-read every few months and go "oh yeah, we should do that". Furthermore, your bile and sarcasm does nothing to enhance your arguements, and significantly hampers them, as people who always rant are the first to be ignored.
If you want to continue this exchange, feel free to email me and not clog up this thread any further.
You also might be in a better position to assess what's "barely relevant" if you were to test gameplay at high latencies, as I did. We lost Icarus and other distant-location vets over the speed issue, in which top speeds definitely played a part. It is the rapid *change* in speed that's toughest on high latency connections, and the turbo ramp-up is a big part of that.
Also, this has nothing to do with the thread topic. This thread is about reworking the flight model entirely, not punching a few new numbers into the object definitions. If that's what you want, fine, make a new topic and lay it out. And no, I did not see your many supposed relevant suggestions on the topic, and if I did, I don't remember them. In fact, it's possible that I may be subconciously inclined to skim your posts entirely, because they are often as confrontational and poorly chosen as this one.
I think my record on listening to the player base and suggestions, within the limits of my own workload and life, is well documented. If I don't implement your suggestion, it may have nothing to do with the suggestion, and more to do with my other responsibilities. There are lot and lots of great suggestions that fall by the wayside, and I go back and re-read every few months and go "oh yeah, we should do that". Furthermore, your bile and sarcasm does nothing to enhance your arguements, and significantly hampers them, as people who always rant are the first to be ignored.
If you want to continue this exchange, feel free to email me and not clog up this thread any further.
(D'oh! My post is rendered unnecessary. Retracted!)
Recall that you suggested I post further on this matter here in the UIT thread. As for my ranting, if you wish to ignore otherwise meritorious suggestions (a different debate) out of irrational motives, by all means do so.
We're done here; carry on.
We're done here; carry on.
But anyway... Am I the only one who has to bring threads back on topic?
The Turbo Acceleration should remain somewhat quick, I just hate the deceleration rate from turbo, and from non-turbo. Hitting the break should be equally forceful as hitting the opposite direction of current travel, no more, no less.
The Turbo Acceleration should remain somewhat quick, I just hate the deceleration rate from turbo, and from non-turbo. Hitting the break should be equally forceful as hitting the opposite direction of current travel, no more, no less.
Rise oh mighty thread from the past.
Last night I had a very interesting experience, and it got me thinking about this thread again.
From Incarnates original post,
“Well, for one thing.. there's a tremendous amount of "space" that is currently unused, that I would like to make use of. Sectors tend to have one and only one point of interest (station, wormhole, etc). I have always wanted multiple stations spread out across a sector..”
Anyone here taken a ride on a Concussion Catapult? Well if you haven’t let me explain it to you. Drop a whole bunch of concussion mines in a group, blow one up, and the chain reaction shoots you off at 3000-4000 MS or more. At that speed you are 45K out in under 15 seconds. I have heard some people have gotten it to 32,000 MS, and spent the next 10 Min waiting to slow down. No idea how far they got, but it must have been incredible.
Anyway, it is clear that the physics for this speed of travel exists, that the game can handle it. That and players are in fact doing it for kicks. So how about we formalize it, and tie it into this trust debate?
My proposal, a way to store the energy from a ships turbo thrust, and to “pop” it all off at one time, much like the Repair gun, or Charged Cannon, is as follows
The player stores N thrust for popping (PN) equal to the turbo trust N (TTN) while holding down a key.
This value increases by TTN every second.
A counter on the HUD shows the current value of PN.
Add another counter that calculates the speed and distance that will be reached as it relates to you current ship configuration and weight, based on the PN.
Top PN or expected distance could be configured, so that the power of the jump could be controlled, and the PN value held, until a fleet was ready to all do it at the same time.
For ships that cannot accommodate infinite boost, the PN increase is done in fractions of the max battery output, so as to not make these ships useless for this type of travel.
The regular turbo is not available during the charge up time.
There is a minimum of 10 seconds worth of storage, or the “pop” fizzles.
You can still maneuver to look at the pretty vistas as they fly past you at insane speeds.
Popping delivers the value of PN for a one second burst, and the ship travels in a strait line in the direction it was pointing, as if turbo thrust was being used.
Popping also turns on the FA (see below for reason)
The ship cannot add additional trust until it has fallen back down to less than 5ms travel speed.
Give it a new, very bright, explosive behind ship graphic, that can be seen from 100’sK away.
So now you would have a way to move around an enormous sector with multiple stations, in a controlled, predictable, but not exactly safe manner. It could not be easily used to avoid pirates like an in sector jump would, and it should not affect the combat model, as the warm up times make frequent use of it in combat somewhat prohibitive. Oh, and you get to see space wiz by at incredible speeds.
Just imagine the possibilities.
Pirates up between “points of interest in sectors” and sitting on their PN waiting from 10K or more away for convoys to show up.
Large scale battles where capital ships reinforce a fighter fleet between them, while they attempt to launch very long range missiles that also “pop” at the enemy capital ships.
Mining convoys supported by refinement ships 1,000’s of K’s away for relative safety.
Watching a fleet of war ships, capitals and fighters, fly towards you in unison, at 1000’s of MS, and then start engaging your group at close range, when they slow only 1-2K out from your location. I have visions of the attack on the death star from return of the Jedi running through my mind.
Gives me goose bumps just thinking about it.
Last night I had a very interesting experience, and it got me thinking about this thread again.
From Incarnates original post,
“Well, for one thing.. there's a tremendous amount of "space" that is currently unused, that I would like to make use of. Sectors tend to have one and only one point of interest (station, wormhole, etc). I have always wanted multiple stations spread out across a sector..”
Anyone here taken a ride on a Concussion Catapult? Well if you haven’t let me explain it to you. Drop a whole bunch of concussion mines in a group, blow one up, and the chain reaction shoots you off at 3000-4000 MS or more. At that speed you are 45K out in under 15 seconds. I have heard some people have gotten it to 32,000 MS, and spent the next 10 Min waiting to slow down. No idea how far they got, but it must have been incredible.
Anyway, it is clear that the physics for this speed of travel exists, that the game can handle it. That and players are in fact doing it for kicks. So how about we formalize it, and tie it into this trust debate?
My proposal, a way to store the energy from a ships turbo thrust, and to “pop” it all off at one time, much like the Repair gun, or Charged Cannon, is as follows
The player stores N thrust for popping (PN) equal to the turbo trust N (TTN) while holding down a key.
This value increases by TTN every second.
A counter on the HUD shows the current value of PN.
Add another counter that calculates the speed and distance that will be reached as it relates to you current ship configuration and weight, based on the PN.
Top PN or expected distance could be configured, so that the power of the jump could be controlled, and the PN value held, until a fleet was ready to all do it at the same time.
For ships that cannot accommodate infinite boost, the PN increase is done in fractions of the max battery output, so as to not make these ships useless for this type of travel.
The regular turbo is not available during the charge up time.
There is a minimum of 10 seconds worth of storage, or the “pop” fizzles.
You can still maneuver to look at the pretty vistas as they fly past you at insane speeds.
Popping delivers the value of PN for a one second burst, and the ship travels in a strait line in the direction it was pointing, as if turbo thrust was being used.
Popping also turns on the FA (see below for reason)
The ship cannot add additional trust until it has fallen back down to less than 5ms travel speed.
Give it a new, very bright, explosive behind ship graphic, that can be seen from 100’sK away.
So now you would have a way to move around an enormous sector with multiple stations, in a controlled, predictable, but not exactly safe manner. It could not be easily used to avoid pirates like an in sector jump would, and it should not affect the combat model, as the warm up times make frequent use of it in combat somewhat prohibitive. Oh, and you get to see space wiz by at incredible speeds.
Just imagine the possibilities.
Pirates up between “points of interest in sectors” and sitting on their PN waiting from 10K or more away for convoys to show up.
Large scale battles where capital ships reinforce a fighter fleet between them, while they attempt to launch very long range missiles that also “pop” at the enemy capital ships.
Mining convoys supported by refinement ships 1,000’s of K’s away for relative safety.
Watching a fleet of war ships, capitals and fighters, fly towards you in unison, at 1000’s of MS, and then start engaging your group at close range, when they slow only 1-2K out from your location. I have visions of the attack on the death star from return of the Jedi running through my mind.
Gives me goose bumps just thinking about it.
PsyRa,
That's good. I'd like some way of going insanely fast for short periods of time. Like a s-port afterburner (Afterburner is the best)
That's good. I'd like some way of going insanely fast for short periods of time. Like a s-port afterburner (Afterburner is the best)
I too love PsyRa's idea. Would it be a problem to implement? Would it cause lag or whatever even if you could only move in one direction for the entire duration of the boost? My guess is that there is some sort of fundamental problem with this, which is why we don't already have something like it.
To avoid abusing this to run from combat situations, make the charge-up take a while, maybe 10 seconds, and during that 10 seconds you can't be using the battery at all (boosting, firing weapons, etc...). There should also be some simple way of plotting a course since you can't change directions and you'll be traveling beyond visual or radar range.
To avoid abusing this to run from combat situations, make the charge-up take a while, maybe 10 seconds, and during that 10 seconds you can't be using the battery at all (boosting, firing weapons, etc...). There should also be some simple way of plotting a course since you can't change directions and you'll be traveling beyond visual or radar range.
Well I think that most people get lag for two reasons. One, high ping or network packet loss, so that they end up skipping around as the where they/you think they are, and the servers opinion on the matter reconcile. I expect that through most of the trip, say when they are above 1,000 ms, this would be happening, but would be hard to notice due to the speeds involved. As long as the server dealt with collisions appropriately, regardless of what was seen, I don't see a problem with it.
The second is over work on their own Graphics card. I guess this could be toned down by some type of default animation, and removal of the ability of players to watch their travel at speeds over a certain level. Kinda like the spirals seen on the Millennium Falcon cockpit when it entered hyperspace.
When I did the Catapult, I saw literally no change in the screen until I was already at 30K distance, and had slowed to 3,000 MS. I suspect everyones system will be able to cope with this differently, much like the lag being caused by the trail effects.
The second is over work on their own Graphics card. I guess this could be toned down by some type of default animation, and removal of the ability of players to watch their travel at speeds over a certain level. Kinda like the spirals seen on the Millennium Falcon cockpit when it entered hyperspace.
When I did the Catapult, I saw literally no change in the screen until I was already at 30K distance, and had slowed to 3,000 MS. I suspect everyones system will be able to cope with this differently, much like the lag being caused by the trail effects.
could just have the graphics settings go WAY down when the burst occurs but some of us are already at or near the bottom of the graphics settings just to be able to fight.
liddy, very good idea, however just to re-configure the graphics I think your computer would need to take a couple of seconds...
There's another way to keep this from being abused in combat; make it require an addon. (Or five, to be effective in a Ragnorak, 3 for a Centaur...) Or, make a special Power Cell for it that recharges very slow, but is good for "popping" for some reason.
[edit]This is true, Strat. Wasn't thinking. Ignore above statement, please. =p[/edit]
[edit]This is true, Strat. Wasn't thinking. Ignore above statement, please. =p[/edit]
Na, SuperMegaMynt. You don't want the ship to be useless. I don't see this as an add-on sort of thing, just an additional built-in feature of the propulsion system. People still need to be able to fight, just not suddenly jump away from a fight.
From Above:
The regular turbo is not available during the charge up time.
There is a minimum of 10 seconds worth of storage, or the “pop” fizzles.
I did some math and testing.
Turbo appears to have a 3X factor to the ships N Trust.
It takes a thrust of 500N of force to push 1,000,110 KG of mass to speed 50, in about 17.97 seconds.
So extrapolating the math.
A Serco vulture popping after 60 seconds of build up, with a mass of 4710 KG would reach a top speed of 18345ms.
A Moth with 1,000,110 mass would only reach 180 MS.
That said, due to the physics of the rubber band on over speed, a moth would slow down much slower, so that reaching 5400MS (30 Min charge time) in a ship with that much mass could take it as far as a vulture at the 18345, speed.
I would have to do more math, but perhaps the "pop" should always take 60 seconds to "charge", and then take the player the desired distance, with all the required calculations for force etc, being automatic.
The regular turbo is not available during the charge up time.
There is a minimum of 10 seconds worth of storage, or the “pop” fizzles.
I did some math and testing.
Turbo appears to have a 3X factor to the ships N Trust.
It takes a thrust of 500N of force to push 1,000,110 KG of mass to speed 50, in about 17.97 seconds.
So extrapolating the math.
A Serco vulture popping after 60 seconds of build up, with a mass of 4710 KG would reach a top speed of 18345ms.
A Moth with 1,000,110 mass would only reach 180 MS.
That said, due to the physics of the rubber band on over speed, a moth would slow down much slower, so that reaching 5400MS (30 Min charge time) in a ship with that much mass could take it as far as a vulture at the 18345, speed.
I would have to do more math, but perhaps the "pop" should always take 60 seconds to "charge", and then take the player the desired distance, with all the required calculations for force etc, being automatic.
It's kind of like a cross-breed between an in-system jump and turboing.
It's a neat idea. Although I'm sure my video card wouldn't be able to render it, at least we could get to faraway places in-sector very quickly. That would be pretty cool.
It's a neat idea. Although I'm sure my video card wouldn't be able to render it, at least we could get to faraway places in-sector very quickly. That would be pretty cool.