Posts by DerWeiseler

Stell mal die Logfile hier rein, die zeigt meistens den Grund oder zumindest den Anhaltspunkt für Abstürze auf.

Leute, kein Grund euch hier gegenseitig anzukeifen wenn noch weitere Ideen kommen. Einfach drauf los schreiben, wir haben eine sehr lange Liste mit weiteren Ideen, die permanent aktualisiert wird. Von daher braucht sich niemand an "Mod ist final" oder ähnlichem aufzuhängen. Außerdem stellen wir regelmäßig fest, dass wir diese Aussage besser nicht gebrauchen sollten, so viel wie derzeit noch aktiv an der eigentlich finalen Version noch geschraubt, umgebaut und erweitert wird. Nicht mal der angepriesene Fuhrpark ist vor Last-Minute-Änderungen sicher :blackeye:
Aber um die Frage von @Fireman1984 zu beantworten: Das wird nicht umgesetzt werden. Erstens hab ich aus dem Stehgreif keinen Plan, wie man das umsetzen könnte (und es graut mir schon immer, wenn ich meine derzeit noch auszuführenden Script-Arbeiten sehe, da führt jeder neue Input den ich mit Hirnschmalz zusammenkleistern muss zu einem kleinen Nervenzusammenbruch, frag mal unsere Mudder), und zweitens haben wir *zensiert wegen "das ist geheim"*

Für die Tür gibt es ja auch
PlayAnimOpenDoor("Warntafel", 5.f, Caller);

Lad mal dein Logfile hoch, zu finden unter "C:\Program Files (x86)\sixteen tons entertainment\Emergency4\logfile.txt" (bzw. dort wo es installiert ist) oder wenn dort nix ist unter "C:\Users\<deinBenutzername>\AppData\Local\VirtualStore\Program Files (x86)\sixteen tons entertainment\Emergency4\logfile.txt" (der Ordner ist versteckt, geh also in deinen Profil-Ordner und schreib den Rest von Hand oben in die Leiste rein)

Hallo an alle Script-Bewanderten :hi:

Ist es möglich, dass Game::IsInTrigger() im CheckTarget tatsächlich nicht MP-tauglich ist? Im SP funktioniert die Abfrage problemlos:

if (v.HasName("Fhz1"))
		{
			Vector est = Game::GetCommandPos();
			if (!Game::IsInTrigger("Trigger1", est))
				return false;
		}

Genauer gesagt steckt dieser Teil bei mir in den BFE-Versionen von Move, Arrest, EnterHouse und FahrzeugPosition. Im MP wird CheckTarget dadurch aber nicht false.

Sofern bestätigt ist, dass das wirklich nicht geht, gibt es dann noch eine Alternative?

Ich hab mich mal hingesetzt und dazu recherchiert. Es geht dabei tatsächlich nicht um Einsatzfahrten, sondern um die Aufzeichnung von Einsätzen bzw. Einsatzstellen, und es gab dort bereits mehrfach Probleme. Das Urteil des LG Bonn vom Juni 21 zeigt das auch auf.
Aufgrund des Gerichtstextes bzw. der Videobeschreibungen ist es übrigens auch sehr einfach herauszufinden, um welchen Youtube-Kanal es sich handelt. Und dort sieht man, dass sehr oft keine Einsatzfahrten, sondern um Aufnahmen über Situationen an Einsatzstellen.
Wenn dann vom Angeklagten solche Kommentare drunter stehen wie "Ach mir ist das völlig egal...Ich hab schon so viele Anzeigen...Bis jetzt wurde bis auf eine alles eingestellt." ist es wohl auch mal angebracht, dass er verurteilt wird.

Seine Ansichten und die von vielen anderen Gaffern in Form von "Das was und wie ich es mache ist rechtlich einwandfrei" oder "Weil ich Feuerwehrleute bei einem Rettungseinsatz nicht gepixelt habe...Das muss man allerdings eigentlich auch nicht und macht auch sonst eigentlich keiner" ändern sich jetzt vielleicht mal.

