Jump to content

KSP Loading...: Sharing Horizons with ESA


UomoCapra

Recommended Posts

49 minutes ago, Superfluous J said:

The Kerbals were so amazed that two such different shaped/sized/nozzled engines would have EXACTLY the same stats from mass to Isp, they decided it would anger the Kraken if they renamed it now.

 

47 minutes ago, Poodmund said:

 

There is scope here to tailor this engine motor model/part as a new part, tailored to the included Ariane 5 craft, even if to make it Aestus like in its own regard.

Even if SQUAD does not make the new variant a separate part (which would make more sense than having it as a Poodle variant) it wouldn't be too hard to make it into a standalone engine with a Module Manager patch. Just increase the mass and vacuum Isp a bit to account for the longer nozzle, add some kind of suffix to its code name (perhaps something like RE-L10-L) and give it a dog name, in keeping with the Terrier and Poodle.

Link to comment
Share on other sites

Keep in mind too that Kerbal is still a game for players with a variety of different skill levels.  Having similar sized engines that fill the same niche but with  slightly different stats sounds great to a veteran.  For a newer player, it can be confusing, and the poodle is fairly early in the tech tree.

Plus, once that design decision was made, we'd then have to carry it through, making dozens more engines, and figure out how to add them without having some engines that overshadow others.

Link to comment
Share on other sites

39 minutes ago, Maxsimal said:

Keep in mind too that Kerbal is still a game for players with a variety of different skill levels.  Having similar sized engines that fill the same niche but with  slightly different stats sounds great to a veteran.  For a newer player, it can be confusing, and the poodle is fairly early in the tech tree.

Plus, once that design decision was made, we'd then have to carry it through, making dozens more engines, and figure out how to add them without having some engines that overshadow others.

I think this is the right decision. Also, I note that part variants can have different masses, could they have different thrusts?

We could have just 1 "vacuum optimized, 2.5m diameter" engine, and then have a couple variants of it for fine tuning to our designs.

As it is, I already feel the Reliant and the Kodiak are very similar. The poodle and the Wolfhound fill the same niche (with the wolfhound just being a bit OP with its Isp), the skiff and the Skipper fill the same niche - well, I think they should fill the same niche but the Skiff's thrust is too anemic to be worth it, and I find it not very useful after its TWR nerf.

I think part variants is the way to do it, but if the part variants can have slightly different stats for some tweaking, that would be great.

For instance, this variant has a single nozzle, and thus one doesn't get any roll control from thrust vectoring. If everything else is the same, then it is objectively worse. If it is instead a little lighter, has 5 more Isp, or 10 kN more thrust... something like that, that would be great.

If different part variants can have different stats (They can already have different masses), that would open up a lot of creative possibilities. You could then have variations of the nozzle length: Eve optimized, kerbin sea level optimized, vacuum optimized, etc. Then you could have just a few "base" engines for each size. A large variant, and a small variant (like reliant vs terrier). You could even have swivelling/non swivelling (like reliant vs swivel). For the large variant of each size, you could have a high TWR low base Isp (still affected by nozzle shape), representing a kerlox rocket, and a lower TWR higher Isp engine representing a Hydrolox rocket.

IMO, part variants for each engine is much better than cluttering up the parts menu.

Link to comment
Share on other sites

1 minute ago, KerikBalm said:

I think this is the right decision. Also, I note that part variants can have different masses, could they have different thrusts?

We could have just 1 "vacuum optimized, 2.5m diameter" engine, and then have a couple variants of it for fine tuning to our designs.

As it is, I already feel the Reliant and the Kodiak are very similar. The poodle and the Wolfhound fill the same niche (with the wolfhound just being a bit OP with its Isp), the skiff and the Skipper fill the same niche - well, I think they should fill the same niche but the Skiff's thrust is too anemic to be worth it, and I find it not very useful after its TWR nerf.

I think part variants is the way to do it, but if the part variants can have slightly different stats for some tweaking, that would be great.

For instance, this variant has a single nozzle, and thus one doesn't get any roll control from thrust vectoring. If everything else is the same, then it is objectively worse. If it is instead a little lighter, has 5 more Isp, or 10 kN more thrust... something like that, that would be great.

If different part variants can have different stats (They can already have different masses), that would open up a lot of creative possibilities. You could then have variations of the nozzle length: Eve optimized, kerbin sea level optimized, vacuum optimized, etc. Then you could have just a few "base" engines for each size. A large variant, and a small variant (like reliant vs terrier). You could even have swivelling/non swivelling (like reliant vs swivel). For the large variant of each size, you could have a high TWR low base Isp (still affected by nozzle shape), representing a kerlox rocket, and a lower TWR higher Isp engine representing a Hydrolox rocket.

