Rudy

1. To najlepiej za pomocą alarmu (czy odliczającej się zmiennej w sumie na jedno wychodzi) 2. Masz rację, zmienna w łódce, test warunkowy i sprawa załatwiona ;) 3. Każ im najpierw biec do punktu przed drzwiami łodzi a potem dopiero do środka :) 4. Dodaj sobie do żołnierzy zmienną oznaczająca id obiektu, w którym są (np łódź, samolot, ciężarówka): GML slave = -1; // czyli brak przynależności</span> Gdy wejdą na pokład zmień slave na id łodzi i dodaj do step ten kod: GML if (slave != -1) { x += slave.x-slave.xprevious; y += slave.y-slave.yprevious; } Powinni wtedy zostać na łodzi :) .

Pewnie dlatego, że woli przyjmować podziękowania od płci pięknej ;) .

Wymuszasz na stacji wysunięcie płyty, ona może się jeszcze kręcić, gorzej, może się rozpędzać. Ingerujesz w poprawne działanie, a każda taka ingerencja nie jest dobra. W ostateczności jednak to może być jedyne wyjście.

Aa to proste, też tak miałem z innym :) . W moim pendrive ta biała płytka ze złączami i obudowa wtyczki jest osobno. Wystarczy otworzyć pendrive'a i docisnąć z drugiej strony środek tak, by płytka i obudowa była równo ze sobą. (o ile jest to zwykłe przesunięcie, jak uszkodzenie złączy, czy wnętrza to już gorzej) Nie pisałem o tym, bo ten błąd wyglądał u mnie inaczej, wykrywał urządzenie do przenoszenia danych, ale nie mógł go otworzyć (Włóż dysk do stacji F)

Ja kiedyś miałem podobny problem, odinstalowałem urządzenie i zainstalowałem na nowo. Wczytuje się dłużej, ale działa. Potem jednak podobny problem i tu już nie udało się tego zrobić, więc to nie jest pewny sposób.

Port byłby tutaj najlepszy: Obiekt kontroler GML (Create) // Stałe wst_sila = 10; // w px wst_czas = 60; // 2s, jeżeli room_speed == 30 // Zmienne wstrzas = wst_czas; // kontroluje wstrząśnięcie, patrz dalej</span> GML (Step) if (wstrzas < wst_czas) { var sila; sila = wst_sila*(wst_czas-wstrzas)/wst_czas; view_xport[0] = random_range(-sila, sila); view_yport[0] = random_range(-sila, sila); wstrzas += 1; } else { view_xport[0] = 0; view_yport[0] = 0; } I teraz, jeżeli korzystasz z viewu 0, view_xport i view_yport masz ustawione na 0 i ustawisz podczas gry zmienną wstrzas na 0, powinno ci wstrząsnąć ;) EDIT: A jednak nie wstrząśnie. Nie wiem czemu, port nie może być < 0, podobnie jak view.

GML (Draw) if (idzie_poziomo && image_index == 4) image_index = 0; if (idzie_pionowo && image_index == 8) image_index = 4;

Hmm... sprawdzaj kąt lotu, tzn spróbuj dodać spadanie zależne od kątu, czyli: GML y += abs(hspeed)/5; // ewentualnie lengthdir_y(speed, image_angle), jeśli nie lubisz hspeed</span> Zaczynaj zmieniać kierunek lotu dopiero, gdy samolot się przekrzywi, ale nie też tak od razu, tylko stopniowo, wraz ze wzrostem skrętu.

