I'm fine thanks! I just don't have much time to play the game anymore, so i tend to visit the forum much less than i used to. But i'm trying to drop in more often from now on. I'm surprised to see this topic is still discussed, wow! So as of this day most people voted for one or the other option, or even both! Only a quarter of all votes dislike both ideas, which is bearable imo. To be honest i would have never expected that it resonates so well within the community.
I haven't had time either, but I hope to be able to play again next year. I always tune in to see if anything neat has been added. The merge feature would be a nice addition to the game
Good performance with large/many ships is something lots of people are interested in, so that doesn't surprise me at all . It doesn't seem like we've been able to work out the best way to do this yet, though :-/.
I think most of the time the most simple(uncomplicated) and versatile sollution should be used. (but idk, what this would be, tbh)
Agreed. To me, the best option would seem to be fusing small groups of contiguous blocks of the same kind that are all more or less at the same layer within a ship, and allow at least one large hole to be made in them upon reaching a certain HP threshold (maybe have multiple thresholds, even). Then we'd get the benefits of fewer rendered objects (though maybe not many fewer triangles), a concept of armor plates, and still retain the ability to create hull breaches. The trick would be to find a relatively fast way to assess what layer a block belonged to and to section up a ship's hull into chunks of the right size, as well as to do the merging without messing up texturing. It'd be a lot of technical heavy-lifting, to be sure.
9 pages, TLDR... so maybe rehash. If ships could convert to single peice when pilot is in cockpit. Then reverts when exit? Could damage be made to work like mining tunnels? Wherever a weapon hits, a dent is made. But not exactly a block by block display. Or... Damage could still be calculated against a BP version under the hood, then the image gets deformed. Once the pilot exits, the BP is updated appropriately. Bigger sized block sections...yes. not so keen on pooling HP as a whole. The overall concept has merit though. No point to calculate thousands of individual blocks that are buried.
You guys are overthink stuff that was done by other games. There is actually no need to merge in you enter and unmerge after lol you can do in the design phase. Avorion: Merging has been made with an auto tool in the ship editor. Only groups of similar similar and connected. But first the build system need to support multi sized blocks on the same grid scale. EI: A half block would really only occupy the space it shows and you could actually place another half block. Tho this system is implemented in a game where you don't actually access the interior ship or place systems, everything from engines to fighter hangars are freeform blocks expect turrets and mods (but you can design the shape of your turret). In this game the HP is only pooled for the actually merged parts. So if you have a little wing shape non merged it could still blow up. Its also a strategy choice. Do I pool my blocks and risky getting a huge part being blow, or do I a keep little bits and risk losing power/speed/fighters etc, everyone I get hit by a peashooter. (Note that this game not only let you chose grid size for every block also let you freeform outside the grid.) SkyWanderers: The other system I tested uses a similar multi grid, but you cannot freeform outside it like the former. In this game, there is no difference in using multi blocks or freeform/merge because the game already pool HP and Armor. Of course combat in this game is much more cartoon like and really pre alpha so this could change. Also the game has a repair tool that rebuilds your ship from blueprint using a beam. And I need to confirm but maybe block parts are can still be offed even if they are merged in this one because they are still in the grid. Well There is plenty of youtube footage of how merging blocks on voxel games using unity is possible. While I love the games above for their creative freedom I actually prefer this game to do not do merge. At least not yet. This game is great because it actually have content to do while playing instead of just raiding lifeless planets or mine asteroid like so many other. Also there is a certain charm about armor placement and multi layering hull. Idk feels more grity and its friendlier in the begginer builder. Try to build a cool ship in your first avorion play thro to see the nightmare. Also none of those games goes for the 3d asset route and dented hull dmg they use a more minecraftey way of show dmg on blocks with masks. Also not sure if its against the rules to use the competition as an exemple.
not really a merge block per say, I would like to see a docking port added, that would allow as ship to run off a mothers ship power and air as well as a serve as a shirt sleeve wat to board and debark onto the mother vessel or base.
I thought I might revisit this thread. I think Sephrajin had a great compromise. A baked hull. Basically you start with a baked steel hull, then "outfit" it like you would a traditional warship. Add armor, weapons, power, and habitability with the individual blocks. I could see an addition of hull integrity being implemented to account for hull damage eventually leading to structural failure. You lose some ability to target some components, but as I recall no one liked the auto targeting of cores anyway.
Such a hull or merge system is not "realistic" how damage behaves. The closest becomes "shields", suggested many times (mostly without explaining detailed functionality, "I suggest peace on earth"). Most space vessels in sci-fi movies and series and so on seems to be "PvE" or worse. Suspect created by peoples that do not understand combat or avoid the construction demands. Along how they can be constructed and used, lack of physics knowledge (of their own universe). Another solution could be to tie damage to the core, that then have all the HP and all other devices and blocks are "indestructible" until the core is taken. Becomes a kind of shield. An exception could be weapons and movement devices. If to have that you can move around in a vessel during flight, then the above system makes it difficult to have a "boarding" system. Also almost no need to move around inside either, you can do most stuff through the Control Panel (maybe only need harvest drones added). Stationary bases is another issue, should those also have the same function? Then issue with how to approach POIs. The current and new coding also determine how much you can save of calculations. Then the time aspect, how long will it take to get it finished. Less time for other functions, or game finished in 2025 (then outdated)?
Read through most of this but decided to skip to the end since it seemed nobody was going the direction I'm about to. I understand the motivation behind merging blocks but I think it's only halfway to the right solution. The core problem being presented is that ships are made up of hundreds or thousands of blocks so every time collision and damage calculations occur, many items need to be checked. This can be simplified to the following statement: something happened that could affect one or more items in a large list. Summary of the rest of my post: this should be optimized in code and no changes made to building or how we interact with things. Naturally, you would then conclude that making the list smaller would solve the problem. I agree with the logic there but I think the suggested implementation makes too many tradeoffs that aren't necessary. You could reduce the number of things to iterate over in other ways. Think of your list of blocks like a pile of books. If you sort them by the right criteria (name, genre, etc) then you don't have to start at the bottom and check every book because you can now focus on just a subset of the books. If you have 1000 books sorted alphabetically by name and the name of the book you want starts with a Z then it's likely to be the last one or at least closer to the end than the beginning. You can then optimize your search by starting at the other end of the pile. Now maybe you found it after checking just a few books instead of 900+. There are many other techniques that can be used to quickly search through the list of blocks. The key distinction here is that the player sees no difference in the game other than better performance. The game makes use of sorting and some assumptions about the data (aka an algorithm) to more efficiently find what it needs. Here's a possible solution: When an object is loaded into the environment it should be "indexed" immediately. This would mean adding all of its blocks to a much more structured list that could be visualized as more of a tree or a hierarchy of groups. The first layer represents an area in the world. If the world is stored as a grid that is 1000 x 1000 for example, we could split that into 4 groups of 500 x 500. Now if we need to check collision for a projectile we figure out which group the projectile is in and check the location of other blocks in just that group. This already narrows down the list to just blocks in the area. You could have another layer that splits the group further into smaller areas. Each layer you create like this will drastically reduce the number of items you have to check. That makes the block list more of a memory concern than a cpu time issue. If that's confusing then maybe googling something like binary search would lead you to a good example of a similar algorithm. I don't see any reason why something like this couldn't be used to solve performance issues related to high block counts without compromising our experience.
My thought was to have Damage Control Units (DCU). Currently, if my CV is danaged, I can wave my magic repair gun around to fix any visible boo-boos (time consuming), or return to a base with a repair bay to do a complete fix-up (also time consuming). The DCU would be similar to the T2 Repair Bay with a DC block and a DC console. It could also be a tab on the Control Panel maybe ? The idea is that as damage occurs, repairs can be initiated thru the DC console. Perhaps they can repair a bit more slowly so it can be overwhelmed by a fleet of adversaries for the more blood-thirsty crowd. It would consume resources as the T2 repair bay, and power as well. Obviously, I haven't worked out all the details, but I think the concept is both viable and appropriate. Thank you
Neal, post: 101702, member: 16244"]First: this is purely hypothetical and very radical in this state of the game. Hmmm.... I prefer choosing where i spawn my blue print, and keeping the choice to integrate it or not with antoher one . To manage power between different ones.(BA) For ships... dont see the finality need, maybe i misunderstand it. Feature i would like for ships is modular blueprint integration capacity. same thing i want to BA. And increasing hitpoint by generators...hmmm, shields is a part of answer no ? It will open an dangerous way...The...GeneratorCHiP... bêêêêêê....XD
I just came across this post and was pondering last night how crazy it must be for computer to process so many pieces individual hit points at once! It’s really no wonder the game is more taxing than it appears. Personally I would love this idea especially if it frees up power to improve performance, graphics, and other aspects. However that said I do love how you can lose individual devices. Not so much blocks but losing thrusters, fuel tank, etc can be exciting! If it were possible I would love to still have this feature but I think your idea of merging blocks should be worth considering if feasible.
I suggested something similar to this, but my idea was merging only some of the blocks. It works like polarized hull plating in fiction. This tech magnetizes the hull armor plates, making them stick together, dispersing transferred destructive energy over a greater area, regardless of the weapon type used. So basic implementation of this in game would be making several blocks a single entity. As some pointed out here doing this for all devices would not be practical, but binding at least some blocks together would still reduce the processing power. You also dont need to to this for whole ship, internal hull or parts of it, armor or parts of it can be merged separately.
I knew I had this discussion somewhere! Yeah the compiling of blocks is something that always comes up in my mind. When building a structure or vehicle it would be nice if player can somehow have a 'compile' command that essentially calculates just one single pool of HP. I would be ok with something like a critical hit taking out a random device while losing certain amount of damage causes random hull blocks to disappear. Maybe just thrusters and turrets have their own HP pools that you can target and destroy but the hull should be one big pool you need to whittle down. Only issue is that there are probably all sorts of limitations due to the voxel nature of the game. Don't get me wrong I absolutely adore the voxel thing it's integral to the game but if vehicles and bases can somehow be converted into 'one object' instead of a bajillion blocks with HP pools of their own I have to imagine that would free up a lot of processing for better performance and maybe even open up possibilities for combat. Technical limitations with voxel aside - Area specific damage (wearing out one side of hull and blowing up internals) is cool but I would way rather have a buttery smooth space battle with scores of other SVs and a couple of CVs.
Maybe a middle of the road approach would be better(at least from gameplay perspective) issue is that in this scenario you could not strategically target something like guns or propulsion, since the whole structure takes damage, so i would suggest devices be completely ignored, as for solid blocks, i would suggest a sort for radiating damage system, so the block being hit would take perhaps 50% damage, while the rest would radiate away into surrounding blocks with those adjacent taking the biggest portion, and then increasingly less as you go out. This way damage would be modeled more realistically then just that one block being damaged, but of course that may well actually make the performance issue worse rather then better.