IMO, part variants for each engine is much better than cluttering up the parts menu.

thats sorta what BDB did, Its cool and I would like functional engine variants but I doubt the devs would add that

Link to comment
Share on other sites

Dumb question - do the flags count against the part limit? If so, they will not really be that usable on career until you hit tier 2 of the VAB/SPH. For that matter - is it possible to make launch clamps not count against the part limit? Seems rather silly to have something that doesn't actually fly on the rocket count against the part limit.

Link to comment
Share on other sites

18 hours ago, UomoCapra said:

xXrEVnbGSGv_wWEHvwhWciiP3ckqd3Gd-PMEfsjnyYsbj1ylXKwxFA_oKyIQbCRInSmdKKYxJGEcKiquS68a0Bn7_FgG76ONvVoBrJqC8CS5afqT5-5ISmQq

 

5e42GBhmaibeULuLBZ2DlQtzPrLg2crAw_CzarpbjykuagLsu7qWFE28TwISj7yQzFQGJvdmjSoRnt3hlyRVsXr-SEeRXU5x6dFbSKG2znmGRpH_3Fy9rO1r

 

ZlHxYVRQpqSkej_LnXhNFcDpr4UfHsWl20DNoa2Q

sGWg13lSkXeQr-HNBdLkms1JOOO843SJnaRAvR00SyKVWLeFXe15v0GXJ0OR1_oCuB5U92sOV7gIF8aakMNyy2SH7Z8zifsYuiEx8VaT7GtUgDDpAv97fk4M

imC-DtBt_YxQMne61vchNwW7vUncU0LRBCy2ZnyJ

ylzVYPpyBfD13f5uShk6ttXy5RTR0SX9YIY5zygX

Looks pretty good imo.  I like the new parts as they deviate from the rather dull and overused cylindrical everything (i totally understand why real rockets are that way as its a structurally strong shape, but no scifi movie i recall actually had starships that were cylinders in their entireity, not even the more organic looking ships were truly cylindrical).  Im still not 100% sure what ill be using them for, but at the least ill probably integrate them into some sort of low part count bridge design (very hard to make a good looking bridge right now without eating alot of parts into it as i need to use wings or structural panels to build it out of).

The comets seem cool, hopefully they will be movable like asteroids as i totally want to make a starbase out of a comet and obviously move it somewhere genuinely useful like orbit around a planet or so).

6iUBL1k.png

Flags are also neat, nnot really gamechanging, but defenetely improvement to immersion when i cab finally properly label my different faction's warships and not rely on the tiny and awkwardly places flags on command pods (which are often at least partially clipped into the hull anyways), or relying on that huge tail wing thing with a built in flag decal (ive used those on a few ships, but with 1 exception (where it just fit perfect as a component of the ship), they tend to look out of place and forced on most ships that arent like SSTOs or aircrafts.

 

 

As for the tiny grabber, thats something that seriously makes the game massively better.  It will make my parasite fighters much easier to build as previously i literally had to build them around the standard klaw which looked awkward and had to be clipped excessively to get anything useful out of.  Now it means i can more or less build a starfighter i like the look of in of its own, and slap a mini-klaw on afterwards (itll still require some though as to how it fits on, but its smaller so i can always stick it on different directions and such.

HYmD4MS.png

0IMnUVi.png

I managed not all that badly up to now, but it still just looks really awkward having rthat massive bulge sticking out of the bottom just to make the fighter capable of landing on the surface of a capital ship and not be 100% reliant on assault carriers (or even the unarmored unarmed dedicated carriers which i dont really use much anymore as they are useless in any sort of fights).  Also a bit unrelated, but since we get a better texture for the klaw, can we also have the old one updated at least with the white texture or even the whole model.  Its not a genuinely bad looking part, but its aged quite a bit from its release and could use a bit of a polish.

 

Fairings look alright, hopefully they fixed the horrendous texture (missing mipmaps) and normal map (flipped so one side sticks out and other side sticks in) bugs associated with these.

MPvLEWU.png

9KpjGTE.png

These are from a post a while ago, no idea if anyone noticed (or even bothered to care), but this bug alone is why i really avoid fairings as they look extremely janky and its very very difficult to not notice especially on the white/BW models which feature much ore distinct normal maps, but even the orange one is dead obvious when zoomed in closer).  Ill have to see what they release to determine if i still need to keep deleting the normal map and using flat parts as i cant stand this bug (which is also present in restock btw as it reuses the model from the base game).

 

