vertex

But I can do a lot of thinking in 5 minutes. For example I thought about that issue of crashing into a station or a planet after warp and considered what it implied. Now the only thing it means is that the responsibility to stop before warping shifts from the warp script to the player. If you want to be safe on warp exit: just stop before you warp. Not too much to ask for and let's be real - that instant brake the warp does as soon as you activate it feels reeeaally awkward. I found myself sitting there and asking "Why can't I cancel warp and use it as brake? It's much better at the task than my space brakes!" In addition, if you've got a scout ahead of you that can tell you if the destination is clear, you can implement nice new tactics - or you take a chance to hit the ground (ehem,...) running blindly, hehe. Again that would be completely in the player's responsibility. Nobody complains that you burn in the atmosphere if you get in too fast - why should it be an issue when you go too fast into warp? ¯\_(ツ)_/¯

nice concern! Didn't think of that, but kinda obvious, yeah. Could be solved by making low speed a condition to be met before warp will be available. But I kinda like the idea of going from high speed to warp. I think if warp would keep the momentum and not insta-brake, only suspending momentum during the time of warp, it would solve this and be a nice addition by adding the option to come out of warp flying forward (if your momentum lined up with your warp direction). /edit/ps Adds to "player responsibility" too I think. I'd like it.

First of all: awesome! I really like the idea of stored momentum and wished for it quite some time. But I see huge issues with it that at first feel worse than not fixing it right away. Sorry, I didn't read all of the non-NQ replies here, but I want to add to the list of concerns and apologize if they've already been mentioned. Most of the time I got my AGG ship parked at 1050m above my base at Sanctuary (using the fact that logging out will freeze it in place because the AGG wouldn't keep it there when I'm gone as I understand it). I use an elevator platform (sometimes called magic carpet) to reach it and go down again. The AGG ship can maneuver in atmosphere but not lift without AGG support. Will my design be invalidated by this change? @NQ-Naunet could you please put child gloves on for us AGG captains and explain exactly how we need to prepare and what to expect? If I get disconnected while piloting, along with restoring my momentum, logging in should also restore me in the pilot seat. Otherwise I might crash for not reaching the seat fast enough. The position from where the player entered a seat should always be persistent. Currently you can get trapped in your own construct when you log out while seated, because it resets the position from where you entered the seat originally and the "default position after login" can place you inside the ship's structure, effectively trapping you. If your ship is stationary and frozen that's ok and you can enter build mode to free yourself - but if momentum is restored you might end up trapped, racing against time to get out of the structure before you hit something. You could argue bad ship design, but I feel that would be unfair, as placing a seat in a spot with a low ceiling for example or between flat elements would be a perfectly fine design in reality, but gets you trapped in DU. Remember to restore thrust settings and engine states as well. If you are floating on vertical engines (like elevator platform / magic carpet or heavy hauler with slow starting XL space engines) and need to set thrust and spin up these engines first, it could be enough to get you into a non-recoverable position. Make 100% sure that all game assets have been loaded before you restore momentum. Right after login I remember to experience heavy lag before the game runs fluently after everything loaded. Stuff like that made me fall through the ground and get a "Back to the surface..." screen - or fall through not loaded elements and end up in space (a friend entered another player's construct throug the not yet loaded door and got trapped for thinking there was none). Latter being ok if my ship is stationary - but imagine falling out of your ship when logging in, while the momentum is being restored and your ship shoots away. Ouch. You should freeze players in place until the surface they were standing on has been fully loaded or securely known to have be removed. When I first tried the radar in orbit to lock onto a ship out of curiosity DU dived into some kind of memory leak and made the game unplayable. Other times I was on a perfect approach vector, but the loading of planetary assets (or something else) killed my framerate. In both situations I had to use the emergency exit brake to avoid fatality. Same happened on markets where we already made a habit of landing 1km away and walking the distance to avoid crashing due to market lag. There seems to be a loop that constantly reinitializes all elements on a construct. This loop has a flaw and sometimes skips an element or takes minutes to find and enable it (at launch or mid flight). Just yesterday I was unable to turn right with my elevator platform and kept spinning left until 1-ish minute later DU realized that I had adjustors to turn right too. In the past this often led to situations where the emergency exit brake was the only thing that could rescue me. Given some time I think I could come up with more situation where a logout is the only thing able to rescue me from bad situations that I didn't cause myself. I'm all in on the idea that it should be in the player's control to live or die by being careful and planning ahead - but right now I feel like freezing my ship using logout to brake does more good than it does bad. Further I'd like to know if freezing a ship will be completely gone and if not I'd like to know if an approaching player or running around on your ship will initialize physics, or if that only happens when you enter the pilot seat? Regarding the maneuver tool: 50m is not enough and I feel this should scale with core size. If your ship is 128m, moving it by 50m doesn't suffice, while at the same time it's enough for an XS sized ship. Imagine your L sized ship laying on its back and you can't get it high enough to spin around? Errr... nope. Ok, takes only 3 Minutes to reset, but still rather uncomfortable to stand around watching the clock tick. Maneuver distance should always at least be a tad more than the edge length of your ship's building zone - best make it the distance between the upper left front and lower right back corner (I'm sure there's a term for the diagonal line in 3D space in English, but I don't know it). The constraints about standing on a planet or static construct should be enough to prevent platform-climbing and I don't see any benefit in limiting L cores (or XL later?) to 50m. Also, what happens when I stand on my carrier and maneuver a small ship around on it? Will it initialize physics after maneuvering and fall down on the carrier, meaning no more "docked at the side using clamp-ish force fields to walk over"? Maybe implement docking clamps first before removing the option to use the maneuver tool to simulate the effect.. but I'm not sure if that was even implied. Some clarification would be welcome, but either way it's not that crucial as the removal of the emergency brake

And I need a dislike button for people pushing their own agenda on completely unrelated topics But I think dislike buttons don't foster constructivity or lead to good relations - all they do is giving people a way to vent at the expense of the receiver who might not feel welcome anymore, even if there would be plenty of others who share their view. If we want to keep the general spirit of the community on the constructive side and people commenting in a way that's adding to the topic and kindness and prospering conversation instead of flame wars and trolling, a dislike button is out of the question. If someone wants to disagree, like I do with the request for a dislike button and thereby give somewhat negative feedback, they should be willing to take the effort and extra step to address it and provide a reason, as I feel I'm doing right now. Someone I don't remember once said that it takes 10 positive interactions to make up for 1 negative one. Yet I feel that some frustrated or vexed people are more likely to vent by smacking a dislike button than people who are satisfied are likely to remember to like something before moving on. Speaking for myself only, but if I encounter something I strongly disagree with, it makes me slow down and try to fix it, while something I like makes me want more and carry on, getting in the flow and being more likely to forget about giving feedback. The like button enables me to give that feedback, even if I have nothing to add, which is fine in that situation. The dislike button on the other hand enables me to give feedback too, but leaves the reasoning behind it completely in the open - just saying "that's wrong" doesn't help anyone improve. "How do you like my new ice cream flavor?" - "I don't!" - "Why, what's wrong, too sweet?" - "I just don't like it." - "Too fruity? Too sour? Too soft? What shall I do?" - "Search for another job!" ... there will be some grinning but it doesn't help the producer move forward and improve. Some people would hit the dislike button for bad grammar or errors in spelling, targeting a non-native language writer, while some would hit the like button for a violation of etiquette or trolling. In my opinion both is wrong, but the dislike does more bad to the non-native writer than it would do good on the troll, while a like on the writer could encourage him to overcome his reluctance to continue to write in that foreign language he's learning, boost his confidence and in time he might improve on his language skills, whereas the troll may experience positive reinforcement too, but be handled by forum staff sooner or later. A constructive member that turned away is harder to be reached out to. A "disagree" button maybe, but again, if people want to disagree they should do so by writing a reply and provide a better idea or at least explain what they think is wrong with it. However, I think we could do with a "please don't quote like that" button... shamelessly pushing my own agenda here after I feel I wrote enough to make up for it above ?

Here, I'll help out - Naunet can have one of mine Not just to chime in for you tho, but because I love the feeling of someone on the team "being open about stuff" and sharing thoughts, not too scared off by the idea of being overruled and having to sail back eventually. Kinda exactly the feeling that was a bit lacking for way too long. I always felt like it started with some NMS comment JC made during Kickstarter - never wanted to even ponder too loud about something that might not come into the game. Was just an impression that stuck around for me tho On topic: I'm not the most active member here and I'm not reading every post by far, but even I ran into that limit occasionally. Sure, I have spikes in presence but still, the limit and how it's implemented doesn't feel good. The term "today" alone is weak - what does that mean? If I reach it and decide to keep a tab open to add my reaction for a very good comment later, what should I set my timer for? If it literally is "today" I think the concept behind it is seriously lacking and should at least be something like "in the past 24 hours" (which I presume it is, but that's not clear). Example for reference: if it was 24 likes/day and resets at 00:00 o'clock, you'd have issues if you use the member's time zone as constraint that he could circumvent - but if you use 00:00 UTC you'd have people in the forums from 22:00 to 02:00 maybe and if they were late yesterday and early today they'd run into a limit that would feel random and for them reset at something like 18:00. The free 100k credits in DU have a timeout of 23h, which is a better solution. Since it's easier to code than dealing with timezones I guess the forum does the same and it's just the message that is poorly phrased, probably... but if some dev decided to use "count where date = today" it's just as easy as a "count where now -86400 <= timestamp"... you never know when a dev's brain ran out of coffee, so might be worth to check, hehe. But it's a minor issue. I realize the paragraph above might sound more irritated than I actually am about it. The frightening thing is that I could lose myself in hypotheses and concepts for a couple of more pages, so I'll better stop while I can... .oO( Thinking about modding this board too much. I'd probably add multiple constraints and create gradients that allow short term spikes while limiting long term excessive abuse... but wouldn't want to run into the too-modded-to-update trap... entirely depends on this 3rd party app's framework... oh dang it, note to myself: stop it already! )

