BAMcSH_

I noticed whilst using some force turrets the other day that stationary asteroids seem to be shelved by the server, and when you begin pushing them it takes a moment before the server catches up. I would estimate this to be an optimization decision, but could be wrong.

The Engine().brakeThrust field does not include braking thrust from Inertial Dampeners attached to the ship. Through some testing I have confirmed that the ShipAI():fly() function also does not consider Inertial Dampeners when calculating this value. A ship with no thrusters that apply braking thrust will fly obscenely slow if there are any entities anywhere along its flight path, including extremely long distances past the destination, even if it has sufficient Inertial Dampeners to halt it from maximum velocity in exceedingly short fashion. The same ship fitted with braking thrusters will fly considerably faster towards its destination, even if other entities exist along its flight path. A search of the forum indicates that this was reported more than a year ago, but went unanswered. This would be a useful calculation to have for flight management purposes.

priestkatten, By default resource laden asteroids will respawn via this script 2 to 8 minutes after they are destroyed. This script will have no effect on sectors without resources in them. Which file did you place the line in? There are several options.

You can create turrets by defining a TurretTemplate and instantiating it on a ship or other entity with the Entity():addTurret() function (which I have a dedicated post explaining the functionality of)

Heya Linkfish. If you load into the game and do it through chat, the script will persist indefinitely. So if you only have one starting sector then it's just a one-time set and forget for the server. As far as noted in the scripting docs, the Sector() constructor does not accept any arguments, so it can only return the sector that the current script is running in I believe. EDIT: I guess I should mention, now that I think about it, there is an obvious solution here. The startsector.lua script gets run on player faction owned sectors only, so whether you only have one of them or multiple, adding the call in only that script will cause resources to respawn in all start sectors.

You can't detect the turret as a block, but you can determine the index of the block the turret is attached to via getAttachedBlockIndex called on the turret, and when that block index is destroyed on the ship, the turret is ejected into space. Yeah, my setValue on the ship seems to be getting eaten though, and invoking the script doesn't preserve local values. I'll probably have to jank this a bit.

I didn't get around to testing it, but a strategy I considered was using Entity():isCollectable to find loot that was freshly dropped by the player, who wouldn't be able to pick it up for a few seconds. Since it's possible to determine when turrets are destroyed via callbacks, as well as when the player's own ship's plan is modified (blocks destroyed), I feel like that route could bear fruit for you. I'm currently testing the viability of automatically placing/resetting turrets when the player enters the build menu to prevent duping via the script I'm working on, so I'll post later with how that goes.

Well, the old turret will still be there if you don't delete it via the function from Sector, but using that command doesn't cause floating loot, which is nice. My first attempt at replacing a turret involved temporarily deleting the block it was attached to and then quickly grabbing and deleting the resulting loot object, and that was uhh, less than ideal. EDIT: Oh, but also, you don't have to delete the old turret until after the new one is added. In fact, you can stack however many turrets you want in the same spot, their collisions don't matter.

Certainly! Here's an example, this is where I placed the function to add the script in one of the sector generator scripts, asteroidfield.lua: When I did this I actually just did a blanket search/replace for the entire directory using Notepad++, but the easy objective is to look for that other line where the events script is added and stick the line to add my script right after.

