Hangar Doors of Arbitrary SIze -- Mission Download Only -- System Complete!

[General Zaroff]

I have built a system that allows the player to convert metal floor plates into horizontal hangar doors. The size of the finished hangar door is not constrained. The features are these:

Converts any number of metal floor plates into horizontal hangar doors, in any shape or style. The player assigns door data in a CLOSED state. Thereafter the doors can be opened or closed.

There are ten DOOR GROUP IDs available. Odd Groups open along a principle axis of the first plate in the group most closely aligned with the player's LEFT at the time the plate is added to a door group. Even groups open RIGHT.  Finished doors may be opened along or in opposed pairs of adjacent groups 1,2 .....3.4 .... etc.  There's no specific requirement for opposed pairs to actually open over the same cavity... but if you want double doors, that's what they're for.

Distance of the door assembly's opening is automatically configured based on the total width and placement of all plates in a group as calculated along the direction in which the door assembly opens. Opening speed is configured in a setup data script.

Setup is persistent across restarts. The system uses inventory data to store basic setup data. Upon the first demand for a hangar door OPEN, the system calculates all required setup data needed for operation. Any time a plate is added to a group, removed from a group, or deleted, the setup data is invalidated. The determination of setup data doesn't take but a second or two, so you can modify and test the door configuration easily and interactively.

Hangar doors assume a requirement for the first key in the inventory of the player at the time the first metal plate is added to a group. It is only possible to add plates, delete plates, clear plates, or open and close doors if that key is still in the player's possession.

A player can only convert plates to doors from plates the player crafted.

There is a significant mission file hit on the client side. There's lots of code. There is a server component including some public variable handlers to manage data base IO. No separate download and install is required of the player.

If the server crashes while the doors are operating or open, the doors are closed on restart.

Sound effects are supported.

Here's a file showing a pair of doors operating. The left door is an arbitrary collection of four plates and has to move further than the right door because it's wider, so takes a bit longer to open or close. I open the left door, close it, and then open both doors and close them together.

http://www.ericpeterson.info/dztools/P1010579.MOV

I have three sets of changes I want to make before I release it to the community. 

First, I'm going to add a material component to the crafting conversion -- an engine, a tire, a scrap metal for the first plate in a  door group.. scrap and tire for subsequent plates added to a group. Second, I'm trying to trigger a clanging sound when the doors are closed together, but the sound handle code as provided under playSound in the BI Scripting wiki that describes how to terminate a sound after a specified time uses A3 code, and I don't seem to be getting a good sound delete/terminate when I delete the handle, which is what I need to do to play a second sound a single time instead of the machine noise in a loop  Third, the first time i open and close the doors based on new metal plates just crafted I get fantastic animation at the coded speed, about 30 fps. The motion is nice and smooth. After a restart I get motion as you see in the video. Actual update to the visible object db isn't nearly as fast as the rate at which the routine that does the setPos runs. The video was recorded immediately after server startup and join -- as you can see the rules.sqf -based feature intro is still running. I believe this happens because, when the server is still running the session during which the plates are crafted the player's client owns them.  For subsequent sessions I assume the server owns them. I'm trying to find a command that will let me figure out in the server side which client is invoking the handler... but I haven't found it yet.  This is purely a cosmetic issue. Based on the message traffic over the last few years it looks like ANY doors big enough to actually secure choppers have been a community wish for a long, long time.

There's no reason this couldn't be extended to vertical doors built from, say, block walls.  The move routine that actually iterates the opening and closing would have to understand rotation of an object in 3-space about a specific axis rather than simply sliding bits along, but most of my support code is written with this goal in mind. An object type is almost always an argument, where necessary, allowing the same infrastructure to be extended to vertical doors of arbitrary size.

Comments? Wants? Feedback?

- ep

 

 

[salival]

That's a really cool idea!

[General Zaroff]

Thanks!

Just to clarify I'm specifically looking for experience that can answer these two questions so I can wrap it up:

First, neither of these code snippets from the wiki:

playSound "AlarmCar";

[] spawn { _sound = ASLToAGL [0,0,0] nearestObject "#soundonvehicle"; sleep 1.2; deleteVehicle _sound; };

 

playSound "Alarm";

hint "Started!";

[] spawn { _sound = ASLToAGL [0,0,0] nearestObject "#soundonvehicle"; waitUntil {isNull _sound}; hint "Finished!"; };

 

...  function properly in A2. ASLToAGL maybe has a different syntax?

 

Second, I need to figure out how either a client can get its own clientID or how a server can get the clientID of a particular client. I'm probably being stupid and just missed it....

I see:

_clientID = owner _someobject;

