AvorionCraft
-
Posts
180 -
Joined
-
Last visited
-
Days Won
13
Content Type
Profiles
Forums
Events
Posts posted by AvorionCraft
-
-
On 9/20/2023 at 1:34 AM, sineme said:
# Add method getEngineProperties to ShipDatabaseEntry
local acceleration, decceleration, maxVelocity, yaw, pitch, roll = ShipDatabaseEntry:getEngineProperties()
Could be used to estimate per sector duration of map commands.
# Add required energy to the return values of ShipDatabaseEntry:getHyperSpaceProperties
local jumpRange, canJumpRifts, hyperspaceCooldown, isHyperspaceEngineImpaired, requiredEnergy = ShipDatabaseEntry.getHyperspaceProperties
Could be used to calculate the travel time between sectors for a map command. i.e. the maximum between the hyperspace cooldown and the time it takes to recharge the energy required for the jump.
# Document behaviour of Galaxy:getSectorView
seems to only return a sectorView for the sector you are in and sectors that are connected to your current sector. Fortunately there is Player:getKnownSector, otherwise the mod I am working on would've turned out to be a waste of time.
TTTTTTTTTTTT HH HH III SSSS
TT HH HH III SS
TT HHHHHH III SSS
TT HH HH III SS
TT HH HH III SSSS
#####AND####
#############Add method to get docking blocks to only attach to other specific docking blocks.
To fix problems laid out here:(Assuming)
local docking, docking range, docking bounding box, color--docking stuff=yes, add it
Add multiple docking types to base game: Commerce, structure connect, parasite connect
Commerce works as current docks do.
Structure dock: allows color coded docking blocks that only attract a docking block of the same color (stations)
Parasite dock: allows color coded docking blocks that only attract a docking block of the same color (ships) -
Its pretty strange that non-xsotan people built massive jump gates that required xsotan artifacts to function.
I've tried to mod it, but I can't. It just keeps going back to inactive.
Ancient Gates are underutilized in the game because you have to waste a slot on the key.
Alternatively, make it so that once a gate has been activated with a key, it remains active permanently.
Second, give XSTN-I an alternative function, like radar/deepscan/scan, and/or object detection or reduced risk of getting attacked by xsotan while equipped or something.
###edit###I answered my own request:
Look up "Always Active Ancient Gates" mod # 3131761086This should be basegame. js.
-
This is the whole point of the integrity field--keeps chunks of ships from being sheered off.
Build a ship and convert all of your integrity field generators to blank hull, and start running into asteroids. You'll find real quick that what you're talking about is in fact, a thing.
-
There's a small laundry list of things that would make this game better in general.
We'll see how well the behemoth update works out, as apparently some of the data flow/networking problems are allegedly being fixed. That's probably the biggest issue--networking overhead.
-
Networking issues
- 180,000 ping should never happen. Not in this day and age. Its all apparently purely engine latency, of too much happening locally, and its almost like its running FTP rather than UDP. Result is ludicrous rubber banding on servers, insane ping, and too waiting upwards of five minutes for reactions to reply from the server.
-
UI issues
- Torpedoes and fighters---an integer input. How this has not been done is a head scratcher. If there's 45 torpedoes of a type the player wants, we still have to click it 45 times. The engine lags, the ping goes crazy, and then you wind up either underclicking or overclicking and either not buying enough or buying too many torpedoes or fighters. Fighters are far worse for some reason, and I haven't been able to figure out why. Huge optimization issue with this.
-
No in game localized builder.
-
As mentioned in suggestions forum:
When you need to make small edits to a ship while on a server, the server has to acknowledge every change. You cannot convert a ship into lower elements without making it two elements only. Its like that tool aspect was half way completed. Instead, a local version that allows the player to load the ship before "submitting for build" would allow full local engine alterations before submitting the changes to the server, and thus building your ship without any issues. This would allow down converting of a ship from X slots to X-y slots as the player is capable wherever they are in the galaxy and with whatever permissions they have, upconverting, or converting from one element to another without a hassle. It would also get rid of the server latency associated with making alterations. Since the server apparently reloads the ship with every change you do--literally every change. That is an enormous amount of networking overhead that is entirely, completely unnecessary. Local build. Submit to server. You cut down on 99% of the network load related to the build screen with just that. The only thing server side necessary would be whether or not they are broken stacking blocks like the old 1000stacks, or if the ship exceeds server limitations or something to that effect. In which case, the build does not get submitted, and the server notifies the player that "hey you can't do that, make a change, lower the volume, size, slots, materials, whatever."
-
As mentioned in suggestions forum:
It has to be admitted that there are vast limitations to a game that was designed as a college project that turned out to be good enough to release. There are rumors of a second Avorion coming at some point. I think I'll draw up a different post regarding that.
Most of the problems with Avorion are back end and how the server handles data, voxels, internal systems.
I've thrown out a boatload of suggestions over the last couple of years that could dramatically improve the game overall. But the things listed above are definitely the biggest issues I have with it presently. Rubberbanding and watching 200k ping (I think the record is 384k presently) because of how the networking traffic is structured is the biggest thing to tackle.
-
Networking issues
-
Mods come and go. The "override mods" button isn't a guarantee that you can get into an old galaxy file.
If anything, a button that specifies "no mods for this galaxy" (especially for ship builders) would be good. -
Having 30 different variances of the same subsystem eats into your inventory dramatically.
Why not set it so there are a total of five sub qualities of any particular quality?
Example: Generator
Exceptional I-V
I: battery regen
II: low battery regen, generator
III: moderate battery regen, higher generator
IV: better battery regent, higher regenerator+
V: best battery regen for quality, best generator for quality
And then---make it so you can upgrade these modules to the next quality at an equipment dock.the stats are made more static, so you don't have 50 different generators in your inventory of 34%/58%, 40%/72%, 22%/79%, etc
Do this across the board, and make it so quality tier I is "junk tier stats X-X%", but each tier II-V are STATIC in nature, and at a price, these tiers can be upgraded to the next tier.
when it comes to research, its random, so you can potentially get a Tier V exotic out of a bunch of junk Tier I's for example. However, if you research 5 Tier V's, you get a Tier V exotic, and so forth.
There is just too much loot in the game for this not to be a thing.
-
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.
-
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!
-
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.
edit: Aditionally, transporters should not require a module in order to function. Its a waste of a valuable slot for very limited award. It makes sense for there to be a transporter node specifically for mining modules (like the hybrid SDK stuff) but just to have extra range to trade? Not so much. If transporter modules were to stay 'required,' they should have other benefits that benefit mining and salvaging.
Alternatively----modules that are affected by blocks directly could have their own tab. Transporters, radar, coms, fighter modules. Honestly there's so much that just seems like a waste currently that requires a module to function when you already have the block.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/-100Supercharger - 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.
-
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.
-
On 8/2/2023 at 7:33 PM, Reclusiarch said:
Yes. I think the Interface GUI for puting in your Turret Build Designs onto the Turret needs some smoothing, currently its
1>select Turret Base
2>click Turret
3>click Design Mode
4>click Block
5>click show Templates
6>navigate
7>click apply
8>press esc
Instead...
>>>> select Turret Base > pop-up Pallet of Turret Designs next to Inventory of Turrets, select Deign choice > apply
have a button to queue the Pallet of Turret Designs at any time
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.
-
Laserzwei has a shipyard mod that does some of what you ask. Handy for servers that have slot limitations. Allows circumvention. Unfortunately, you have to prepare your ship for the materials you have on hand.
Mod 1695671502
-
Really though....
Somewhere in here is a shape that could allow us to properly do curves without having a sideways dance of a thousand pieces.
-
I need this block... its been 3 years since you posted this. Why is this not yet a thing?
-
Not possible with the current engine, but possibly with the second Avorion, maybe?
-
Presently, turrets are sized 1-6.
Coaxial turrets only appear once you hit xanion space (rarely).
In dev mode, you can create size 1 coaxial chaingun turrets.
This should be base game. The AI is smart enough to use coaxial turrets, so these would be of great benefit to your extra captains with your extra ships.
Slap even a single coaxial turret on a ship and it suddenly knows which end is the pointy end, since the behavior seems to prioritize facing the side to them enemy with the most turrets, coaxial amount seems to circumvent that. A ship knowing which way is the pointy end will act more proper in combat in general, by not doing stupid things like "I'm going to point my butt at the enemy because reasons."
No. Point the front of your ship---the most armored part of your ship---at the enemy. Doy.
There's a few changes I'd like to propose for turrets in general.
Chain guns are sized 1-3. This should be increased, but with alterations.
Size 4-5-6 chain guns would have significantly lower speed than their smaller companions. A firing rate of max 2-3 versus their smaller faster counterparts.Faster than cannons, but never overheating, with lower dps. Size 4-6 chain gun would basically be a rapid fire cannon, but non-explosive, never dealing with cooldown.
I think this would be a nice addition.
-
This would be nice, yes. presently they're just "wherever" which is irritating.
-
1
-
-
I realize that, just building on your notion is all.
-
If you set up a ship to guard one position, they'll just sit there, making any coaxial mounts worthless. Please add behavior so that ships will roll, pitch, yaw to go after a target from their most powerful angle.
-
Seems to me like this would be a simple feature to add. Yet we still do not have this. :/
-
Reference data.
16ms update. why do I have 283k ping? -
-
-
^Hyperthreaded
Numbered Torpedo Tubes
in Suggestions & Idea Voting
Posted
Instead of just "Torpedo Tubes" Frontal and Side, increase the blocks to Torpedo Front/Side 1,2,3,4,5,6,7,8,9,10. So that way we can designate what tube is firing what direction and appropriately team them.
So have the "basic I don't care" torpedo launcher and the other 10 per front/side.