Support | News | Classic | F.A.Q. | Discord | Discussions | Wiki | Roadmap

Cosmoteer "unstable" release candidate 0.15.7 RC1 is now available for testing! This update contains a lot of bug fixes, as well as some balance tweaks, nifty new modding features, and small QoL improvements. Your feedback is welcome and appreciated!

Download 0.15.7_rc1

Changelog:

  • Balance:
    • Nuke explosions will now become "anchored" to any ship hit by the expanding shockwave.
    • An Engine Room will now act as a central delivery point for adjacent thrusters to which crew can deliver batteries without having to travel to each one individually.
  • Crew A.I.:
    • Crew will now return to their quarters immediately after finishing a job.
    • When delivering H.E. missile parts to an H.E. launcher, crew are now guaranteed to complete construction of any in-progress missiles before starting to build a new missile.
    • When crew drop off a large battery containing more power than the receiving part needs, the crew will no longer briefly hold a smaller battery containing the excess power. Any excess power will now be immediately lost.
  • Built-In Ships:
    • Added the 12 winning ships from the Jan. 2020 faction design contest.
    • Updated to Valor and Crescent Wrath so that they will again spawn in Bounty Hunter.
    • Updated the Excalibur to have sensor arrays.
  • User Interface:
    • When building or repairing, crew that become disconnected from their quarters will now be teleported back to their quarters.
    • Removed the "Reset Crew Positions" option from the crew panel because crew will now automatically reset their own positions when building and repairing.
    • Crew, power, and ammo bars no longer display a "minimum" amount because that was potentially misleading for new players.
    • Crew, power, and ammo bars now fade out after passing the "suggested" line to indicate diminishing returns.
    • In build mode, the grid coordinates of the mouse cursor are now displayed beneath the "Total Ship Value" display,
    • Mouse edge pan is now enabled again by default for new players and is the default method of camera control described in the first tutorial.
    • When a ship is at maximum capacity, the ROSTER tab in the crew panel will now display a message reading "Build more quarters to hire more crew."
    • The mods manager now has labeled buttons for activating and deactivating the selected mod.
    • Nearly all popup dialog boxes and windows will now properly respond to pressing the Enter (confirm) and Escape (cancel) hotkeys.
    • The loading screen now has a starry background with the text "Walternate Realities Presents".
    • Removed the info about the "eye" icon from the "Attacking the Enemy" tutorial. (The eye icon still exists and works fine, only the tutorial blurb about it has been removed.)
    • Miscellaneous translation updates from the Cosmoteer Translation Project.
  • Multiplayer:
    • Setting a ship for another player will now un-ready that player.
  • Bug Fixes:
    • Possible for fix severe lag spikes during gameplay on some computers.
    • Crash on startup when Windows "Controlled folder access" (ransomware protection) is enabled. It will still be impossible to save games, ships, and game settings.
    • Crash if the game can't create the Saved Ships or Lost Ships folders.
    • Crash on startup if the Mods folder doesn't exist and the game is unable to create it.
    • Rare crash if exiting the game before it is fully loaded.
    • Crash when trying to delete a ship from the ship library and the language is set to Latin American Spanish.
    • Crash when viewing Engine Room stats in Hungarian.
    • Crash when viewing Mine Launcher stats in Traditional Chinese.
    • Crash if the news window is displayed while start or loading a game. (It will no longer be displayed.)
    • Rare crash when a ship is damaged at the very same moment that it is removed from the game.
    • Crash when clicking on a map sector to view its information and for some reason the height of the game window is very short.
    • On very rare occasions (but more common with certain mods), making an FTL jump would prevent the game from being saved from that point onwards.
    • Audio glitches would often happen during gameplay, especially when there are a lot of things going on, such as a big battle.
    • When switching from Domination to another game mode, ships worth more than 1,000,000 would be removed on the non-host players' screens but not on the host's screen, resulting in other problems such as being unable to ready or unintentionally entering the game as an observer.
    • Crash on the multiplayer pre-game setup screen if a player selects a ship and then immediately leaves the match.
    • Crash in multiplayer if a missile launcher's mode is changed and then, before the mode is actually changed due to network latency, the launcher is then given a target.
    • On the multiplayer pre-game setup screen, it was possible to select a ship and then click ready before the ship is fully uploaded, allowing the game to launch either without that ship or with the previous ship in that slot.
    • In Arena or Domination multiplayer games, removing a ship from your fleet selection and then immediately spawning your fleet or spawning the new ship that dropped into that slot would sometimes cause the old ship to be spawned.
    • In Arena or Domination multiplayer games, changing a ship slot and then spawning immediately afterwards would sometimes spawn the old ship in the slot.
    • In Arena multiplayer games, clicking the "Respawn" button multiple times in rapid succession after the countdown is completed would cause you to automatically respawn the next time round.
    • Crash if a player in a multiplayer game removes a ship while another player is trying to set its role priorities.
    • Installing mods containing additional decals wasn't always causing multiplayer incompatibility, which could later causes crashes and desyncs during the game.
    • Modifying a ship's blueprints would immediately remove any crew in excess of the ship's current crew capacity. This will now only be done when the "MAKE IT SO" button is clicked.
    • Crew would wait at a mine factory for it to produce mines even if it didn't have any ammunition in stock.
    • Crew that were walking almost on top of each other in the same direction would often not cause each other to slow down.
    • Crew with nothing better to do would never stop manning a room even if it was powered off. Now they will return to their quarters if the room is powered off.
    • Projectiles could sometimes pass through shields if they hit the shield in the same location as the non-existing portion of a triangle or wedge armor block.
    • Weapons firing at small, fast-moving targets (such as PD firing at projectiles) were being more inaccurate than intended.
    • Fixed-direction weapons would sometimes fire too early.
    • Modded ships that had parts or doors not found in any active mods wouldn't appear in the Ship Library.
    • If an enemy ship is being displayed in the Picture-In-Picture while the player is using Direct Control Mode, but the player has not explicitly targeted the enemy ship, it would sometimes be impossible to target weapons on the enemy ship by clicking in the Picture-In-Picture.
    • The Mine Factory was displaying the incorrect production rate for mines.
    • Creating a new ship in multiplayer Creative Mode would cause the view to focus on the wrong spot.
    • Creating or joining a multiplayer game and then going back to the lobby would scroll that chat window back up to the top.
    • An empty tooltip would sometimes be displayed after deleting a ship on the multiple pre-game setup screen.
    • If a ship splits into multiple piece while in Direct Control mode and each piece has a Control Room, each such piece would be selected and thus Direct Control mode would be canceled.
    • Pressing Ctrl+A to select all crew while the mouse cursor was over any interface elements didn't work.
    • Clicking-and-dragging multiple overlapping command handles would drag all of them at once.
    • Rotation target lines would appear to jitter depending on how fast the target was moving laterally relative to the selected ship.
    • Selection circles around crew would often be a little glitchy and not perfectly centered on them.
  • Modding:
    • Replaced PartCrew's 'AllowMinPriorityCrewing' parameter with a 'HighPriorityPrerequisites' list of toggles. If any of the specified toggles are off, crew will still be allowed to operate the part, but only if they have nothing else to do.
    • AmmoStorageProxy can now be used in almost any way that a regular AmmoStorage can, including as a supplier, a toggle, and a value.
    • AmmoStorage components can now be made non-drainable by EMP-like effects by setting 'IsDrainable = false'.
    • IonEnergyStorage now has optional 'ToggleOnAmmo' and 'ToggleOffAmmo' parameters that work identically to those of AmmoStorage.
    • IonEnergyStorage now has an optional ProvidedValueRange parameter that works identically to that of AmmoStorage.
    • IonEnergyStorage components can now be made drainable by EMP-like effects by settings 'IsDrainable = true'.
    • IonEnergyStorage components can now optionally supply ammo just like AmmoStorage components by setting 'SuppliesAmmo = true'.
    • IonEnergyStorage can now be given a list of 'AnticipateMoreAmmoFrom' components just like AmmoStorage.
    • All ammo storage component types now support a 'ProvidedValuePerAmmo' parameter that can be used to control the value it provides to other components based on the amount of ammo. The default value is 0.
    • Removed the 'AmmoPerProvidedValue' from IonEnergyStorage. Use ProvidedValuePerAmmo instead.
    • Added a 'MultiAmmoStorage' part component which can be used to logically combine multiple other ammo storage components (including AmmoStorage, AmmoStorageProxy, and MultiAmmoStorage) into a single component that can in most cases be treated as a single storage with the total capacity of all the combined storages. It has almost all of the same features as a regular AmmoStorage component, including the ability to take ammo for delivery and supply ammo (using identical customization parameters). Which of the combined storages it will favor when adding ammo or removing ammo can be controlled with the 'AddMode' and 'RemoveMode' parameters, each of which can be given one of these values:
      • InOrder (the default for 'AddMode')
        • When adding: Ammo will be added to the ammo storages in the order listed until each in turn is full.
        • Whem removing: Ammo will be removed from the ammo storages in the order listed until each in turn is empty.
      • InReverseOrder (the default for 'RemoveMode)')
        • When adding: Ammo will be added to the ammo storages in the reverse of the order listed until each in turn is full.
        • When removing: Ammo will be added to the ammo storages in the reverse of the order listed until each in turn is empty.
      • PrioritizeMostEmptyCapacity
        • When adding: Ammo will be added to the ammo storages in the order of most remaining capacity first until all storages have the same remaining capacity, after which the ammo will be distributed evenly across all storages.
        • When removing: Ammo will be removed from the ammo storages in the order of most remaining capacity first until each in turn is empty.
      • PrioritizeLeastEmptyCapacity
        • When adding: Ammo will be added to the ammo storages in the order of least remaining capacity first until each in turn is full.
        • When removing: Ammo will be removed from the ammo storages in the order of least remaining capacity first until all storages have the same remaining capacity, after which the ammo will be removed evenly across all storages.
      • PrioritizeMostAmmo
        • When adding: Ammo will be added to the ammo storages in the order of most ammo first until each in turn is full.
        • When removing: Ammo will be removed from the ammo storages in the order of most ammo first until all storages have the same amount of ammo, after which the ammo will be removed evenly across all storages.
      • PrioritizeLeastAmmo
        • When adding: Ammo will be added to the ammo storages in the order of least ammo first until all storages have the same amount of ammo, after which the ammo will be distributed evenly across all storages.
        • When removing: Ammo will be removed from the ammo storages in the order of least ammo first until each in turn is empty.
      • DistributeEvenly
        • When adding: Ammo will be added to the ammo storages in as equally-sized portions as possible. Any units of ammo that can't be evenly divided will be added to storages in the order listed.
        • When removing: Ammo will be removed from the ammo storages in as equally-sized portions as possible. Any units of ammo that can't be evenly divided will be removed from the storages in the reverse of the order listed.
      • DistributeRandomly
        • When adding: Ammo will be added to the ammo storages in random order until each in turn is full.
        • Whem removing: Ammo will be removed from the ammo storages in random order until each in turn is empty.
    • Removed the 'AmmoSum' part component. Use 'MultiAmmoStorage' instead.
    • MultiToggle, MultiTrigger, MultiValue, and the new MultiAmmoStorage now all support a 'ViaBuffs' block that allows it to hook to components in other parts that are either buffing or being buffed by the local part. Set 'IncomingBuffTypes', 'OutgoingBuffProviders', and 'ComponentID' of ViaBuffs as desired. (See the Engine Room's 'CombinedBatteryStorage' component for an example.)
    • Added a 'ComponentPresenceToggle' component which is similar to a proxy but can be hooked to a component of any type and is toggled "on" when the hooked component exists and "off" when it does not.
    • A ToggledComponents with 'IncludeInBlueprints = true' but whose Toggle doesn't support IncludeInBlueprints will no longer crash; the contained components will now always be included when rendering the ship's blueprints.

Walt Nuke explosions will now become "anchored" to any ship hit by the expanding shockwave.
An Engine Room will now act as a central delivery point for adjacent thrusters to which crew can deliver batteries without having to travel to each one individually

Y E S! I thought this would take longer. Has Engine Room capacity increased too?

newageofpower Has Engine Room capacity increased too?

No, why would it?

    newageofpower Engine rooms automatically distribute the batteries they recieve to the thrusters (I assume after the engine room has full power), not store extra batteries that will be specifically stored to distribute to the thrusters when they're running out. Crew still have to bring power to the engine room if the thrusters need more power.

    Walt An Engine Room will now act as a central delivery point for adjacent thrusters to which crew can deliver batteries without having to travel to each one individually.

    This is an insane buff, but at the same time I really like it thematically.

    Also I don't feel like you "fixed" nukes in any meaningful way, exp guns don't seem to work anymore but the nuke bombs are not affected much:

    Walt An Engine Room will now act as a central delivery point for adjacent thrusters to which crew can deliver batteries without having to travel to each one individually

    ^ First thing i tested ofc.
    Like the new rule and engine "blocks" are less congested now.
    Noticed when the engine room is not accessible crew will still deliver power directly to the thrusters.

    I asked this before the RC already.
    Many thruster arrangements are built so that some thrusters are closer to a reactor then the engineroom.
    Sometimes thrusters are even adjecent to the reactor when the engine room is not.
    Would very much appreciate that crew delivers power to thrusters directly if they are closer to the reactor then the engienroom-hub.

    I know @Walt said this was tricky - but crew does decisions based on distance all the time - so i speculate it might be not too tricky.


    ty for all the bugfixes - so many that i went tldr 😉

    regards,

    • Walt replied to this.

      Nordwolf Also I don't feel like you "fixed" nukes in any meaningful way, exp guns don't seem to work anymore but the nuke bombs are not affected much:

      It should now be no worse than getting hit with a regular nuke. Which is still pretty bad considering how cheap storages are. Making storages and (maybe) launchers less explosive is still an option, which might also be good for other reasons.

      The new loading screen looks nice!

      Walt An Engine Room will now act as a central delivery point for adjacent thrusters to which crew can deliver batteries without having to travel to each one individually.

      Bug: when filling up a boost thruster via an engine room, crew bring many more batteries than are needed.

      I don't really like this change. It makes crew and crew management less important. It adds complexity (more rules and exceptions) but reduces depth (less crew management). And it's a HUGE buff to engine rooms, which were already must-haves.

      (also, did I miss something? It sounds like this has been discussed already, but I didn't see anything on the discord)

      Walt Weapons firing at small, fast-moving targets (such as PD firing at projectiles) were being more inaccurate than intended.
      Walt Fixed-direction weapons would sometimes fire too early.

      Glad these are fixed!

      Nordwolf Also I don't feel like you "fixed" nukes in any meaningful way, exp guns don't seem to work anymore but the nuke bombs are not affected much:

      In the experimental balance mods, wasn't the nuke storage explosion reduced?

      Or, why not make the nuke explosion instant? That would get rid of any weirdness, and is probably a lot easier than making lots of physics changes.

      Walt It should now be no worse than getting hit with a regular nuke.

      Uh. It still looks much worse than a regular nuke or two in Nord's video.

      Dalas120 I don't really like this change. It makes crew and crew management less important. It adds complexity (more rules and exceptions) but reduces depth (less crew management). And it's a HUGE buff to engine rooms, which were already must-haves.

      With the massive increase in crew demand coming (from Walt's Factory Centralization Plan) crew management is going to be more vital than it is in version 0.15.6 despite automated thrust block power distribution. Walt is adding this to make centralized power and engine blocks more compatible; currently it's an quite a pain in the butt to efficiently run multiple engine blocks off of a single MR/LR's capacity.

      Engine rooms are dominant in Elimination/Arena, but almost unseen in Domination; I wouldn't call them "must have".

      Dalas120 reduces depth (less crew management)

      Is there actually any interesting crew management in how engine room pods were designed before this update?

      There was some concern that decreasing congested crew speeds in non corridor rooms (as I did in the balance prototypes but haven't yet decided whether to include that in this update) would really hurt engine room pods. Allowing crew to deliver power to the engine room is in part a reaction to that concern, but also I just think it's cool.

      Dalas120 And it's a HUGE buff to engine rooms, which were already must-haves.

      I'm considering reducing the engine room buff back down to 50% as it was originally intended.

      Dalas120 also, did I miss something? It sounds like this has been discussed already, but I didn't see anything on the discord

      It's been discussed before yeah, but I don't remember where.

      Dalas120 In the experimental balance mods, wasn't the nuke storage explosion reduced?

      Yes, I might still do that.

      Dalas120 Or, why not make the nuke explosion instant? That would get rid of any weirdness, and is probably a lot easier than making lots of physics changes.

      Because I don't like how that feels, plus it's better for performance if the damage is spread out over multiple frames.

      SpaceCat I know @Walt said this was tricky - but crew does decisions based on distance all the time - so i speculate it might be not too tricky.

      The problem is that when crew are delivering power to and engine room, they have no idea which thruster will receive the power. The engine room itself decides that on arrival.

      newageofpower Uh. It still looks much worse than a regular nuke or two in Nord's video.

      The ship in that video is getting hit with 16 nuke storages. Pretty sure 16 real nukes would do a lot more damage than that.

      Walt Is there actually any interesting crew management in how engine room pods were designed before this update?

      Once you've built an optimized stand-alone engine pod I don't think there's much, but (for me at least) crew does have a lot of influence over how you arrange engines and reactors. Especially on smaller ships that try to power engines, shields, and weapons from the same reactor.

      Walt There was some concern that decreasing congested crew speeds in non corridor rooms (as I did in the balance prototypes but haven't yet decided whether to include that in this update) would really hurt engine room pods.

      That's a good point. I'm not sure it's necessarily a bad thing though - it might force people to plan room for corridors and walkways around thrusters.

      newageofpower Engine rooms are dominant in Elimination/Arena, but almost unseen in Domination; I wouldn't call them "must have".

      Isn't that because many Dom ships are too small for engine rooms, or don't even bring reactors (which makes engine rooms bad)? Almost every medium-large ship I've seen has used engine rooms by all thrusters.

      Dalas120 Bug: when filling up a boost thruster via an engine room, crew bring many more batteries than are needed.

      Also expierienced by now. No matter if used in normal mode or after depleting in boost mode.

      Might this be in conjunction with (?):

      Walt The problem is that when crew are delivering power to and engine room, they have no idea which thruster will receive the power. The engine room itself decides that on arrival.

        SpaceCat Also expierienced by now. No matter if used in normal mode or after depleting in boost mode.

        Already fixed.

        Walt Uh. It still looks much worse than a regular nuke or two in Nord's video.

        The ship in that video is getting hit with 16 nuke storages. Pretty sure 16 real nukes would do a lot more damage than that

        Then again it is hard to fire 16 nukes at once - but still easy to deliver the storage bomb!
        In the clip you see the ship igniting long before it gets to the target.
        Nukes rly should explode in a short flash and not dragging for so long - not saying instant damage but very short.
        (maybe making nuke anchoring obsolete ...)

        Dalas120 Isn't that because many Dom ships are too small for engine rooms, or don't even bring reactors (which makes engine rooms bad)? Almost every medium-large ship I've seen has used engine rooms by all thrusters.

        More that the majority of Dom combat is about trying to control the nodes; if your ship is insanely fast but regularly flies out of the node its usually a bad thing. Once the fleet sizes go up faster ships dedicated to hunting other ships can be useful, but zone control is the bread and butter of competitive domination.

        And yeah, I play mostly 1.5m Elimination/Arena, where everything but turning thrusters (and usually those too) are always mounted on engine rooms. But the complaint about engine rooms being ubiquitous on 1.5m+ ships is like complaining shield generators are almost always featured under armor or weapons.

        Dalas120 That's a good point. I'm not sure it's necessarily a bad thing though - it might force people to plan room for corridors and walkways around thrusters.

        That would make thruster blocks further away from a reactor unworkable. Already even with storages touching the block , fed by double walkway can deplete on some of my centralized reactor designs.

          To me it seems like crew doesn't have a good idea of the ER power consumption, they seem to wildly underestimate the amount of crew needed to deliver the power, like half the crew stays in their bunks/quarters most of the time when ER is slowly running out of power. This is very noticeable on medium distances from a large reactor.

          Nordwolf I found a bug where crew don't consider thrusters to be connected to an engine room until it's operational. Could this be related?