All Activity

This is a good idea. I gave up on caring about Captain rolls because on top of being rare, getting a good one is rarer than rare. Its why I always have a dedicated ship who's sole purpose is to run around and pick up captains at every sector.

Currently, captains are an absolutely absurd amount of RNG. Assuming the player goes for tier 3 captains, the following all are dictated by RNG: the captain classes, the number of perks, and the perks themselves. Assuming the wiki is accurate, tier 3 captains can have between 2-4 positive and 1-2 neutral perks. That is to say, if a player desires to have the highest quantity of perks on their captain, that's a 1/3 chance for 4 positive perks and a 1/2 chance for 2 neutral, or a 1/6 chance for maximum total perks. Then you have the desired class of the captain. Given that classes come in pairs for a tier 3 captain, that's a 1/7 chance for a given primary class and 1/6 chance for a given secondary, or 1/42 for a given pair. Then, of course, you have the variance of perks themselves. If a player desires specific perks, there is a 4/8 chance for the first desired perk, a 3/7 for the second, 2/6 for the third, and 1/5 for the fourth positive perk for a 24/1680 chance to have four desired positive perks. This gets followed by a 2/6 and 1/5 chance for the two neutral perks* for a 2/30 chance for two desired neutral perks. Between the three values, that's a 1/6 chance multiplied by a 1/42 chance multiplied by a 24/1680 chance multiplied by a 2/30 chance for a grand total of a 48/127,000,800 chance of a "perfect" desired captain. That's a measly .000378% chance of getting it, or an expected 26 *thousand* captains per perfect captain assuming average normal distribution. This brings me to the suggestion: the ability to place captains into academy blocks. This would allow players to spend credits to reroll both the captains classes and the perks one at a time into a (chosen, not RNG) new perk or class. In order to balance how powerful this would be, I suggest the following drawbacks: rerolling perks would cost a base of one million (1,000,000) credits and would double for each perk rerolled. That is to say, if a captain gets all 6 perks rerolled, it would cost 1 + 2 + 4 + 8 + 16 + 32 = 63 million credits. Rerolling a class would function using the same cost, but using a 4x multiplier instead of a 2x multiplier. For example, a captain that gets 3 perks rerolled, followed by two class rerolls would cost a total of 1 + 2 + 4 + 16 + 64 = 87 million credits. Number of perks and tier on the captain would be constant and unable to be rerolled. Similarly, perks would only be rerollable into the same type, (positive to positive, negative to negative, etc.), such that rerolling "humble" into educated would be doable but rerolling "greedy" into "humble" would not be possible. This system would allow players to realistically achieve perfect captains while also still heavily encourage grinding for a "good" starter captain before rerolling in order to save on cost.

Multiplayer & Security Updated Steam API to v 1.57, added authentication safety against man-in-the-middle attacks Bugfixes Fixed a crash on Linux related to recent Steam client updates affecting singleplayer and hosting multiplayer games Fixed an issue where the dedicated server settings were not fully visible in the ServerRunner window

Yes, been thinking about this block for months. The key difference between this block and all others is that it is the only block that has 1 additional Vertex that is not aligned to another vertex, its location sits between 2 other Vertices exactly at mid point. At 1st I thought this block was left out intentionally because of scaling issues, but knowing that it always is 10/2 in the above example you wouldn't have to calculate it.

Hi there, Same problem here but after try to start offline ,Avorion won't start anymore about SteamAPI error. I hate such errors which only about copyprotection (steam)... I will keep trying ... --- Okay, now i got rid of the steamAPI error (Installed Avorion beta + switching to proton hotfix) and the game starts again. --- Now i've Avorion Beta installed and if i start the server from shell i can connect to it in the multiplayer menu.

:c queria tradução

Dear Boxelware. Build it. Package it. Shut up and take my money. Problems: "You do not have nao/trin/xan/ogo/avo knowledge to build this." "You do not have the resources to build this." - (Secondary solution--more than just a -2 to +2 size range on adjustment) "Block count too high for server." Solutions: Step 1: Leave server. Step 2: Log into local game. Step 3: Make adjustments. Step 4: Save. Step 5: Log back into server. Step 6: Realize you missed something else. Step 7: Leave server. Step 8: Log into local game. Step 9: Make adjustments. Step 10: Save. Repeat steps 5-10 as required. Step 11: Finally load ship. Step 12: Realize your server buddies did the thing without you. Proper solutions: 3rd party separate app that allows building turrets and ships outside of avorion. Ingame local option to build/adjust ships that doesn't talk to the webservers for every single adjusted block---applies blocks once you hit "apply." Best solution: 3rd party app. Shut up and take my money. Make it a DLC. I'll pay for it. Other reasons: Change one block on a ship while logged into a server. Server says "better update the whole ship" Server sends the whole ship back and forth umpteen times. Do this 6 or 7 times and you lag out. Super efficient!

