What are these? [image of a map]

[mrmidi]

Sorry I got called out on an emergency.

I miss spoke above in the sentence "Then in the tower you will only see 3 air spawns and the "H" hanger spawn." it should read Then in the tower you will see 3 spawns The "H" spawn is also
an air spawn.

The reason for adding the air spawns to a Vbase is because on an air field such as the large airfield all the spawns are already taken
by the spawns on the runways.

There for it's much easier to just add air spawns to a vehicle field.

edit: Also when adding air spawns to a vbase, the first one is always attached to the "H" no matter where it's placed in the terrain.

 
midi

[Easyscor]

I am confused....

Why would the designer do this in the first place?

It makes no sense....

You have an airfield less than a sector away...


Further...I am setting the planes/fields to default for the purpose of discerning whether or not they are airfields, ports or vbases to use in another program....

I find it confounding why a designer would do such a convoluted thing as assign aircraft rights to a vbase...and as it is now obvious...the game will override his decisions if you choose default setup in cm tools - fields...

What logical reason could explain why terrain designer would create a vbase and then allow its use as an airfield for a special event? (which of course requires that *fld and *pln) are not present when loading the terrain offline?

Yet another layer of obfuscation ...

Scratching head at this point

These terrains are also meant for the AvA, and other SEA events which don't want airspawns most of the time. By default, aircraft are not available at a V-base, so the airspawns are automatically disabled unless the host enables them on purpose so it's not a bug (also see midi's post). It's a choice the designer made to assist the hosts.

What discrepancy in the spawn field numbers or direction did you find in the northsea oba file??

[oneway]

These terrains are also meant for the AvA, and other SEA events which don't want airspawns most of the time. By default, aircraft are not available at a V-base, so the airspawns are automatically disabled unless the host enables them on purpose so it's not a bug (also see midi's post). It's a choice the designer made to assist the hosts.

What discrepancy in the spawn field numbers or direction did you find in the northsea oba file??

90 is Knight vbase located in 16.14.2/5 and has 3 air spawns located: 7.18.8, 7.10.7 and 9.3.4

I stumbled across this by using the system generated *.pln file for northsea...and terrain designers *.pln file and comparing the list of base types reported back by using a function that among other things, sniffs out whether a field is a typical airfield, a port, a v-base or a CV...

I found it odd that the terrain designer would embed aircraft capability in a vbase when a nearby abase  would have sufficed, though I could understand the use of the vbase 90 as the airspawn base if the use of A89 was slated in parallel for active use and the setup was to include 89 as normal non-spawn airbase for the purpose of defending V90...under that circumstance it somewhat makes sense but not entirely seeing as nearby 88 could also serve as the rear defense base cover 89 instead ...and then use 89 as the airspawn base...

Oneway

[oneway]

Welcome to the world of terrain building....

It could be that the airspawns were added manually in a text editor and the designer was bitten by the zero equals one issue.

Strip

It happens often when using zero based indexing but in this case it is not...in fact V90 is the source of those air spawns...

There is a zero based index error in counting on the special events Totals Kills reported on the log pages though....TotalKills always reports 1 less than the actual total for both teams in the team summaries....

Oneway

[oneway]

edit: Also when adding air spawns to a vbase, the first one is always attached to the "H" no matter where it's placed in the terrain.

 
midi

That is interesting in as much as the 3 air spawn icons on northsea do not indicated H as a keypad choice....in the case of this map, the choices are keypads: 8, 7 and 4...

Though you are entirely correct in as much that when loading up northsea and going to V90 and enabling aircraft...the choices include H, N and W...H is only available to fighters and it represents the air spawn in 7.10....and though the icon would indicate a spawn in the North West at keypad, 7...you are in fact deposited in the center of 7.10 at kp5...which of course is consistent when choosing H from 90 as your spawn out...one would expect to spawn in the middle of that sector...

Oneway

[oneway]

This terrain designing stuff makes me scratch my head and want to drink beer before lunch....

 

I just also put 2 and 2 together to arrive at: the spawn points can be anywhere on the map or within a grid, the keypad choices so chosen have absolutley no bearing on where in the sector you spawn out...

One more quick question on these things....

In the Var/DoD file their are object settings for hardness, down time and a hardness multiplier for these entry points...Is there some sort of funky setting when building a terrain that lets them become visible and destroyable?

If not...why do they have settings like a normal object?

Perhaps they just inherit from a core object type that exposes these property settings....

Oneway

[Strip]

Nothing short of redesigning the object can change whether its visible or not, in theory they could be set to destructable though.

At heart spawns are just invisible objects with similar properties to regular objects.

Strip

[oneway]

Nothing short of redesigning the object can change whether its visible or not, in theory they could be set to destructable though.

At heart spawns are just invisible objects with similar properties to regular objects.

Strip

Yep....

The principal of object inheritance in program design often finds the descendant exposing properties, methods and events that have no meaning in its extended / new role...often this is done to avoid redundant code, but has the opposite effect in terms of reflecting back on ancestor type...

I couldn't possibly conceive of any human logical reason why a spawn point (ie entry) has the ability to have its object hardness and downtime's settable...

Though thus it is and shall be...

Thanks....

Oneway

[USRanger]

I build terrains & Oneway makes my head hurt.

[ghostdancer]

Correct Oneway. When spawning from a field you have 9 possible spawns that correspond to the key pad

7  8  9

4  5  6

1  2  3


Depending on the base used (or custom based created) any number of these can be active and control spawning. Normally a designer tries to link up a position with the direction you spawn ... basically the 7 position would spawn you to the NW. But nothing forces a designer to do so. Sometimes a designer might not do so for design reasons and have things work differently because he needs the spawns.

For instance if I was creating a Germany terrain I might setup a base on the West side of the map and assign air spawns to it to help simulate 8th Air Force bombing campaigns. I might assign positions 9,8,7,6,4,3,2,1 to be air spawns all at the various points east of the base (NE, E, and SE) at various positions and altitudes so that I can have B17 raids coming from different positions for my and other events.

As I designer I could either use 1 base with 8 spawn points or maybe I set 3 bases and only use the 9,6,3 positions to create 9 spawn points for my airspawns.  Either would work but depending on the rest of my design I might just go with 1 base. Why? Well because the more objects on the terrain the larger the file size and other issues. So with one base I get 8 air spawns. With 3 bases (while more clean visually to have 3 bases with just the east facing spawns active) I now actually tripled the number of objects put into the terrain (3 times the AA, bomber hangars, etc.).

Normally this is not an issue but say if I have a terrain with say 200 bases or more and say I do some custom object work I might for stability reasons and file size decide to just go for using one base. There is also an upper limit of how many objects a terrain really can handle and remain stable (I forget what it is off the top of my head).

So that is why I designer might just use one base and have spawns go off to places all over the map that might not at first make sense.

[ghostdancer]

As for why Entry points can be made destroyable or have their hardness increased ... my best guess here is probably a programming decision on how they created and managed properties for objects. Basically as far as I can determine all objects have the same properties which can be modified. However, in this case only HTC (in the MAs) or CMs, AvA staff, or Trainers can actually modify those properties in a loaded terrain. Basically a very small group and there is no reason these folk would ever do so. So my best guess is that they are simply trusting we would not do something like that rather than modify their code or write extra code that turned off this ability of certain objects.

You would have to actually ask HTC to find out the reasons why though. I am just hazarding a guess.

[oneway]

server lag...

[oneway]

...

[oneway]

lame server lag extra posts...sorry

[oneway]

How do you assign a key pad to an entry point?

I have been toying around with my test terrain...and have observed the following behavior...

If you place multiple fighter spawns on a terrain slaved to the same base...and them leave them at the default rotation 0.00...then key pad 8 (North) is the only active extra spawn direction...and it will spawn you at the last spawn point in the spawn point list of the oba for that field. In other words the game ignores the first spawn added...

If you go in an tweak the rotation of the spawn point the editor/game attempts to choose the next free available spawn direction taking into consideration any previous spawns in the list, as well as the spawns part of the group master that the extra spawns are attached to or owned by...

Is there a way to: Add a spawn point and make work from a specific keypad...and override this somewhat funky behavior of the editor?

Where is the keypad for a spawn stored prior to compilation / build...it certainly is not in the oba unless I am missing something...

Oneway