Nie chcę przerywać konwersacji (jest bardzo ciekawa i mam nadzieję, że jeszcze trochę potrwa :) ), lecz mógłby ktoś na końcu swej wypowiedzi dodać rozwiązanie mojego (i Edie'go) problemu (mniej więcej bazują na tym samym)? Fakt, że prędzej, czy później musiałbym okraść bank mnie nie satysfakcjonuje, zanim ponownie okradłbym bank, musiałoby wystąpić kilka zdarzeń, które naprowadziłoby mnie do tej decyzji. Aby zdarzenia miały efekt, musiałyby być przemyślane. Fizyka świata (czy coś, co odpowiada za czas), musiałaby wtedy mieć coś na kształt rozumu, by ułożyć i zaplanować te wszystkie zdarzenia. W co nie wierzę, bo jako tako zjawisko nie może myśleć.

No dobrze, to ja mam takie pytanie z kategorii paradoksów czasowych. Załóżmy, że mamy wehikuł czasu, lecz możemy przesłać przez nie tylko przedmioty (czy nas samych już nie) i jest lekki więc przenośny. Opracowujemy plan napadu na bank. Wchodzimy do środka i przesyłamy pieniądze w przeszłość do siebie. Po udanym przeniesieniu zabijają nas, nie żyjemy. Wracamy z akcją do przeszłości, siedząc sobie przy biurku przed nami pojawiają się pieniądze. Skoro już je mamy, nie musimy napadać na bank i żyjemy dalej. Pytanie brzmi, czy taki paradoks jest możliwy? Skoro przeniesienie pieniędzy nie wystąpiło (bo przed planowanym atakiem już je dostaliśmy i zdarzenie obrabowania banku zniknęło), to skąd je mamy?

@Chell Jeżeli je ogarną to niedługo będzie koniec świata. Przez chciwość ludzi ktoś zatrzymie czas, zmieni rzeczywistość, żeby jemu było lepiej. O ten wehikuł ludzie będą walczyć, nastąpi wojna, którą ludzkość przegra. Po prostu zniszczy sama siebie. Człowiek będzie mógł posiąść wiedzę nt. przemieszczania się w wyższych wymiarach, dopiero, gdy się zjednoczy. Gdy powstanie jedno wielkie państwo beż żadnych granic i murów. Na to będziemy musieli długo czekać.

Są różne wersje wielowymiarowej rzeczywistości. Do geometrii postrzega się wszystkie wymiary jako przestrzenne i ewentualnie jeden czasowy, jeżeli chcielibyśmy pokazać animację. Z kolei w rzeczywistości (podobno) jest tak: http://youtu.be/8RjujY-wo5Q http://youtu.be/a0KgEfBwPsc

Uwierz mi, że staram się jak mogę :P . Owszem, masz rację. Załóżmy jednak, że mamy wyobraźnię. Dzięki temu założeniu możemy za pomocą owej wyobraźni pozmieniać niektóre piksele, by bardziej pasowały do reszty. Dzięki temu zamiast czekać na jeden niepowtarzalny obrazek mamy kilka(set/tysięcy) obrazków, które przypominają ten główny. Teraz, jak te obrazki byłyby rozłożone w pętli programu? (0 - nie ten obrazek, 1 - ten) 0000000000000 (i jakieś 10000 tys. 0) 01001001001111111111(tysiąc jedynek)111111100100010000100... Efekt? Na nasz obrazek będziemy musieli czekać jakieś 10017 zer. A teraz, zmieszajmy wszystko ze sobą: 00000000010000000000001000000000001000001000000000000000100000000010000000000000 0000... Obraz pojawia się już wcześniej, co prawda tylko przez mały okres czasu, ale mózgowi powinno wystarczyć.

Jeżeli chodzi o losowość to może dobry pomysł, po mając jakiś obrazek to wiadomo, jeżeli zmieni się parę pikseli o małą wartość to sam sens obrazka się nie zmieni. Jeżeli ktoś miałby sprawdzać działanie tej teorii, najlepiej każdej kombinacji pikseli przypisać jakiś indeks i dopilnować, żeby ten indeks się nie powtarzał. Uzyskamy losowość, oraz "niepowtarzalność", jaką da nam for. Jedyny problem to to, że ta liczbę troszkę... duża :) . A jak dodać do tego zapamiętanie wszystkich wystąpień to przyda się dodatkowa pamięć :) . Chyba, żeby wymyślić wzór, który by przeszedł przez wszystkie te indeksy nie powtarzając żadnego, wtedy zejdzie nam to do jednej liczby i obsługi podstawowych działań na niej (do wzoru).

Mi to przypomina The Game of Life :)

Czas. Zakładając nawet, że będziemy widzieć jedną taką klatkę 320x240x24bps w ciągu 0.1s. daje nam to (wg calc) 1 288 490 188 800 s, czyli ponad 4 tysiąclecia. Komu by się chciało tak długo czekać? :P No chyba, że trochę utniemy na jakości i damy sobie np 320x240x8bps x 0.1s to już mamy wtedy 1 966 080 s, czyli 22 dni, 18 h, 8 min. ;)