.. and it's A2, but it only returns a valid ID if the object is already local to a particular client, but that's what I'm trying to cause when the object isn't local to any client. Ultimately I want to send ownership to the client on which the player is manipulating the doors so at least he sees smoother animation... of course I'm assuming the procedural animation using setPosASL is time-aliased because the client doesn't have ownership of the metal door plates subsequent to a restart after the session in which they were crafted.

I see:

_id = clientOwner;

... but that's A3. 

 

Both of these are just persnickety details to clean up sound effects and visuals, but I'd like the system to do precisely what I intended before opening it up.

- ep

[seelenapparat]

from which side do you need to play the sound?

client or serverside?

there is the RemoteExec function in arma for stuff like this.

 

1. an example for a serverside sound:

{
	if (isPlayer _x AND (_x distance _Zed) < 50) then {
		[_Zed,_x,"loc",rSAY,"electric"] call RE;
	};
} foreach playableUnits;

where _x is the player. which you get serverside via playableUnits function.

or, of course, via the invoked public variable event handler. (which must include the player)

_Zed is the zombie in this example.

 

2. clientside it works like this:

_nul = [objNull, player, rSAY, "convert_ammo"] call RE;  

(where convert_ammo is the soundname)

 

3. In epoch most client IDs get sent via the appropriate public variable event handler (check this file for reference: publicEH)

for example in a PVEH you sent the reference to the player to the server:

PVDZ_obj_Delete = [_plant,player];
publicVariableServer "PVDZ_obj_Delete";

serverside you just need to use:

_clientID = owner _player;

send to client like this:

PVCDZ_plr_Login = [_charID,_inventory,_backpack,_survival,_isNew,dayz_versionNo,_model,_isHiveOk,_newPlayer,_isInfected,_group,_CharacterCoins,_playerCoins,_BankCoins];
(owner _playerObj) publicVariableClient "PVCDZ_plr_Login";

 

done. does this help?

[General Zaroff]

Thanks for the feedback. As for the sound, it would probably be more useful if I actually showed you what I was trying to do.

When the doors open ( or close ) I initialize script handles to the running door actuation routines and then fire off an instance of the sound routine. When the open/close routines is called, I don't have any information locally about how long the open/close will take, so I simply set a bool high until both script handles show scriptdone. Below is the sound routine.

 

//
// execVM "HDAS_Client\PlayDoorSounds.sqf";
//

private [ "_sound" ];

// the duration of the sound bite
fNoiseTime = gblfDoorCloseNoiseDuration;

// initialize a timer flag
bTimerOut = false;

// do a loop as long as the flag is high
while { gblbDoorSoundRunning } do {

    // play the sound
    playSound "oggVMCEngine";

    // get a handle to the sound
    _sound = [ 0 , 0 , 0 ] nearestObject "#soundonvehicle";

    // re-init the timer flag
    bTimerOut = false;

    // spawn a timer
    [] spawn { sleep fNoiseTime; bTimerOut = true;};

    // now what we need to do is play for the length of the sound OR until gblbDoorSoundRunning is false....
    waitUntil { sleep 0.05; bTimerOut || ( !gblbDoorSoundRunning ) }; 

    // if we get to here, either the timer has run out OR the flag has dropped to false
    // if the timer has dropped to false, we need to kill the sound
    if ( !gblbDoorSoundRunning ) then {
        deleteVehicle _sound;
    };
};

// we're done here

 

