Halley Placement

Should the placement of the engines matter? Eg, putting them in the western hemisphere will result in a potentially longer manoeuvre compared to building them in the eastern hemisphere.

stuff like that will probably be put in much later mate i should think but the point is very valid

yes it should.

And Uber for the Umpteenth time create an engine building gimmic so that they are lined up! I might sound a little picky but this is more than very immersion-ruining.

I'd like it. Most people build them in the same area anyway. It looks silly when there are halleys all over the place though.

I dont think so. Well I mean, technically it should matter but I don't think the intention of the game is to create such a detailed orbital simulation, but rather to create an approximate abstraction of the mechanics involved.

It's essentially a cost and benefit analysis. If a requirement of placing the engines in physically plausible locations positively impacted the game by creating fun and challenging gameplay then they might well implement such a feature. As it stands, the only plausible benefit of simulating this would be having to fight over ideal placement locations, but I dont think this is within the scope of the mechanics as Uber currently envision them. Rather they would spend time adding a feature that would benefit essentially no one except a fairly small section of the community. As it stands, we are just supposed to accept that the Halley is able to solve a trajectory regardless of where they are placed - a little suspension of disbelief is required. This does look strange when you require two halleys but build them on opposite ends of the planet - the propulsion would be cancelled out you would think. Maybe they should create a hardcoded restriction that required halleys to be built touching each other (or at least very close) to avoid such situations.