Ten skrypt mam też w przykładzie, dircmp, jedynie bez wyznaczania kierunku przez point_direction, ale za to zwracający różnicę zawsze w zakresie (-180, 180>. Można i tak, lecz co jeśli będzie bardzo mała przeszkoda w bardzo dużej odległości? Albo jeśli będzie odbijało się tuż przy wieszchołku? Wtedy jedna/dwie linie będą miały końce zupełnie gdzie indziej i efekt wyjdzie... nie taki jak powinien być ;P

Mi tam nie przeszkadza, że mamy na forum kogoś z zachowania podobnego do House'a :P Poza tym nie widzę tutaj, żeby Sernat zaczął, chyba, że propozycja użycia dokumentacji to coś obraźliwego. Na chwilę obecną temat wyczerpany: 1. Sprawę załatwić tilesami (skoro nie na środku to ustawić na środek (originy, przesunięcie pozycji itp) 2. Jak sernat, użycie particlów 3. Wygląda na rozwiązany Czekamy na post autora tematu.

Zrobiłem mały przykładzik co do moich rozważań odbicia lasera. Sprawdź, czy ci pasuje. Każda odbicie zwalnia pfs o mniej więcej 30 z 600, przy roomie 10000x10000 (na mniejszym różnica 2-4 fps). Rzuć okiem, czy ci odpowiada. Jedynie co to musisz opisać za pomocą prostych i krzywych swoje figury. Ewentualnie ulepszysz kod o kolejne typy powierzchni :) . PLIK

Jest to optymalizacja ale mała. Sposób? Ustaw maksymalny test na cały room. Wtedy dalszego zasięgu nie będzie, a sprawdzanie binarne jest chyba najbardziej zoptymalizowanym sposobem. A jeśli już chcesz swój pomysł, to nie dziel na 100 mniejszych tylko binarnie (wtedy zamiast 100 masz 7 sprawdzeń ;P ). Im więcej obiektów tym więcej ma GM do przetworzenia, a jeśli będziesz miał takie rozwiązanie, będzie mniej obliczeń bez efektu (jak kontrola zmiennych prędkości, animacji itd, każdy obiekt to ma) No właśnie, a tak jeżeli płaska powierzchnia - wpisujesz do danych dwa punkty i przy odbiciu odwołujesz się do nich. collision_point powinno załatwić sprawę ;) .

Albo po prostu opisać każdą przeszkodę punktami krańcowymi i przy kolizji odwoływać się do nich.

Moim zdaniem h/vspeed jest tu dobrze wykorzystane. Po co pisać speed=, direction= jak można to zrobić w jednej linii? Poza tym założę się, że GM załatwia sprawę zmiany przesunięcia co klatkę za pomocą h/vspeed, nie speed, direction i trygonometrią.

Od teraz muszę sprawdzać co piszę ;D . Ale co tam, wprawny uczeń znalazłby błąd :) . No tak, zał: zycie należy do <0, max_zycie> :) Bez nawiasu będzie nawet lepiej, komputer najpierw mnoży, potem dzieli, dzięki temu działa na przyjaznych jemu większych liczbach. A efekt ten sam :) . Wtedy można nawet to rozwiązać na liczbach całkowitych ;P .

osobiście zrobiłbym te życie nieco inaczej (na poziomach 1-3 jeszcze ify ujdą, wyższe poziomy to już switch ale najlepiej byłoby znaleźć zależność i wpisać wzór, np zycie = 4+power(poziom, 2); albo zycie = 2+poziom*3; itd. draw_sprite_ext w porównaniu do draw_healthbar nie jest najlepszym rozwiązaniem, potrzebny jest sprite. Nie mniej jednak można to obejść i to na dwa sposoby :) . GML (Create) max_zycie = 160; zycie = max_zycie; 1. - przekształcenie draw_healthbar: GML (Draw1) draw_healthbar(view_xview[0]+110, view_yview[0]+150, view_xview[0]+450, view_yview[0]+180, zycie*100/max_zycie, 0, c_red, c_green, 0, 1, 1); 2. - symulowanie draw_healthbar: GML (Draw2) draw_set_color(make_color_rgb(floor(min(255, 510-zycie*510/max_zycie)), floor(min(255, zycie*510/max_zycie)),0)); draw_rectangle(view_xview[0]+110, view_yview[0]+150, view_xview[0]+110+340*zycie/max_zycie, view_yview[0]+180, 0); draw_set_color(c_black); draw_rectangle(view_xview[0]+109, view_yview[0]+149, view_xview[0]+451, view_yview[0]+181, 0);

Dodam też, że do interakcji z GM'em musisz używać keyboard_check_direct() (np do włączenia wciskania, gdy nie ma focusa), dobrze też by po symulowaniu wciśnięcia klawisza symulować też jego puszczenie.