Czy idzie podczepić coś innego niż kamere do danego objektu?

No właśnie, a konkretnie chce podczepić element logiczny do tego addonu na komin.



A w element logiczny wpisać skrypt dymu. W efekcie będzie to fajnie wyglądało i ty samym będzie realistyczne.

Jeśli miałby to być obiekt statyczny, nie byłoby problemu, natomiast przy ruchomym, element logiczny musiałby stale podążać za obiektem, co wymagałoby skryptu, który co ułamek sekundy zwracałby pozycję statku a następnie sytuował ten element komenda setpos (getpos) na wysokości komina. Sporo roboty i efekt może nie wyjśc dobrze, zważywszy na dośc spore obciązenie takim niepozornym skryptem, kompa.

Jakie obciazenie kompa? gdzie sporo roboty? i co moze nie wyjsc dobrze?! wytarczy zapetlic setposa i po sprawie...

To sie nazywa "spieprzacz rozrywki"

Pop, każdy skrypt obciąza kompa a szczególnie taki, który jest powtarzany wielokrotnie w ciągu krótkiego czasu. SiD to dobrze ujął

A wiesz jak ofp obciaza kompa? nie lepiej grac w bierki?

PoP... jak chcesz to se pograj w bierki... Prawda jest taka, że każdy jeden skrypt powoduje obciążenie... Może nie aż tak kolosalne, że się grać nie da, ale zawsze. Zresztą co do grywalności to w dużej mierze zależy od sprzętu.

A teraz koniec gadania o obciązeniach... lepiej napiszcie jak taki skrypt wygląda, bo sam jestem ciekawy, jaki bedzie efekt

Udało mi sie wyczarowac ten dymek

Ale jest problem zamiast nad którymś kominkiem jest na środku, a ja nie wiem jak to zrobić.

Tak wygląda ten bajerek

36 KB

A tak skrypt.

Kod: Zaznacz cały

;Smoke.sqs

#Smoke

_cam CamSetTarget objnull

_ox = GetPos Smoke Select 0
_oy = GetPos Smoke Select 1
_cam CamSetPos [_ox,_oy,0]
_cam CamCommit 0

Smoke Setpos Getpos Ship

Smoke1 Setpos Getpos Smoke
Smoke1 setpos [getpos this select 0, getpos this select 1, (getpos this select 2) +44]

goto "Smoke"


Przydałby mi się jeszcze skrypt bardziej naturalnego dymu, bo ten jest zbyt kłębiasty.

Wdarł się jeszcze jeden mały bug. Mianowicie małe kłębki dymu z pod okrętu. Jest tam element logiczny, który jest podstawą dla drugiego EL z którego wydobywa się dym. Nie wiem jak to usunąć. W podstawie nie ma skryptu dymu, tak więc czemu z tamtąd się wydobywa ?


[HAV] Ostatni raz ostrzegam.... za kolejne screeny > 100 KB w tagach wyciągnę konsekwencje

[DODANE] Już się tak nie denerwuj, poprawiłem teraz ma 36 KB

Pop, każdy skrypt obciąza kompa a szczególnie taki, który jest powtarzany wielokrotnie w ciągu krótkiego czasu. SiD to dobrze ujął

No ja juz kurde nie wytrzymam! Przeczytali na forum i na slowo uwierzyli.
Nie chce mi sie tlumaczyc, ale w skrocie -
skrypt sam w sobie laga nigdy nie powoduje. Jego koszt CPU jest zawsze zaden. Operuje on na kilku zmiennych zmieniajac ich wartosci.
Obiekt GameLogic nie ma modelu - bledem jest myslenie o nim jako o obiekcie, gdyz w rzeczywistosci skalada sie on tylko z trzech zmiennych - czyli pozycji.
Idac za waszym tokiem rozumowania eventhandler powinien powodowac zawieszenie kompa - w koncu jest to skrypt wykonywany 10000 razy na sekunde.