The spawned timer is working just fine. The bool set from the calling routine dropping when the door scripts wrap up is working just fine. I know precisely WHEN to terminate the sound and I can always key some code to execute at that moment. What's not working is this:

    if ( !gblbDoorSoundRunning ) then {
        deleteVehicle _sound;

I presume it's not working because the sample in the wiki is setting the _sound handle using 

   _sound = [ 0 , 0 , 0 ] nearestObject "#soundonvehicle";

instead of 

   _sound = ASLToAGL [ 0 , 0 , 0 ] nearestObject "#soundonvehicle";

 

I could rewrite my code to predefine the total time required to play the machine noise representing the sliding doors, but I'd still need to terminate that sound at the moment the doors close. The samples in the wiki that show how to interrupt playback both rely on the same _sound handle definition that uses A3 code. And that's the key. I need to interrupt playback. 

Thanks for the remote exec examples. I hadn't thought of the issue that the doors will only make noise on the activating player's client. Ultimately I'd like to spread that noise around to the other players. The question remains.... how do I interrupt a playback?

I suppose I could use a very short ogg file and loop through it just enough times to barely cover the motion..... simpler.... hmmmm. I might try that. It would be easy enough to build another server event to cause other clients to run the ogg a specified number of times. I should have thought of that before.  Conceptually simpler.

 

 

As for the client ID issue, I hadn't thought of using  _id = owner player.  Of course the client is always the owner of that client's player object! Like I said, a stupid oversight. Thank you.

 

 

[General Zaroff]

Ah. I hadn't known playSound was single player only. Or rather, only caused playback on the executing client in MP. Just never thought about it. Thanks for that. Modifying code. Let's see if just running through the RE call to rSay a fixed number of times with a delay works....

[seelenapparat]

just in short:

loops dont work very good in arma.

thats why there is a preconfigured way to do loops (createsoundsource; which is a subconfig of cfgvehicles -> needs a custom .pbo to work).

check the generator running in epoch script for reference. loops are a pain in the ass otherwise.

just play a sound, set a sleep on it wich is same lenght as the sound and repeat. but expect clientside differences in how the sound is actually percieved by each client (pauses etc.)

[General Zaroff]

Yeah, I know. Gonna try the rSay/sleep loop and see how bad it is.

Thanks,

- ep

[General Zaroff]

I have integrated crafting materials requirements. The first door of any group requires scrap, tire, and engine, and subsequent panels require scrap and a tire. 

I have changed the sound over from the nonfunctional handle-based terminate to a loop of predefined duration, simply repeating a short effect, using rSay instead of playSound. 

I have added a server side public event handler that transfers ownership of the doors to whoever is trying to open them. The resulting procedural animation on the primary client is, as I presumed, dramatically improved.

I've added a CLANG that sounds nearly upon close complete.

I have added a system that allows one player with the correct key to open the door, while another player with a correct key can close it. That was not previously possible.

Thank you very much seelenapparat. You allowed me to improve this considerably. I just need to test the crafting part and the multiple-player setup and then I'll post it with instructions and an installation guide.

New video ...

http://www.ericpeterson.info/dztools/P1010580.MOV

- ep

[kingpapawawa]

@General Zaroff I for one would love to see more of this.  I have a test server and willing to help in any way a non coder can =)

[General Zaroff]

Thanks for the support! Finishing off the downloadable package and installation instructions -- it's damnably pervasive on the client side, with tendrils that need to reach into a dozen different subsystems -- is actually on my short list for this week. I've been slammed with work and other projects, but haven't forgotten. I hope to have it posted by the end of this week.

 

[General Zaroff]

My apologies for the delay. I have integrated the system with 1.0.6.2 and have updated the code and installation instructions. The use instructions are online, hosted on one of my sites for easy access. After some testing I will be ready for release.

 

- ep

[Krussedull]

are this readY ? =) 

 

[Krussedull]

we can test this out on our server for you and help you whit the prossess ?

[General Zaroff]

I am in final testing! My 1.0.6.2 server is running. My documentation is complete. My use instructions are posted on my website. I hope to complete testing this weekend!

Sorry for the delays!

 

[Tanita-Corp]

whats news?

[General Zaroff]

Sorry. Slammed at work. Multiple family health emergencies. Had to travel. AND I'm stuck debugging the 1.0.6.2 server. Got a Waiting for Server bug I haven't seen in a while... a syntax error in a precompiled library somewhere. Working on it. Haven't forgotten. Haven't given up!

 

 

[Tanita-Corp]

Families First
 

[General Zaroff]

Hey folks -- 

Sorry I haven't been on this. Have received messages and do not mean to be ignoring same. Had some health issues. Working thru them. Attended the funeral of an old friend north of San Francisco a couple weeks back, too -- a famous game developer, Martin Cameron, one of the very first employees of LucasArts and the creator of the TIE Defender, among other things. Then had a family funeral last week in Boston. Back on this now. Had a bad 1.0.6.2 client install that wasn't showing in Steam library file verify, for some reason, and then a nasty, crafty little bug in the client init code. HDAS is pretty invasive and slowed down some config installation routines to the point that some of the core compiles weren't getting done in time! Added some flags and waitUntils in the core compile inits -- will document that when I upload. 

Running a clean 1.0.6.2 client download and install now. The only errors I'm seeing seem to be due to leftover 1.0.6.1 library code client-side. As soon as my install runs I should be able to get back to final debug, provided the thunderstorms don't shut down my power!

Apologies for the delays!

[Tanita-Corp]

we wait y)

[General Zaroff]

I've got a clean startup and client join, error-free, and I'm back to testing, but this time under 1.0.6.2! I'll be pulling the password off the server that supports hangar doors now and posting the files as soon as I run some tests.

Here's are the INSTRUCTIONS for USING the hangar door system. I've got some cleanup and completion to do on the install instructions. I'd appreciate any feedback so I can clear up any use confusion before I go live with the server open and the downloads:

http://ericpeterson.info/doors.txt