Jump to content

Helediron

Alpha Tester
  • Posts

    341
  • Joined

  • Last visited

Posts posted by Helediron

  1. Currently you can't get the destination coordinates in Lua scripts. There is no API call for it. It's one of the most requested features. I suggest you send a ticket to support about it.

     

    Assuming we get it one day, then calculations are straight-forward. Everything in DU are in 3d world coordinates and the unit is meter. If you subtract your ship's world position from target, the result is vector pointing from ship to target and its length is the distance in meters.

     

    Go into your game directory, game\data\lua and look around. There is e.g. cpml\vec3.lua for 3d vector calculations and very useful.

     

    local target = vec3(1,2,3)

    local ship = vec3(4,5,6)

    local toTarget = target - ship

    local distance = toTarget:len()

     

    Your velocity is also a vector. If you are flying towards the target, then its length is your speed in m/s. If not, you need some math but vec3 has e.g. projections to do it.

     

    There are actually two coordinate systems in use when sharing locations: world and planetary coordinates. World coordinates are the basis. Planetary coordinates are local polar lat/lon coordinates. Each planet is actually a huge sphere construct placed in fixed position in world coordinates. World z axis is their North pole and x is Greenwich line.

     

    If you browse DU Discord's Lua channel, you should quite soon find sources to convert planetary lat/lon coordinates to world coordinates.

  2. 2 hours ago, SuverLen said:

    Hey there thanks for the scripts. May u help me by this error by follower pet? image.thumb.png.de46f53e9d6e42ec454d8677b7401c31.png

    You probably have links mixed up. Go to build mode, links tool. Point each link and check the tooltips. Looks like slot "core" is not really going to actual core. When you find a wrong link name in tooltip, open the Lua editor and write the correct name to slot on left column.

    And check all links. If you have one wrong there is probably another that got swapped with the First. I mean if a telemeter is named as core, the probably core is named as telemeter.

  3. I have a bugfix for it, and the code is below. Note that this works together with other code which automatically manage ground engines, e.g. set them to max altitude before landing. This code does not work alone. But I think you can test it by pressing Alt+Space/C

     

    The idea is to get distance to ground, ground engine max altitude, and keep vertical atmos off until ship is over 90% of the max. There is small hesitation at max while verticals warm up.

     

    The code is in system.flush, and the patch code goes around the part where vertical engines are handled. IIRC the first and last  comment are from default script, aiding to find the location. I hope they match current default script.

     

    The code is clipped from flight script but had to edit heavily to get the gist of it.

    Quote

      -- Vertical Translation
      local distanceToGround = 5 -- actually link a ground engine or
      -- telemeter and get the distance
      local groundCapability = unit.computeGroundEngineAltitudeStabilizationCapabilities()
      local maxHoveringAltitude = groundCapability[1]
      if distanceToGround > 0.4 and
       distanceToGround < maxHoveringAltitude * 0.9 then
        -- Bugfix: when landing verticals don't shut down even when ground engines take over.
        Nav:setEngineForceCommand("thrust analog vertical", vec3.zero)
      else
        ... -- here is the default script vertical engines code, twentysome lines
      end
      -- Auto Navigation (speed Control)

     

     

  4. Agree with this.

     

    I got also an alternative idea: let me see locations of respads. If player can activate a respad, they have some rights to the ship, and knowing where my activated respads are would be a bloody nice feature. AND it could also tell where the borrowed ship is, assuming the pad is named after the ship.

  5. On 5/1/2019 at 12:01 AM, DaphneJones said:

    So a large container still holds the same volume, but what about mass? Does iron still mass 8kg per liter when it's in the container, i.e. L container full of iron masses 1024 tons? If so, I don't see how this solves the cargo problem unless you can make more with the same amount of mined material.

     

    Someone said on discord that mass is reduced by a factor of 16, but I don't see that in the devblog.

    That was my writing but foremost about volume: 64m3 to 4000 liters gave that exact 16:1 number.

     

    Mass reduction is not directly mentioned. They said they reduce volume and weight. Also they mention that mass carries over in crafting and in future we can transport ore in atmosphere.

     

    I checked few elements like small space engine. It weights one ton and uses about 20 tons of ore. I only looked few other examples and they all pointed to similar 1:10 or 1:20 reduction in ore mass from ore to element in r0.14. Assuming element weights don't change and they use same amount of ore in r0.15 too, this pointo to at least 1:10 reduction in ore weight.

     

    My larger freighter can lift away from planet without AG about 200 tons from Alioth, 400t from other atmo planets and 1000 tons from airless. Asuming 1:10 weight reduction in r0.15 that 200 tons would estimate to  one or two deposits refined to pure, depending on density.

     

    Hover freighters were already easy and effective, so they are not a reason to change ore weights.

     

  6. 9 hours ago, Oxyorum said:

     

    This is already accounted for:

     

     

    It describes the exact scenario you are concerned about.

     

    EDIT: I realize you are talking about the ability to miss the change even after the offer is automatically deselected. Although I would personally chalk that to lack of care by the player in question, it wouldn't hurt to add in some sort of pop-up window that will indicate that one of the parties changed their offer, in addition to the automatic deselect. That way, players have a visual queue and are more likely to double check their offer before accepting it a second time.

    This is NOT the situation the blog describes.  Now i am nasty: this is why the cheat works. We don't anticipate it. We trust the UI and don't even realize we got scammed. This is a common cheat in some other MMOs.

     

  7. I suspect there is a flaw in barter UI. Of course I have not yet used it, but I have seen same flaw being abused elsewhere. Looks like the UI allows common cheat where the other use can quickly change their offer.

    1. Other user places e.g. 5000000 ducks as their offer.
    2. I place my stuff.
    3. They click confirm, wait one second, take a zero away and reconfirm.
    4. On my side I see their first confirmation and click my own. Because i have to momentarily concentrate to my own UI, there is a good chance I don't notice their change and second verification until too late.

    The flaw in the UI is that I can't freeze their offer for review before acceptance. A simple fix would be that I could do it with "Looks good" button. My accept button stays disabled until I clicked the "Looks good". Any change from other side before I manage click the acceptance would disable accept and resets "Looks good". I need to re-verify their new offer. And if their change comes after my acceptance it would reset it (as described in the blog).

     

    This two-stage acceptance should be rather simple change in client UI only. It does not need any change in the server protocol.

×
×
  • Create New...