Jump to content

AtomicTech

Members
  • Posts

    2,160
  • Joined

Posts posted by AtomicTech

  1. https://www.linkedin.com/in/grace2ek/

    1714416295154?e=1715187600&v=beta&t=eIJS

    Got us an open for work for an associate producer.

    https://www.eurogamer.net/kerbal-space-program-2-studio-reportedly-shut-down-by-take-two

    "Looks like they might have laid off the entire KSP 2 dev team. Intercept Games are the only team in the Take-Two offices in Seattle and they had around 70 employees. Lots of LinkedIn profiles saying looking for work. Kerbal Space Program 2 might be dead. pic.twitter.com/Q9SqBwEyeK

    — GiantWaffle (@GiantWaffle) May 1, 2024"

     

    https://gamingbolt.com/kerbal-space-program-2-developer-intercept-games-has-reportedly-been-shut-down

    "A former Intercept Games developer recently confirmed on Twitter that he had been laid off by the studio, while others – such as associate producer Grace Tuohey-Kay and community manager Dakota Callahan – have listed themselves as being “open for work” on their LinkedIn profiles."

    (Note: Dakota's profile no longer lists the open for work.)

  2. 23 minutes ago, Lisias said:

    Releasing the IP was never the objective. Only the Source Code.

    As a matter of fact, given the current status quo, Open Sourcing KSP¹ may be their best shot to make the franchise profitable again.

    See Doom, Quake, Half Live, Descent et all. The IP (including assets, as music, meshes and textures) are still being commercially exploited by the current IP owners, besides the source code being released decades ago.

    See the recent Tomb Raider Remastered series - they even hired the dude from OpenLara to work on it.

    Things keep going as they are now, it's a matter of (short) time until things get really, really ugly - what may include, even, malicious 3rd parties trying to exploit the Community. There's no respect for the EULA already (between other problems I had detected, but can't disclose publicly), getting malware agents around here is a question of "When" and "Who", and not "If" anymore.

    Having the Source Code available will push always most malicious agents from the Scene, as everything will be openly available for inspection. Of course, you will still need to trust the tool that will deliver the binaries to you - but, frankly, the Linux Scene proved again and again that it's possible to have reliable and trustworthy distribution channels for such binaries.

    The worst problem, right now, is to gather trustworthy and competent people around the project. Too much damage was done in the last few years, some of them really nasty. EULAs as contracts, not licenses (no matter what they say to you) - do you will trust licensing your code to people that don't respect your EULAs?

    Open Source is based on Trust and Chain of Responsibilities. And every time one of these two pillars are broken, things goes South. Badly. (Jia Tan anyone?)

    Open Source is a development model, not a business model. Anyone trying to extract profit directly from Open Source sooner or later will try some scammy stunt - and, frankly, we are losing both the Trust and the Chain of Responsibility on this Scene - they need to tackle down this problem before going Open Source, otherwise the initiative will fail.

    Yes.

  3. 2 minutes ago, GGG-GoodGuyGreg said:

    Which to me reads now even more reasons NOT to release the KSP1 source, if the rumours turn out to be true, then KSP1 would be the only way to make money off of the IP

    There's gonna be a volumetric poop-ton of technical debt and it's going to cost a ton get it removed. At least if we do it then we've already got a start and it's free for PD. We've already outlined how we want to have access the source code and it's to the benefit of all parties involved.

  4.  
    Company Location Layoff Start Date # of Workers Closure Layoff Type of Layoff Received Date
    Take- Two Interactive Software, Inc. Seattle 6/28/2024 70 Closure Permanent 4/29/2024

     

    Folks, it looks like T2 might've shut down IG; stay up to date with the forums and Discord to follow this developing situation. Let's not repeat the meltdown that happened earlier today.

  5. 15 hours ago, rfried said:

    Hello AtomicTech! And thank you for your gorgeous mod.

    I encountered this issue after upgrading from 2.2.0 to 3.0.0
    The Flame effects and Sound effects continue after Flame-Out of all SRBs.
    Uninstalling Real Plume does fix this issue.

    Steps to reproduce:

    1. KSP 1.12.5 + DLCs(BG,MH)

    2. CKAN Install of Restock Waterfall Expansion Mod

       This pulls in some deps and the mod list consists of:

         B9 Part Switch (B9PartSwitch v2.20.0)
         Breaking Ground (BreakingGround-DLC 1.7.1)
         Making History (MakingHistory-DLC 1.12.1)
         Module Manager (ModuleManager 4.2.3)
         ReStock (ReStock 1.4.3)
         Restock Waterfall Expansion (RestockWaterfallExpansion 3.0.0)
         Waterfall Core (Waterfall 0.9.0)

       => SRBs are ok then.

    3. CKAN Install of Real Plume - Stock Configs

       This pulls in
       
         Real Plume (RealPlume 2:v13.3.2)
         Real Plume - Stock Configs (RealPlume-StockConfigs v4.0.8)
         SmokeScreen - Extended FX Plugin (SmokeScreen 2.8.14.0)

       => SRBs does continue show Flames and generate Sound after Flame-Out
          (see example in screenshot with Flea SRB)

    rwe300andrealplume.jpg

    Gotcha; I'll try to investigate this and see where I've messed up in porting the plumes.

  6. 21 hours ago, Nuke said:

    leds like to fail closed. which is usually the first step in a cascade failure. one led goes, the others in the chain get more current, so their lives get shortened. one fails, the others et even more current, and so on.

    you could give every led a resistor (usually with a constant voltage supply) but that results in waste heat and less efficiency. so you are supposed to use constant current drivers, usually in conjunction with series strings (single leds exist with several series strings connected in parallel). you might be able to get current supplies that can detect led failures (eg by measuring voltage drop and drive current) and change their regulation parameters on the fly. but led bulbs are built to cost and such advanced features are not included. you can always leave some brightness on the table in an effort to keep the leds in spec, but then a competitor can jack up its current and claim that their bulbs are brighter. regardless a defect in one is a defect in all. that said usually the current drivers fail before than the leds (salvaged so many off of dead bulbs).

    All you really need is a good LED and a good resistor. A red LED paired with a good 220 ohm resistor will last for a good long while :)

  7. 8 hours ago, Nate Simpson said:

    image.png.2ecbf49af7003579f762847848787a

    Hello! It’s been a while! 

    I know that many of you have been wondering about the status of KSP2, so I thought I’d give you an update on how things are going. 

    We have an incremental update on the way! The v0.2.2.0 update will address a number of common user experience issues, some of which have been causing frustration for quite a while. In many cases, a thing that was reported as a single bug (Delta-V calculations being incorrect, or trajectory lines being broken) were actually half a dozen or more closely related bugs. 

    We identified a series of issues that we believed were negatively impacting moment-to-moment gameplay and the first-time user experience, and we dug deep into those bug clusters to make meaningful improvements. Some of those issues include: 

    • Parachutes don’t deploy reliably (doubly true when fairings are in the mix) 
    • Fairings don’t protect their contents from heating 
    • Trajectory lines in the map view sometimes disappear (often related to erroneous designation of craft as “landed” when in flight) 
    • Landed vehicles fall through terrain during time warp 
    • Maneuver nodes refuse to allow the player to plan beyond the calculated Delta-V allowance, which in many cases is an incorrect value 

    We’ve submitted changes to address a number of these issues – in the case of the last one, we’ll just be letting you plan beyond your current dV allowance while we continue to improve our Delta-V accuracy over the longer term (there’s a very challenging set of problems to solve in the pursuit of accurate Delta-V projections for every possible vehicle that a player can make, so this is something we’ll likely be refining for quite a while).  

    For this update, we’ve also prioritized a new kind of issue: in some cases, the first-time user experience is undermined by a failure of the UI to clearly communicate how to progress between phases of gameplay – put simply, we sometimes put new players in a position where they don’t know what they’re supposed to do next. We’ve received a huge quantity of very helpful user feedback in this area since the For Science! Update. For example, since most of us are seasoned KSP veterans, it never occurred to us that we hadn’t fully communicated that “revert to VAB” is a very different thing from “return to VAB.” We received a rash of bug reports from people who were confused about having lost progress after completing their missions and reverting to VAB. Yikes! Similarly, the lack of a clear call to action when a vehicle can be recovered frequently left new players staring at a landed vehicle and not knowing there were more steps to follow. We’ve made some UI changes to address issues like this, and we think the flow has improved as a result. 

    Another usability issue that even catches me out on occasion -- trying to do illegal actions (for example, parachute deployment) while in time warp states other than 1x. In fact, we believe quite a few bug reports we’ve gotten about actions being broken have actually been the result of people attempting to do things under time warp that weren’t allowed. This is an area of ongoing work for us – not only do we need to do a better job of communicating to the player when they’re warping, but we also need to make clear what actions are and are not allowed under both physics and on-rails time warp. We’ve made some small UI changes to increase the player’s awareness of their time warp state, and we’re looking forward to seeing if those changes feel good to you. I know we talk a lot about the value of Early Access, but this is a great example of how your reporting helps us target our efforts. 

    We still haven’t nailed down the exact date for this update, but we’ll notify you here once we’re on final approach. 

    Most of our team continues to be pointed squarely at the Colonies update. We’re making a lot of progress this month on colony founding, the colony assembly experience, and colony gameplay mechanics. There are lots of interesting problems to solve here – some are super obvious (colony parts exist at a wide range of scales, and the Base Assembly Editor – the colony version of a VAB - needs to feel equally good when you’re connecting a small truss or a giant hab module). Other issues – for example, how vehicles interact with colonies on both the systems and physics levels – come with a lot of edge cases that need to be satisfied. We remain very excited about the ways colony gameplay will move KSP2 into completely new territory, and we’re definitely eager to see what our legendarily creative players do with these new systems. 

    In parallel with our colony work, we’re continuing to find significant opportunities to improve performance and stability. We just made a change to PQS decals that got us huge memory usage improvements – mostly VRAM (this one is still being tested, so it won’t go into the v0.2.2.0 update – but I was just so excited about the improvement that I had to share): 

    image.png

    And of course, while all this work is going on, Ghassen Lahmar (aka Blackrack) continues to make big strides with clouds. Here’s a peek at some of the improvements he’s working on today (yep, that’s multiple layers)!

    cloudwip.png

    And because the VFX team can’t ever stop making things better, they’ve begun an overhaul of exhaust plumes to bring them more in line with reality (which thankfully is also quite beautiful):

    enginewip.png

    Thanks as always for sticking with us as we work through each challenge – we couldn’t be more grateful to have your support as we move toward the Colonies era! 
     

    Nate

    Glad to hear from y'all :)

    I am quite weirdly excited about the realistic hydrogen plumes! 

×
×
  • Create New...