Jump to content


Alpha Tester
  • Posts

  • Joined

  • Last visited

1 Follower

Profile Information

  • Gender
  • Location:
    Germany, NRW
  • Interests
    Making stuff, 3d printing, openscad,arduino, raspbery Pi, RC, etc.....
    and of course DU
  • backer_title
  • Alpha

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I would take a different approach. A capital ship powered with rockets/atmo engines shouldn't be able to easily land on a planet Espceialy if they only use normal atmo engines. We do actually have better engine types: AGG's. The AGG's used to be really useful when we've been able to operate them at higher speed. and honestly they are the most expensive engine tech in this game currently, but became basically useless with the slow ascend/descend speed they now have. If they are that expensive and high tier, why not make them useful? Why have an altitude limit on them of 1000m which leads to all the AGG towers everybody hates? My proposal: keep AGG's expensive but make them useful again! Remove the 1000m altitude limit and allow them to be used with higher ascend/descend speed. If you want to "nerf" them, maybe put in a mass limit at which they can be operated or make them even more expensive.
  2. well. my fastest atmo only ship went up to 6130kmh and did not have any voxels.. landed safely at my base after getting to that speed.
  3. well the other workaround is: do not use any voxel material on your construct. without honeycomb, the cross secrion calculation is always right.
  4. Only very temporary workaround is going to build mode, waiting for better values to display, and directly activating the control unit. but it does not even last the full flight. i got contacted by NQ every now and then about my ticket on this sisue, but always just standard replies. nothing resolved till today. no big red error message on screen, not a lot of people relize the bug even exists, so no priority on it
  5. Thanks a lot! a step in the right direction! some problems just can be resolved so much quicker and it does not make sense to always create a ticket just to get your ship out if the terrain loaded after landing and fetch is not working or whatever..
  6. a standard hover engine detects water, so hovering above 0 meters is still possible there. a telemeter though displays ground surface (thorugh water) not sure if something has changed, but works as expected for me.
  7. OK, so Schematics cost for T1 stuff will be reduced. everybody in game will be able again to build their own stuff. Even though i appreciate the change, i personally spent most my money since 0.23 in T1 Schematics to set up an industry to create those mainly T1 parts affeccted by the element destruction mechanics ( which oops.. won't happen) i assume no refund will happen... so all for nothing .. let's start over ( yet again)
  8. the problem basically occurs as sometimes when the pilot quickly presses any of the buttons for the roll/pitch/yaw axis, one of the Filters/Events when releasing the key is not gettting executed. this leads to that axis constantly firing the adjustors. The change above fixes this and works great for any default autoconfig. If you use another HUD/flight control script, this might work, but might as well break other stuff.. so try at your own risk if you use something else then the default autoconfigs
  9. **Fixing the "Roll of death" aka "Stuck Adjustor" bug in DU** Since almost forever there is a bug in the default autoconfigure scripts that causes adjustors to behave like they are "stuck". This leads to a lot of crashes. So here is the fix. Open the LUA Editor of your control unit (hoverseat, commandchair, remote control, whatever) click on "system" In here we have to change 6 different "actions" for the 3 axis. they are the "ActionStop" actions for the following keys: -left -right -forward -backward -yawleft -yawright Each of these actions is trying to change one specific variable by in/decreasing it. you have to basically overwrite the single line and assign the value 0 to that variable Here is the example for ActioStop(Forward): Original Line: pitchInput = pitchInput + 1 change tis line to: pitchInput=0 now do that kind of change for all the above mentioned actions (each axis will have a different variable name) then hit "apply" and enjoy the fixed bug, where your adjusters will not get stuck again. If you want, you can create your own autoconfigure script with these changes (copy the default\**config file to the custom\ directory and do the changes in there
  10. they are since an update last week.. they haven't been really usefull anyway ( except maybe for repairing voxel damage from PvP), as they only replaced elements instead of repairing them with scrap. so just wait a bit for them and hopefully have NQ make them usefull finally...
  11. here is a quick video demonstrating the bug in build mode. This constructs has 0.81m² and 0.38m² being displayed.. if you would finish this build, usually the 0.81 would get applied when flying, resulting in a much reduced top speed. ( unless you use the build mode steps i documented in the top post in this thread, to make the physiscs use the 0.38)
  12. here ya go.. xs core & basic l atmo with my main account talents.. and same with engine lvl 5 talents: Regarding the cross section bug, you'll probably only see it if you are working on xs elements with an ultra small cross section( like the hagboard)
  13. Flying Faster with less or ...Dual Universe and the cross section calculation I quite enjoy building small efficient atmo flyers (you probably know the Hagboard) The key to the fun factor of these little ships is keeping the Frontal Cross section as low as possible. For the Hagboard it is usually 0.38 which is the smallest value that is possible if you still want to have the comfort of a hover engine on your construct. But since some months, DU is not making it easy for these little ships. There is a bad bug with the cross section calculation which usually leads to a wrong (higher) calculation of the frontal cross section. You can easily see the problem by entering build mode and having a look at your max speed & frontal cross section. In most cases you first see lower speeds and a higher cross section, and after some additional seconds this value changes to the "real" values. So the frontal cross section is supposed to be the total surface of the ship when looking from the front. This should be a static value, but due to the bug, we get 2 separate values. Even worse: when starting a flight DU usually takes the "worse" value to calculate the flight physics. I assume that the first "bad" calculation is done on the client side, and the second "real" values somehow come either from the server or using some values being loaded fro the server. As sometimes the server is slow, we get into a situation where the "better" values might even never get loaded to the client. As well during flight, DU re-calculates this values. So even if we manage to start a flight with the "better" values, we might get faster speed & Acceleration at first, but after some control movements DU usually falls back to the slow values. There is 1 trick how you can do a test flight and "force" DU into the faster values.. give this a try: 1. place your construct flight ready, pointing towards a wide open area ( e.g. a big water surface) 2. enter build mode and look at your max speed / frontal cross section 3. wait for the max Speed & Cross section to be displayed with the "better" values 4. exit build mode and directly activate the seat/remote controller 5. give full throttle, avoid steering and try to stay between 100 and 300 m... By following these steps you should be able to do a flight with the "full potential" of your construct. Another possibility to increase the speed of your construct is to remove ALL Honeycomb from it. The cross section calculation only fails if there is at least 1 honeycomb voxel on your construct. so without them, it should always use the "better" values. i have 2 tickets around this topic open now for 1-2 months, but obviously NQ has more important things to fix right now. But as i get asked multiple times a day, i thought it would be easier to give the explanation here so i could point people to it 😉 Have fun flying, Hagbard
  14. alt click with the tool you used to place it..
  15. Thx Helediron.. waiting desperately for those as well 😉
  • Create New...