Posts by Caralenor

    2. Du sagst, es wäre möglich, Namen zu nennen? Ähm, ganz einfach: Nein - Alleine der Datenschutz spielt hier schon dagegen, aber ich könnte mir vorstellen, dass es zu diesem Punkt noch mehr Hintergründe gibt.

    "Datenschutz" bei In-Game-Char-Namen?

    Zum einen ist "Datenschutz" der Schutz des Einzelnen vor dem Mißbrauch seiner Daten (auch wenn medial und von anderen Ahnungslosen anderes suggeriert bzw. gelebt wird).

    Zum anderen *konkret* welche ach-so-tolle "Daten" wären hier zu schützen?

    Wieder mal Mißbrauch des "Datenschutzes" als Ausrede bzw. Totschlagargument zur Geheimhaltung/Vertuschung/Förderung der Intransparenz.

    Dann sollen die "Veteranen" die wie immer nur Schwachsinn von sich geben mal mit Quest/Grotte Sachen ohne BK-Titel in die Inis. Viel Spaß

    Spaß hatten wir in der Ini immer - keine Angst^^ Ok, da sind die Leute halt auch alle mit dem Zeug aus den letzten Inis davor rein (und sonstigem legalen Aufputschmitteln, die man so selber basteln kann - die sind erstmal *wesentlich* wichtiger als "Eisenblut").

    Nur die "so-und-so-viel-% mehr Dmg" durch "Eisenblut" bringen - naturgemäß/mathematisch bedingt - bei einer halbwegs guten Rüssi+etc. auch ums Etzerl mehr als ohne eine und natürlich tut man sich dann beim Bursten leichter. Und wenn dann auch noch 2 Feuerübungen da sind sowie passenden Musik gespielt wird, ist es noch ein bißchen mehr.

    Gebt dem neuen Server halt ne Möglichkeit dran zu kommen und fertig. Und wenns im Itemshop ist.

    Bring' halt ein gutes und sinnvolles Argument dafür (und nicht nur rumweinen a la "ohne das geht es nicht", das ja trivial wiederlegt worden ist). Ja, damals war das eine oder andere schon anders als heute (aber nachdem die "Veteranen" eh immer nur Schwachsinn schreiben, erläutere ich die - in diesem Kontext relevanten - Unterschiede/Randbedingungen/Umstände nicht. Tja ...).

    Ihr würdet genauso rumjammern, könntet ihr nichts weiter laufen weil ihr 2 Jahre jeden Tag Pvp machen müsst.

    ROTFL - ich hab weit länger als 2 Jahre BK - der war viel früher nur um 20:00 und da mußte die Gilde erstmal reinkommen - gemacht und auch nicht rumgejammert - i.Ü. hättest Du auch im alten Forum keine "Jammer-Posts" von mir gefunden - da sind immer Argumente/Beobachtungen/... dabei (auch wenn die viele negiert/ignoriert/als solche nicht erkennen wollten).

    Und wenn ich lese "Lernt die Events" könnte ich auch kotzen. Jeder hier bursted die Bosse nur um und redet was von Events.

    Du willst jetzt nicht ernsthaft den Tag 1 einer neuen Ini (wo jeder nur "altes" Euipment haben kann) mit der Situation "ewig später" vergleichen, wo die Leute Stats und Zeug aus der "neuen" Ini haben, oder?

    Als würde Runewaker irgendwelche Events fixen.

    Die fixen tatsächlich gelegentlich Boß-Events - mitunter werden die sogar schwerer. Böse Zungen vermuten, daß nur Events "gefixt" werden, die "zu leicht" sind;-)

    Entweder Krypta B2 fällt sofort oder du bist weg

    Yup, das war am Tag 1 bei dem Boß auch so (und ging viel, viel öfters schief als es funktioniert hat - live with it...). Aber bei vielen anderen Bossen halt nicht - *eg* Krypta Boß 5 konnte "man" lang nicht bursten - so what, wenn "man" das Event sowieso vorher schon "können" mußte. OK, es geht im Laufe der Zeit schneller und die Chance auf Boß-Fails reduziert sich massiv^^

    was heisst denn "in den A... schieben" wenn man dafür massig Kohle hinblättert?

    "Pay to win" - SCNR

    Und ja, BK-Titel als solche sind schon hilfreich und - natürlich - in die Ini tunlichst mitzubringen (alternativ/zusätzlich zu Bufffood und Musikinstrumenten), aber "Eisenblut" als solches ist nicht notwendig und noch weniger hinreichend - auch bei Burstbossen ...


    Im Großen: Das kann - muß - nur GF beantworten, weil "früher" BK-Abzeichen halt *unter gewissen Randbedingungen* effizienter zu "farmen" waren als heute (und die Sinnhaftigkeit dessen war damals schon - harmlos formuliert - "umstritten").

    Und ich meine nicht die Zeit vor meiner Zeit, wo man angeblich auch 40 Minuten nach Beginn des BKs direkt die Gilde gewechselt hat und den BK der neuen Gilde betreten hat (nachdem dem man bei der alten schon BK mit Abzeichen etc. gemacht hat).

    BK-Titel sind massiv überschätzt: Da hat damals mal ein Gilde "Säule" praktisch Server-First gecleart und genau 2 Chars in der Gilde hatten "Eisenblut". Der eine Char war nicht mit und der andere war ein Heiler, der mit war.

    Wenn der Raid gute Rüssi hat, die Mobs und Events in- und auswendig kennt, tun/t sich die/der Heiler/in/nen immer leichter als am Tag 1 .....

    Ini-kenntnis ist das wichtigste was ein Heiler braucht um gut zu heilen (wann kommt auf wen der Schaden und muss der volles Leben haben zu überleben) . Außer man ist hoffnungslos überpimpt dann kann es reichen einfach Quell zu spamen (Balancing besseres Inidesign bräuchte es hier aber das ist ja ein Fremdwort) -.- .

    Ja, klar, wenn der Heiler (oder gar der Tank) keinen Plan von der Ini/Boß/Event haben, mag "bursten" noch funktionieren, aber sonst eher weniger.

    Aber ein Heiler tut sich halt - mit Ini/Boß/Event-Kenntnis, die man am Anfang relativ flott draufhaben sollte - brutal leichter (oder geht mit einer SekKlasse mit, die die DDs vonwegen Bursten noch mehr supportet eben weil es nicht mehr soooooviel Heal braucht - vom Tank angefangen ....), wenn der Raid ausgepimpt (eben weil die DDs viel mehr aushalten) ist als wenn es ein First-Try ist.

    Du hast mich falsch verstanden. Vielleicht hätte ich das NUR gross schreiben sollen.

    Die aktuelle ini kann man nur mit einem Stab heilen (1h oder 2h mir vollkommen egal, aber ohne Rüstung und Schmuck).

    Der einzig sinnvolle Maßstab ist aber nicht die aktuelle Ini nach ausreichend langer Zeit, daß der Raid ausgepimpt ist (und die DDs im aktuellen PvP-Equip den Trash tanken) mit Rüssi und Stats der ini, sondern die ini am Tag 1, wo alle Zeug von davor anhaben.

    Wenn der Raid gute Rüssi hat, die Mobs und Events in- und auswendig kennt, tun/t sich die/der Heiler/in/nen immer leichter als am Tag 1 .....

    Ich hab da vor Ewigkeiten schon etliche "kleine" durchgezogen (durchlaufen und Mobs en passant weghauen bzw. weg bomben, beide Runen holen und Event deaktivieren, der/die anderen müssen schauen, daß sie's überleben;-) - mal ging der Titel aufs erste Mal, mal nicht.


    Ich streß' mich dabei auch nicht (und könnte auch Scruti pushen;-) - ist seit mind. 30 Levels solo machbar (als DD - als Tank wohl früher;-)


    "Sterben" ist weder notwendig noch hinreichend mEn - mWn hat anfangs ein Bug verhindert, daß das Event ohne geordnetem Sterben gescheit funktioniert auf der 2. Plattform Und der Bug ist längst behoben.

    Das hab ich - offensichtlich - primär gemeint. K.A. ob die im Kern irgendeine Art von Garbage Collection bzw. "automatischem Freigeben" eingebaut haben - beides (mit und ohne GC und auch je nach Art von GC - auch da gibt es mehrere ...) hat Vor- und Nachteile (und multi-threading machen die Probleme mit GC bei schlechtem SW-Design nur noch viel größer).

    Typ 2: fehlerhaftes/langsames Memory Management/Zu große Listen

    -> Programm stürzt ab bevor Speicher freigegeben wird.

    Beispiel(e) c++:

    Code
    1. std::vector<double*> vector;
    2. for (int i=0;50000;++i) {
    3. vector.push_back(new double[100]);
    4. }
    5. for (int i=0;50000;++i) {
    6. delete[] vector[i];
    7. }
    8. vector.clear();
    9. </double*>

    Kein gutes Beispiel aber Problem sollte klar sein.

    C++ hat keine automatische Garbage Collection deshalb sollte derartiges eigentlich nicht zuschlagen können (und die Mechanismen aus der STL bzw. Boost-Lib sind mWn auch thrad-safe BTW).

    Typ 3: Memory Fragmentation

    -> Speicher ist theoretisch vorhanden, jedoch kann kein zusammenhängendes Stück alloziiert werden, welches groß genug ist.


    Angenommen ich hab nurnoch unzusammenhängende Blöcke in meinem Addressraum von weniger als 1024Bytes und versuche 1025Bytes zu alloziieren.

    => egal wie viele solche Blöcke ich habe, selbst wenn alle genau 1024Bytes lang sind und zwischendrin jeweils nur 1 Byte belegt ist kommt es zu einer Out-of-Memory Exception.

    Ja, das zu bedenken und zu vermeiden gehört auch zum Entwickler-Job und zu "dynamischer Speicherverwaltung" dazu - so what?
    Die Fragmentierung wird halt noch schneller akut, wenn da und dort Blöcke belegt und nie wieder freigegeben werden und damit den freien Speicher zerstückeln.
    Aber mit 2 GB Adreßraum sollte schon einiges machbar sein.


    Und ja, die Fehler werden sich alle multiplizieren (und nicht nur addieren) ....

    1+2 sind vergleichsweise "einfach" zu beheben, sobald man sie gefunden hat (wobei das wort einfach relativ ist, je nach komplexität). Nummer 3 ist da schon etwas nerviger.

    Naja, das ganze Zeug mal mit "Address sanitizer" bauen, testen lassen und den Fallout angehen. Ja, das ist unsexy, mühsam, aufwendig und $MANAGER nichts neues auf eine Slide oder sonstwohin packen.

    Es gibt Libs, die da helfen können, etc. - alles keine "rocket science" sondern mbMn "Handwerk".


    Erfahrungsgemäß werden 1+2 werden im Labor auch nicht unbedingt oft auftreten und 3 vermutlich noch seltener (was dann nicht für die Qualität des Testens spricht ...).


    zu 3): Je nachdem, wie das im Design ausschaut, können stellenweise "Memory Pools" hilfreich sein (und braucht man auch zwischendrin nichts freigeben;-).


    Und wer weiß, wie oft die im Kern "char *p = new char[256];" mit dazugehörigem "delete p;" haben - da wünscht man sich, daß die C++-Anfänger wieder malloc()+free() verwenden (dort gibt es diesen konkreten Bug nicht:-). Naja, es existieren aktuelle C++-Compiler, die da schon mal eine Warnung von sich geben (nur ist das im allgemeinen Fall nicht immer erkennbar).

    "Double free" ist böse, wird von einigen C/C++-Libs auch nur mit Extra-Optionen hart geahndet[1], läßt sich aber dafür sauber und *trivial* (mit allen vernünftigen C/C++-Libs) lösen, wenn man nach dam "delete" den Pointer auf NULL/0/nullptr setzt - es braucht auch nur ganz, ganz wenig Disziplin dafür (oder gleich ein Makro verwenden;-).

    Ich selbst bin kein Entwickler. Aber die Runewaker Jungs haben da ein paar von. Und sie haben Spiel geschrieben, dass es zur Marktreife brachte. Wäre der Leak ein triviales Poblem, dass einfach zu lösen wäre, hätten sie das bereits vor ein paar Jahren erledigt.

    Naja, ich bin halt einer (und deshalb hält sich mein Mitleid in Grenzen, wenn dermaßen dilettantisch agiert[0] wird und das Reparieren *offensichtlicher* Probleme, die praktisch deterministisch und trivial triggerbar sind, verweigert wird): Die Entwickler von damals wird es nicht mehr bei RW (oder wo immer die her waren) nicht mehr geben - in SO-Asien soll es seit vielen, vielen Jahren ziemliche Fluktuation bei derartigen Jobs geben (Foxconn wird nicht die einzige Verheizer-Bude dort sein ....).

    Und wenn keiner mehr da ist, der den gesamten Sourcecode+Dessen Design+dessen Evolution halbwegs überblickt, werden triviale Probleme halt nur schwer lösbar.


    Dann kommt dazu, daß -zig neue Features im Laufe der Zeit dazugebaut worden sind. Sind die anständig rein designt und implementiert worden oder hat der ganz neue Kollege/Praktikant die nur ganz schnell irgendwie dazugebastelt?


    Und viele Bugs sind ja dann doch auch mal gefixt worden - angeblich bzw. offiziell. Nur war das so, daß jemand die *Ursache* des Bugs (gesucht+)gefunden hat und dort das gefixt hat oder hat man oben nur die Symptome kaschiert (was nach außen bei technik-fernen Schichten als "Bug Fix" gesehen werden kann, auch wenn es keiner ist)? Dann sammeln sich jede Menge Workarounds - "Würgarounds";-) - an, die an der Oberfläche nur die Fehler kaschieren und irgendwann wird das Reparieren der Ursachen echter Bug noch mühsamer, weil man die Workarounds extra anpassen bzw. entsorgen muß.

    Das Implementieren neuer Features bzw. Contents wird ja dadurch auch nicht einfacher (sondern RW-verursachterweise noch aufwendiger für RW).


    Ohne automatisiertes Regression Testing wird das nochmal mühsamer - wird RW wohl auch nicht haben, weil sonst würden Bugs *nach* einem Fix nicht wieder auftauchen - was schon des öfteren passiert ist - (und es kostet zusätzlich Geld und beim Release 1.0 sieht keiner den Nutzen und alle nur Aufwand etc. Naja, jetzt wär der Nutzen vielfach da .....).


    Naja, und andere wirklich sauschwierige Probleme wie "NPC hat SYS_* Namen" oder bereits angesprochene Verkaufschars, die anderes liefern als in der Auslage steht (und derartiges ist ja alles auch nicht zum 1. Mal passiert) haben auch viele Monate bis zur Behebung gebraucht - und da gibt das 100% reproduzierbar und so offensichtlich, daß man es nicht leugnen oder wegargumentieren kann.


    PS: Danke an alle, die bis hierher durchgehalten haben. Wer "meine nervigen Walls of Text"(TM) lesen will, braucht es auch nicht;-)


    [0]: Ich will gar nicht "gearbeitet" sagen.

    [1]: Ich will (bereits) freien Speicher nochmal freigeben. Das Ziel ist, daß der Speicher nachher frei ist - was er ja ist. Ist das jetzt ein Fehler bzw. auf welcher Ebene ist einer?

    2. Für Memory leaks gibt es unendlich viele mögliche Gründe. Wir selbst haben keine Rechte am Quellcode, das muss RW fixen. Wenn hier gesagt wird das dauert 500 (Beispiel) Manntage, dann glauben wir das ersteinmal und wägen ab, ob nicht doch andere Änderungen wichtiger sind.

    Für Memory Leaks gibt es eigentlich nur einen Grund: Angeforderter (und bekommener) Speicher wird nicht mehr freigegeben (for whatever reason).

    Oder hab ich was vergessen? Ich lerne immer noch gerne dazu!


    Nach den erlebten Symptomen der letzten Jahre haben die leider viel größere Leichen im Keller als "Memory Leaks" (und deshalb wird das Reparieren der Memory Leaks so aufwendig sein. Naja, oder "man" will das halt einfach nicht fixen ...).


    Es ist halt traurig, daß RW derartige handwerkliche Anfängerprobleme nicht selbstverständlich sofort auf eigene Kosten repariert (so iSv "Gewährleistung" und "Oops, ja, ist passiert, shit happens, kein Thema, wird unverzüglich repariert - wir haben ja einen Ruf zu verlieren").

    Memory Leaks (und Ressourcen Leaks i.A.) sind bei seriösen Programmierkursen kein nice-to-have Thema, sondern relativ früh Thema. Und mit Race Conditions ist das i.Ü. genauso.


    Note to self: Never ever buy, rent or lease software from RW.

    Nur das es hier - wenn überhaupt - allenfalls um Datensicherheit und nicht um Datenschutz geht (weil bei Datenschutz geht um den Schutz des einzelnen Menschen vor dem Mißbrauch etc. seiner persönlichen Daten).


    Ja, viel zuviele haben die DSGVO für noch mehr Fehl- und Desinformation mißbraucht (aus verschiedenen Gründen - mEn meistens halt aus purer Inkompetenz/Unwissenheit, gewisse Branchen können mit FUD Geld machen, ...).

    Quote

    "Hängt wohl v.a. davon ab, ob man Alkoholiker ist (und die regelmäßige Dosis braucht) oder nur zur "Happy Hour" saufen geht ..."

    Hm. Ist man eher Alkoholiker, wenn man alle 3 Tage gemütlich 2 Bier trinkt oder doch nicht eher, wenn man Alle zwei Wochen sich annähernd besinnungslos säuft?

    Abgesehen von irgendwelchen "amtlichen Definitionen" (die ich nicht kenn') oder "WHO hat irgendwann irgendwas gesagt" (was beides letztendlich ziemlich relativ ist, weil der menschliche Körper und die Medizin soweit entfernt einer sog. exakten Wissenschaft sind, wie es nur sein kann), ist nach allem, was ich so gelesen hab, zweiteres weit weniger ein Indikator für eine Sucht als ersteres.


    Und "Vergleich" einer qualitativen und einer quantitativen Aussage ist sowieso - naja, eh scho wissn ....


    Hinweis: Manche sind schon nach 3 Bier besinnungslos. Ob das alle 2 Wochen schlimmer als 2 Bier alle 3 Tage ist? Gesundheitlich und psychisch mbMn nicht - aber Suchtkontrolle ist halt immer so eine Sache ...

    @Cara dein beitrag ist sowohl sinnlos als auch nervig zu lesen. wie immer eigentlich.

    Die Original-Frage war vollständig und korrekt beantwortet, so wie sie gestellt war. Wo ist dann das Problem bei einer einfachen und direkten Antwort drauf?


    Und wenn ich die (mbMn) offensichtliche Intention der Frage (und nicht die gestellte Frage als solche ohne Interpretation) beantworte, bist Du offensichtlich auch nicht glücklicher damit, oder?


    Tja, und schön für Dich, daß immer genau weißt, was der Fragesteller eigentlich genau wissen wollte, obwohl es gar nicht da steht, aber ich nimm' das nicht für mich in Anspruch.

    Und sry, aber in vielen Fragen ist halt sehr so dermaßen viel direkt impliziert (wenn man Kenntnis des Spiels voraussetzt - was ich natürlich tue, wenn nicht explizit anderes dabei steht), daß es nur sehr wenig Interpretationsspielraum gibt.


    PS: Ich hab' nicht auf die 1. Meta-Ebene gewechselt, wenn Beschwerden darüber kommen. Nicht daß es mich stört oder mMn off-topic wäre - ganz im Gegenteil ....

    SchuMa fährt mehr Schaden als Sch/Bew (aber nicht arg viel mehr).

    Wenn Du noch mehr Schaden als ein SchuMa fahren willst, organisier' Dir ein Kata und wechsel auf Ku/* .....

    [HdÜ] letzten muss man trotz dieses "krassen" high lvl(für die ini) das Event spielen.

    66 oder 74 ist ja noch nicht "krasses High-Level" - eher 100;-)


    Und ja, weil für's pure Nuken wird halt pAtk/mAtk und v.a. der Schaden fehlen, wenn man die Equip und Bufffood-Beschreibung liest (und ich geh' mal davon aus, daß auch keine Instrumente, Sternbild-Begleiter, Gildenburg-Türme, jede Menge Hausmädchen, etc. dabei waren bzw. existieren). Und wenn die Full-DDs weniger krass sind, bringt ein Supporter auch weniger BTW (als ob es damals Supporter gegeben hätte).

    Andererseits kommt mit den Level 66+ auch (viel?) weniger Schaden rein als mit 50+ damals und HdÜ/letzter war damals auch mit guten Heilern nicht ohne "schon auch mal selber potten, wenn man einer der DDs ist, die die Adds zum richtigen Tor ziehen" zu machen ...


    Und "selber machen mit Low-Char ohne viel Infrastruktur drumrum": Sry, aber BTDT already years ago - <aetz>ohne Arkanium- bzw. Muschel-Stats oder Lvl 60+Quest-Equip</aetz>;-)


    Aber wenn ihr Spaß dran habt, macht nur^^