Skrypt "powoduje" laga jedynie gdy twozy obiekt 3D - koszt obliczen dla dowolnego, nawet najprostszego obiektu jest ogromny. Jakby dac wam papier i olowek to godzinami byscie przeksztalcenia liczyli zeby wygenerowac jego obraz.

Kolejnym bledem jest np. proba robienia tracerow jako pojedynczego obiektu 3D - "chmurki" (cloudlets) maja maly koszt CPU - a to dlatego, ze sa obiektami 2D - tzn. powstaja na ekranie jako bitmapy, nie w efekcie mapowania tekstury.

Sid - myslales moze o skrypcie ktory TWOZY obiekt. Ten zaproponowany tutaj nikomu laga nie zrobi - chyba ze w OFP grasz na kalkulatorze.
Kolejna bujda sa zreszta zalety sqf...
Nie wierzcie we wszystko co pisza.

Pando opierasz się na logice i podchodzisz do tego w sposób teoretyczny, podczas gdy oni (i nie ukrywam że ja również) w sposób empiryczny.

_obiekt = smoke
_pos = statek
_dlugosc = 32193021
_wysokosc = 44

#1
~0.01
_obiekt setpos[(getpos _pos select 0)+_dlugosc*sin(getdir _pos),(getpos _pos select 1)+_dlugosc*cos(getdir _pos),(getpos _pos select 2) + _wysokosc]
_obiekt setdir getdir _pos
goto "1"

Jelsi chcesz wylaczyc skrypt gdy statek zostanie zniszczony :

_obiekt = smoke
_pos = statek
_dlugosc = 32193021
_wysokosc = 44

#stan
? !(alive _pos) : goto "end"


#1
~0.01
_obiekt setpos[(getpos _pos select 0)+_dlugosc*sin(getdir _pos),(getpos _pos select 1)+_dlugosc*cos(getdir _pos),(getpos _pos select 2) + _wysokosc]
_obiekt setdir getdir _pos
goto "stan"

Pando opierasz się na logice i podchodzisz do tego w sposób teoretyczny, podczas gdy oni (i nie ukrywam że ja również) w sposób empiryczny.

Kod: Zaznacz cały

_sol = _this select 0
_tab = []
_i=0
#loop1
_s="Logic" camcreate getpos _sol
_tab = _tab + [_s]
_i=_i+1
?(_i<1000):goto "loop1"

#loop
_i=0
#setloop
_tab select _i setpos getpos _sol
_i=_i+1
?(_i<1000): goto "setloop"
~0.001
goto "loop"

Jezeli ktos sadzi, ze skrypt powoduje laga niech sprobuje uruchomic ten i ocenic samemu. Twozy on 1000 obiektow GL i porusza nimi za obiektem 1000 razy na sekunde.

Ja już patrzę na wszystko pod kątem MP. Tam te informacje muszą być wymieniane pomiędzy klientami oraz serwerem i niestety powoduje to problemy.

Ja już patrzę na wszystko pod kątem MP. Tam te informacje muszą być wymieniane pomiędzy klientami oraz serwerem i niestety powoduje to problemy.

Coz misje MP nie wymagaja slicznych efektow, wiec obylyby sie bez dymu... czy statku wogole
Tam rzeczywisci przekazywanie kilku tysiecy zmiennych na sekunde sprawiloby problem.
Rada jest jedna (co tez robie) - grac na SP . Tam mozna sobie na fajerwerki pozwolic.

Coz misje MP nie wymagaja slicznych efektow, wiec obylyby sie bez dymu... czy statku wogole
Tam rzeczywisci przekazywanie kilku tysiecy zmiennych na sekunde sprawiloby problem.
Rada jest jedna (co tez robie) - grac na SP . Tam mozna sobie na fajerwerki pozwolic.

Owszem, w SP można sobie pozwolić na dużo, dużo więcej, ale dla mnie to niewielka zaleta. Granie "z komputerem" wypada blado w porównaniu z graniem "na komputerze" bez względu na to jakimi bajernymi efektami się je ubarwi.

Dryf tematyczny zaczyna postępować