KSP2 would be even better with a standalone VAB/SPH craft editor so one can work on craft whenever one wants to

[darthgently]

See subject.  Subject edited to be more broad.

One could work on craft while mining enough fuel to continue a mission

One could work on craft during long burns

One could work on craft while Scansat scanning

One could work on craft without running the entire program, like maybe even on a smaller, less powerful notepad computer, while on the train or bus

Who knows what the possibilities are if one had a standalone craft editor.  Especially if the craft could be imported via wifi to the console game also.

Edited June 28, 2021 by darthgently

[jimmymcgoochie]

A long title with an empty body won't persuade anyone. WHY do you think this would be a good thing, how would it be beneficial to add this to the game, what about people who don't have more than one screen?

[darthgently]

I state why it would be a good idea in the "long title".  I'm sorry you find the long title a problem.  I'm not the only one who appreciates a title that allows one to know what a thread is about without drilling down on it.  It is a one sentence suggestion.  Why take more than one sentence.  I could probably be convinced otherwise, but haven't read a convincing argument yet

People who don't have another screen don't have to use the *standalone* editor.  The in-game editor would still be there of course.  I'd pay $14.99 for a separate standalone craft editor.  Am I the only one?

[The Aziz]

I know of one: it's not needed because we won't have to be focused on one craft during long burns. Interstellar voyages will take at least decades, I don't see why would I need to watch my mothership burn one way for half a journey and then spend the other half burning retrograde to slow down. Same applies to any interplanetary trips. You set it up, you fire it, you leave it, you timewarp, you get back when it's done.

[darthgently]

43 minutes ago, The Aziz said:

I know of one: it's not needed because we won't have to be focused on one craft during long burns. Interstellar voyages will take at least decades, I don't see why would I need to watch my mothership burn one way for half a journey and then spend the other half burning retrograde to slow down. Same applies to any interplanetary trips. You set it up, you fire it, you leave it, you timewarp, you get back when it's done.

I'm not sure if you are agreeing with the idea or not.  Maybe you have an extra "not" in there.  What harm does it do to you if someone else works on a craft while a burn is happening?  Does NASA stop working on the next launch system while a probe burns toward Mars?  The player takes the place of many roles in the game which in reality would be working in parallel.  I use my kOS scripts for most of my play, so there really isn't anything for me to do during a burn.   If I carve out time to play the game, I want to play it

Edited June 27, 2021 by darthgently

[MKI]

Might be solving the wrong problem with this sorta feature.

If your "bored" during long burns, KSP2 shouldn't let you get bored during long burns.

As mentioned above, the right way to fix this is to manage "long burns" differently, which I think is already a feature. That way you get get back to building the next awesome thing in the full on editor, or get to your destination without waiting several minutes watching engines firing. I can't see KSP 2 launching where we need to wait hours or even days to get up to a percentage of light speed using an orion drive haha. 

 

On the topic of "multiple screens", there are other possible feature that would be nice here, such as multiple cameras/pop-out windows, similar to Microsoft Flight Simulator X. However, I'd see that sorta of support as an amazing nice to have for those with big setups and that's it, while also being 100% useless for console players, so I can't really see any work being committed to that sorta feature. But I digress ;D

[darthgently]

32 minutes ago, MKI said:

Might be solving the wrong problem with this sorta feature.

If your "bored" during long burns, KSP2 shouldn't let you get bored during long burns.

As mentioned above, the right way to fix this is to manage "long burns" differently, which I think is already a feature. That way you get get back to building the next awesome thing in the full on editor, or get to your destination without waiting several minutes watching engines firing. I can't see KSP 2 launching where we need to wait hours or even days to get up to a percentage of light speed using an orion drive haha. 

 

On the topic of "multiple screens", there are other possible feature that would be nice here, such as multiple cameras/pop-out windows, similar to Microsoft Flight Simulator X. However, I'd see that sorta of support as an amazing nice to have for those with big setups and that's it, while also being 100% useless for console players, so I can't really see any work being committed to that sorta feature. But I digress ;D

