Jump to content

xisec

Members
  • Posts

    38
  • Joined

xisec's Achievements

0

Reputation

  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! :(
×
×
  • Create New...