The celestial gameplay is essentially "fudged" in a lot of ways (at least, it appears that way - I don't know for sure) - it is not, apparently, a 100% accurate simulation (but then no one would expect it to be), the halleys do not solve an accurate solution for collision, but rather have their general orbit adjusted in a plausible way within a certain range of the target in order to "intercept" the orbital path. Once intercepted, it appears a "collision script" takes over which (sometimes quite jarringly at present) moves the asteroid into a position from where it can drop onto specific location the player has selected on the planet.

I dont doubt they will improve the simulation as it stands, but I dont think it is realistic for them to spend development time worrying about velocities, angles, rotations and all the other necessary components of a truely simulated orbital collision down to the level of worrying about optimal halley placement.

In saying that I would love if the mechanics in the engine were exposed enough to allow for industrious modders to add this kind of granularity to the game for people who want to play Kerbal Annihilation.

It might look silly, but realistically speaking you have to.
Since if you only have engines on one side, you can only accelerate, not decelerate.
Unless the rotation of the planet moves your engines so they point at your prograde vector, in which case you would decelerate.

And even if you have engines at the 'front' and 'back' of the planet, you need engines to manouvers at the 'top', 'bottom' and 'sides' as well.

It's really best to spread them out to minimize the damage they will take when you get nuked.

naaah. it's good where it is. we're already so far departed from "realistic" (in favor of AWESOME) that trying to get realistic with the halleys will not only be pointless, but detract from gameplay. (I have to find the unobstructed real estate to build them in a certain configuration/proximity? what happens when I've built 2 and can't fit the 3rd?)

Couldn't agree more.
Really should have made that clearer in my previous post come to think of it.

Like this? (Nostalgia alert)



They are lined up and angled correctly, kinda. They LOOK awesome. But does it matter gameplay wise? As long as you don't put one and then another directly on the opposite side of the planet. I don't like physics anyway.

http://www.youtube.com/watch?feature=player_detailpage&v=T4kvsGCCTuo#t=630

plus Neutrino said on one of the livestreams he'd find it pretty cool if the players could have Hailley tugs of wars with the planets. effectively so far building a halleiy on the same planet as your opponent is -1 hailley to him. but it should be upgraded to a tug of war with engines lit is possible.

Realistically you would just want to tilt them so the total thrust vector goes through the center of mass. The placement initself isn't that bad it's where they are pointing.

Something I mentioned the last time his game up was that maybe we should think about a different approach to the model itself to help correct the isse to some degree. My idea is to model the engines such that they are mounted on something like a gimbal and could swivel some degrees in any direction, kind of like Vectored Thrust in a way. Maybe I'll do a mockup at some point.

Mike

Yeah "it'd be cool" and "it's feasible" don't always intersect unfortunately, but if they do add a lot more detail to planetary collisions that would be interesting too. For example, having power cut out to halleys mid transit resulting in the asteroid colliding with the sun, missing the target or leaving the solar system. Those would be hilarious features but I dont think we'll see them. I think the chances of the adding "failed attempts at planetary collision" are slim at this point, but we shall see (aside from planetary defences as seen in the teaser trailer)

At the moment it seems there are essentially two games running in PA. One models the oribital pathways in a 2d gravity plane simulation, the other models the planets (and units) in a 3d simulation. The orbital pathways and bodies corespond to a 3d planet, but they are still separate in reality. That's why an asteroid does not smoothly impact on a designated location, because the celestial view is a 2d simulation and cant calculate an impact onto a 3d point in space or on the surface of a planet. In order to cross the boundary into the 3d planetary shell, it needs to be fudged at present using what seems to be an impact script of sorts. When an asteroid reaches the intercept point in the 2d simulation the game "cheats" and places it into the 3d planetary simulation. I think they'll be able to smooth this out in the future, at present it can produce some strange looking pathways.

It would be nice if this changed in the future but at present it looks like a hardcoded limitation of how the engine is set up.

Note this is all speculation on my part, but I think it's pretty much correct.

Cutting power just makes you fall, that is continue on your current orbit. Realistically you don't accidentally fly into the sun or out of system. Those two manuvers are one of the most energy consuming manuvers requiring the longest of burns.

Orbiting can be defined as a perpetual falling, just you go so fast that you keep missing it.

I would say, screw realism in this aspect of the game. Let alone that a celestial body has a spin and rotates anyway by default. Even if fascinating in principle, having to realistically place halleys it surely is a complication that I (for one) do not feel is needed game-play wise.

ps. Physic is just awesome.

ps2. Kerbal Annihilation could be quite a cool mod of KSP, or PA as well.

did you by any chance follow the link I gave and watched the video?

I remember watching that live, it doesnt change what I was saying in that at present there are a couple of flaws in the model they use to simulate collisions (it seems). That is, targeting a point in 3d space using the 2d gravity model requires some "close enough" and ultimately scripted behaviour which currently looks odd in some cases. the 2d model would only - if I understand correctly - be able to calculate an intersect along the equator of a planet (assuming no axis tilt in that case).

Secondly, It isnt clear if the 2d simulation for calculating collisions accounts for planet size - often collisions in the 2d model appear to "miss" before the 3d collision calculation script "snaps" them into the correct position for them to fall onto the 3d coordinate. Likewise the 2d model doesnt account for planetary rotation, all it really seems to be aware of is the centre coordinate of the entire planet which it aims for, then triggers a collision script (with accompanying music) when it reaches a "close enough" position.

it's an interesting setup which will hopefully see some refinement before launch.

Not necessarily, it could be tidally locked.

Perhaps halleys should have a "radius range of effect" thats scales to the current halley numbering system.. and all of the surface area of the body needs to be covered it this "range" for halleys to work. Then the game makes calculations based on relative position of motion or force vector with respect to each halley.
After those "Easy" calculations are made it will tell halleys that face away from the desired vector, with angular deviation parameters of course, to trigger their firing animation.
In reality placing thrusters all over the boddy would be a easyier way to maneuver the body as thrusters not properly alligned with the desired motion vector can thrust vector to aid mobility.
Im not asking to see thrust vectoring halleys... although it would be nice.... but just to find a way to make animations sync up.
I think this would work, and i perso.al would choose motion vector calculations as opposed to force because motion is the most visualy informative data point we can use in game... not the numerical value but just watching something move provides information on its own.

Force vectors wont dont really matter (****from a gameplay stand point****) because they have a tendency to not always be in line with the motion vector of choice. Which is the celstial bodies path of travel for us..