Ok, what is your idea to make long burns more "exciting"?  I'm curious

I edited the subject to better reflect the idea.  I also added more text to my first post which I'll repeat here.

One could work on craft while mining enough fuel to continue a mission

One could work on craft during long burns

One could work on craft while Scansat scanning

One could work on craft without running the entire program, like maybe even on a smaller, less powerful notepad computer, while on the train or bus

Who knows what the possibilities are if one had a standalone craft editor.  Especially if the craft could be imported via wifi to the console game also.

[MKI]

36 minutes ago, darthgently said:

Ok, what is your idea to make long burns more "exciting"?  I'm curious

Remove the idea/problem of "long burns" in its entirety because they aren't exciting. 

There's a number of ways to deal with the problem, from multiple levels and implementations of automation to execute the task without you sitting there in realtime, to removing the need to deal with long transfer burns in its entirety, where they are executed automatically without you paying attention.  

I'd compare it to interactive loading screens, sure the game will be more fun if I can run around while the next area loads. Or better yet just remove loading screens so I can keep doing whatever I wanted to get to in the first place.

 

 

Edited June 28, 2021 by MKI

[darthgently]

1 minute ago, MKI said:

Remove the idea/problem of "long burns" in its entirety because they aren't exciting. 

There's a number of ways to deal with the problem, from multiple levels and implementations of automation to execute the task without you sitting there in realtime, to removing the need to deal with long transfer burns in its entirety, where they are executed automatically without you paying attention.  

I'd compare it to interactive loading screens, sure the game will be more fun if I can run around while the next are loads. Or better yet just remove loading screens so I can keep doing whatever I wanted to get to in the first place.

 

 

I like the realism of long burns, but I automate them via kOS scripts I've written.  I gotta say this:  Of all the games I've ever played, KSP by far has more ways and style that it can be played.  So I don't get it when people even have an opinion about how someone else should play it.  I put these suggestions in for the dev team and constructive feedback.  If it isn't a feature you would use, no one would force you to use it.

But I bet even console users would be interested in a stand-alone craft editor with a smaller footprint than the main program (which would still load the same editor within the program) especially if they could import the resulting craft onto the console and finish editing it there, launch it, etc.

[MKI]

Just now, darthgently said:

So I don't get it when people even have an opinion about how someone else should play it.  I put these suggestions in for the dev team and constructive feedback.  If it isn't a feature you would use, no one would force you to use it.

Its not so much "this feature is bad! It should never be in the game!" rather is the feature worth spending dev time on to add support for when a simpler solution would solve the same problem, while also making the overall game better for more people and situations. 

Adding the build editors into the flying mode would require changes to the game to essentially load 2 scenes in itself. Not only could this lead to performance issues, but I would assume would require a heavy rewrite of the flight mode of the game to support a whole other context within itself. Something as simple as what does a given key do would require a whole re-write of the flight mode of the game to take into context this other "scene within a scene". Not a cheap proposal in terms of dev time.

Take this example, if switching between the VAB and flying mode took .1 second you technically have your feature you're looking for, except your engine couldn't run while you switched between the 2 scene. Fix that problem and the underlying reason why you'd want the original feature of having the build editor while flying is also fixed, along with supporting other people who don't have a monster computer that loads scenes in .1 second. 

 

6 minutes ago, darthgently said:

But I bet even console users would be interested in a stand-alone craft editor with a smaller footprint than the main program (which would still load the same editor within the program) especially if they could import the resulting craft onto the console and finish editing it there, launch it, etc.

This has a similar reasoning, the dev time to build a "simpler" editor could also just be used optimizing the normal editor for console. Solves the same problem but (hopefully) requires less work now and later, as players and developers only have to deal with 1 editor rather than 2. 

 

13 minutes ago, darthgently said:

If it isn't a feature you would use, no one would force you to use it.

If not enough people use it because it's not widely useful it might actually be a waste of dev time that could be spent on more core features, this is especially true for features that require more work than something simpler that is easier to support (like new parts)
 