Can I haz cookie? ? Uoh.. yeah, I remember UO. I'm older now but not much smarter. A bit calmer, if anything, maybe? Anyhow, got a message from the past for you: OoOoOoooOooOOoOoOooOooOOOooOOOooOooOooooOooOooOoOooOOoOo OOoOOOOO OoooOoOOOooOoooo OOoOOOOO OoOOOoOOOoooOoOoOooOOOOoOooOooOO OOoOOOOO OoOoOoOoOooOoooOOooOoOOoOoooOooOOooOOoOoOoooOOoOOoooOOooOooOOoOo

Um das Widget zu aktivieren musst du die Funktion show() aufrufen. Vorher muss der AGG mit Controller (bspw Pilotensitz) verbunden werden. Anschließend den Lua-Editor öffnen (Controller anschauen und Strg+L drücken oder über das Kontextmenü) und den Slot auf der linken Seite in "agg" umbenennen. Kannst dir auch nen andern Namen für den Slot aussuchen, aber dann musst du das folgende Script entsprechend anpassen: -- Zielhöhe in Metern über dem Meeresspiegel agg.setBaseAltitude(1000) -- Widget anzeigen lassen agg.show() -- AGG einschalten agg.activate() Dieses Script kannst du ans Ende von unit.start() packen. "unit.start()" heisst links auf "unit" zu klicken und dann in der nächsten Spalte "start()" auszuwählen, wo sich bereits das Initialisationsscript befindet. "unit" ist dabei der Slot (so wie "agg" im Beispiel). Man ruft also quasi die Funktion "start()" im Slot "unit" auf. Zu beachten ist, dass der AGG nicht sofort auf der eingestellten Höhe funktioniert, sofern seine aktuell erreichte Höhe zu sehr von der Zielhöhe abweicht. Die aktuell erreichte (ich nenn es mal) Stabilisationshöhe ändert sich nur mit circa 4m/s - geht also recht langsam. Ich glaub beim ersten Start ist die bei 1000m, aber da ich den AGG im All eingebaut habe und dann oben gewartet hab, bis ich in der AGG-Bubble war, bin ich mir da nicht ganz sicher. Der AGG manipuliert die Schwerkraft auf der aktuellen Stabilisationshöhe - man fällt dann quasi aufwärts oder abwärts - das führt leider auch zu einer recht nervigen Oszillation und es dauert lange, bis das Schiff wirklich still steht. Gut ist aber, dass das Teil sogar dann weiterläuft, wenn man den Pilotensessel verlässt. Mein Script sieht so aus: AggAltitude = math.floor(core.getAltitude()) agg.setBaseAltitude(AggAltitude) agg.show() agg.activate() Da hole ich mir zuerst die aktuelle Höhe und setze den AGG dann darauf. Der AGG merkt sich auch seine letzte Stabilisationshöhe, sodass man sich ausloggen kann und wenn man wieder in den Sessel klettert, liegt das Schiff stabil auf der aktuellen Höhe. Wenn du die Triebwerke benutzt um umher zu fliegen, dann Vorsicht: falls du dabei zu hoch oder zu tief fliegst und dabei aus der AGG-Bubble raus kommst, dann fällst du wie ein Stein. Ob du in der Bubble bist siehst du an der Gravitationsanzeige - innerhalb der Bubble liegt die immer bei <0.1 g wenn stationär oder sehr dicht dran. Du kannst dir neue Filter, wie bspw system.startAction(option1) anlegen, die du dann standardmäßig mit Alt+1 (option1) bis Alt+9 (option 9) aufrufen kannst, um die Höhe zu verändern. Also bspw mit Alt+1 machst du AggAltitude = AggAltitude +100 und mit Alt+2 dann AggAltitude = AggAltitude -100. Ich hab mir eine Option zum Setzen der Höhe belegt und eine zweite zum ändern des Inkrements, sodass ich nur zwei benötige, um die Höhe um +1, -1, +10, -10, +100, -100, +1000, ... etc zu verändern - die Bedienung ist dann halt nicht ganz so komfortabel, aber dafür lässt sich jeder Wert schnell erreichen