Sprich: Einsatzfahrten sind davon nicht betroffen. Es geht vielmehr um "Bildnisse aus dem Bereiche der Zeitgeschichte" ("besondere Ereignisse oder Handlungen" -> ist bei Routine-Einsätzen nicht der Fall) und eine "Angelegenheit von öffentlichem Interesse" (z.B. pflichtwidriges Verhalten, Tätlichkeiten etc.). Beiwerke sind es in diesen Fällen auch nicht, wie es bei Einsatzfahrten der Fall ist. Daher erscheint mir das Urteil auch schlüssig und völlig angebracht. Gerade vor dem Hintergrund, wenn man mehrfach darauf hingewiesen/belehrt wurde und mich penetrant weigere, die Persönlichkeitsrechte zu wahren. Das man das dann so eskalieren lassen muss verstehe ich nicht...

Bzgl. der Member-Geschichte: In Winterberg hat der Doc glaube ich dafür bis zum Exzess Flags manipuliert, da war doch glaube ich hier auch vor längerer Zeit mal ein Thema, von Nikolas. So wie du dir das vorstellst, geht es aber nicht. Für gewisse Sachen gibt es sicherlich aber auch andere, vordefinierte Methoden (z.B. kannst du die Notwendigkeit eines NA ja auch von GetLife() abhängig machen). DummyCommands dürften aber eigentlich auch nicht großartig zu Ladezeitverlängerungen führen :hmm:

Bzgl. des Wetters noch ganz doof gefragt, die "Climate-Transition" in den fp_params war dafür auch ausgeschaltet? Nicht dass das dabei dazwischenfunkt. Schnee, Blitze, Wind und Nebel kann man ja in den Map-Properties auch ändern, vermutlich lässt es sich deswegen per Command-Script ändern.

Da ist beim Kopieren noch eine } verloren gegangen, habe das oben korrigiert.
Häng dann auch noch mal das gesamte Script an, wie es anschließend eingebaut ist, sofern das den Absturz nicht behebt (sollte aber dann zu einer Fehlermeldung führen).

Quote from fresh freddie

Und zwar fährt das angeklickte Auto den Path zuende und bleibt an dessen Ende stehen, anstatt sofort stehen zu bleiben. Wie lässt sich das fixen?

Hm, dann ist der Pfad wohl zwischengespeichert und wird dennoch zuende gefahren :hmm: Versuch es mal mit einem zusätzlichen Aufruf von
t.PushActionWait(ACTION_NEWLIST,0.1);
Damit sollten alle aktuellen Aktionen, wie auch die Fahrt entlang des Pfades, gelöscht werden. Vorsicht, kann passieren dass das Fahrzeug sofort beim Ausführen des Commands stehen bleibt, dann könntest du dir einen Workaround mit Aufruf per childID bauen.

Quote from fresh freddie

Geht das auch bei Fahrzeugen? Das Skript soll nur bei zivilen Fahrzeugen funktionieren. Daher soll Squad und Gangster in CheckTarget ausgeschlossen werden.

Sofern dein Gangster-Fahrzeug als Gangster_Getaway festgelegt ist:

Vehicle v(Target);
if (v.GetVehicleType() == VT_ALL_SQUAD_VEHICLES || v.GetVehicleType()==VT_GANGSTER_GETAWAY)
return false;

Wobei ich nicht weiß, ob VT_GANGSTER_GETAWAY nicht sogar in VT_ALL_SQUAD_VEHICLES enthalten ist. Da wirst du mal rumprobieren müssen.

Da ich nicht weiß, wie du dir den Ablauf des Script vorgestellt hast, fällt mir gerade auch auf, dass das Yelp-Signal auf der Stelle stehen bleiben wird. An sich aktualisiert Audio::PlaySample3D() die Position nicht, das müsste dann z.B. über ein abgespecktes Sosi-Script geregelt werden.

Wie bereits erwähnt in VcmdAlarm, was du in der Bieberfelde.script findest.
Dort im Abschnitt PushActions stehen sämtliche Fahrzeuge drin. Dort fügst du bei den gewünschten Fahrzeugen einfach diese Zeile ein, z.B. beim 1/10-1 so:

if (v.HasName("01_10_01"))
{
v.SetMaxPassengers(2);
v.PushActionExecuteCommand(ACTION_APPEND, "Create_Person",&v, 26, true);
v.PushActionWait(ACTION_APPEND,2.0f);
Audio::PlaySample3D("mod:Audio/FX/Alarm/Wachgong_1_10_1.wav", v.GetPosition(), false);
}

Quote from fresh freddie

1. "Cant Call in Current Scope" bei MoveTo