[darthgently]

25 minutes ago, MKI said:

Its not so much "this feature is bad! It should never be in the game!" rather is the feature worth spending dev time on to add support for when a simpler solution would solve the same problem, while also making the overall game better for more people and situations. 

Adding the build editors into the flying mode would require changes to the game to essentially load 2 scenes in itself. Not only could this lead to performance issues, but I would assume would require a heavy rewrite of the flight mode of the game to support a whole other context within itself. Something as simple as what does a given key do would require a whole re-write of the flight mode of the game to take into context this other "scene within a scene". Not a cheap proposal in terms of dev time.

Take this example, if switching between the VAB and flying mode took .1 second you technically have your feature you're looking for, except your engine couldn't run while you switched between the 2 scene. Fix that problem and the underlying reason why you'd want the original feature of having the build editor while flying is also fixed, along with supporting other people who don't have a monster computer that loads scenes in .1 second. 

 

This has a similar reasoning, the dev time to build a "simpler" editor could also just be used optimizing the normal editor for console. Solves the same problem but (hopefully) requires less work now and later, as players and developers only have to deal with 1 editor rather than 2. 

 

If not enough people use it because it's not widely useful it might actually be a waste of dev time that could be spent on more core features, this is especially true for features that require more work than something simpler that is easier to support (like new parts)
 

You need to read a lot more carefully.  *STANDALONE* editor.  As in you can edit a craft *OUTSIDE* of KSP.  I don't know how much more clear I can be than the subject.  Maybe "standalone" isn't as commonly understood a term as I thought

26 minutes ago, MKI said:

This has a similar reasoning, the dev time to build a "simpler" editor could also just be used optimizing the normal editor for console. Solves the same problem but (hopefully) requires less work now and later, as players and developers only have to deal with 1 editor rather than 2. 
 

The code would be the same.  But would be compiled twice; once to a standalone programs, and once as normal as part of the main program.  There would be a little release overhead, but once the right adjustments had been mand it would be ONE codebase generating both flavors.  This is not rocket science

28 minutes ago, MKI said:

If not enough people use it because it's not widely useful it might actually be a waste of dev time that could be spent on more core features, this is especially true for features that require more work than something simpler that is easier to support (like new parts)

 

I'm going to just leave it here for the devs and other employees working on KSP and let them decide.  Your feedback has been interesting and appreciated

[Bej Kerman]

This won't benefit many people - probably 1 at most - and will only further bloat KSP 2 with niche features that will probably come out as 3rd party applications.

12 hours ago, MKI said:

Remove the idea/problem of "long burns" in its entirety because they aren't exciting. 

KSP 2 will let rockets do burns in the background while the vessel is not loaded (automated milk runs may even extend to massive interstellar ships) and timewarp will have a much higher limit for long burns. This has probably already been solved.

[darthgently]

3 hours ago, Bej Kerman said:

This won't benefit many people - probably 1 at most - and will only further bloat KSP 2 with niche features that will probably come out as 3rd party applications.

KSP 2 will let rockets do burns in the background while the vessel is not loaded (automated milk runs may even extend to massive interstellar ships) and timewarp will have a much higher limit for long burns. This has probably already been solved.

It wouldn't bloat the main program at all because it would be *standalone*.  Read people.  It wouldn't just be for long burns.  Read the thread.

Edited June 29, 2021 by darthgently

[Bej Kerman]

22 minutes ago, darthgently said:

It wouldn't bloat the main program at all because it would be *standalone*.

It's still going to take time that would be best spent on things that would be used by more than the 2 people.

22 minutes ago, darthgently said:

Read people.  It wouldn't just be for long burns.  Read the thread.

Except if you read what I said, then you'll see that I didn't quote you when bringing up long burns.

[darthgently]

2 hours ago, Bej Kerman said:

It's still going to take time that would be best spent on things that would be used by more than the 2 people.

Except if you read what I said, then you'll see that I didn't quote you when bringing up long burns.

