Jump to content

Bartybum

Members
  • Posts

    278
  • Joined

  • Last visited

Posts posted by Bartybum

  1. 10 hours ago, lajoswinkler said:

    It's just a matter of naming the product. Sure, use new stuff, make it modern, that's all good, but KSP v2.0 instead of KSP 2... that's a marketing move. It kind of makes no sense to make such division with a basically sandbox, openly creative game such as this one. Or Minecraft, for that matter.

    But it is KSP 2. It isn't an update of the old code - it's an entirely new game made from scratch

    9 hours ago, lajoswinkler said:

    I don't think I'm being understood here. I'm saying "make it all brand new and launch it under v.2.0". That's it.

    Yes, I know it would kind of violate the whole software versioning thing, who cares? :D

    This sounds to me like an argument stemming from not wanting pay for it...

    Because if a person were happy to pay for it, then at that point it makes no difference whether it's separate or an iteration of 1.x.

  2. 51 minutes ago, GoldForest said:

    Please no talking about planet wants

    I WANT THERE TO BE A SPINNING NEUTRON STAR THATS 0.5 LIGHT YEARS OUT WHICH HAS A GAS GIANT ORBITING IT WITH 5 MOONS SPECIFICALLY CALLED KHADJFSO, LEDRDED, SASDAFF, URUHEFG AND GOJKAFD AND I WANT ONE TO HAVE LIFE ON IT WITH TREES AND CITIES AND KERMANS WALKING AROUND AND ERROR ERROR ERROR ERROR

    I cannot for the life of me understand why some people are that specific in their wishlists, to the point of listing names. It screams a hilarious lack of awareness

    Now that that's off my chest :sticktongue: I don't care much for launch towers, or really anything else you've listed save for perhaps the mining equipment (a bit more complex mining could be nice I suppose), but I'd really like more realistic launch clamp options.

  3. 1 hour ago, lajoswinkler said:

    An entirely new game is a marketing thing because now you have to buy it again. ;)

    Well that's definitely part of it, but can you really blame them? KSP 1.x's source code is almost a decade old now, and the effort to update it to modern standards would likely be economically prohibitive. It's been said heaps of times in this thread already.

  4. 52 minutes ago, lajoswinkler said:

    Yes, a bit larger, but not Kerbin=Earth. It's too much. Takes too long. I've played with RSS sized system and even as someone with quite long attention span, it was tedious.

    That payload thing... gets me every time. :D

    I haven't played RSS, but I'm not sure I could handle the added difficulty. The 2.5x mod for KSP 1.x seemed like it'd be a nice balance between realism and gameplay.

  5. On 8/24/2019 at 10:53 AM, Thelizard said:

    By making a sequel we effectively admit that the first had core flaws that couldn't be fixed with an update.

    You might wanna get off that high horse before it buckles underneath the weight of your misplaced pride lol.

    You didn't make the game - you're just a consumer like the rest of us. It's okay to admit KSP has flaws that can't be fixed without a major rewrite sinking countless hours to the point that it becomes an uneconomic decision to do so for free.

  6. 6 hours ago, putnamto said:

    the only talk of multiplayer that i see here, and i highly dislike is the people that want competitive.

    just because your in another room with somebody does not mean you need to want to try to kill them, why is everybody everwhere, on every multiplayer discussion for any game like this?

    And just who are you to judge them for that? Not everyone has to play the game the way you want them to. Why do you think BD Armory is so immensely successful?

  7. 16 hours ago, Kerenatus said:

    I'm always talking about the issues related to the being-worked-on craft file my dude, you don't work something on nothing, you work on a file. But since you don't know the basics, i'd leave it here.

    I still don't see why two people can't work on it at the same time ¯\_(ツ)_/¯ If you know the basics then please do explain. Like I'm genuinely interested (like actually, no hostilities here) to know why the technical aspect would be so controversial

  8. 3 minutes ago, Kerenatus said:

    seperate craft files => seperate editing, which is effectively just sharing craft files like what we have on steam right now, but in a relatively convenient way.

     

    Maybe I phrased my idea wrong, so I'll go again.

    I'm saying that while in a shared VAB session, let both builders save the craft at any point to their own clientside repositories, but only allow the host of the building session to control which craft file is being worked on at any given time. Picture a normal singleplayer VAB session, but now add a guest. The guest is just along for the ride, but can add/remove parts and save the craft to their own repository.

    Again, it's the same concept as a shared cockpit in flight simulator. Both the pilot and copilot can steer the plane, but only the pilot can choose which plane is loaded.

    12 minutes ago, Kerenatus said:

    basic grasp

    "On a friendly note, allow me to say something rather condescending" :/

    Granted, I don't know how to program/network/whatever, but I'm assuming the devs do. This isn't that unreasonable, since after all they do intend to tackle multiplayer.

    Since neither of us two are writing the game, I think it's a bit premature to think it can't be done.

  9. On 8/23/2019 at 5:55 AM, Kerenatus said:

    In a technical vew, allowing building a vessel live between several players may well require the server to constantly saving temporary craft files for every online game and even more back-up files if reverting is allowed,which is highly inefficient. While doing it solo, the game needs only to save it locally and having the craft file online only when you decide to share certain crafts.

    I don't expect them to arrange that much server resource for the MP feature of the mainly solo-focusing game.

    It may look simple in human logic, but require a [~ snip ~] ton of unnecessary resource for the computers.

    Assuming the craft file is local to the VAB-host's client, you could just not give the guest access to the VAB-host's craft file repository. Furthermore, you could give the guest a "download craft file" button to let them save it to their own local repository (if the host checks a "share craft file" button). It's the same as sharing a cockpit in a flight simlator server, where the guest can push buttons (add/take off parts), but the host still holds the reins (saving, and what craft file is loaded).

  10. On 8/23/2019 at 5:43 AM, Kerenatus said:

    IMOH, allowing players to share VAB live doesn't really worth all the potential [~ snip ~].

    What? I just suggested a very simple fix to the abuse - how is there any potential [~ snip ~]?

    Saying "oh no I think it's best left untouched" in light of what I've suggested is a total cop-out.

  11. 2 minutes ago, Kerenatus said:

    If vessels still use a tree structure, it'd be quite hard to revert guest changes only while a vessel building is in process.

    Not really. If they suddenly grief you, then you kick them, then revert their changes one by one until all their griefing is reversed.

    If their griefing has been slow and not really visible over time, then a system that informs you when and what they've just placed would fix that issue too.

  12. 1 minute ago, Kerbart said:

    I agree that griefing will be a problem, the most likely solution is us learning to deal with it. And the ability to revert.

    This ^^^ and my suggestion combined would be great - forcing a save prior to accepting, and then having the ability to revert guests' changes

    1 minute ago, GoldForest said:

    Okay, I guess you could find ways to limit it, but it would still be a hassle, and that's not preventing abuse, that's just a solution to revert the abuse. 

    In that case your request is incorrect. It's impossible to prevent people from acting like dicks; the best you can do is revert the effects.

  13. 6 minutes ago, GoldForest said:

    Still room for abuse. 
    "Hey can I join you?"
    "I don't know." 
    "I only want to see what you're working on."
    "Okay."
    [Ninjamaster_123 has joined the build process]
    *Ninjamaster_123 proceeds to randomly and quickly add and delete parts before they can be kicked.*
    "Hahahahhahahahaha" - Ninjamaster_123

    (Prompt): "Allow [player] shared VAB/SPH access? Your craft will be autosaved before you accept (Y/N)"

    Problem solved. No room for abuse.

  14. Yeesh, couple of people in this thread forgot how to think. MP will absolutely be optional, and it absolutely won't affect SP. I can't read the future, but I can absolutely guarantee they're going to be separate. I have no idea why anyone would even begin to think any other way. Countless games in the world successfully separate SP and MP; it's not like it's some new concept.

    The devs have made it a point to show us that they're well aware of what game KSP is at heart. Forcing MP on those who don't want it would go against everything. Peeps are worrying about a non-issue.

  15. 23 minutes ago, decimal-simplex said:

    Okay for the record I do not consider the inclusion of sci-fi things like FTL to be part of "polishing" the game nor have I noticed them "missing." If you want that sort of thing you can play Elite or something. It has no place in KSP.

    Bit hostile there but okay :/.

    You've misread my comment; I consider FTL a feature, not polishing. There's a slight difference between the two that I'll elaborate on in future (I'm a bit pressed for time at the moment). If we don't get FTL then I can understand (albeit more star systems and planets will still be definitely highly desired).

    Regarding something sci-fi having no place in KSP, I'd argue that given the fact we have:

    1. a dead Kraken on Bop

    2. an alien head and ancient Kerbal progenitor SSTV signal on Duna

    3. the alien stone henge on Vall

    I'd argue that the game has already shown it's somewhat okay with science fiction being part of it. In addition, when it first came out the Interstellar mod was one of, if not THE most popular KSP mod. Plenty of people could hence argue that FTL can have a place in KSP.

    My wish for FTL is a consequence of my wish for more star systems, because of how significantly the game would change (with respect to interstellar base and station construction). At those time periods, you're looking at multidecadal voyages and contracts being conducted while trying to manage your space agency. Sub-luminal space travel just isn't workable with multiple star systems logistically in the scope of career mode.

  16. 3 hours ago, Waxing_Kibbous said:

    The obvious solution is to have set prop units that can be tweaked if the "advanced tweakables" setting is enabled. The hard part is coming up with sane defaults for the prop units.

    I don't think it'd be too hard to come up with defaults for a prop disk / prop unit.

    You'd have something like tweakables really similar to what the current options allow: number of blades, deployment, direction, authority, blade variant.

    And just use the same resultant vector values for lift and drag that you get with the standard props.

    It'd take some amount of work but I don't think it's anything too complicated.

  17. High priority:

    - More landing wheel variants/adjustable landing gear height (Highest priority!)

    - 2.5m trusses for larger stations

    - Longer fuel tanks: It'd be really nice to have an FL-T1600, Jumbo-128 and S3-28800 instead of having to stack two of the largest tank lengths we already have

    - Inflatable habitation modules

    - More station modules i.e. labs doing different experiments, logistics modules, etc.

    - More small aircraft wing panel sizes: they're almost there, but there's one or two missing shapes I'd like to see

     

    Medium priority:

    - More structural adapters: one short length like the Brand Adapter 02, and a long one like the normal Brand Adapter

    - More 5m part skins: I don't want every large rocket to look like a Saturn V derivative

    - Flatter inline RCS tanks

    - More Mk3-compatible wings: referring to both panel wings and single piece wings, with corresponding control surfaces. The current selection is really lacking. I'd like a way to make larger airliner wings and SSTOs look nice.

    - More 0.625m fuel tanks

    - More fuel tank adapters: the current ones are a bit varied and random when it comes to lengths and diameters. A more comprehensive selection would really be nice

     

    Low priority:

    - 3.75m probe core & reaction wheel

    - Longer Mk3 adapters: something to allow nicer noses and tails instead of the stubby ones that are only possible now

    - 2.5m Rapiers, turbofans and turbojets

    - Larger solar panels

    - 2.5m SRBs

×
×
  • Create New...