Jump to content

xisec

Members
  • Posts

    38
  • Joined

Everything posted by xisec

  1. Yes, this would be a nice QoL implementation... It is annoying to have to teleport to everyship before order a new route
  2. Hi again! La Quinta Alianza is a litte spanish-speaking alliance created by 3 teammates 3 years ago. Now, we are pleased to inaugurate our little public dedicated server. Everyone can join it: IP: 62.113.247.66 IP alias: lqa.4npserver.de Password: lqa More info in the Discord server. La Quinta Alianza
  3. This would be really nice
  4. Hi ! "Transform all selected Blocks" (TASB) and "Only show specifig blocks" (OSSB) together are incredible powerfull and usefull building functions. Change our ships fitting is much easier now, we haven't to be "digging" in our ships removing and placing blocks only to change their block type. BUT there is a little problem: Gyro Arrays, Hangar, Directional Thrusters... Orientation dependent blocks (ODBs) can't be transformed easily. For those, we still need the traditional: 1) "Dig" in the ship to reach the block to be replaced. 2) Replace the block with the same dimensions but rotated in the desired position in order to perform its new functionality. The tediousness of this step is the biggest problem right now. Even change a superficial ODB is a little pain, and even more if the dimensions are a bit odd, like x=2.53 y=5.67 z=3.84. 3) "Bury" the transformed block again. So I propose a new building function: "Change block orientation" (CBO): It would allow to change the orientation of already placed blocks. In technical words, it would change the "look" and "up" attributes (xml ship desing) of the block without changing its dimensions. This way, we would be able to transform ODBs with the function OSSB in the same way we use it now with TASB. It would be a blessing. And it seems easy to implement. A function to CBO in hand (CBOIH) would be nice too. It seems even easier to implement, but this way we still would be unable to transform blocks inside the ship. And if CBO is implemented, we can just place blocks and orientate them later. Thanks for reading !
  5. Hi guys! I was trying to figure out the solar panels credit cost formula, but I am a bit stucked (and, lately, needed of time, also ::) ) I will drop here my spreadsheet with some numbers: https://docs.google.com/spreadsheets/d/1KE7cDbHAXdh8xdLrYmfD-X5jPUsdKLaxkeo4PQ-O8pI/edit?usp=sharing * In context: -The price of the other types of cubes is calculated with this formula: cc = v * mf * tf where cc = credit cost v = volume mf = material credit cost factor tf = type credit cost factor ( this two last are game constants, for example, the mf for Titanium is 15 and the tf for Cargo Bay type is 2.5 ) - The formula for the energy generated is: E = sqrt( 6000000000000 * v * a ) where E = energy v = volume a = area (maybe the cost formula is similar or related to this! ) See u in Avorion!!
  6. Hey mates! I have been spending some time in a project lately. It is an Avorion builder API for Java. It not only allow to plan designs, but also simulates mechanics and stats ( some mechanics have been very hard to figure out, like hyperspace reach and cooldown). This may allow to program advanced procedurally designs based on parameters or ship requeriments. The alpha versión is advanced, but not ready yet. However, viewing the evolution of the game AI creating new procedurally designs, I will drop here a little teaser too :) I know that devs provide an API for modding in Lua, but I am a kind of fan of Java, and I love to analyze games as well, so... I am enjoying this and I think that can be funny to use for someone else. TEASER: (I am in the village now, so the upload speed is VERY slow. It may take a handful of hours to finish) The file created in the video is attached to this post. P.S: You may find some bug in the teaser :P I will also take the opportunity to pump this post: https://www.avorion.net/forum/index.php/topic,6015.0.html avuilder4j-showcase.txt
  7. It seems that there isn't pieces overlap... that's nice! Guys, the AI is evolving... We must too ... Very soon ;)
  8. Ok, I think that I have it. I though that each face of the cuboid had an index of reference. In this case, for example, if you rotate a cuboid over the axis Z, only the Up value should change, since the Look value is in the Z axis and does not rotate. But it seems that this is not the case. The right approximation is: you have to imagine a cuboid inside a system of references. So it is like the references are in the coordinate system, the references are not in the cuboid faces. Each cuboid has a side that is the designated Look and Up face. By default, when the cube is placed wihout any rotation (default position), the face facing towards upper y (uy) is the Up, and the face facing towards lower z (lz) is the Look. For example, in the case of the cube "Ligh", the light bulb is the Up side, and the side that by default appears in lz is the Face side. In this case, if you rotate a cuboid over the axis Z, any of the Up or Look value can change, depending of the state of rotation of the cuboid. Now all numbers of the experimental data about rotations fix with the theory. Remember N1,N2 = Look, Up values. So 5,3 means look 5 and up 3. Around X: 5,3 (default) -> 2,5 -> 4,2 -> 3,4 -> 5,3 (again) Around Y: 5,3 (default) -> 0,3 -> 4,3 -> 1,3 -> 5,3 (again) Around Z: 5,3 (default) -> 5,0 -> 5,2 -> 5.1 -> 5,3 (again) Also, since default position, I have rotated the cube over X one time and I have repeated the previous movements since this position (2,5). This are the experiment numbers, which fix with the references: Around X: 2,5 (test position) -> 4,2 -> 3,4 -> 5,3 -> 2,5 (again) Around Y: 2,5 (test position) -> 2,0 -> 2,4 -> 2,1 -> 2,5 (again) Around Z: 2,5 (test position) -> 1,5 -> 3,5 -> 0,5 -> 2,5 (again)
  9. No, I can't fit it. I copied the experimental results wrong in the previous post. I have edited and corrected it there, but I will paste them again here anyway: Around X: 5,3 (default) -> 2,5 -> 4,2 -> 3,4 -> 5,3 (again) Around Y: 5,3 (default) -> 0,3 -> 4,3 -> 1,3 -> 5,3 (again) Around Z: 5,3 (default) -> 5,0 -> 5,2 -> 5.1 -> 5,3 (again) This is what I can't fit: My wrong case. In the case of rotation around Z, the results should be: 5,3 (default) -> 5,0 -> 5,2 -> 5.1 -> 5,3 (again) but with my references the result are: 5,3 (default) -> 5,1 -> 5,2 -> 5.0 -> 5,3 (again) ( References in axis X seems to be reversed) Your wrong case, peacefighter. In the case of rotation around Y, the results should be: 5,3 (default) -> 0,3 -> 4,3 -> 1,3 -> 5,3 (again) but they are: 5,3 (default) -> 1,3 -> 4,3 -> 0,3 -> 5,3 (again) ( References in axis X seems to be reversed) If I try to fix the references so the results are correct in one axis, the results become incoherent in other axis. I have checked the experimental results like 20 times, and they are right. At this point, and viewing the odd reference numbers that we get, I think that there may be some bug in game which prints wrong the xml files but at the import time it is corrected in someway. Or maybe I am missing something, but I have squeezing my brain too much and I find all results incoherents.
  10. Welcome to Avorion! In order to increase your turrets number you need system upgrades: https://steamcommunity.com/app/445220/discussions/0/135507548124622365/
  11. Hi again peacefighter ! I am creating an API of Avorion for Java. To create our own procedurally or parameterized designs. It will be able to calculate some game values also, hence the database. It will also allow some unavailable operations in the game, like escalate the ships only in one axis, escalate by systems slots required, and so on. It is advanced... I would like to publish it before new year. I will publish the whole code.
  12. Hey peacefighter! Yes, you are right, I've been squeezing my brain today with this and I think that I have some results. The practical results are coherent, but the results "references" that I have figured out are a bit "weird" I think: If you edit an xml ship file introducing a wrong Up and Look combination, the design corrects it and set this default values: 5 for Look 3 for Up And, if you rotate the block over the diferent axes, the orientation values are these ( <Look>,<Up> ): Around X: 5,3 (default) -> 2,5 -> 4,2 -> 3,4 -> 5,3 (again) Around Y: 5,3 (default) -> 0,3 -> 4,3 -> 1,3 -> 5,3 (again) Around Z: 5,3 (default) -> 5,0 -> 5,2 -> 5.1 -> 5,3 (again) This leads to this default orientation references: This is a bit weird because: 1.- "Up" is down. Edit. Sorry, it can be represented like this, but the not symmetrical issue (2) is still there: 2.- The faces index are not symmetrical: lower x face = 1 upper x face= 0 ly = 3 uy = 2 lz = 4 uz = 5 <--- is inversely to the rest: higer number for upper and minor for lower. It is a bit weird but any other indexes or references does not match with my "experiments".
  13. Hmm... Do you refer to the modding API, right? I haven't seen anything about this there :-\
  14. Hello there! I am working on a personal project about Avorion and I needed a database, so I will share it here. It is a SQLite3 database. Database: https://drive.google.com/file/d/1IeTUXqt_C5gxQ-6jqbybEyFYDJIDqJpY/view?usp=sharing Database export file: https://drive.google.com/open?id=1SUOBXm_5C0jUeLOxwvGFtDKG0Fys4Ubd Here is also a google calc with the tables and views: https://docs.google.com/spreadsheets/d/1kPZCVP2YwgZlZmgdvyKqTUgISATYdqQI3WEUARCAHOE/edit?usp=sharing Please report errors! I hope it helps someone! See u in Avorion! ;)
  15. xisec

    Forum Bug

    yeah guys, too buggy! :(
  16. I am working with some xml ship design files and I am having problems to solve the meaning of some values. Let's go with an example. Ship's XML file: <?xml version="1" encoding="utf-8"?> <ship_design> <plan accumulateHealth="true" convex="false"> <item parent="-1" index="0"> <block lx="-1" ly="-1" lz="-1" ux="1" uy="1" uz="1" index="1" material="0" look="1" up="3" color="ffbfaea3"/> </item> <!-- Red, X --> <item parent="0" index="1"> <block lx="1" ly="-0.5" lz="-0.5" ux="2" uy="0.5" uz="0.5" index="61" material="3" look="3" up="5" color="ffff0000"/> </item> <item parent="1" index="2"> <block lx="2" ly="-0.5" lz="-0.5" ux="3" uy="0.5" uz="0.5" index="61" material="3" look="5" up="2" color="ffff0000"/> </item> <item parent="2" index="3"> <block lx="3" ly="-0.5" lz="-0.5" ux="4" uy="0.5" uz="0.5" index="61" material="3" look="2" up="4" color="ffff0000"/> </item> <item parent="3" index="4"> <block lx="4" ly="-0.5" lz="-0.5" ux="5" uy="0.5" uz="0.5" index="61" material="3" look="4" up="3" color="ffff0000"/> </item> <!-- loop --> <item parent="4" index="5"> <block lx="4" ly="-0.5" lz="-0.5" ux="5" uy="0.5" uz="0.5" index="61" material="3" look="3" up="5" color="ffff0000"/> </item> <item parent="5" index="6"> <block lx="5" ly="-0.5" lz="-0.5" ux="6" uy="0.5" uz="0.5" index="61" material="3" look="5" up="2" color="ffff0000"/> </item> <item parent="6" index="7"> <block lx="6" ly="-0.5" lz="-0.5" ux="7" uy="0.5" uz="0.5" index="61" material="3" look="2" up="4" color="ffff0000"/> </item> <item parent="7" index="8"> <block lx="8" ly="-0.5" lz="-0.5" ux="9" uy="0.5" uz="0.5" index="61" material="3" look="4" up="3" color="ffff0000"/> </item> <!-- loop --> <item parent="8" index="9"> <block lx="9" ly="-0.5" lz="-0.5" ux="10" uy="0.5" uz="0.5" index="61" material="3" look="3" up="5" color="ffff0000"/> </item> <item parent="9" index="10"> <block lx="10" ly="-0.5" lz="-0.5" ux="11" uy="0.5" uz="0.5" index="61" material="3" look="5" up="2" color="ffff0000"/> </item> <item parent="10" index="11"> <block lx="11" ly="-0.5" lz="-0.5" ux="12" uy="0.5" uz="0.5" index="61" material="3" look="2" up="4" color="ffff0000"/> </item> <item parent="11" index="12"> <block lx="12" ly="-0.5" lz="-0.5" ux="13" uy="0.5" uz="0.5" index="61" material="3" look="4" up="3" color="ffff0000"/> </item> <!-- Green, Y --> <!-- loop --> <item parent="0" index="14"> <block lx="-0.5" ly="0" lz="-0.5" ux="0.5" uy="1" uz="0.5" index="61" material="3" look="3" up="5" color="ff00ff00"/> </item> <item parent="14" index="16"> <block lx="-0.5" ly="2" lz="-0.5" ux="0.5" uy="3" uz="0.5" index="61" material="3" look="3" up="0" color="ff00ff00"/> </item> <item parent="16" index="17"> <block lx="-0.5" ly="3" lz="-0.5" ux="0.5" uy="4" uz="0.5" index="61" material="3" look="3" up="4" color="ff00ff00"/> </item> <item parent="17" index="19"> <block lx="-0.5" ly="3" lz="-0.5" ux="0.5" uy="4" uz="0.5" index="61" material="3" look="3" up="1" color="ff00ff00"/> </item> <!-- loop --> <item parent="19" index="20"> <block lx="-0.5" ly="4" lz="-0.5" ux="0.5" uy="5" uz="0.5" index="61" material="3" look="3" up="5" color="ff00ff00"/> </item> <item parent="20" index="21"> <block lx="-0.5" ly="6" lz="-0.5" ux="0.5" uy="7" uz="0.5" index="61" material="3" look="3" up="0" color="ff00ff00"/> </item> <item parent="21" index="22"> <block lx="-0.5" ly="7" lz="-0.5" ux="0.5" uy="8" uz="0.5" index="61" material="3" look="3" up="4" color="ff00ff00"/> </item> <item parent="22" index="23"> <block lx="-0.5" ly="8" lz="-0.5" ux="0.5" uy="9" uz="0.5" index="61" material="3" look="3" up="1" color="ff00ff00"/> </item> <!-- loop --> <item parent="23" index="24"> <block lx="-0.5" ly="9" lz="-0.5" ux="0.5" uy="10" uz="0.5" index="61" material="3" look="3" up="5" color="ff00ff00"/> </item> <item parent="24" index="25"> <block lx="-0.5" ly="10" lz="-0.5" ux="0.5" uy="11" uz="0.5" index="61" material="3" look="3" up="0" color="ff00ff00"/> </item> <item parent="25" index="26"> <block lx="-0.5" ly="11" lz="-0.5" ux="0.5" uy="12" uz="0.5" index="61" material="3" look="3" up="4" color="ff00ff00"/> </item> <item parent="26" index="27"> <block lx="-0.5" ly="12" lz="-0.5" ux="0.5" uy="13" uz="0.5" index="61" material="3" look="3" up="1" color="ffeeee00"/> </item> <!-- Blue, Z --> <item parent="0" index="28"> <block lx="-0.5" ly="-0.5" lz="1" ux="0.5" uy="0.5" uz="2" index="61" material="3" look="3" up="1" color="ff0000ff"/> </item> <item parent="28" index="29"> <block lx="-0.5" ly="-0.5" lz="2" ux="0.5" uy="0.5" uz="3" index="61" material="3" look="0" up="3" color="ff0000ff"/> </item> <item parent="29" index="30"> <block lx="-0.5" ly="-0.5" lz="3" ux="0.5" uy="0.5" uz="4" index="61" material="3" look="2" up="0" color="ff0000ff"/> </item> <item parent="30" index="31"> <block lx="-0.5" ly="-0.5" lz="4" ux="0.5" uy="0.5" uz="5" index="61" material="3" look="1" up="2" color="ff0000ff"/> </item> <!-- loop --> <item parent="31" index="32"> <block lx="-0.5" ly="-0.5" lz="5" ux="0.5" uy="0.5" uz="6" index="61" material="3" look="3" up="1" color="ff0000ff"/> </item> <item parent="32" index="33"> <block lx="-0.5" ly="-0.5" lz="6" ux="0.5" uy="0.5" uz="7" index="61" material="3" look="0" up="3" color="ff0000ff"/> </item> <item parent="33" index="34"> <block lx="-0.5" ly="-0.5" lz="7" ux="0.5" uy="0.5" uz="8" index="61" material="3" look="2" up="0" color="ff0000ff"/> </item> <item parent="34" index="35"> <block lx="-0.5" ly="-0.5" lz="8" ux="0.5" uy="0.5" uz="9" index="61" material="3" look="1" up="2" color="ff0000ff"/> </item> <!-- loop --> <item parent="35" index="36"> <block lx="-0.5" ly="-0.5" lz="9" ux="0.5" uy="0.5" uz="10" index="61" material="3" look="3" up="1" color="ff0000ff"/> </item> <item parent="36" index="37"> <block lx="-0.5" ly="-0.5" lz="10" ux="0.5" uy="0.5" uz="11" index="61" material="3" look="0" up="3" color="ff0000ff"/> </item> <item parent="37" index="38"> <block lx="-0.5" ly="-0.5" lz="11" ux="0.5" uy="0.5" uz="12" index="61" material="3" look="2" up="0" color="ff0000ff"/> </item> <item parent="38" index="39"> <block lx="-0.5" ly="-0.5" lz="12" ux="0.5" uy="0.5" uz="13" index="61" material="3" look="1" up="2" color="ff0000ff"/> </item> <!-- Yellow --> <item parent="12" index="44"> <block lx="13" ly="-0.5" lz="-0.5" ux="14" uy="0.5" uz="0.5" index="61" material="3" look="3" up="1" color="ffeeee00"/> </item> <item parent="39" index="45"> <block lx="-0.5" ly="-0.5" lz="13" ux="0.5" uy="0.5" uz="14" index="61" material="3" look="3" up="1" color="ffeeee00"/> </item> <item parent="0" index="46"> <block lx="-0.5" ly="-2" lz="-0.5" ux="0.5" uy="-1" uz="0.5" index="61" material="3" look="3" up="1" color="ffeeee00"/> </item> </plan> </ship_design> Ship: Some attributes are easy to figure out: Each block has an index number and a parent identified by its index. Block's dimensions are defined by 6 variables, upper and down values in each axis ( in Cartesian coordinates ): lx, ux, ly, uy, lz, uz. The plan's attributes, "accumulateHealth" and "convex", seems to always have the same values, "true" and "false" respectively. I don't know what could be the meaning of this neither. But the attributes whose meaning I would like to figure out, because of their importance, are, mainly, "look" and "up"; and "color" in a lesser extent. COLOR: The last 6 digits configure a RGB color format, ok. But what are the 2 first digits? They are also hex values, but it seems that they are always "ff". I have performed some test changing this digits, but it seems that nothing changes. LOOK and UP. This two attributes determine the block's orientation (if a directional thruster is working on X, Y, or Z; if a corner shaped block is "upside down", and so on). But I can not understand the relation between the values of this attributes and the block's final orientation. The possible values, for both of them, is from 0 to 5. [i have to go now, i will edit and expand my explanation] Do you have, guys, any idea of the meaning of this values? Thx for reading! See u in Avorion!
  17. I have played one game since months ago and yes, I have found the hyperspace cooldown hard to improve. The solution in my case has been to mantain my ships at low mass to be able to continue playing; I would say that the game is harder in this sense.
  18. Hello everybody! I was wondering if it would be possible to implement a mod to reload ships xml files from the game folder. Currently, it happens when the client loads the galaxy (when the player enters at some server); so if you import some ships files into your game folder you have to leave and reenter the galaxy to load them. Sometimes the reenter method is a real pain if you are importing, renaming, or changing your ships folder tree. Also, I am currently working in an Avorion ship building api for Java (you know, to procedurally create ships and play a bit with the possibilities), which will produce ships xml files, and a mod to reload would be really handy, both for development tests and for the afterwards use of the api (of course, the api will be published, and I hope that soon!). I have had a fast look into the game api but I haven't seen anything about the ships reload. Is it even feasible with the current game api? Thanks for reading, see u in Avorion! ;D
  19. Yes, the game has opted for "HP bar battles" (HBB) rather than "destruction battles" (DB). If you focus enough, you still can destroy some vulnerable and strategic parts, but I think that Ships integrity is more like a weakness that can appear if the ship is not well built, and not a battle main point. The HBB was increased with the introduction of the torpedoes in the 0.16.6: That mentioned block break threshold (BBT) depends of difficulty, which is in some way indicative that block break is not a game core feature: (This threshold is only for player ships, not IA's) Are DB viable? I think that yes, it could be a mechanic with more importance in the game with an active presence in battles. I would even say that it would not require big changes. IFG block mechanic is nice, it introduces complexity in the construction aspect of the game. In order to introduce DB, its effect has to be reduced significantly. Not everyone likes DB? Well, as with the collision damage, BBT could be a separate game setting, not linked to difficulty. What about massively torpedoes damage? I find it ok. If a torpedoe has a certain damage and it hits you, well, you should suffer that damage, right? If the IA kills you easily, low the difficulty. Is the IA launching too much torpedoes? Is the IA launching very powerfull torpedoes? You are able to repair your broken blocks anywhere, and in cheaper way in stations. Nice. If with the introduction of DB the reparation cost are to high, reparations costs in general could be lowered. DB would also in some way mitigate the Health/durability issue: https://steamcommunity.com/app/445220/discussions/0/135510393198186982/.
  20. THE EXPLOIT. Well, I have just started a game with newest features, but it seems that reconstruction tokens have an obvious exploit: You can use a low price design to buy a reconstruction token, and then apply your main ship design. For example, you can use a low price design to buy a reconstruction token (for example, for 1000 credits), and then evolve the ship applying your main design (for example, with a price of 50k credits). If you are destroyed, your 50k ship is restored. I wonder for a solution... Maybe, if a ship with a bought token increases in a certain %, the price that the ship had when the token was bougth (30%, for example), the token may be invalidated. Maybe with a message like: Your ship has increased its token value too much. The reconstruction token must be updated. If it a ship with a invalidated token is destroyed, it can't be reconstructed, and the token price is returned. Free tokens (those that are gift at lower difficulties when a ship is found, and so on) are special, because they are not affected by the exploit, so they would not be affected with this mechanic. THE PRICE Also, I have noticed that the token price is usually higher than the ~30%. In fact, it is more often ~60%. Do you have noticed any reason? May be a bug?
  21. I have just created the game difficulty wiki page, mainly to recopilate information about its effects. After diving a while into the patch notes I have created a table with some of them. Please feel free to consult it and contribute ! https://avorion.gamepedia.com/Difficulty See u ;D
  22. thx for have fixed this, very fast! http://www.avorion.net/forum/index.php/topic,4529.0.html
  23. -- Sorry I quoted the entire post by error here
  24. After a look to the blocks' basic stats (durability, density, energy consumption, and so on), I would say that it is time to a revision and a rebalance. Some are old issues, and others may be result of the recent game changes, that have hadn't time to be revised yet. I will use this data to compare the numbers: Abstract Block values compared with the abstract hull values as reference: And a long table with particular values compared with the Trinium Hull Block values as reference, here are some screenshots: 1. The Durability/Density Issue. Under my point of view, armor and chassis blocks should be the most efficient block in terms of durability/density. Why? Well, these are the main functional stats of chassis. If other block types, like solar pannels, have better stats, players may use it instead of chassis (armor and hull) blocks; and I don't know about you, but I would not like to see that situation into the game. I would like to armor to be used as armor (compact and efficient barrier), and hull to be used as hull (efficient filling material). Maybe in real world other blocks should have better dur/den than a tipical armor material, like the recorder block, for example, but I would not like to see a ship using recorder blocks as armor in the game :/. Price is also a variable to have into account, but players will not care to pay in order to have the best material performance. If we see the numbers, we find some odd data, like that solar pannels have the top values: As we see, armor and chassis are far away from the top: Game balance importance: 2/10 Game aesthetics importance: 8.5/10 Fixation difficulty forecast: 2/10 2. Energy Consumptions. While some blocks, like chassis, have an energy consumption, other ones, like hangars, lights or holos consume 0 energy. Assembly blocks aso do not consume energy! Game balance importance: 3/10 Game aesthetics importance: 5/10 Fixation difficulty forecast: 1/10 3. Other individual balances: -Right now, thrusters, for example, have a ridiculous durability (12,5% compared with an abstract hull), having into account that sometimes they need to be placed in the edge of the ships, and thus, sometimes exposed; with not doubt, more exposed than engines. I think that their Dur should be increased at least to 50%. Game balance importance: 5/10 Game aesthetics importance: 1/10 Fixation difficulty forecast: 1/10 -Any other desired changes. Thx for reading, see u guys o7
  25. Nice improvements! ;D But I have a question. The time passed simulation does include some kind of trading simulation, or only self production and self consumption simulation? I really think some kind of trading simulation would be a good balancing feature, making the stocks more random than a predictable disconnected chain of production, avoiding the exploit of somekind of "broken" routes or similar situations. See u o7
×
×
  • Create New...