Really?  Bej wrote "...and timewarp will have a much higher limit for long burns.  This has probably already been solved. "

[snip]

2 hours ago, Bej Kerman said:

It's still going to take time that would be best spent on things that would be used by more than the 2 people.

The code already exists.  The editors already exist.  It would simply be an additional compile for a standalone version that only has the editors.  Nevermind, seriously.  If you don't get it, move on.

Edited June 29, 2021 by Vanamonde

[BigFatStupidHead]

I've often thought a stand-alone builder would have been a great feature for KSP1. I could have whiled away the hours designing ships when running full KSP would have been impractical.

[darthgently]

25 minutes ago, BigFatStupidHead said:

I've often thought a stand-alone builder would have been a great feature for KSP1. I could have whiled away the hours designing ships when running full KSP would have been impractical.

Exactly. Not just for when doing something else in KSP.  One could design a craft on a lower performance portable platform while waiting for a flight, or waiting at the dentist, then import it to the game later.  I don't play console, but if the craft could also be imported to the console version it would be great to be able to import it there also

[MKI]

2 hours ago, darthgently said:

The code already exists.  The editors already exist.  It would simply be an additional compile for a standalone version that only has the editors.  Nevermind, seriously.  If you don't get it, move on.

This unfortunately isn't how game development, or how software development works.

Unity (like most game engines) has an idea of scenes, the scene for the VAB is essentially 1 "context" for the player, and the "flight mode" is another. I'm sure it's possible to put a "scene within a scene", but I'm also sure it would require extra considerations to support as such. As I mentioned before something as simple as what hitting a key does changes if you have 2 scenes open at the same time. 

Taking 2 seperate things and smashing them together doesn't work "magically" when it comes to software development, this is especially true if they were built before such an idea took place. So any assumptions made during the development for either scene no longer holds, requiring at least a large portion of review to see what will break/wont break.  Which could result in a lot of work if large portions of the code need to be updated with this new requirement, or maybe less, but the surface area of the feature needs to be reviewed. The VAB and flight mode are are the 2 most complicated parts of KSP, so it would at least be a lot to review to combine these 2 aspects, let alone rewrite it to handle the new contexts. 

 

17 hours ago, darthgently said:

You need to read a lot more carefully.  *STANDALONE* editor.  As in you can edit a craft *OUTSIDE* of KSP.  I don't know how much more clear I can be than the subject.  Maybe "standalone" isn't as commonly understood a term as I thought

The term "standalone" means something is by itself, IE it "stands alone". I believe this would better describe the current VAB setup, where you go into the VAB and use it by itself. If with the usage of this term you mean more of a "shared popout, get anytime anywhere for any reason or something along those lines", then yea the VAB isn't "standalone". The VAB by itself isn't "attached" to anything, at least in a game development sense. Yes the VAB is physically attached within the game itself via models/shaders/collisions with the rest of the KSC, but that doesn't mean its code is that related. 

Maybe having a button to directly jump to the VAB/SPH from flight mode would solve a lot of problems, instead of jumping through all the hopes of the KSC screen. This however doesn't address the original "long burn" issue, but that appears to have been confirmed anyways. There might already be a menu button to get back to the VAB/SPH automatically though. (Maybe I'm thinking of the revert flight buttons?)

 

OMG I just realized what you mean by "standalone".

You mean standalone application that isn't within the KSP game itself.

This entire time I was thinking of having the scene within a scene crap. To have that scene be its on executable would require taking the existing code and building around it so it can run as its own executable. I have no idea how difficult it would be, as it would again require a full review of the VAB code so you can abstract away the rest of the game so it can run in 2 different contexts. This again isn't a small task, but it would be less than some fancy "scene within a scene" idea. 

Edited June 29, 2021 by MKI

[Vanamonde]

Some comments have been removed from this thread. 1) Please don't post to tell others where they should post. It's off-topic for the thread and creates clutter for others to have to click past. 2) If someone is really bothering you you can set that person on ignore. Please do that rather than accuse others of trolling. 3) Keep it polite, please. 

