Port and Associative CV Creation Question...

[oneway]

To Any and All....

If/when creating a terrain, and you create a port....does the TE automatically generate a CV group for that port?

If NOT, then what is the process of attaching a CV group to a port?

FURTHER AND MORE IMPORTANT:

Can a map designer attach a CV to any type of base...

In other words, Can a Map Designer create VBase or Airbase, Create a new CV group...and then attach it to that base?

MOST  IMPORTANT...

Can a CV group exist without a base attachment...In other words can a map designer create a CV group with no home port or no home base? We are talking operational task groups here...not the fake ones that can be inserted as simple objects/group with no functionality....these are real working task groups that in the ma are always associated with a port element..

I am parsing an oba file and have found the oba data column 16 (zero index)  seems to indicate that a CV group can be attached to any type of base...that would be the object data line in the object inclusion process...the oba file I am parsing indicates that CV's are attached to all manner of bases (Air, Vehicle, Port)....

My present conclusion is that this is true given the underlying data and logic flow...

Confirm this observation or conclusion if you could..my coding in this regard is in a stalemate until this discovery/assumption is verified....or discounted....

 

Oneway

Edit: Just to be clear...I don't know want to know how to do it; I want to know how you do it....how you do it gives invaluable insight into the format of the TE/output oba file format.....which is what I am trying to crunch...

[danny37]

NO,the TE does not atuomatically generate a TG for a port.as you know the PORT is under AVAILABLE SHAPES in the TE.
the TG is under SHAPE GROUPS,when you add a TG to the terrain you still give it a number as you would a vbase or airfield.
but to attach it to a port there is a drop down in the properties box with all ports listed,when you pick the port you want it for
it attaches it to that port.


you can attach it to an airfield but that airfield i think has to be deseinated as a port,i dont think you can attach it to a vbase or another TG
some of the terrains we have now some ports have small airfields but they are assigned as ports.this i think goes back to the properties box
and the drop down list of fields you can assign a TG to,i think it only shows ports to choose as the TGs owner.which is why you would have to assign
the airfield as a port.

as for a TG not being assigned to a field im not sure that will work either,may want to ask someone from HTC about that.
anyway i hope i helped you out and not confused you more lol

[Denholm]

Task Groups will operate fine without being linked to a port. If that's an acceptable standard for inclusion into MA terrain circulation is a matter beyond my knowledge.

[oneway]

Task Groups will operate fine without being linked to a port. If that's an acceptable standard for inclusion into MA terrain circulation is a matter beyond my knowledge.

You are correct in the former...

As to the latter, I would seriously doubt it..as I have never witnessed a rogue CV with no master field or anchor back in ma....

Operational task groups can be created out of thin air as long as they are field owned...in order to, and be consistent with Terrain Design Standards, they must have a map room associated with them...In other words the map room is created first and given a field owned ID...then the subsequent task group is part of that field...

Why?

My present assumption is that a map room needs to be a governor of a CV group given the fact that CV's are not group masters...thus, when the cv respawns, the program can check the owner (via object data), and flag back and destroy the map room at the time of spawn to switch ownership...if necessary...just a theory...but it is consistent with program behavior at this point...

To the previous comments/suggestions regarding what can be a cv Master:

A CV group can be slaved certainly to a port, and definitely to a small airfield...as to VBases and other fields I am not sure as I have not tested that...I would bet you can assign a cv to any group master with map room to get a desired result...that maproom being standalone, or incorporated via the presence of town with a map room object owned by that town...which is owned by that base...or any other group designated group master included withinin the outer group master(eg field) as a sub group master...to THAT wrapper master

For an example of CV group slaved to a small airfield, load up northsea and destroy field 69 map room..then go to CV 121 and destroy the 'cv'...wait a few minutes and you will find that 121 is now Knight owned...

As to actually assigning CV's to owner fields within the TE, I still have not figured that out, nor have any desire to do so, as the behavior model I was looking for has been revealed...

The critical value is the Object Data Value in Column 16[z-index] of the oba file for SHP 000...it governs and is the master to the task group in terms of capturing CV's...that is the value/field you must kill/capture to take the CV...

That data value indicates/creates a subservient relationship between the field so noted and the task group, with the object data value indicating the master, and the task group owning that data value being the slave..

It hints a bit of circular reference...from a coding perspective...but it is what it is...

 

Oneway

[ghostdancer]

Some quick answers for you.

1) You can create a port and not have a taskforce attached to it. You create and place it seperate from CV creation.

2) You create a taskforce separate from a port. During this process you designate the owner of the TF though. Personally I have not tried attaching one to a different type of base (vbase or airfield). I don't know what would happen but such a design would not be accepted in the MA. As for the SEA terrains I would have to actually evaluate if it could be attached to a non port and what the affects were before I said the SEA would or would not accept such designs.

3) As stated taskforces don't have to be assigned to a base when created but not sure what the affects of doing this would be. Obviously the CV could not be captured via taking its controlling base. Other affects outside of this might or might not be present. Would need testing to see what would happen.

4) When creating a Taskforce you actually have to create and place a maproom for it. Basically most designers stick the map rooms for the Task Forces off to an use corner of the map. So your hypothesis is probably correct. When a task force is attached to a field most likely when its map room is destroyed and switched by a troops capturing the same thing happens to the Task Force.