Für uns: Wartungsarbeiten am Dienstag 2020-11-24 ab 09:30 bis circa 10:15 oder 10:30

Donnerstags Patch-Tag. Sprich Wartungsarbeiten am 2020-11-19 von 10:30 bis ~11:30 (UTC+0100)

Doesn't even need to be that either. I had the same issue in the past and it went away soon after. Might wanna try to delete the cache or rebooting your PC or just wait a bit. Filing a report won't do any harm in the meantime. In my experience that's just a random hiccup from time to time and you should not be too worried about it just yet /edit https://board.dualthegame.com/index.php?/topic/20376-you-were-disconnected-by-an-admin/ The next server restart could also solve this btw.

Kein Unterschied. Man kann die verschiedenen Treibstoffe nicht mixen - das ist alles. Ich vermute der Grund für die Existenz von X1-X4 ist, dass man für Kergon T2 Erze braucht, die nicht alle auf jedem Planeten/Mond verfügbar sind. Dank der verschiedenen Rezepte kannst du überall Kergon produzieren und strandest nicht einfach so. Ansonsten sind die Sorten wohl gleichwertig. Wenn du alle Erze zur Verfügung hast kannst du dir die Sort aussuchen, für welche du die meisten Rohstoffe hast, oder die Rohstoffe einfach für nix anderes brauchst. Natron ist ganz praktisch, da es eine sehr geringe Masse hat und leichter transportiert werden kann. Also gibt es neben der Verfügbarkeit halt ein paar logistische Unterschiede. Mehr Schub oder weniger Verbrauch oder so gibt es da meines Wissens nach aber nicht