Now what i really like are the new shiny round tanks, obviously inspired by/stolen from restock mod, but i like these better (assuming the normals arent messed up or something) as they have those dark lines dividing segments unlike restock's models which lack them.

Strut varianst are welcome, but i still wish they redid the awful 3d model of the bases which often needs to be rotated to align with the part its mated to (unless the parts are parallel, one side will be at weird angle.  I suggest making the base a circular shape (like the place anywhere sinle RCS thruster or similar) so that nomatter the orientation it doesnt ever look out of place or weird (and lets face it, even if they choose a square end it could look much prettier then the terrible 3d model we have now).  Fuel lines arent too bad imo though, and they may as well keep it a similar shape to the dump valve.

Engine looks nice, and i welcome a asthetic taste choice to the poodle (i do actually like the dual engine we have now, but the choice to use this model even if its identical stats is cool.

SRB seems to be updated, nothing really special about it but at least fits the rest.  Ans the new texture for the 2.5m tanks ill have to see in game as ive not really been very impressed with the 2.5m revamp (i mean in some ways i even miss the oil drum textures which looked amazing in refineries, now i ned to use the ore tanks for asthetics in refineries as the 2.5m tank doesnt fit whatsoever in that environment.  THe grey looks like it might let me use them now, so ill have to see.

 

Anyways, looks to be a decent update (assuming it doesnt break every mod im running like a few have as thats always annoying to deal with). 

Edited by panzer1b
Link to comment
Share on other sites

2 hours ago, Maxsimal said:

Keep in mind too that Kerbal is still a game for players with a variety of different skill levels.  Having similar sized engines that fill the same niche but with  slightly different stats sounds great to a veteran.  For a newer player, it can be confusing, and the poodle is fairly early in the tech tree.

Plus, once that design decision was made, we'd then have to carry it through, making dozens more engines, and figure out how to add them without having some engines that overshadow others.

Engine variants are a nice idea, but for something so radically different shape and size a separate part seems a no brainer :D

Edited by Beale
Link to comment
Share on other sites

2 hours ago, Maxsimal said:

Having similar sized engines that fill the same niche but with  slightly different stats sounds great to a veteran.  For a newer player, it can be confusing, and the poodle is fairly early in the tech tree.

Couldn't the same argument be made about the Swivel/Reliant?

Swivel has gimbal and very little higher isp, reliant has no gimbal but slighly higher thrust. Otherwise pretty much the same.

 

Link to comment
Share on other sites

2 hours ago, Maxsimal said:

Keep in mind too that Kerbal is still a game for players with a variety of different skill levels...  for a newer player, it can be confusing..

I agree that all games need to have a level of entry as to not put off new players from progressing past the early game but the last time this justification was used we were told that Δv and TWR readouts were unecessary to the Vanilla game because they are too confusing to the player.

I would ask that you don't sell your playerbase short by considering them to all be simple.

Edited by Poodmund
Typo
Link to comment
Share on other sites

1 hour ago, matteeeo said:

Will comets behave like very big asteroids, or will they have their own weak gravity and small SOI?

The former - and I suspect it's not an issue of willingness on Squad's part, but rather a hard limitation of the game engine that makes it impossible to assign gravity and spheres of influence to anything not permanently on rails.

KSP uses a two-body gravity simulation. An object's orbit is defined solely by the gravity well of its parent body, and nothing else. Your spaceship's low Mun orbit is influenced only by the Mun, nothing else. The Mun's orbit is influenced only by Kerbin. Kerbin's orbit is only influenced by the Sun. This entire construct is what gives rise to spheres of influence in the first place (which do not exist in a proper N-body simulation). They are an artificial boundary at which the game engine decides to switch the parent body of an object, and therefore changes the one thing that influences that object's orbit.

Spheres of influence are, as the name suggests, spheres - as a result of simply setting a constant that says "you must be this far from a body to leave its sphere of influence". This is not a realistic approach, but then again, neither is a two-body gravity simulation. It's a simplification, made both for the sake of gameplay as well as for the sake of performance.

And unfortunately, there is a situation where this whole construct comes crashing down like a house of cards. Namely, when you have two bodies that share the same parent body, and can come close enough on their respective orbits that their spheres of influence intersect. Like, imagine if Minmus was on an eccentric orbit with a periapsis just a thousand kilometers above the sphere of influence of the Mun. They would never collide, or actually enter each other's SoIs; the distance is more than big enough for that. But sometimes, their spheres of influence would intersect. There would occasionally be, for a few hours, an area of space that is inside the Mun's SoI and inside Minmus' SoI at the same time. But this is a two-body simulation. A spacecraft's orbit can only ever be influenced by one parent body. Which one applies? From the game engine's point of view, the answer to this question will likely be "critical exception" or "division by zero" or other such delightful stuff. And no, the spheres of influence cannot "squish against each other" to dynamically form a common boundary. Remember, the sphere of influence is really just one single, fixed number that says "you must be this far away to leave".

You have never before thought about this problem because the KSP solar system is built specifically so that there cannot possibly ever be a situation in which two spheres of influence overlap. Not even at Jool with its bevy of moons. All of the orbits keep well away from each other, and this is by design. Both for the realism aspect (if this was a N-body simulation, objects coming this close to one another would immediately ruin each other's orbits), and for preventing that big no-no case from ever occuring.

And now, consider what happens if you give players an object that has a sphere of influence, and that object is not on permanent rails. It can be moved. Its orbit can be changed to intersect another SoI. It can be landed on the surface of celestial objects. It can be collected in piles of a dozen in a single spot, because the game spawns an infinite number of them if you simply wait long enough (or use the debug menu).

...Yeah, that's not going to end well for anyone involved, is it? :P

So, unfortunately, there are only two possible options here:

  • Add one or two comets to the Kerbin system as fixed, permanently on-rails, celestial objects. Their orbits would be designed so that they never come near any other celestial body. They would have gravity, and a sphere of influence, and their own names, and so on. They would work exactly like Gilly does, except with perhaps even less gravity. You would always have exactly these one or two, with exactly the same model and texture and parameters. No more would ever spawn, and there is no discovery mechanic. You could not move them, or claw into them.
  • Add procedurally generated comets that use the asteroid base mechanic. There will be an infinite amount of them, given enough time, and they will gradually appear and disappear again (if ignored). This provides unique challenges that are slightly different in every playthrough, or even in different phases of the same playthrough. They can have different shapes and sizes and textures. They can be intercepted and moved to new orbits by the player, and given custom names, and/or incorporated into space stations. They are allowed to enter and exit spheres of influence like a spacecraft does, so If they happen to cross a sphere of influence other than the Sun's, their orbit will be believably deflected by that gravity well. But they will not have gravity or spheres of influence of their own.

Pick one. You cannot have both. And so, Squad made their choice.

 

Edited by Streetwind
Link to comment
Share on other sites

22 minutes ago, Poodmund said:

I agree that all games need to have a level of entry as to not put off new players from progressing past the early game but the last time this justification was used we were told that Δv and TWR readouts were unecessary to the Vanilla game because they are too confusing to the player.

I would ask that you don't sell your playerbase short by considering them to all be simple.

Wasn't around when rationale was given - but dV was put in in a way that helps highlight how it works with the stage stack, and TWR is only shown when you click on the stage stack to get more info, something people do as they get comfortable with the UI.  Maybe at the time the developers were reacting to the way mods like KER and Mechjeb present the info which can be a bit of information glut for the unprepared.

Games like this have a life cycle where you learn what's needed, and where to put those needed items for better and better UX.  For most game genres, this occurs over multiple games with multiple developers.  KSP is unique in a lot of respects, and one of the ways is that it has a long history of iterative development within the title itself.

 

26 minutes ago, GrandProtectorDark said:

Couldn't the same argument be made about the Swivel/Reliant?

Swivel has gimbal and very little higher isp, reliant has no gimbal but slighly higher thrust. Otherwise pretty much the same.

 

The player learning how engine gimbal works is the reason those exist, and the difference between some gimbal & no gimbal at all is pretty significant.

Link to comment
Share on other sites

20 hours ago, raptor30 said:

so no clouds? :(

They are probably not planning on adding that. The problem is, it will probably run slow on a lot of people's computers. (I guess it could be togglable in the settings, but there are good mods that add clouds.)

Link to comment
Share on other sites

3 minutes ago, KazBodnar said:

They are probably not planning on adding that. The problem is, it will probably run slow on a lot of people's computers. (I guess it could be togglable in the settings, but there are good mods that add clouds.)

Agree with you

Link to comment
Share on other sites

37 minutes ago, KazBodnar said:

They are probably not planning on adding that. The problem is, it will probably run slow on a lot of people's computers. (I guess it could be togglable in the settings, but there are good mods that add clouds.)

 

The same thing could be said for all these texture revamps; they've left a toggle to use the legacy for low spec systems.  That's like saying don't do any part or planet revamps, because we call all download mods instead.

Link to comment
Share on other sites

Awesome!!!Cant wait!!!

Will the comets appear in current savegames as well?

Will they be in tracking station or only when taking missions?

Sry if these questions have been answered before :p.

Edited by Boyster
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...