Formel automatisch auswerten

  • @Tomura, Ja, ist toll, dass Unreal sowas bereitstellt, nur ist das ExceptionHandling nicht so gut gelöst :/ . Vor einem Monat habe ich fast kaum Unreal C++ Snippets/Funktionen verwendet und nun eigentlich nur noch so, einfach auf Grund der Einfachheit und der Kompatibilität der verschiedenen Plattformen.


    @Franz99, Danke für die positive Rückmeldung. Ich nehme dir das garantiert nicht übel.


    Nun zur Problembehandlung. Ich habe mir mal den Quellcode von FMath::Eval() angesehen. Dies ist wirklich ein Bug von Unreal. Dieser Fehler tritt auf, solltest du das die abgerundete geschlossene Klammer verwenden ")". Alles danach wird nicht mehr ausgeführt.


    (3+6*(2*7+3)-5)*5*(4-5/6)+(2*(4-2)) = (3+6*(2*7+3) = 105.0


    Betroffene Zeile:


    \Engine\Source\Runtime\Core\Private\Math\UnrealMath.cpp SubEval()



    C
    // ...
    else if (c == TEXT(")"))
    {
    	*pStr = FString(TEXT(")")) + *pStr;
    	*pResult = V;
    	return 1;
    }
    // ...

    Das return 1; und *pStr = FString(TEXT(")")) + *pStr; haben zur Folge, dass die Funktion zu früh beendet wird. Etwaig braucht man den Source Code von Github (https://www.unrealengine.com/ue4-on-github), die Datei ist bei mir zumindest schreibgeschützt und wenn ich diese aufhebe und sie beschreibe/überschreibe lässt sich dadurch keine Veränderung feststellen. Wenn du dir nicht unbedingt den Source-Code holen willst, würde ich dir empfehlen den Ausschnitt von FMath::Eval() und SubEval ins Blueprint zu packen, dann kannst du auch direkt dein eigenes ExceptionHandling schreiben. Musst dann halt das Blueprint um UNumericalEquation::Eval() und UNumericalEquation::SubEval() erweitern.


    FMath::Eval()

    SubEval()


    Hoffe ich konnte dir den Fehler/Bug etwas genauer erläutern. Wenn dich C++ interessiert ist es sicher schlau, sich gerade damit auseinanderzusetzen. Hier hast du so gesehen ein einfaches Problem, welches du mit deiner langjährigen Programmiererfahrung, auch ohne grossartige C++ Kenntnisse, lösen kannst. Aber sonst würde ich mir das nicht antun. Finde ich ehrlich gesagt gerade bisschen Schade, dass die Funktion einen Bug hat.


    PS: Wir werden uns denke ich noch gut verstehen,... ich meine wir kommen ja aus dem selben Fach (PHP<3 etc.), wenn's um Programmieren geht :P

    9 Mal editiert, zuletzt von Arktos ()

  • @Metho
    Erst einmal ein dickes Danke, dass du dir diese Arbeit hier machst. :thumbup:
    Ja, das ist echt schade mit dem Bug.
    Somit kann ich das erstmal nicht nutzen - es sei denn ich fix das wirklich selber, wenn die Zeit dafür da ist.
    In meiner BP Lösung habe ich ja noch viel mehr Dinge integriert - wie KReisbogenberechnung und Loops usw.
    Das müsste ich in C++ erst einmal mit integrieren.
    Im ersten Überblick sieht das auch wirklich nicht so schwierig aus.
    Im Grunde sind es ja nur if else in Funktionen gepackt die entweder den Wert oder true/false raus hauen.
    Das wäre doch aber mal eine Sache, die man als Bug-Report Epic Games melden sollte.
    Trotzdem muss ich sagen, dass ich mir nicht wirklich vorstellen kann, dass die Methode viel schneller laufen soll als wenn man die Sache im Blueprint lösst.
    Im Grunde sollte das sogar fast identisch sein, denn mein BP wird ebenso als C++ am Ende compiliert und die Methode sieht mir sehr nach der Methode aus, die ich im Moment benutze.
    Ob ich in C++ "If ()" benutze oder im Blueprint ein Branch sollte höchstens einen Speicherunterschied geben.
    Aber du hast absolut recht - es ist eine Chance gut in C++ einzusteigen. :)


    @Dj EKI
    Da hast du im Grunde recht. ;)
    Edit: (Nach deinem nachträglichen Edit passt meine Antwort nicht mehr richtig :D)

  • Ich habe eben bemerkt, dass @Tomura Formel nicht ganz korrekt mit den Klammern ist. So müsste die lauten, dann funktioniert sie auch bei mir ((3+(6*((2*7)+3))-5)*5*(4-(5/6)))+(2*(4-2))


    Ja das ist die automatische Umstellung von Google.
    Aber die Formel sollte auch in der Urform funktionieren.
    Denn Google klammert nur noch zusätzlich Punkt vor Strich.

  • Na ich hab doch schon längst eine eigene BP Lösung mit vielen zusätzlichen Funktionen erstellt. (sinus, cos, pi, loops, modulo ect.pp)
    Allerdings fixt die Klammerumstellung nicht den Bug von Epic.
    Dort bricht die Funktion nach der abschließenden Klammer ab.
    Das heißt auch bei ((3+(6*((2*7)+3))-5)*5*(4-(5/6)))+(2*(4-2)) wäre vermutlich nach ((3+(6*((2*7) Schluss.

  • Ehrlich gesagt ein sehr peinlicher Fehler.

    Ich würde "peinlich" durch "ärgerlich" ersetzen. ;)
    Vorallem, weil die ganze Funktion und dessen Arbeitsaufwand seitens der Epic-Entwickler erstmal so fast für die Katz' ist.
    Man sollte den Bug reporten und dann hoffen, dass die Priorität ausreichend ist. :)

  • @Dj EKI @Franz99 mal sehen was sich im Entwickler-Studio von Unreal Engine ergibt, vielleicht bekommen wir ja eine erweiterte Funktion mit Sin/Cos etc..


    ...
    Ich denke das mit Blueprints und C++ wird eine ewige Debatte bleiben. Ich persönlich konnte mit Blueprints performance-technisch auch positive Resultate erzielen. Jedoch hat @Tomura mit seiner Aussage schon Recht, die Blueprints werden nicht speziell nochmals optimiert und zudem haben sie einen kleinen *Überschuss* weil alles auf Funktionen/Methoden basiert, aber das ist verkraftbar.


    Was mir halt gerade noch einfällt wäre das Blueprint "Switch on String" statt einem "Branch", wenn du das noch nicht verwendest, damit könntest du ebenfalls Code sparen, aber ich denke, das benutzt du bereits.

  • Danke für den Tipp, aber wann immer es geht und ich nix interpolieren oder halten muss switche ich, um Bereiche einfach von der Rechnung auszuschließen.
    Ich kenn das natürlich. :)
    Nachteilig ist bei BPs, dass sie manchmal etwas Spaghetti-Code verursachen.
    Deshalb ist es auch von Vorteil so ein wenig auch von Scripten zu verstehen und die BPs dementsprechend zu gestalten.
    Ein guter Tipp ist deshalb bei Wiederholungen auch im BP immer Funktionen zu erstellen.
    Schon bei Macros erhält man Spaghetti.
    Das sollte man immer im Hinterkopf behalten.
    Durch BPs bin ich kreativer, weil ich mich nicht all zu sehr auf den Code konzentrieren muss und dadurch optisch mit einem Blick Fehler erkenne oder mir Ideen kommen.
    Manchmal schaue ich das BP einfach nur Minutenlang an und dann kommen die Ideen ganz von selbst.
    Das ist bei direkten Coden schon etwas schwieriger.
    Hat halt alles sein Für und Wider. :)