First: yes, placing it from linked container is correct. There are multiple reasons why it might fail - even tho I think that got fixed, in the past the linked container sometimes didn't work properly. Relogging and reset/relink the container could help. Then make sure that your linked container is selected: you can see the "link icon" above your inventory next to the "box icon" - it should be selected and means that the linked container is your active container. You can switch the active container by clicking on these icons or pressing ctrl+i on your keyboard. It will give a message "switched active container to...". Last thing that comes to mind is that there was/is an issue where you can't place claimed elements. Look at the symbol of the scanner - if there's a "person icon" on it, it's claimed and you should right click and "unclaim" the element before you try to place it again

Noch nicht im Discord angekündigt, Server ist aber wieder offen /edit

Noch nicht da, ist aber geplant. Schau mal hier: https://upvote.dualuniverse.game/suggestions/116123/playerdriven-simple-mission-system Btw Gesamtliste hier: https://upvote.dualuniverse.game Ich warte auch drauf... auch wenn ich den Voxel Vertices Editor noch viel lieber sehen würde

Wenn der Blip auf der Karte grau ist, dann suchst du den zerstörten Core (nennt sich "Haupteinheit" im Deutschen, glaub ich ?) und reparierst ihn - dann isses dein Konstrukt

Du nutzt die E-Mail Adresse für den Login, ja? Falls nicht: muttu tun tun.