I would love to be able to edit ships in real time so I dont have to leave a multiplayer game and come back. Is there a way for this to happen? Logging in and out of a server sucks when all I need to do is change turret blocks to the proper tech level? Is there no way to have a check box to ignore resource limitations and prevent changes from being made in game? This would be a HUUGE... quality of life improvement for the multiplayer experience. I would even pay for a small ship builder app as a dlc if need be

I selected this one. Yes, I can confirm that using the Beta Branch, and being online in Steam works fine!

v2.4.1 fixes the issue for me.

The new beta branch patch hopefully addresses this issue. Does version 2.4.1 work for you?

Can you try the current beta branch version while the steam client is online?

Behemoth Events Increased number of bonus turret slots for Behemoth Combat/Civil Turret Control Systems Adjusted slightly misleading Behemoth Carrier Systems description Remote Ship Management Remote managing the selected ship now requires the player to hold "I" Briefly pressing "I" while having another ship selected now just opens your current ship's management window again Added visual clues to the remote manage window to make it more clear it is not your current ship's window Fleet Tab Improved compact view to take currently selected ship or station into account Ships that have yield ready to claim will now display an icon in compact view Misc Updated Credits Bugfixes Fixed a crash on Linux related to recent Steam client updates affecting singleplayer and hosting multiplayer games Fixed a crash when opening system tab in ship window while having a subsystem installed in a locked slot Fixed an issue where escorting ships prioritized gates over jumps even when target sector was in jump range They will still attempt to use gates if their hyperspace engine is on cooldown Fixed an issue where escorting ships did not immediately jump with the leader when possible Fixed an issue that caused error messages "You can't modify the component ControlUnit" Fixed an issue where player owned resource depots gave incorrect amounts of resources and money Fixed an issue where the filter for stolen goods overruled other cargo bay filter settings Fixed an issue where toggling compact view off and on resulted in the wrong row being expanded Fixed an issue where a Long-Distance-Trader subsystem's tooltip claimed to provide software for Transporter Blocks even when it didn't

It does! Fired right up when steam is in offline mode Sorry I didn't notice this until today, I didn't seem to get an email about the reply!

After getting back to this game after not playing for a few years I've noticed when entering debug mode (via the puzzle piece button) it auto targets my ship? Is there a way to turn this off or target other objects? (since the destroy and delete commands just nuke my own vessel which isn't especially helpful.)

Thanks everyone for providing the logs. We are working with high priority on this issue. In the meantime you can put your steam client into offline mode to play singleplayer mode.

Does it work when you put the steam client in offline mode?

Just got the game today, eager to start doing the things, but sadly I get a crash. From the server logs, which I'll attach: 2023-11-08 17-56-52| Error initializing server command line input interface: assign: Operation not permitted I'm running PopOS! Pop!_OS 22.04 LTS x86_64 Kernel: 6.5.4-76060504-generic CPU: AMD Ryzen 9 3950X (32) @ 3.500GHz GPU: NVIDIA GeForce RTX 3080 Ti Memory: 46257MiB / 64234MiB serverlog.7z

