General Zaroff
-
Posts
48 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Articles
Posts posted by 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!
-
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!
-
-
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
- Schalldampfer and totis
-
2
-
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.
-
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
-
Yeah, I know. Gonna try the rSay/sleep loop and see how bad it is.
Thanks,
- ep
-
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....
-
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.
-
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
-
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
- looter809, juandayz and Schalldampfer
-
3
-
I'm trying to build hangar doors of arbitrary size. To do that I need to overload data into existing data base fields.
Using setVariable from the client doesn't cause an update of the object to the hive, even if the third argument that the BI scripting wiki says makes the change "persistent and global" is set to true.
Next step was to try calling setVariable from the server, triggered by a client publishing a public variable to the server and the server calling setVariable in the event handler. I know the event handler is firing successfully, but that setVariable doesn't result in a hive update, either. I didn't think it would but I had to try the simple stuff first.
Next step is to call server_hiveWrite from within my new event handler, OR to update server_updateObject with a new case option. However, either of those approaches requires a detailed understanding of the key formatting system feeding server_hiveWrite.
The server_hiveWrite routine just rearranges data and calls a core routine called callExtension, to which I have no access, so I can't figure out the key formatting. Going through all the various update and publish routines, I've compiled this list of key formats into pseudocode -- pay no attention to typing issues in the key please, and I can only conclude that callExtension parses the key string into MySQL syntax.
UPDATE CALLS
_key = CHILD:303:_objectID:_inventory:_coins:
_key = CHILD:303:_objectID:_variables:_coins:_key = CHILD:305:_objectID:_worldspace:_fuel:
_key = CHILD:306:_objectID:_hitpoints:_damage:
_key = CHILD:306:_objectID:_hitpoints:_damage:
_key = CHILD:306:_objectID:_hitpoints:1:
_key = CHILD:306:_objectID:_hitpoints:0:
CREATE/PUBLISH CALLS_key = CHILD:308:dayZ_instance:_type:0:_characterID:_worldspace:_inventory:[]:0:_objectUID:
from server_publishvehicle.sqf:
_key = CHILD:308:dayZ_instance:_class:_damage:_characterID:_worldspace:[]:_array:_fuel:_uid:
from server_publishvehicle2.sqf:
_key = CHILD:308:dayZ_instance:_class:0:_characterID:_worldspace:[]:[]:1:_uid:
from server_publishvehicle3.sqf:
_key = CHILD:308:dayZ_instance:_class:0:_characterID:_worldspace:[]:[]:1:_uid:
FETCH CALLS
_key = CHILD:388:_uid:
I don't think there's enough information here to figure out the CHILD:3xx formatting. It doesn't appear to have any relationship to MySQL syntax, and attempts to treat the third digit as a bitmask that might map to column indices fail. That was just a guess but the only thing I'd even begun to think might be close to what's happening.
Am I missing something? I can't find any example of any code that requires any db access that's not supported in the above ( which I suppose is an obvious statement). Is it possible to pass MySQL syntax to the db interface from the server?
Is access to other fields -- say, for example, the CharacterID field -- even supported through that CHILD:3xx formatting string?
Hmmm. Maybe I can use the example of the existing :inventory:coins: update sequence, since the modular construction objects I plan to employ are irrelevant to either the door management or plot management systems, which overload the unused inventory field....
Any comments at all? Doesn't look like too many folks spent much time in here any more.
-
That's what I thought -- the AI no patrol/random firing fix is pending in 1.0.6.1. Thought you were saying it was fixed elsewise. My confusion. Apologies.
-
But unlocking the vehicles doesn't fix the issue. They still don't patrol. They still fire randomly at hillsides or into the air....?
-
Ah. The last I looked into the binaries years ago decompiling them was strictly off limits. Live and learn. That's not in the Bi Tools set... it's somewhere else. I found an old post for something called Kegety's Tools, but it's a bad link. But... looks like it's all moot below.
-
OK, there is no addons\dayz_code\config.cpp . I did find one config.cpp, in addons\dayz\config.cpp, but it does not contain the line you reference. It contains a class NoVoice block which includes the statement protocol = "RadioProtocolBase"; , but that's the only reference to any statement containing the string "radio".
Searching for the include statement #include "Configs\RadioProtocol.hpp" .... Hey, that include couldn't be in the binary, could it?
-
Doing this now. Results in a bit.
-
ebaydayz,
Thanks for these posts. I hadn't seen the other discussion, and that's not for lack of trying to find anything else. If there are any suggested tests pending upon my return home in a few hours, I shall implement and report.
Many thanks.
-
Correct. DZAI provides patrols by foot, by air, and by surface vehicle, but no missions. Christmas, you need to study the contents of your init files, look at the examples, etc.
I'm getting surface vehicles stuck whether they're configured for map-wide random or for marker spawns. The marker based custom spawns appear to wake up more easily, and shoot at things. Sometimes they just sit there and shoot into the air forever...
No one has any ideas about this? Anyone see any Epoch 1.0.6 servers with normally moving bandit surface vics chasing waypoints and shooting at players??
-
Well. Guess it's not something I did then. So far I've only installed a derivative of DZAI into Epoch Napf 1.0.6. Still have DZMS and WAI to integrate. As noted, the surface vehicle patrols just sit there. If you take a pot shot at them they might wake up, but they don't fight back effectively. And..... the vehicle with which they spawn sometimes has no relationship to the list of surface patrol vehicles.
FWIW, some of the chopper patrols seem to be stuck, too.
Is the HQ/Side/Center system changed for 1.0.6? Or something in a vehicle superclass or something?
-
I just had a thought. There are limitations to the number of groups that can be assigned to each side HQ. I remember reading somewhere that the limit was a little fuzzy, for whatever reasons. Since the issues seem to pop up for folks who are running WAI -- and absolutely not just for servers running DZMS and WAI together -- and since issues seem to manifest most reliably with game agents, who must have unique relationships back to side controllers and whatever data structures manage them, it's beginning to look to me like something happens to system data integrity when WAI invokes the hostility relationships for side RESISTANCE. I can't see that WAI actually uses a RESISTANCE group anywhere, at least not the way I have it configured. I think I'm going to comment out those relationships and see what happens...
-
The download link to WickedAI?
https://github.com/f3cuk/WICKED-AI
I've been working a lot with the WAI mission system recently. I've shut down my Cherno Epoch server to concentrate on Epoch Napf, since I never liked the artificial map edge and I really like the variability of the Napf terrain.
As KAIWIOS noted above, the problem lies in WAI's use of the side and side hostility assignment system. I suspect it has to do with WAI's use of RESISTANCE HQ and side, but that's just a guess.
I posted a fix for the broken traders in Epoch Napf here:
It relies on actual humanity value checks and geographic locations to determine whether or not the player should interact with the trader, and the first time I installed it, traders started to work perfectly.
Then I started to expand the WAI mission system, I made massive changes to the WAI configuration data and added a large number of missions. After I added a particularly large batch of new and revised code, I fired up the server to play, grabbed one of our loot trucks, and trundled on over to Emmen.
And the traders were broken.
I went admin and popped over to Lenzburg, Schratten, and SWAF, and I discovered that, as it had been prior to installing my 'fix', traders at each location had a distinct failure pattern. As before, both Hero and Bandit traders were broken. The pattern I had noted previously, however -- some traders worked at Lenzburg, none at Emmen, all at Schratten -- no longer prevailed! That set of symptoms -- which I was able to experience in precisely the same details on two other Epoch Napf WAI-equipped servers before I installed WAI on my own server -- had changed!!!
Now, only a single trader, the medical guy, functioned at Lenzburg. Medical and clothing traders worked at Emmen. And the tool/construction and ammo guys weren't working at Schratten.
I immediately uncommented the diagnostic lines and delays in my fnSelfActions.sqf file I'd used to verify that the trader interaction code wasn't even being executed originally -- only delays and print statements -- placed the revised file in the server's ftp area, and restarted.
Not only did I get the diagnostic statements on-screen, but traders functioned perfectly. Remember now -- adding stuff to the WAI missions system is entirely server side, and revision fnSelfActions.sqf is entirely client side.
Uh huh. Ok.
So I and some buds played for a few days, and last night I installed another big batch of new missions and WAI config extensions. Again, nothing but server side changes!
Restarted, went about my business, and when I went to the traders ... broken again, still in the second pattern.
I uncommented out the diagnostic lines in fnSelfActions.sqf, restarted, and the diagnostic messages and traders worked perfectly again!
Commented out the diagnostic code, restarted, and traders are still working fine.
So... not only is the broken trader issue -- and I'll bet other glitches -- somehow related to the WAI's use of the side and hostility system, but also for some inexplicable reason to the "recentness" of the last update! It makes no sense whatsoever. But at least on my Epoch Napf server, completely repeatable.
-
I've decided to close down my Cherno Epoch server this month to concentrate on mods for Napf. Accordingly, I don't want my mods to be lost forever. I'd like to share everything I'm not going to use any more.
This is the construction mods only -- the buildings, roads, and supporting loot table mods.
Let's start with just the buildings and roads:
http://eric-peterson.org/dztools/ConstructionExtensions.zip
- An industrial annex east of Electro, self-explanatory. Nice spot for fresh spawns to loot and build a kit.
- Ghost Town 2.0, a heavily bombed-out community on the main road SE corner of the map, west of Kamenka, with quite a few oddball props and geometry loads. Shipwrecks. Mass graves.
Peasants hanging from rafters in a bombed-out church. Other stuff. I used this in conjunction with a collection of localized detection zones and halloweeny sound track oggs to creep
out new players, who frequently spawn in this area.- Hill Road, a paved spur off the main north-south road along the west side of the map that runs up to one of the nice, flat-topped hills in that area, near the upper NW corner.
Intended to build a base or other stuff up there, but never got around to it.- NCRV2, "North Central Research Village" version 2.0, a large, complex city and military industrial center located in one of the broad flat valleys, top center of the map, near the
edge. NCRV2 is designed as a combat venue, with tons of loot and tons of places to hide. There is a complex road system, a separate hilltop residential area, outlying farms,
barracks, and tons of places to climb to get the drop on bandits. There is no road system connection to the rest of the map. You fly in or drive overland through the woods. I loaded up the region around UMB with DZAI patrols and choppers and worked the roof of the Biotech building with buddies, defending it against more or less continuous onslaughts...- NEAF Details 1 and 2, debris, dead vehicles, additional buildings, wrecks, assorted stuff strewn about the airstrip. Parts of these two files might be based on the work of others.
I honestly can't remember. It's been a long time since I was up there.- Special Forces Training Base ( SFTB ), an entirely new complex airport and military community with barracks, residential, and industrial areas located SW of the main NWAF. Employs
quite a few buildings from other expansions, so make sure you use my custom building loot files too. Tied via roads to existing roads in the region, east to NWAF and west to Lopatino.- Unidentified Military Base, "UMB" version 2.0. This is a very loot-rich military industrial complex in one of the hidden valleys in the far NW corner of the map. Includes access
roads connecting it to the main road. Includes outlying derelict industrial area, rarely used Euro building models, and tons of military stuff. On my Cherno server zeds are faster,
tougher, and hit harder the further you go north and west, so by the time players get to UMB zeds are outrunning sprints easily and pretty much killing with one hit. Additionally, my
custom loot extensions place relatively high zed spawn rates on some of these dredged-up models, so the place is absolutely deadly, zed-wise. When used in conjunction with extra-
difficult zeds and no AI, this mod offers an oddly relaxing, super intensive zombie combat experience....- A collection of water wells spread over the map, used in conjunction with a canteen water filling mod which isn't likely necessary in later versions of Cherno or Cherno Epoch.
- West Pavlovo and the Unauthorized Settlement. This is a large, complex, sprawling development with kilometers of new roads, one small city, one town, and numerous outlying farm and
industrial installations. A new major road intersects the main n-s road west side south of Pavlovo and runs northwest into a new city using a number of rarely used models. A separate
dirt road intersects this road just south of West Pavlovo and heads into Pavlovo proper, intersecting some dirt roads on the west side. Other roads leave West Pavlovo to its SW and
NW, the SW road heading out to some chalets and infrastructure sets, and the NW road heading through the hills and forest into the Unauthorized Settlement. The settlement is a small
rural farming village overrun by a shanty town and some tenements. From the settlement, a road splits off into the woods, west, and leads to some small shacks. Another heads up and
east to some new farms and eventually the main road between Pavlovo and Zelenogorsk. The main road that starts in West Pavlovo and leads all the way through Settlement heads through
a pass, winds through some hills, and eventually intersects some farm roads west of Zelenogorsk. West Pavlovo was designed as a single combat area and I generally placed a single
very high skill AI assassin there. It made for interesting gameplay. Settlement is a nice looting area for middling-newbies who have moved away from the coast. Again, it will all //be a boring place without my building loot extensions.I've posted this stuff previously, but here are old links:
The large floating ocean city of Jotunheim, off the SE coast:http://eric-peterson.org/dztools/City_of_Jotunheim.zip
Here's the building loot extensions -- tested loot drop locations for just about every building in every module. Need a custom loot table system, of course, documented elsewhere by
others:http://eric-peterson.org/dztools/ExpandedBuildingLoot.zip
Finally, you'll need this in your mission.sqm file. Should load all of the above without that blasted deleted content message on startup:
addOns[]=
{
"chernarus",
"ca_modules_animals",
"dayz_anim",
"dayz_code",
"dayz_communityassets",
"dayz_weapons",
"dayz_equip",
"dayz_epoch",
"dayz_vehicles",
"cacharacters_pmc",
"ca_modules_functions",
"glt_m300t",
"pook_h13",
"csj_gyroac",
"map_eu",
"jetskiyanahuiaddon",
"warehouse",
"mbg_killhouses",
"mbg_buildings_3",
"mbg_african_buildings",
"mbg_buildings_2",
"glt_bh_wreck",
"aif_arma1buildings"
};
-
When using Wicked AI missions on Napf, the two "patrol" missions have hardwired Cherno coordinates -- and text, for that matter, but that's easy to fix. Here is revised code that goes in to two "patrol" missions. You need to change the radius of the mission location detection code, too, as well as the blacklist markers in the initialization data, but that's trivial.
_pos_location = [
[ "Bubendorf" , [ 3860 , 14270 , 0 ] ] ,
[ "Hubel" , [ 920 , 10830 , 0 ] ] ,
[ "Hindelbank" , [ 2540 , 11330 , 0 ] ] ,
[ "Ittingen" , [ 2230 , 10210 , 0 ] ] ,
[ "Worb" , [ 2350 , 7680 , 0 ] ] ,
[ "Homburg" , [ 2740 , 6240 , 0 ] ] ,
[ "SW Airbase" , [ 4960 , 4840 , 0 ] ] ,
[ "Waldegg" , [ 8530 , 1280 , 0 ] ] ,
[ "Brienz" , [ 14520 , 3230 , 0 ] ] ,
[ "SE Airbase" , [ 18220 , 2500 , 0 ] ] ,
[ "Froburg" , [ 17260 , 3710 , 0 ] ] ,
[ "Giswil" , [ 16750 , 5350 , 0 ] ] ,
[ "Sorenburg" , [ 13560 , 5500 , 0 ] ] ,
[ "Farnen" , [ 13180 , 7110 , 0 ] ] ,
[ "Schangen" , [ 8930 , 5741 , 0 ] ] ,
[ "Buckten" , [ 5500 , 5940 , 0 ] ] ,
[ "Munsingen" , [ 3970 , 8090 , 0 ] ] ,
[ "Hasle" , [ 3550 , 10120 , 0 ] ] ,
[ "Unterdorf" , [ 5080 , 11230 , 0 ] ] ,
[ "Muttenz" , [ 6300 , 10220 , 0 ] ] ,
[ "Muenchenstein" , [ 6160 , 9930 , 0 ] ] ,
[ "Chatzbach" , [ 7480 , 9510 , 0 ] ] ,
[ "Signau" , [ 5990 , 8870 , 0 ] ] ,
[ "Eggwil" , [ 7370 , 6800 , 0 ] ] ,
[ "Milan" , [ 9980 , 8010 , 0 ] ] ,
[ "Sissach" , [ 11370 , 8910 , 0 ] ] ,
[ "Bruderholz" , [ 9850 , 10130 , 0 ] ] ,
[ "Agerifeld" , [ 8730 , 11320 , 0 ] ] ,
[ "Oberdorf" , [ 5750 , 12040 , 0 ] ] ,
[ "Huttwil" , [ 4630 , 12520 , 0 ] ] ,
[ "Seltisberg" , [ 5950 , 15270 , 0 ] ] ,
[ "Neue Welt" , [ 5670 , 13940 , 0 ] ] ,
[ "Trueb" , [ 7640 , 14300 , 0 ] ] ,
[ "Truebsall" , [ 8450 , 14620 , 0 ] ] ,
[ "Seewen" , [ 6530 , 16760 , 0 ] ] ,
[ "Lenzburg" , [ 9170 , 16300 , 0 ] ] ,
[ "Freidorf" , [ 8390 , 17440 , 0 ] ] ,
[ "Hasenmatt" , [ 11080 , 18460 , 0 ] ] ,
[ "Magden" , [ 10470 , 17180 , 0 ] ] ,
[ "Olten" , [ 9870 , 16770 , 0 ] ] ,
[ "Ruemlingen" , [ 10610 , 16120 , 0 ] ] ,
[ "Hirsegg" , [ 10360 , 14350 , 0 ] ] ,
[ "Napf" , [ 10830 , 11920 , 0 ] ] ,
[ "Liestal" , [ 12560 , 9930 , 0 ] ] ,
[ "Alpnach" , [ 18410 , 9540 , 0 ] ] ,
[ "Sachseln" , [ 14610 , 11090 , 0 ] ] ,
[ "Romoos" , [ 12680 , 11790 , 0 ] ] ,
[ "Lausen" , [ 12090 , 15230 , 0 ] ] ,
[ "Luzern" , [ 14940 , 14120 , 0 ] ] ,
[ "Wolhusen" , [ 14240 , 12980 , 0 ] ] ,
[ "Emmen" , [ 15120 , 13440 , 0 ] ] ,
[ "Horw" , [ 16860 , 14200 , 0 ] ] ,
[ "Meggen" , [ 16080 , 15430 , 0 ] ] ,
[ "NE Airport" , [ 14660 , 16790 , 0 ] ] ,
[ "Suhrenfeld" , [ 16400 , 18550 , 0 ] ] ,
[ "Pfeffiken" , [ 18260 , 17200 , 0 ] ]
];
Hangar Doors of Arbitrary SIze -- Mission Download Only -- System Complete!
in A2: Epoch Mods
Posted
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