The Loot

It's an option in the em4.cfg file, "e4_doocclusion". Changing the value to 0 will disable that effect.

A quick and dirty way could involve a small edit to the EmptyCar script by adding these two lines: v.EnableSpecialLights(true); v.EnableBlueLights(false);

It's an option in the em4.cfg file, "e4_doocclusion", I think. Change that to value to "1" and that should happen.

Those open-top engines make this mod very unique; unexpected amount of variations, too. While I'm at it, one nice detail change would be a more appropriate station alarm sound. I know that one of the past LA submods had a fire bell noise that would work.

Did you delete the original object? The missing commands (assuming that's the issue) were assigned to that object in the map editor; I avoid that by adding all the assigned commands to the objects in the spawn script. Speaking of, there is a name that the freeplay startup script checks objects for to run the spawn script on it/them.

It would be interesting to see a script that gives helicopters the Fire Plane function.

OpenHouses can be weird. Most likely, the person didn't actually enter the house, but managed to get inside the space. Since they aren't "in" the house, they can't exit it properly.

Yeah, I see how that's set up, so I'm not sure how it happened. Testing again, it seems to be the vehicle being parked in front of the station ignores the prototype check, as it and the SWAT truck are ignored if parked in the lot (at least the two starting spots).

One little thing I ran into checking things out: the Bomb Squad SUV can be called by the Patrol Car command, which I think had gone back to the front of the station and that may have caused it.

I noticed that engine seem to have more limited hose connections, is that intended?

itchboy actually figured out how to fix it a while back, and looks like the patrol script in this mod includes it.

You'd have to post the script file for someone to look at.

The entercar script contains conditions that allow or disallow certain types of persons (or those with certain commands assigned) entering certain types of vehicles.

I believe @itchboycame up with a method to try. Use this line in the patrol script commands: v.SetTerrain(TERRAIN_TRAFFIC); I have it before this line PathList p1l("patrolpath01"); And then in the DummyPatrol command, add this line to revert when cancelling the command. v.SetTerrain(TERRAIN_CAR); Never tested it myself, just added it to the files (haven't launched this game in years).

Not sure if you can really change anything related to that function.

Easily done by added a wait pushaction to the vehicle between hiding it at the spawnpoint and then unhiding it and making it move. I'd be surprised it that hadn't been implemented already.

You also have to have the tiller check command run at startup of the map.

From what I remember, this sounds like you've exceeded the limit of how many equipment group commands a person prototype can have. You'll either have to remove some commands, or change some of the equipment commands and comment out the "SetGroupID(CGROUP_GETEQUIPMENT);" line. This will make them show up on the main command list, but be aware of the command limit on that, as well.

Perhaps checking for a vehicle colliding with the VO before changing them to barriers, with a short delay and repeat if there's a vehicle there? If you hadn't already thought of that.

itchboy recently figured out a pretty simple fix to make patrolling vehicles respect traffic lights, which is what always caused them to get stuck.

LAFireStation contains the station Alarm command.

I found that the simplest way to do it was to make dummy commands and assign them to any applicable vehicle, which the equipment script would then check for. object FlagHasBarricade : CommandScript { FlagHasBarricade() { SetGroupID(20); } bool CheckGroupVisibility(GameObject *Caller) { return false; } bool CheckPossible(GameObject *Caller) { return false; } bool CheckTarget(GameObject *Caller, Actor *Target, int childID) { return false; } void PushActions(GameObject *Caller, Actor *Target, int childID) { } }; And then in the script CheckTarget section, just add this: if (!Target->HasCommand("FlagHasBarricade")) return false; It makes it very simple to add new vehicles later: just add the dummy command and they're all set.

Alright, finally got it working. The caller creates a copy of themselves at the command position, it gets hidden (normal method caused an issue with getting a final vector, changing model to an invisible one works), find it with another caller command, make it execute the final command at its position, and then delete itself. I was going to just use an empty object prototype, but the prototype of the caller is essential to the functioning of the scripts.

I suppose it's the method that complicates using a vector in this case, but I've seen them used in seemingly similar ways elsewhere. That mod seems to have some gameplay elements I've gone for myself, so I'll probably check it out in general now.

Basically, I'm trying to add a delay when I use a modified LA Call Vehicle Command, so that there's a wait period during the radio audio, and a vehicle behind chosen and taking actions itself. Vector CmdPos = Game::GetCommandPos(); is outside of Child sections at the top of the script. Under ChildID 0, I have tried both of these commands: Caller->PushActionExecuteCommand(ACTION_APPEND, "PcmdCallALSAmb", CmdPos, 1, false); - It throws this error log: Caller->PushActionExecuteCommand(ACTION_APPEND, "PcmdCallALSAmb", CmdPos.Target, 1, false); - Saw something like that in the Move command, but it throws this much smaller error log: ChildID 1 contains the actual bulk of the script. Is this even possible?