War zu langsam - ist schon wieder vorbei

Ach deshalb sind da immer so wenig Leute in meiner Kontaktliste online...

In der Nacht?

Ach simmer wieder herzig ❤️ Warst du dabei oder ziehst du nur Rückschlüsse aus nichts? Verstehe die Motivation hinter dem Posting irgendwie nicht. Mach halt nen Vorschlag zur Optimierung oder so? Wenn nur zwo da waren und Spaß hatten war's gut - und wenn niemand da war hat's auch niemandem geschadet ¯\_(ツ)_/¯ Halbherzig oder nicht - ich hoffe auf Wiederholung und dass ich's dann nicht verbimmel

Container: einfach verlinken. Starten: Map öffnen (F4) und den Zielplanet auswählen (via System/Zone oben). Auf den "Select Warp Point" Button klicken. Ins Cockpit steigen und prüfen, dass du genug Zellen für den Sprung geladen hast. Ca 100km vom Planet entfernen bis die Warnung "Planet too close" verschwindet. Alt+J drücken um zu springen - alternativ per Tab in den Maus-Overlay-Mode wechseln und den Jump Button klicken. Party \o/ Wenn nach dem Einbau des Warp Drives kein neues Widget auftaucht und du nichts am Lua geändert hast, dann kannst du einfach die Scripts neu initialisieren. Ansonsten musst du noch den Warp Drive mit dem Pilot Controller verbinden und den Slot in "warpdrive" umbenennen (Strg+L auf den Controller, dann siehst du links die Links als Buttons. Einer davon heißt dann "slot5" oder so und wenn du sonst nix verlinkt hast, dann ist das wahrscheinlich der richtige Slot)

Status-Updates gibt's leider nur im Discord... Ich hoffe aber, dass wir die auch bald hier im Forum bekommen. Petition gab es schon:

Scripts lüppen nur, wenn ein Player in der Nähe ist und bspw ein Programming Board benutzt. Wenn's im Lua keine Funktionen gibt um die Serverzeit abzugreifen, dann is Essig mit Ticktock. Jahreszeiten... also Schnee und so gibt's (noch) nicht. Die Planeten sind trauriger Weise alle fix und die Position der Sonne ändert sich. Einen Äquator gibt's aber trotzdem und ja, an den Polen steht die Sonne glaub ich immer recht flach... genau hab ich das aber auch noch nicht untersucht. Flieg doch mal hin und mach ne Zeitrafferaufnahme Davon abgesehen: super Idee. Ich will auch! Hoffentlich haben (oder kriegen) wir eine Schnittstelle zur Alioth-Systemzeit in Lua...

Ach verdammte Hecke... da kuckt man mal ne Woche nicht in die deutschen Ankündigungen und zack war's gestern. Duh... Dafür haste jetzt nen weiteren Stalker. Follow aktiviert. Schluss is mit heimlich posten

Haha, achso, ne, nicht komisch. In den Dispenser packst du quasi ein "Sample" dessen, was der Dispenser ausgeben soll. Selbstverfreilich müssen die Dinger dann auch noch mal im Container liegen, denn aus diesem werden sie dann an den Spieler herausgegeben Bin mir nicht sicher, könnte aber sein, dass man das Set dann immer mindestens 2x vorhalten muss. Falls das so ist wird das aber höchstvermutlich noch optimiert. Aktuell ergibt das in dieser Form durchaus Sinn, da du in dem Container ja noch sonstwas für Sachen liegen haben kannst, die nicht herausgegeben werden sollen. Bzw wenn du 10 Ladungen/Sets im Container hast, dann muss der Dispenser ja irgendwie wissen, welche Menge von was "einem Set" entspricht