[oneway]

Some quick answers for you.

1) You can create a port and not have a taskforce attached to it. You create and place it seperate from CV creation.

2) You create a task force separate from a port. During this process you designate the owner of the TF though. Personally I have not tried attaching one to a different type of base (vbase or airfield). I don't know what would happen but such a design would not be accepted in the MA. As for the SEA terrains I would have to actually evaluate if it could be attached to a non port and what the affects were before I said the SEA would or would not accept such designs.

3) As stated task forces don't have to be assigned to a base when created but not sure what the affects of doing this would be. Obviously the CV could not be captured via taking its controlling base. Other affects outside of this might or might not be present. Would need testing to see what would happen.

4) When creating a Task force you actually have to create and place a maproom for it. Basically most designers stick the map rooms for the Task Forces off to an use corner of the map. So your hypothesis is probably correct. When a task force is attached to a field most likely when its map room is destroyed and switched by a troops capturing the same thing happens to the Task Force.

Exactly....and the way the program (the game) works is it sniffs into the hierarchy of the owning or controlling structure/tree of objects via data line 16...and you could have multiple map rooms...but it is the first instance of map room within that structure that is the governing map room for the cv...if it goes down...and the cv re-spawns...it is THAT map room that is checked...all of the rest are ignored...

Its linear in terms of the map rooms...map room index zero is THE map room...

The 'other' map room that is part of the task group as you say is tucked far away in some obscure place on the map...its existence simply provides the program a way of destroying the cv when the cv re-spawn event is fired within the program...that event checks whether the current owner was the original owner of the parent base prior to the destruction of that cv...it is at this moment that ownership either changes or remains the same...this 'other' map room is just a switch for the program to flip if/when necessary...

It is interesting to look at terrains from a non-terrain creator perspective...but rather a coders perspective on TE output for facility in other applications...

Fascinating...

I have learned more about Terrain creation coding to its output than I have actually trying to create a terrain...its like learning to weave by unraveling a tapestry...

Oneway

..

[ghostdancer]

I have learned more about Terrain creation coding to its output than I have actually trying to create a terrain...its like learning to weave by unraveling a tapestry...

I would disagree with your analogy here slightly. You are learning about the tool used to weave. There is more to weaving than that. The same goes for terrain creation for game play use.

I am graphic designer and do a fair amount of web work. To put it a different way many people go .. "I have a red crayon, blue crayon, and green crayon .. what can I draw with these?" The focus here is all about the tool. Which can be important but it leaves out the creative process and why you are weaving in the first place. To illustrate that example it would be a person saying "I am going to create this artwork, now how am I going to accomplish my vision with just these three crayons." That is why you find in terrains things that seem odd. Basically a creator made a decision and found a work around (many times cumbersome) to still accomplish his vision with the tools he had at hand.

Each terrain creations is fulfilling somebody vision and purpose. A creator first asks himself:

1) Why do I want to create a terrain?
2) What do I want to offer or accomplish with this terrain?
3) Now how am I going to be able to accomplish this with the TE?

The bulk of the work or time is actually spent on questions 1 and 2 which happen before we even open the TE. If HTC changed the TE radically (and they have just a few months ago) a terrain Creator process is still the same. Why do I want to make a terrain? What do I want to accomplish or offer? Now I just have to learn the new TE to figure out how to fulfill my vision.

[oneway]

I am talking TE mechanics...and output...not design and intent of the user or his desired product / intended audience...

The style and flavor of T design in TE is not my cup of tea...that is for the artists...I am a machine...

All I care about is: "if this then what...."

And I stand by my previous assertions...that I have learned more about HOW the TE UI  works based on analyzing its output than I have messing with its interface...or muddling with its sparse help files...

My field of view is a back door look/perspective on this applications output...

I would/will go as far as to say:..if a newb TE guys want to know what makes the TE beast work...he should analyze its oba output every time he makes a change...consequently he will be exponentially more proficient in getting his hands around the throat of the beast...

Subsequently...he will move closer to direct manipulation of oba files via *.txt/*.csv ...which affords the broadest spectrum of flexibility...as you are well aware...

Oneway

[ghostdancer]

Actually interesting discussion that has been debated for a long time. Does form follow function or does function follow form. Obviously I am in the camp that form follows function and that you can't divorce the two and talk form without understanding what function it was built for since that dictated many of the decisions that were made to create the form / tool.

[oneway]

Actually interesting discussion that has been debated for a long time. Does form follow function or does function follow form. Obviously I am in the camp that form follows function and that you can't divorce the two and talk form without understanding what function it was built for since that dictated many of the decisions that were made to create the form / tool.

To me...the most fascinating question is what predicate governed the architects of the TE machine....and was it based on the art of output or the mechanics and utility of straight input?

Understanding what drove them when they made TE in the first place makes it vastly easier to unravel it...from any perspective....

I think it was predicated on mechanics....machine language....coders are not artists in the classic sense....though we appreciate each others work in weird way....its difficult to 'sell' it as art...

TE is a machine driven beast...it exists to simply provide consumable products to another machine.....

Thats from a coders look at things...

Oneway