PushActionMoveTo() existiert nicht als Methode, sondern PushActionMove().

Quote from fresh freddie

2. "Cant Call in Current Scope" bei RemovePath

Ein Actor (z.B. Target) kann nicht auf RemoveObjectPath() zugreifen. Die Lösung ist es das Target nicht als Actor, sondern Vehicle anzusprechen, was du weiter oben ja bereits deklariert hast: t.RemoveObjectPath();

Wenn du es jetzt noch sauberer machen möchstest, rufst du PushActionMove() und IsCommandInRange() nicht über das GameObject "Caller" auf, sondern nutzt direkt das "Vehicle v(Caller)", was du ohnehin deklariert hast und für andere Befehle auch benutzt.

Richtig, es hat eine } gefehlt. Allerdings war eine andere } falsch gesetzt, sodass viel zu viel in der 4x4-Abfrage drin war und dadurch komische Bedingungen entstanden wären.
So sollte es passen:

bool CheckTarget(GameObject *Caller, Actor *Target, int childID)
{
	mr = Commands::CheckMoveConditions(Caller, Target, childID);
	if (mr.Mode == MOVE_ABORT)
		return false;
	if (Caller->GetType() == ACTOR_VEHICLE)
	{
		Vector Pos = Game::GetCommandPos();
		if (Game::IsInTrigger("4x4", Pos))
		{
			if (Caller->GetType() == ACTOR_VEHICLE)
			{
				if (Caller->HasName("03_44_01") || Caller->HasName("03_45_01") || Caller->HasName("04_42_01") || Caller->HasName("05_63_01"))
					return true;
				else
					return false;
			}
		}
		Vehicle v(Caller);
		PersonList l = v.GetPassengers();
		if (l.GetNumPersons() == 0)
			return false;
		if (Caller->HasCommand(DUMMY_HOSESON))
			return false;


		return true;
	}
}

Bei der von @xKnolle gezeigten Variante wird der Sound überall auf der Map zu hören sein.
Wenn du möchtest, dass der Gong nur am alarmierten Fahrzeug hörbar ist, musst du

Audio::PlaySample3D("mod:Audio/FX/PfadZu/AlarmSound.wav", v.GetPosition(), false);

benutzen.

Stell doch auch mal das Logfile aus dem EM4 Hauptverzeichnis hier rein, dann sehen wir vielleicht den Grund des Absturzes

Quote from Firefigter

?ERROR: dynlight.vsf Version 3.0.0.0 or higher required!

Das ist nicht das Problem, diese Meldung kann ignoriert werden, müsste bei jedem Spieler erscheinen.

Was das eigentliche Problem ist:
?VVideoTexture::InitTextureRenderer(): could not find output pin [80040216]

Eventuell wurden zwischenzeitlich Windows Updates installiert, Microsoft hat was das Ausliefern von (fehlerhaften) Updates anbelangt mit Windows 10 ja ordentlich zugelegt... Schau mal ob dir dieses Codec Pack hilft.

@Tommi_wr Installier mal von hier den neuesten Grafiktreiber, vielleicht lässt sich das Problem dadurch beheben.
Ansonsten sind die AMD-Nutzer mal gefragt, ob das vielleicht von einer falschen Einstellung kommen kann.

Zu 1) Ich denke, das werden Sekunden sein. Allerdings verstehe ich deine Frage nicht so ganz, denn es war doch deine Absicht, das Einsatzaufkommen zu verringern, und das erreichst du eben über eine längere Wartezeit zwischen der Erzeugung der Einsätze :hmm:
Zu 2) Da gibt es tatsächlich keinen anderen Weg.

Interessantes Fahrgestell für einen ELW!
Die spiegelverkehrte kleine Klappe auf der Beifahrerseite ist euch bestimmt bekannt :search: Ansonsten ein guter Skin!

@Tommi_wr Welche Grafikkarte bzw. welchen Grafikchip hast du denn? Ich vermute eher, dass es von einem Problem damit kommt.
Drück mal "Windows-Taste + R" (gleichzeitig), gib dxdiag ein und mach mal einen Screenshot vom Reiter "Anzeige".

Zu 1) Vielleicht über <MinDurationBetweenEvents value="90.0"/>? So würde ich das jedenfalls verstehen.
Zu 2) Über die Materials.xml, ich glaube aber darüber kann man eine Doktor-Arbeit schreiben.