Transporter block - Volume Based Presently, the transporter block requires exactly 1 xanion in order to function for the full range of the transport module. It would make more sense if the module were changed to %range instead of +km, and the transporter blocks themselves offered something a little more calculated and mathematical. Like (∛[Volume])*(module-quality [1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7]) So for instance, if a transporter block is 100cubic meters, the cube root would be approx 4.6. 4.6 * {[Rare(1.4)], or 6.4km. 1cubic meter would be .46, * 1.4 would be just .64km range. This would allow the transporters to scale properly. So if a player wanted to extend the range of a transporter to 10km, or further--its now possible. Opening up transport blocks all the way down to naonite would be neat, as well. Radar Block - all shapes Allowing a radar block would allow the construction of radar dishes with function. These would be based on surface area primarily. These, like Transporter block above, would change how the radar modules work--or even erase the need for them altogether. Radar Range of (√Surface Area+{[1/2]*[∛volume]})*(module-quality [1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7]) Scanner range follows the same formula Deep Scan Range of (.5)*(√Surface Area+{[1/2]*[∛volume]})*(module-quality [1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7]) So for radar the radar module and any +radar range on any module would no longer be necessary, however the "object finder" would now require radar blocks in order to run a ping in system for objects, and once pinged, never vanishes--since you know its location (unless the object is moving, its going to be right where it was pinged). 50% effect for Chameleon and Mining Modules. Communications Block - all shapes Nearly identical to the radar block, allows functional construction of communication dishes. This would affect the Trade Module, Sphinx, Injector, 50% effect for Chameleon, increasing the market knowledge range, and a higher chance of marking a nearby sector as red rather than yellow for picking up pirate or even Xsotan communications. Additional Turret Block Functionality Turret blocks themselves should have the potential of adding additional turret slots to a ship rather than relying entirely on modules. The concept of a module makes sense from a baseline point, as you need control systems to operate the weaponry. However, adding an volume function to blocks would have a two-fold change. Most ships are built with paper thin turret blocks, since they don't hold much in an armor value to begin with, and when you have xanion or avorion turret blocks, they're not armored anyway. Each turret block adds integer .1 turret capacity per individual block count * ∛volume. So a 10cubic meter (1x1x1) offers a value of 2.15, round down to 2. Each 1x1x1 turret block (size 2 turret) adds .2 turret capacity. Slot 6 minimum would be cube root 25, thus .25 turret cap Slot 5 minimum would be .2 Slot 4 minimum would be .175 Slot 3 minimum would be .15 Slot 2 minimum would be .1 Slot 1 minimum would be .05 So a ship with 6 Slots 6 turrets, 4 Slot 5s, 4 Slot 4s, 6 slot 3,s 8 slot 2s, 10 slot 1s: Innate capacity of 5.2 Turret slots simply doubling to .2 would give a base 10.4, however, this could also already easily be gamed by simply adding a bunch of turret blocks internally, where the effectively act as turret computers---which is part of the point to begin with. Leaving it at .1 would be fine I believe, and would alter how ships are built as well, as its based on volume and count, rather than volume and surface area. The more individual blocks, the more base control you have prior to the multiplier, and any block less than .5x.5x.5 would not receive this bonus at all, as that turret block does not have the volume to act as a computational control unit--only a control unit. Any turret block would have a minimum requirement of .5 on any one dimension order to classify as a computational control unit for turrets. Rotational lock turret blocks still also need an upgrade. Allow them to have a turret skin--or simply allow an additional functionality to where if a standard or armored turret block sits atop a rotational lock, the turret will not rotate. The same capacity as outlined above would also apply to rotational lock turret blocks with the same minimums. This isn't necessarily a huge change for control counts, but for a vanilla ship, it allows more flexibility on how well rounded a ship is, and potentially helps free up one, or maybe even two module spots for other highly desirable modules without forcing a player's ship into a pigeon hole of gunsgunsgunsshieldsshieldsshieldsjuicejuicejuice. Artifact Control Block - Cube - Concept "Tesseract" Special block that is only creatable via Xanion or Avorion; is effectively a cargo block, where its internal volume, like those above, affect the operation of the artifacts via direct integration. Though honestly, this is already a thing by all rights, since modules integrate directly, but the concept here is that they integrate in one place together. This block has one shape, cube, and must always be a cube in order to be functional, and must be 5cubic meters in volume per artifact to function. 8 artifacts? 40 cubic meters or 4x4x4 block. It has no armor, thus must be placed in a safe space and wrapped in armor. Like the other blocks outlined, the volume of this block acts as a direct % enhancement to artifacts onboard the ship. Not a lot. A multiplier that goes up 2.5% per artifact on the ship. 8 artifacts would result in all artifacts receiving a 1.2 multiplier, or 20% boost. Each additional 10 cubic meters attained adds an additional 1% boost to a max of 10%, or a max of 1.3 multiplier or 30% boost (rounded up if above x.5) Max boosts XSTN-1 - n/a XSTN-2 - 8 arbitrary 6 auto --> 10 Arb 8 Auto XSTN-3 - 10 armed 6 auto --> 13 armed 8 auto XSTN-4 - 10 unarmed 6 auto --> 13 unarmed 8 auto XSTN-5 - 30/25/2/1/2/25/1/-15/30/30/.1/3/5 --> 39/33/3/1/3/33/1/-20/39/39/.1/4/7 XSTN-6 - 0/0/1200/4 --> 0/0/1560/5 XSTN-7 - 200/125 --> 260/163 XSTN-8 - 7/-50/-80 --> 9/-65/-100 Supercharger - Secondary Engine Block This block would be required to touch the engine. So long as the volume of the supercharger is 10% of the engine block, it will enhance the engine block's acceleration performance by 25%, and only acceleration. Barracks This block directly enhances onboard defense, and lowers the cost of boarders by giving them somewhere proper to stay. Enhances internal defense weapons by the same volume percentage as communications/radar enhancements.

Allow me to correct you on that. eyeball--select all turrets you want to change Click the save icon Look for the turret you want to place Apply design This will apply a turret design to each of the selected turret blocks.

Bumping the topic with an additional suggestion: Change docking blocks in an additional way: Allow a dock to have a thinner, tighter docking beam and area: In other words, that big white box? Let us make it smaller. However, the thinner the big white box, the less mass may be docked to it. This would allow more modular designs and tighter variance on ship scaling.

I'm also running Arch Linux, and Avorion stopped working normally after I updated all packages on the system on Oct 29 (I hadn't upgraded these for a few weeks). I believe I also updated Steam at the same time. I'm thankfully able to play singleplayer by following @rfvgyhn's tip to use Go Offline in Steam. So yay, I can keep blasting pirates! Otherwise, when attempting to load a galaxy while steam is in online mode, AvorionServer starts up and crashes within a few seconds with a segfault (SIGSEGV in the server log) and a stack trace (without debug symbols), and sadly the thread that segfaults isn't identified elsewhere in the log. Key bits from the serverlog (full serverlog attached): ... 2023-11-01 20-49-53| Thread 139661494187712 Received signal SIGSEGV ... 2023-11-01 20-49-53| === STACKTRACE ===================================== 2023-11-01 20-49-53| #1: ?? [0xd01781] 2023-11-01 20-49-53| #2: [ext] ?? [0x7f0583a5c710] ... 2023-11-01 20-49-53| #23: [ext] ?? [0x7f0583b2e7cc] 2023-11-01 20-49-53| =================================================== ... Edit: the first and last addresses in this stack fall within the following ranges from the captured avorionserver-maps.txt (and most of the addresses in the middle fall in ranges for steamclient.so): 7f05839ee000-7f0583a6f000 rw-s 00000000 00:18 551121 /dev/shm/u1000-Shm_93c3be7d 7f0583a6f000-7f0583c6f000 rw-s 00000000 00:18 507726 /dev/shm/u1000-ValveIPCSharedObj-Steam In case it's helpful to pin this down, I cross-referenced the libraries that AvorionServer links against the packages that I upgraded when this stopped working. There were four: glibc, zlib, libx11, and libglvnd. % while ! pgrep AvorionServer ; do sleep 1 ; done ; cat /proc/$(pgrep AvorionServer)/maps > avorionserver-maps.txt ... % cat avorionserver-maps.txt | tr -s ' ' | cut -f 6 -d ' ' | sort | uniq | grep /usr | parallel pacman -Qo {} /usr/lib/libstdc++.so.6.0.32 is owned by gcc-libs 13.2.1-3 ... /usr/lib/libz.so.1.3 is owned by zlib 1:1.3-2 % grep -i graded /var/log/pacman.log | grep 'gcc-libs\|glibc\|libcap\|libglvnd\|libx11\|libxau\|libxcb\|libxdmcp\|systemd-libs\|zlib' | grep -v lib32 | grep 10-29 [2023-10-29T13:57:42-0600] [ALPM] upgraded glibc (2.38-5 -> 2.38-7) [2023-10-29T13:57:43-0600] [ALPM] upgraded zlib (1:1.3-1 -> 1:1.3-2) [2023-10-29T13:57:43-0600] [ALPM] upgraded libx11 (1.8.6-1 -> 1.8.7-1) [2023-10-29T13:57:44-0600] [ALPM] upgraded libglvnd (1.6.0-1 -> 1.7.0-1) serverlog 2023-11-01 20-49-50.txt avorionserver-maps.txt

In-sector autopilot (e.g. select own ship, autopilot, Salvage Sector) will attempt to hyperspace jump out of the sector if facing towards the hyperspace target Can be reproduced by setting a hyperspace destination, putting a wreck between your own ship and the hyperspace direction, and turning on salvage sector. The player ship will attempt to engine towards the wreck, which is close enough to the angle of the hyperspace exit and will start charging the hyperspace engine instead. In-sector autopilots should not attempt to leave the sector.

Going Offline and trying to run Avorion gave me the same error message I described above - "Failed ot initalize Steam API".

Me and a friend of mine have been interested in starting a new game soon, but we'd like more people to play with before that. -Time zone is MDT -Expert difficulty -Vanilla, but mods aren’t necessarily off the table -Ideally a pretty long term run -Going to be in the same alliance, but not everything needs to be done together. Just don’t do stuff like taking more resources or items from the vault than you should or start wars without discussing it. You don’t need to do everything as part of the alliance, just work together with it and everyone else. -VC is ideal, but not strictly required