As yet there is not a separate suggestions sub for KSP2  suggestions, since that whole area is pretty much hopes and suggestions. There will be such a sub before long, as I understand it, so in the meantime please submit all KSP2 content to that sub. I have moved this discussion there. Nobody's in trouble over this. We're just letting you know there's going to be some reorganization sooner or later. 

[MKI]

17 hours ago, darthgently said:

The code would be the same.  But would be compiled twice; once to a standalone programs, and once as normal as part of the main program.  There would be a little release overhead, but once the right adjustments had been mand it would be ONE codebase generating both flavors.  This is not rocket science

Yea I skimmed over this and didn't read this part of the post so I was still misunderstanding the actual feature

[Bej Kerman]

2 hours ago, darthgently said:

2 hours ago, Bej Kerman said:

It's still going to take time that would be best spent on things that would be used by more than the 2 people.

Except if you read what I said, then you'll see that I didn't quote you when bringing up long burns.

Really?  Bej wrote "...and timewarp will have a much higher limit for long burns.  This has probably already been solved. "

[snip]

Yes, I said that. I said that below a sentence quoted from MKI and not you.

2 hours ago, darthgently said:

The code already exists.  The editors already exist.  It would simply be an additional compile for a standalone version that only has the editors.  Nevermind, seriously.  If you don't get it, move on.

Code that probably depends on things not necessarily happening within the VAB. Maybe KSP 2 has eliminated the whole separate scenes thing, and has the editing happening with the outside world paused. The VAB can't be expected to work with the code ripped from the environment it's expected to work in.

Other than that, I really see no point in something that lets you edit your crafts outside the game. You might as well just wait till you're at your gaming PC so you can build and test your craft properly.

[mcwaffles2003]

Technically this can already be done... Just load a second instance of KSP and manually transfer the craft file from one save to the other. Personally, I'm not interested in the idea as it not only seems very niche, but it also sounds like a lot of distraction while flying. Switching out of one game where you're flying and timewarping to work on a craft for 30 seconds until you have to jump back to the other game to adjust your ship again seems a bit ridiculous. Flying is an active portion of the game and I see this only serving to cause a lot of frustration with people flying past their maneuver nodes.

[darthgently]

6 minutes ago, mcwaffles2003 said:

Technically this can already be done... Just load a second instance of KSP and manually transfer the craft file from one save to the other. Personally, I'm not interested in the idea as it not only seems very niche, but it also sounds like a lot of distraction while flying. Switching out of one game where you're flying and timewarping to work on a craft for 30 seconds until you have to jump back to the other game to adjust your ship again seems a bit ridiculous. Flying is an active portion of the game and I see this only serving to cause a lot of frustration with people flying past their maneuver nodes.

20 minute burns using argon thrusters isn't very demanding.  Especially when a kOS script is driving.

1 hour ago, Bej Kerman said:

Yes, I said that. I said that below a sentence quoted from MKI and not you.

From here on out, any post I make is not to you, Bej.  So please don't respond

Edited June 29, 2021 by darthgently

[mcwaffles2003]

Just now, darthgently said:

20 minutes burns using argon thrusters isn't very demanding.  Especially when a kOS script is driving.

kOS isn't stock and 20 minute burns on those scales already won't require you to have the ship in active flight like is required in KSP 1 since KSP 2 seems to have background burning. Also, once again, you can already do this. Just load up another instance of KSP and manually transfer the craft file. I've never heard of anyone doing this though despite the capability already existing so I personally don't see it's need to be implemented.

[MKI]

1 minute ago, mcwaffles2003 said:

Just load up another instance of KSP and manually transfer the craft file. I've never heard of anyone doing this though despite the capability already existing so I personally don't see it's need to be implemented.

Just to be clear, this means running another version of KSP, building your stuff then transferring the file manually via the file explorer? Or is KSP smart enough to load up the new/updated file(s) if you saved it in the same save, or with the latest update other saves?