Ne, hab da leider aktuell auch nur das von von MacRae parat, aber ich weiß selbst, dass das nicht (mehr?) richtig funktioniert...
Beiträge von blackfisch
-
-
Theoretisch könnte das klappen, allerdings könnte das zumindest temporär Frameeinbrüche geben. Wie schnell die Texturen geladen werden ist sowieso sehr von der Leistung des Client PCs abhängig, insbesondere von der CPU
-
UG-C nutzt KEINE A3L Fahreuge mehr. Die was du meinst, Dodge Charger, Crown Victoria etc. sind Sonderanfertigungen die sie für insgesamt über 1000€ selbst haben erstellen lassen. Alles was noch im Modpack ist, ist entweder frei erhältlich im Steam Workshop/Armaholic oder gegen Bezahlung erstellt worden
-
Schilder auf Distanz - nimm PAA Dateien und keine JPGs, liegt daran. Mehr geht nicht. Was genau ist denn beim Sitz-Script dein Problem?
-
Ich geh meine ganzen Tuts wo Probleme auftauchen in nächster Zeit nochmal komplett durch, ich weiß allerdings nicht, in wiefern ich dazu komme aus schultechnischen Gründen.
-
Der Ansatz war gut, ja
Merk dir einfach folgendes: Wenn du bei einer Variable nur 2 mögliche Werte hast, nutzt du am besten einen If () Then {} else {} Block, wenn du mehr als zwei Möglichkeiten für ein und dieselbe Variable hast nutzt du im Idealfall eine switch () do {} Case - das hängt mit der Performance und Übersichtlichkeit zusammen
Alles zum Syntax von Befehlen findest du im BI Community Wiki."switch" - BI Community: http://community.bistudio.com/wiki/switch_do
"if" - BI Community: http://community.bistudio.com/wiki/if -
Kleiner Tipp: Statt die Lampen kaputt zu machen, kannst du diese auch einfach "ausschalten" (nur die "Glühbirnen" kaputt machen) und das ganze würde ich in eine switch-case packen:
C
Alles anzeigen_mode = _this select 3; switch (_mode) do { case "1": { { _x setHit ["light_1_hitpoint", 0.97]; _x setHit ["light_2_hitpoint", 0.97]; _x setHit ["light_3_hitpoint", 0.97]; _x setHit ["light_4_hitpoint", 0.97]; } forEach nearestObjects [getMarkerPos "medic_spawn_1", ["Lamps_base_F","PowerLines_base_F","PowerLines_Small_base_F"], 100]; }; case "2": { { _x setHit ["light_1_hitpoint", 0]; _x setHit ["light_2_hitpoint", 0]; _x setHit ["light_3_hitpoint", 0]; _x setHit ["light_4_hitpoint", 0]; } forEach nearestObjects [getMarkerPos "medic_spawn_1", ["Lamps_base_F","PowerLines_base_F","PowerLines_Small_base_F"], 100]; }; case "3": { { _x animate ["Door_1_rot", 0]; } forEach (nearestObjects [getMarkerPos "medic_spawn_1", ["Land_BarGate_F"], 90]); }; case "4": { { _x animate ["Door_1_rot", 1]; } forEach (nearestObjects [getMarkerPos "medic_spawn_1", ["Land_BarGate_F"], 90]); }; }; -
Bei zig tausend Gamelogics aber auch - das verursacht bei der init Performanceeinbrüche, deswegen halte ich das für keine so geniale Lösung
-
C
_Btn1 buttonSetAction "[[10],""life_fnc_removeLicenses"",life_pInact_curTarget,FALSE] spawn life_fnc_MP; closeDialog 0;";wird zu
C_Btn1 buttonSetAction "[10] remoteExecCall [""life_fnc_removeLicenses"",life_pInact_curTarget]; closeDialog 0;";und die anderen Sachen logischerweise halt mit 11 etc auch genau so - musst nur die Zahlen anpassen.
-
Dann könntest du prinzipiell auch eine Gamelogic setzen in die Mitte mit { _x setFuelCargo 0; } forEach (nearestObjects [getPos this, ["Land_FuelStation_01_pump_F","Land_FuelStation_02_pump_F"], 200000]);
Das ist bedeutend weniger aufwendig
-
Es ist trotzdem unnötig viel Arbeit die ganzen GameLogic's erstmal zu setzen und danach abzufragen ob man bei einer Gamelogic ist oder nicht - da macht die Variante von NiiRozz mit den Koordinaten einfach mehr Sinn unter Betrachtung der Effizienz
-
Das mit den Schranken... Hier ein kleines Tut:
- Erstelle eine neue Datei fn_gateOpener.sqf im Ordner core/functions mit folgendem Inhalt
- Ergänze in deiner Functions.hpp unter class Functions folgendes:
- Öffne deine fn_setupActions.sqf und trage dort folgendes bei case west ein (und bei independent wenn auch für Medics/bei civilian für Civ's)
Und das war's auch schon. Wichtig zu wissen ist, die 30 ist die Distanz, ab der die Funktion angezeigt & ausgeführt wird, diese kann beliebig geändert werden.
- Erstelle eine neue Datei fn_gateOpener.sqf im Ordner core/functions mit folgendem Inhalt
-
- Falscher Bereich (Wasteland und nicht Altis Life)
- Blaulichtfarbe: in deiner fn_copLights.sqf findest du folgendes:
einfach bei _lightRed das gleiche eintragen wie bei _lightBlue. Sowas bekommst du übrigens über den Arma Color Picker raus: http://lostvar.com/flashtrash/SPUNsColorPicker.html - Bei ARMA findest du 4 Werte - die ersten 3 sind relevant für dich, der vierte ist der Alpha-Wert (für Transparenz)
- Für Truck Boxer und SUV musst du einfach noch die Koordinaten nachtragen (findest du einfach z.B. mit dem hier: http://www.armaholic.com/page.php?id=31072) - eintragen in der fn_copLights.sqf und die Fahrzeugclass mit eintragen in der fn_keyHandler.sqf, fn_sirenLights.sqf und in der life_server fn_spawnVehicle.sqf
-
Wie meinst du das mit den Schranken denn genau? kannst du das etwas genauer beschreiben, was du meinst?
-
Mach es am besten nicht wo, sondern wie von @B4v4r!4n_Str!k3r korrekt angegeben
-
Nicht wirklich, da das Schild mit dem Spieler gegenüber eine eigene Kollisionsabfrage hat und das Schild dein Gegenüber einfach förmlich umhaut
-
Das ist nicht kompliziert, zumal die im Tutorial gegeben sind. Die Variante mit den Triggers ist außerdem Ressourcenintensiver, besonders Clientseitig wo die ganze Sache dann ausgeführt wird. Da ist die Scripttechnische Lösung deutlich effizienter und schöner
-
[_unit,"jihad"] remoteExec ["life_fnc_say3D",RANY]; würde ich im Tutorial übrigens durch [_unit,"jihad"] remoteExec ["life_fnc_say3D",RCLIENT]; ersetzen, da der Server den Sound ja eh nicht abspielt sondern nur die Clients, ist aber eine reine Schönheitsgeschichte :p
-
Ich weiß nicht warum du es so kompliziert machst? Es gibt die fn_setupStationService.sqf nicht grundlos und die funktioniert auch super
Auf jede Tankstelle eine Gamelogic ist unnötig viel Arbeit und jagt die Größe der Missionfile unnötig in die Höhe :pSuch einfach mal nach Dateien, die im Namen fuel enthalten und schau, dass überall die Classnames wie im Tutorial angegeben sind

-
Bis zur 4.5 kanns schon durchaus noch ein zwei Monate dauern. Grundsätzlich gilt: alle Versionen mit einem "R" im Namen sind Entwicklerversionen und WIP. Diese findest du immer im Repo von ArmaLife: https://github.com/ArmaLife/Framework
Stable Versionen haben keine Buchstaben im Namen sondern nur Zahlen ("4.4") und werden im GitHub von Tonic veröffentlicht: https://github.com/TAWTonic/Altis-Life