Bugi w max skrypcie

[gonre]

Najgorsze przy programowaniu jest to, gdy po skonczeniu pracy "źle iczy" pomimo że po 10 krotnym przestudiowaniu skryptu wychodzi że powinien liczyć dobrze.

Zatem proponuje otoworzyć kącik paranoi (paradoksów)

 

Dla zrozumienia porponuje w MAXScript Listenerze wpisac:

 

( 1.0 + 0.99999999) as integer

 

a nastepnie

 

( 1.0 + 0.9999) as integer

 

Teoretycznie róznicy nie powinno być szczególnie przy takiej samej cyfrze, ale u mnie czasem graniczna ilosć dziewiatek po zerze to 4 a czasem 7

Buuuuu jestem zmeczony dochodzeniem do prawidłowosci w nieprawidłowosciach, aż zapał przygasa, hopsa sa!

 

PS: 3dsMAX 5.1 SP1 nie wiem czy to tak jest tylko w tej wersji, czy może to E.Bartosiewicz w słuchawkach powoduje zakłócenia ;)

[lechoo]

Niezly pomysl z tym kacikiem. Juz jakis czas temu myslalem zeby zrobic cos takiego tylko ze z bugami w max skrypcie. Czasem wyskakuja takie "kwiatki" ze glowa mala :) Jesli ktos znajdzie cos takiego niech tu wzuca. Moze komus innemu oszczedzi to pare godzin pracy.

 

Co do tego zaokraglania to wydaje mi sie ze w niektorych momentach np. do wyswietlania (byc moze tez przed konwersja) max skrypt zaokragla do 5 miejsca po przecinku wiec jesli masz 1.99999999 to wychodzi 2.0000 czyli 2.0. Natomiast 1.9999 po zaokragleniu do pieciu miejsc po przecinku to nadal 1.9999. Natomiast konwersja do integera to zwyczajne "odciecie" czesci ulamkowej, czyli w pierwszym wypadku bedzie 2 a w drugim 1.

W zwyklych obliczeniach na szczescie nie zauwazylem zadnych problemow.

[lechoo]

Zauwazylem ze nie mozna z poziomu max scriptu bezposrednio stworzyc kamery targetCamera uzywajac kostruktora np:

cam = targetCamera()

Mozna to obejsc tworzac freeCamera i zmieniajac jej typ na target

cam = freeCamera()
cam.type = #target[size=1]
[/size]

lub zmieniajac typ na free a potem na target

cam = targetCamera()
cam.type = #free
cam.type = #target[size=1]
[/size]

[lechoo]

Wlasciwie jest to brak w VRay'u. Jego swiatla "VRayLight" nie maja udostepnionj dla max scriptu wlasciwosci excludeList.

[lechoo]

Dotyczy maxa 9.

Kolejne wywolania funkcji menuMan.updateMenuBar() powoduja ze max alokuje coraz wiecej pamieci. Po ktoryms z kolei wykonaniu menu maxa znika.

[gonre]

Znów wziąłem się za skrypty i znalazłem to co mnie kilka razy wQrz...ło okropnie

 

W MAXscripcie przydatny jest skrót CTRL+B który wyszukuje sparowany nawias.

Przy kilku stonicowych skryptach rewelacja, ale jest w tym błąd:

UWZGLĘDNIANE SA NAWIASY W KOMENTARZACH !!!

 

Przykładowo

if i==1 then
(
for i=1 to 4 do
(
    ----   )
 format "c:\\a.dwg\n"
) 
)

 

Jeśli nacisniemy CTL+B z kursorem na pierwszym nawiasie, zaznaczy do PRZEDOSTATNIEGO nawisu, choć powinien obiąć również OSTATNI.

 

Wniosek z tego taki że: --- w śmieciach trzeba mieć porządek ;]

 

PS: Sprawdizłem to teraz w MAX 8 i 9, ale ten problem miałem już w 6

[gonre]

ahhhh...... wyżyję się

 

Mały błędzik i łatwy do poprawienia, ale jak ktoś ma nawyki z C to MAXscript czasem wkurza!

 

 

WERSJA BLĘDNA:

random 2+2 5

 

WERSJA OK

random (2+2) 5

[CgBartosz]

Nie wiem czy to mozna zaliczyc pod "Bug" ale to dosc ciekawa konstrukcja poprawna skladniowo:

() == () 

Zwraca true poniewaz () == undefined.

zatem mozna stosowac undefined albo ().

 

if obj == () do print "Object Undefined"

Krotszy zapis, poprawny skladniowo, jesli komus nie chce sie pisac "undefined" :D

Edytowane 8 Wrzesień 2010 przez CgBartosz

[Gość Swordslayer]

( 1.0 + 0.99999999) as integer

 

Przekształcenie typu z float do int obcina miejsc dziesiętnych, w przypadku 1.0 + 0.99999999 dokładność wartości zmiennopozycyjne około 1,0 jest 1.19209e-007, co oznacza, że wynik nie może być precyzyjnie reprezentowany i jest zaokrąglony do najbliższej reprezentowalnej wartości, która jest 2.0:

 

formattedPrint (1.0 + 0.9999) format:".6f"
--> "1.999900"

formattedPrint (1.0 + 0.99999999) format:".6f"
--> "2.000000"

 

Faktycznie, 1.999900 jest wciąż jeszcze zaokrąglona wartością, w istocie nieco mniejszą. Z drugiej strony, 2.0 jest wynik dokładny, ponieważ jest to potęgą dwóch - żaden problem w formacie dwójkowym.

 

Dlatego jest to zawsze dobry pomysł przy użyciu typu float zamiast przekształcać do typu int używać zaokrąglanie. Zaokraglenie symetryczne do najblizszej parzystej (bankers' rounding) jest preferowanym sposobem zgodnie ze standardem IEEE-754. Jeśli ktoś jest zainteresowany dalszymi szczegółami, wystarczy popatrzeć na Comparing float values.

 

Zauwazylem ze nie mozna z poziomu max scriptu bezposrednio stworzyc kamery targetCamera uzywajac kostruktora

 

NOTE:

In MAXScript, you must explicitly construct a target for those objects that need one.

 

Dlatego więc lepiej jest:

 

targetCamera pos:[x,y,z] target:(targetObject pos:[xt, yt, zt])

 

Disclaimer: I don't speak Polish, I just use MAXScript quite a lot and like talking about it. Online translator is my friend.