Could be a tutorial or just more of a knowledge dump. This function caught my eye as something that would be useful, and I've worked with it extensively the past day or so, so I thought I would share my findings with the community and give a small refresher/tutorial about matrix transformations in regards to this operation. If you wish to only know how to use the function, there's a specific example of what is likely its most usable functionality at the bottom. I am going to assume that you know what a vector is, and to understand these explanations you may need some knowledge of linear algebra. If you don't know these things it will be rather difficult to understand how this function operates. First, some pre-emptive facts about the Matrix object: It contains 6 fields: right, up, look, translation, pos, and position. Right, up, and look are all unit vectors for those corresponding rotational directions. In Avorion it seems like the 3-dimensional plane maps right the x value, up the y value, and z the forward value (look value). A demonstration of this is seen and explained in the first screenshot. Translation, pos, and position all get changed whenever any of the properties are modified, and they generally remain identical. I suspect that they are repeated to allow for matrix operations. The transformNormal and transformCoord functions perform a matrix multiplication between a 3x3 section of the matrix object and the passed vector. The first operates on the rotational unit vectors, the second on the positional coordinates. I have not tested the functionality of the Matrix:transform(vec3) function, and it shows up absolutely nowhere in the base scripts for the game. After some initial attempts where I provided the values of an original, already place turret, it first became clear that the function was using the passed position value from a matrix in a relative way rather than an absolute way, likely because the entity's position is being updated every frame by an offset to the ship's position, since turrets are locked to the ship. I proceeded to perform this test, which proved quite revealing: The rotation vectors of the generated turret's matrix are directly proportional to the ship's when the passed unit vectors are the base vectors for right, up, and forward (look). This suggests that the rotation of the turret is also determined in relation to the ship's every frame. Further, note that the magnitude of the passed positional offset is maintained in the magnitude of the offset of the generated turret, even though the new offset is not the same. Finally, note that the new positional offset is equivalent to the magnitude of the passed positional offset multiplied by the magnitude of the ship's "right" unit vector. This provides us the knowledge that the offset is determined by applying the magnitude of the passed position's x, y and z to the directional unit vectors right, up, and forward of the ship in order to determine the generated turret's position. Now that these facts are observed, they meet logical expectations for how a turret's position would need to be determined every frame, so it would seem the mystery is solved. Now all that's left is some math, but first some confirmation on our observations regarding the rotation vectors: We can observe that abnormal rotation values had no effect on the magnitude of the positional offset. We can also see from the passed right rotational value that given rotational values are multiplied to the ship's. The passed look is the unit vector of the passed up, and indeed, the produced vectors for up and look are different lengths in the exact same direction. Generated rotation vectors are seen to be directly proportional to the passed vectors multiplied by the Ship's without any extra shenanigans. Specifically, the x value of the generated turret's right vector is determined by multiplying the passed right vector's x, y, and z values to the ship's right.x, up.x, and look.x values and then adding them all together. This process may sound familiar to you: it's matrix multiplication. For the uninitiated, the product of two matrices A * B is equivalent to the sum of the products of every row of A and every column of B. The resulting generated values of the turret's rotations are the product of the passed vectors as rows of the first matrix A and the ship's vectors as rows in the second matrix B. This also reveals that the position vector is repeated 3 times to allow for a matrix multiplication to determine the new position. The generated turret's position value is the result of a matrix multiplication between the passed translation, pos, and position vectors and the ship's right, up, and look vectors to obtain an offset, which is added to the ship's position to acquire the turret's final position. Wikipedia gives very proficient explanations of matrix multiplication as well as matrix transformations, if you're looking to understand them. This isn't exactly required to make use of this function however. Now that we understand exactly where the produced values are coming from, lets examine a potential use of this function: Replacing an existing turret with a new turret. This is a helpful process for a couple reasons, one of which being that modifications to a turret's template do not effect the existing turret, and in order to instantiate the change we must remove that turret and respawn it. So lets develop a function for this process, along with how we can use some matrix operations to make it simpler on ourselves. Given an existing turret, we know values for its rotation and position from its own position matrix, since it is an entity. These values, however, are absolute values that are derived from the ship it is attached to each frame in the engine. If we want to find the correct matrix values to pass to the addTurret function, we have to perform a division. Matrix division, if I'm being strictly correct, does not exist. It is possible however to emulate using a matrix inverse. Thankfully, Avorion's matrix object provides this operation to us, so I don't need to explain it here. We can determine that, since the generated turret position is the result of A x B where A and B are the right, up, and look vectors of the passed matrix and the ship's matrix respectively, if we multiply an existing turret's matrix by the inverse of the ship's matrix, we obtain a matrix that will reproduce the existing turret's values when passed to the addTurret function. This results in an incredibly simple sub-operation to get what we want: function swapTurrets(ship, oldTurret, newTurret) ship:addTurret(CreateTemplateFromTurret(newTurret), oldTurret.position * ship.position:getInverse(), oldTurret:getAttachedBlockIndex()) end You can also remove the old turret from the ship by calling the Sector():deleteEntity function, quite pain-free. Now, most of this post has been discussing the matrix variable of the input, but there are two others with simpler explanations. The first input is the turret template you want to instantiate on the ship. As seen in the code snippet, you can generate this from an existing turret via the global function CreateTemplateFromTurret, but there are other ways to come by it. I'll leave those to you. The third input of the function determines the block index the turret is attached to. It does not need to be in physical contact or even anywhere remotely close to this block. In fact, all this seems to do is determine when the turret is destroyed. Since turrets themselves do not take damage and have no durability, a turret is only destroyed when the block specified by this index is destroyed. I believe that concludes this little tutorial, so allow me to sum up my findings in a littler TL;DR: The addTurret function performs a matrix multiplication between the passed matrix and the ship's position matrix to determine the position of the new turret, requiring the position to be given as an offset from the ship's. Retrieving the position matrix property from a turret entity will give you the absolute values of its position and rotations, instead of the relative values required by the addTurret function. The provided block index does not effect the turret's position, and only causes the turret to be destroyed when the block is destroyed. Using the multiplication operator on two matrices causes two separate 3x3 multiplication operations between the right, up, and look values as well as the translation, pos, and position values of the matrices.

There are sector generation scripts in the scripts/sectors directory. If you want resources to respawn in every sector, you can find the line where the events script is added in each of those sector generation script files and paste the line to add my script to the sector there.

Thanks, I'll probably do that soon. I have a couple other ideas I'm fleshing out and then I will likely start a thread for all my scripts.

Hey there! I made something that I think fits what you're looking for. This script, when attached to a Sector, causes any destroyed asteroids with resources to respawn as a new random asteroid with resources befitting the Sector sometime within mintime and maxtime, as defined in the script. I attached it to every sector by adding Sector():addScript("data/scripts/sector/resourcerespawn.lua") after the Sector():addScript("data/scripts/sector/events.lua", "events/pirateattack.lua") in all of the sector generation functions. If you wanted it to only run in the start sector, I'm not certain where the best place would be to add it in the scripts, but you could run it manually via the chat at that point by just manually executing /run Sector():addScript("data/scripts/sector/resourcerespawn.lua") The one drawback here is that the script won't spawn new resources (I tried that first, determining fitting positions was a nightmare, not to mention I wouldn't really know if things intersected), so you have to get it running on the sector before anyone mines it. All your players will need the script also I believe, I'm not really sure, this has been a learning experience. EDIT: I forgot to mention, place the script in data/scripts/sector as seen in the function calls. EDIT 2: Fixed a problem with script. I actually made this script the same day you made this post, but the forum wouldn't allow me to complete registration on my primary email, so I finally ended up doing another registration with a gmail. resourcerespawn.lua