Jump to content

vertex

Alpha Team Vanguard
  • Posts

    630
  • Joined

  • Last visited

Everything posted by vertex

  1. Sechs, wenn sie nichts geändert haben. Bei allen Stufen ist immer 1x größere Version = 6x kleinere Version. Vorteil = spart Gewicht und Links, Nachteil = längere Anlaufzeit. Einige XS Elemente sind ganz praktisch, wenn man Schwebeplattformen bauen will, oder winzige Gleiter (wie den Novark Speeder) zusammenstellt. Das ist teils sehr praktisch, aber sobald Fracht ins Spiel kommt sind die sinnlos. Ich hab ein winziges Konstrukt um von A nach B zu kommen - hat nur einen XS Atmo Tank, 2S Triebwerke, einen Hover Seat und ein paar XS Adjustors. Atmo Speed so um die 1400km/h. Man kann auch Mining-Platformen bauen und so. Aber das ist alles nur entweder unterirdisch oder atmosphärisch - evtl ergeben die Space Elemente Sinn, wenn man damit reine Raumgleiter bastelt, aber wenn man einen Hybrid will stößt man sehr schnell an alle Grenzen. Zum Drift: Bremse nutzen. Auto Level bringt dich auch dein Rollen auf 0, nicht aber das Nicken. Ich hab mir mein Script so umgeschrieben, dass auch die Nase auf 0 bleibt und beim Start automatisch die Parkbremse aktiviert wird. Wenn du absolut jedes Abdriften verhindern willst, ohne dafür die Bremse zu benutzen, dann musst du noch einiges mehr an Steuerung automatisieren. Könntest auch die Parkbremse erweitern, indem du sie bei Antriebsimpulsen automatisch deaktivierst, oder so. Ich nutze das Wegdriften um meine Position im Schwebeflug anzupassen - dafür hab ich keinerlei Antriebe rechts/links/rauf/runter oder für rückwärts. Alt+2 schaltet bei mir die Parkbremse ein, dann ist das Schiff absolut stationär, selbst wenn ich nicke, rolle oder giere. Kann dann im Stillstand die Triebwerke anfeuern und per Alt+2 die Parkbremse lösen, um mit vollem Schub direkt vom Fleck abzuheben.
  2. Verteiler.. bleh. Ist das ein Transfer Unit? Sorry, aber die deutsche Übersetzung von DU ist so grottig... Wie sieht das Ding denn aus? Lichtgrauer Kasten mit ner abgerundeten Ecke und ner Dose mit orangenem Deckel oben drauf? Das ist dann ein Transfer Unit - das schubst Dinge von einem Container in einen anderen - sonst nix. Dispenser sind... Würfel... ohne Dose... und haben sowas wie ein Inventar und Einstellungen - kein Industry UI. Das sind die Dinger, die einem Waren ausgeben, wenn man mit ihnen interagiert...
  3. Keine Ahnung, ob man Zugriff auf Spielernamen oder das RDMS via Lua hat, aber ein Screen vor dem mehrere Spieler gleichzeitig stehen könnten, kann zwar "Access Denied" ausgeben, aber spätestens wenn es eine persönliche Begrüßung werden soll, muss man (falls es geht) entweder ein Array verwenden und mehrere Namen erwähnen, oder den Spieler ein Programming Board aktivieren lassen. Da man den Zugriff aufs Programming Board via RDMS regeln kann, sollte zumindest ein einfaches "Access Granted" eher simpel sein. Man kann dann einfach den Screen mit dem Board verbinden, Slotname in "screen" ändern und dann im unit.start() per screen.activate() den Bildschirm einschalten. Weiterhin kann man bei unit.start() und unit.stop() jeweils andere Meldungen per screen.setHTML() platzieren.
  4. Verteiler... sind das nicht Container Hubs? Klingt eher nach Dispenser... argh. Ok, also ich weiss nicht, ob Dispenser eine Maximalmenge haben, die sie ausgeben können - aber es gibt ja auch noch den "Heavy Dispenser" oder so? Also möglich. Ich hab die bisher nur für Tankstellen benutzt um jeweils 500L Sprit auszuwerfen. Dazu musste ein Container mit dem Dispenser verknüpft und dann ein Sample, also die 500L Sprit, in den Dispenser gelegt werden. Außerdem muss man einstellen, wie oft und in welchem zeitlichen Abstand ein Spieler Zeug rausholen darf. Sandardmäßig darf jeder glaube ich nur ein mal ran.
  5. Ne, hab ich noch nicht probiert. Das mit der Ausrichtung bezieht sich auf "nicht exakt" oder auf "gar nicht"? Im letzteren Fall: R gedrückt halten und mit dem Mausrad den Kern drehen. Bin mir nicht sicher ob das exakt wird - schon mal probiert?
  6. Ein kleines Raketentriebwerk bastelt man sich mit Ressourcen vom Markt recht schnell zusammen - das ist nicht so sehr das Problem. Aber die Brenndauer der Dinger ist, meiner zugegeben ziemlich veralteten Erfahrung nach, vollkommen lächerlich. Ich hab ein mal eins gebaut und einen Tank in wenigen Sekunden leer geblasen - anschließend hat man permanent die "Out of Fuel"-Warnung und der Xeron Fuel ist dazu noch unverschämt teuer. Mich wundert es daher kaum, dass man die Dinger fast nirgendwo sieht. Für mich erscheint es sinnvoller die Raketen zu überspringen und direkt einen AGG zu besorgen ¯\_(ツ)_/¯ Wenn's nach mir ginge würden wir einfach H²O² als Raketentreibstoff verwenden. Der Begriff "Rocket Science" wird häufig als "hoch technisch und kompliziert" misbraucht, dabei sind Raketen an sich ziemlich primitiv - die Erste startete angeblich im Jahre 1232 in China - aber in Dual Universe sind die Triebwerke sozusagen "Endgame-Technologie" und die Spritkosten stehen irgendwie in keinem sinnvollen Verhältnis zum Nutzen. Fürs Triebwerk braucht man Pyrite, Garnierite und Petalite. Dh man ist praktisch gezwungen zuerst ohne Raketen vom Planeten runter zu kommen, um die Ressourcen zu besorgen (bzw irgendein anderer Spieler muss dies zuerst tun und das Zeug dann am Markt anbieten). Meiner Meinung nach sollte das genau andersherum sein - ein Triebwerk, welches im All genug "Schub gegens Nix" erzeugt, um tonnenschwere Schiffe zu bewegen, erscheint mir doch als eine technologisch eher fortschrittlichere Apparatur, verglichen mit einem besseren Feuerzeug Flammenwerfer, welcher nur aus ein paar Rohrleitungen und einer Brennkammer besteht, um Treibstoff zu verbrennen der in DU zumindest theoretisch kostenlos mit dem Recycler aus Luft und Wasser hergestellt werden könnte Man kann die Dinger auch nicht regeln - da geht nur an/aus. Die haben zwar schön viel Bumms, aber was bringt einem das, wenn man bereits ab ~1200km/h in der Atmosphäre verglüht? Ich denke früher oder später merkt NQ das auch noch - bis dahin sehe ich Raketen eher als lustiges Gimmick
  7. "Alt+F4 Notfallbremse" ist aktuell erlaubt Solltest aber trotzdem ein Ticket dazu auf machen. Irgendwas komisches ist da im Busch.
  8. Jarp. Dauert ein bischen bis man sich dran gewöhnt hat, dass man die ganzen kleinen Engines vergessen kann. "MOAR THRUST!" und gut - das schließt "brake thrust" mit ein Bei Triebwerken und Bremsen benutz ich eigentlich nix mehr unter L - auch nicht für kleine S Frachter. Ist ein bischen schade, dass die so wenig Leistung haben - außer als Manövriertriebwerk fällt mir bspw keine Verwendung für XS Engines ein. Die taugen ja nicht mal um ein XS Taxi ins All zu befördern. Bisher: Ja. Ich hab die Wing-Elemente schon komplett in Voxeltragflächen versteckt und war kein Problem. Bei Engines sieht das leider anders aus... Jo, genau da liegt halt der Haken. Beim Verlassen der Atmosphäre ist das ja noch nicht so schlimm - entweder der Schwung reicht, oder nicht. Aber beim Wiedereintritt, wenn der Boden immer schneller näher kommt, wird es manchmal schon gruselig auf die Triebwerke zu warten. Gute Bremsen helfen aber bei der Transition. Solange dein Schwung ausreicht um die Raumtriebwerke zu zünden, bevor du wieder zurück auf den Planeten fällst, ist alles gut. Sollten auch die Frachter-Engines schaffen, wenn deine senkrechte Escape Velocity über hmm... naja, mindestens 600km/h liegt? Ansonsten kannst du ja auch langsam in einen Orbit steigen. Die Skills helfen übrigens dabei, dass die Space Engines früher zünden und die Atmo Engines länger feuern. Gibt auch Skills die die Anlaufzeit reduzieren
  9. While these are opposing statements I just couldn't agree more with BOTH of them At first it took me what felt like forever waiting for the vertex editor and I didn't touch much of voxelmancy, even tho I knew the mechanics and could manipulate stuff to get the expected results. My nick ain't a coincidence after all, but it took me a very long time to experience moments in which I actually had fun manipulating voxels and see the pro-voxelmancy side of things. Still these remained rare occasions and I always reverted to rather simple shapes on large scale because doing what I wanted was just too tedious and felt like doing the pontius-pilatus-run (English "pillar to post"?) for every single line, row and column in the 512x512x512 grid. Choice was like either do a flat roof and be done in 1 minute or make a nice curve, add details and invest days just for the looks of it while also knowing it would result in a worse frontal cross-section. While usually being just a happy builder on the "style over quality" side, the lack of advanced tools like vertex editor pushed me to the opposite side of this spectrum in DU, which in fact has been my greatest disappointment so far and the reason I just can't resist joining this off-topic discussion right now Seeing this being on 1st place right after the pinned votes was the best news ever to me: https://upvote.dualuniverse.game/suggestions/122830/voxel-vertices-editor If you didn't already: vote for it rite meow. Wheee! \o/ Feeling guilty now. On topic: well, to my knowledge NQ has been rather courteous (what's a good word for "kulant" in English?) regarding refunds. So good luck on your support ticket and sorry it didn't work out for you. Anyways, on the level of moral intuition I feel like the right thing to do with a pledge that didn't turn out as expected is just seeing it like one took a chance and lost some money gambling. When I pledged back in the days I already knew this could turn out as something like EVE and possibly drive me away, or it might even fail completely as many other Kickstarter campaigns failed in the past. So I took the highest stake I ever did in my gaming history (several hundreds of €), because I've never seen any concept/chance that came even close to this project - but I accepted the risk of losing all that money even before I spent it. Thing is I knew my finances back then and knew that if it turned out well, I'd have spent that money and could live without it - when it doesn't work out tho and I don't get the money back, it's still the same on my financial side and I couldn't claim that I'm in trouble without that amount, because that would be the case even if it worked out too. Just mentioning this because I've seen others who made it seem as if it was a lot of money that impacts their life significantly and... well... I failed to relate on why spend it in the first place if pockets are too tight. Might not apply here tho, so sorry in that case - didn't mean to offend or suggest anything, just sharing experience/thoughts.
  10. Sorry, in that case I failed to grasp what your issue was. Just tried to help. Didn't experience any bugs dealing with RDMS since beta release either - worst case that happened to me was that some ppl claimed the newly granted permissions didn't work right away, so I asked them to relog real quick and that solved it every time so far. But it seems I need to add that I didn't add territory policies in the past two weeks or so - just assumed sharing the unit was a different approach that I'm not aware of and the RDMS should still work the same as when I did it
  11. This sounds as if you right click the unit? I never tried that approach and didn't think you could even share "the unit" as such. I always grant access to the territory through RDMS. Hit F7 and create a new policy, add a name and the friends you want to grant access to as well as the permissions/rights you want to grant, then on the right side pick the tag name that corresponds to your territory name. On all 3 columns don't forget to press the "Add" button and make sure the items you selected are shown in the list below. Double check that you didn't add "All" in the actor list on the left then proceed to save the new policy. Optionally you can define a new actor in the actors tab to make a list of people so you don't have to pick them individually each time you create a new policy. You can also define own tags on certain elements and then find them in the tag list to grant access to certain elements instead of just giving access to the whole construct (cores get the name of the construct automatically assigned as tag which appears in the default list - granting permissions to cores refers to all elements on that construct).
  12. A convenience store is about to open and the guy installing the self-checkout did what he always does, but the management software of the terminal experiences an exception and didn't finish installing the routine that would trigger the alarm when someone takes stuff through the rfid scan field. Some of the workers notice this and start to take stuff out of the store. Some of these guys return and say "Look, I just took this and went out without issue - something wrong here?" while others take a hike and sell the stuff on eBay. The workers that returned, reported and helped the store owner to fix the issue were fine and continued to work the next day, while the guys who left without notice were fired. In conclusion? There's no conclusion. This is all completely beside the point of this thread. There is room for improvement on the EULA and on the in-game rule set - that's it. Pretty pretty pleeeeaaase... don't hijack this thread to continue that fruitless M15 topic
  13. Well, I think it's too early to say they didn't do anything. If they previously thought it's just user error all the time and now they finally trace the exploit, it could be days or weeks until they've worked it all out. But we might see more results by then - maybe they can even trace other instances of this and finally compensate the players who made the tickets. Sure, from past experience it's easy to jump to the conclusion that NQ will never change - but DU changes and NQ evolves - I don't think we're just treading water here
  14. @Mordgier Yeah, I can see that might be an issue. Tho I would admit it if it was my mistake, hence I don't rule it out completely. You say "You know they won't", addressing me, and again state an absolute that you can't be sure about - that's our main difference here. I don't feel comfortable when you state things as facts that are "most probable in your opinion" at best. Prime example: I don't know if they won't. And I can't speak for everyone else, like you do. Would you be a dear and drop that habit? It's really annoying. Just a request tho But this excursion now successfully dragged me away from my initial stance, which I still hold: ban is justified and even if players might argue that it's unclear with POS, it still is very clear with NOS. So there's one more clear line - and that's better than no clear line at all.
  15. Yeah sorry, I've already fixed that in the meantime to read And as I already said: RDMS policies are not the only thing that can lead to the software granting access. So asking for proof refers to something that would prove that an NQ employee added a policy by mistake that granted public build access. Please don't try to tear that apart just because I wasn't repeating the specific definition again. I think I made my opinion rather clear: I think it's not proven that NQ fumbled and created such a policy and there are more possible explanations. That's why I react to absolute statements like those Mordgier made with a request for proof. No, I don't and I never have
  16. Maybe I'm more sympathetic because we (different dev team) have been guilty of that too in the past. Developing something you get alot of claims and if you investigate a certain amount, every time with the same result of "user error", you start to classify and dismiss it - until suddenly, by chance, you experience the same issue and have to roll back. It's not beautiful, but it happens. Being able to destroy NOS that are not meant as PVE target always qualifies as exploit. By NQ? Proof? I think you just try to nail me down with questions that imply a line of reasoning that's irrelevant. I've said everything I had on my mind and it's up to you to see and respect my side or simply disagree. I see your side and I disagree deeply, feeling you're trying to twist things in your favor.
  17. This "just pressed B" argument is invalid. The level of difficulty to use an exploit has nothing to do with the classification.
  18. Or not what happened here. There's more things that can break than the RDMS. As I repeatedly said there doesn't seem to be any confirmation that anyone at NQ has set that market to public access. On the contrary, there are claims that suggest there's another bug that lets people access constructs even tho there are no policies set in RDMS that would allow it. In addition, from personal experience, I know that even if you set up the RDMS properly, it doesn't always work. All in all the claim that it's "exactly what happened here" is a weak hypothesis at best. And my paragraph above is not false - it's basically the same as what you said. In conclusion to my first example I said "at first you have someone actively creating rules", which is true in your example too (still unknown if this has been the case with the market). Then I continued with "that grant someone else access who then abuses these permissions", which is also true because that "someone" can just as well refer to "everyone" and each individual being "someone" in that group. I can see the possibility that they added the wrong tag to a policy (core instead of terminals) or the core (terminal tag added to core), which would make it publicly accessible. But that's not confirmed - and even if it was the case and would be confirmed, I'd still consider this a bug or error in game design and not equal to someone setting up their private property RDMS wrong, simply because markets are not player owned structures, but part of game design and basic funcitonality.
  19. Nah, we don't completely disagree there - I feel like most ppl agree that those things could do well with an update, to put it mildly That's why after quoting that I followed up picking the last bit "detrimental to the proper functioning of the game", because the rest is too open to interpretation. And it's why I stressed that this doesn't apply here, because the destruction of that market is so clear a violation of all of those rubber band paragraphs that no matter how far you manage to stretch them, this incident would still blow that rubber away. Not only this but in addition it's perfectly clear that it was an error/bug/exploit and we've just had a very clear announcement regarding this. So while I agree that this is difficult with those other issues, I still think it's not difficult here. On the contrary, it's very obvious, testified, tracable, provable and even the vague wording can't be interpreted in any way that would justify the act, which all leads to it being such a perfect opportunity to make an example. I like it. Considering the other issues, well, it may be easy to fight over the interpretation, but I think it's rather easy to grasp the general intention. The letter of the law might be confusing, but the spirit is clear. We have many of these vague things in our laws too and at some point there needs to be a judicial precedent that can be referred to later. Some here want to turn the "non-interfere with RDMS theft" into that precedent case to apply here, but it's pretty easily dismantled if you think about how such an RDMS theft goes down: they trick someone into trusting them and giving them permission and then they steal the assets. So at first you have someone actively creating rules that grant someone else access who then abuses these permissions. People on this thread claim that's what happened here, but that's just a hollow statement so far and if you think for just one second about if there's a chance that NQ wanted to grant public access to build mode on a market you'd immediately arrive at "no, wait, that must be an error or a mistake" - which even is established by circumstantial evidence looking at the "pls no ban" hovering above the scene. If there's a bug that enables players to exploit the RDMS and rob someone who otherwise didn't let anyone trick him and made no mistake with configuration... well, at least to me it's pretty obvious that this wouldn't be covered by the "non-interfere with RDMS theft" precedent. Instead we have a new precedent here: destruction of public buildings and game features is detrimental to the proper functioning of the game and leads to a ban. It's as simple as it can get. On previous incidents, like the dock-theft from safe zone, they let offenders off the hook who participated in such acts before the announcement. Maybe because it was too difficult to prove, maybe because there was reasonable doubt on the interpretation, maybe both. But in this case it's neither - it's easy to prove, there's no doubt and the offending party knew exactly what they were doing. Bottom line: it doesn't compare and whatever ppl may think about the rest of the game, other rules or other incidents, doesn't affect this case. And shouldn't either - issues should be evaluated on a case-by-case basis and it will not always be black or white - but in this case it is clear as day and night.
  20. Or I'd get another hand full of mates telling me that NQ is a half-... need to rephrase this to comply with forum etiquette, so let's say: that NQ is afraid of players getting mad at them and therefore doesn't issue hard enough sanctions. There is a good amount of ppl who welcome finally seeing NQ taking serious action - and I'm one of them. For me NQ has just reinforced my trust because I can smell change in the wind that previously was just way too calm and forgiving with warnings and announcements repeated over and over but without any real consequences. Huh, I just realize I need to head back to the OP and hit that round button with the heart symbol on it I disagree - they would've come out as the team that you can screw over if you get the chance and thereby work against everything we do here day after day. Now that sounds interesting - yeah, they could still do something like that. Still, I think punishment for those "legendary bank robbers" is correct and if it's a lifelong sentence - fine @Darrkwolf okay, EVE then. I'm pretty sure that CCP was a well established company and had a solid game running at the time they fixed that exploit you mentioned within a few hours. Tho even if not it doesn't change the fact that exploiting an obvious error in the game is a bannable offense. This hasn't been weeks. But that's just counting peas and in my opinion is irrelevant to the topic at hand. Sure there are bigger issues at play - a lot of them, I think, actually. But all that does for me is make me even more sympathetic and makes me want to hand them some cookies and coffee or a pizza. In my opinion DU development is taking leaps since release of beta. A week ago I couldn't set my industry up on sanctuary because of performance issues - yesterday it was just as smooth as Jago. I can see progress and that changes everything for me. If it doesn't do the same for you, I guess we can still agree to disagree? Because I don't think that we will hit common ground on the evaluation of these issues and their implications.
  21. No, it woudln't. "An issue" can be like.... anything? Including but not limited to RDMS. In my opinion the option to exploit does not need to be announced ¯\_(ツ)_/¯ Btw: I don't care about EVE. I'm not into archeology
  22. Hence all these people that reported but didn't exploit it are proof that it is possible to report and not exploit. Something that those now banned failed to do. They didn't only fail, they did the exact opposite: they did not report but they did exploit. So if NQ can't fix the issue fast enough, next time when there's an issue like this NQ should shut down the servers and re-open them once the issue is fixed, so nobody thinks it's ok to exploit if NQ doesn't fix instantly? I certainly wouldn't like that. The rest of that posting again implies that it was RDMS mismanagement which still nobody provided any proof for.
  23. Yeah, until some days ago I had the same feeling and feared that this would be the case - but then I heard that the ticket in question finally got addressed and solved after 6 weeks. So I was really relieved to know that they are not lost. I'm not defending that there's no response in 6 weeks - if it was my system I'd write some lines of code to update tickets within 24h with an automated response and have one person to go over them just to reply "Thanks! That's an issue with X and I'll forward to Y!" etc. But that again is something that needs someone to organize and do it and might not receive priority for quite some time, especially if you're deep into other things - like fixing a market that someone destroyed on purpose. Plus even with that response players would give them shit about "I just received some automated response and some guy said he's not capable and had to forward me to someone else who now ignores me!" ... it's hard to satisfy and if you can't jump to 100% you might be inclined to postpone that jump until your boots are fully charged. Regarding player base gives more support than it receives: weellll... compare size of the player base with the size of the support staff. They can't hire a support guy for $7/month which not even all players pay, so that comparison will always be off. Regarding funding: for a project like this 22 million are a drop of water on a hot stone. Budget is really limited and cuts need to be made and priorities set. If we want a bright future in DU we should stick together and help as good as we can - not cause additional issues and throw dung balls
  24. No, they don't "because of that". I agree with the sentiment that communication needs improvement, but I strongly disagree with using this incident as leverage to achieve this. NQ still has to grow into the shoes they build. Just because they don't fit yet doesn't relieve you from your obligation to report bugs and exploits and is unrelated to other issues. This is not a street with similar lanes in both directions. The support that flows into your direction is vastly different and unrelated to the support we give to the developers. If you withhold your support on purpose because on the other side the support is delayed, you're comparing a single person twiddling thumbs with a whole support staff that works 8h a day just to get back to you as soon as they can. That comparison feels off to me and refusing to cooperate based on it feels unfair, especially since it doesn't cost you much effort to report a bug or exploit and just be done with it.
  25. @Mordgier I don't think that the length of your answer is in a good relation to the length of that quote. But apart from this I think there's a huge difference between harming yourself and harming others. Analog to this you're not allowed to poke a needle through someone else's ear without their permission - but you're always welcome to poke a hole through your own ear if you want to wear an earring. That's so simple it almost seems like you're trying to derail an official thread? Juuuust pondering On top of that I referred to the second part of that paragraph. Please don't quote my entire posting just to address something that's not even part of my argument and was just included because the paragraph number was in front of it. If you read my posting you might notice that I refer to everything in that quote but the part you quoted me for ¯\_(ツ)_/¯
×
×
  • Create New...