Blitzkrieg I : Generation II

[Major Pain]

No one is taking a stab at questions?   Come on... i won't bite...

[dragonwolf]

Isn't the towpoint supposed to be "3" instead of "10"?

As far as what's missing, I've stared and stared but I don't see it.

[Major Pain]

lol...  Nope...

Ok... I guess everyone is stumped on this one, so here are the answers.



1: Does anyone spot the obvious above about the railroad car model?

<TowPoint2D x="0" y="-61.2764"/>

<HookPoint x="0" y="61.7125"/>


Look at the two values.  The model is not exactly centered.   Remember, when i said as a model builder it important that I try to center the model along the y axis?   here is one that is very close, but not exact.   It sits a bit forward of the center line by about .25 m

To be exactly centered each value would need to be about ~ +61.4944 on the HookPoint and -61.4944 on the TowPoint.









2: What is missing here?

TowPoint="10"

<TowPoint2D x="0" y="-43.6585"/>

<HookPoint x="0" y="43.098"/>


We do not have the level of the hitch defined.  It is not enough to define the x, y.  We must also define "z" or height in 3D.  Otherwise, the height could be anywhere from the ground to infinity in the air.  In this case we must define the third value in relation to the height of the model above its lowest level, the bottom of the tires/wheels.


I know, you all have other various things that are pressing on your minds all the time... so it is difficult to read questions and catch up to where I am going.    That was not fair perhaps on my part.   

[dragonwolf]

OMG!, you may not believe this but I actually thought about those same exact answers but since you gave examples with different "y" values I just shrugged it off.

When thinking 2D vs 3D I thought, "Ok, if 2D has a x and y factor, wouldn't 3D also need a z factor, I just misnamed it depth, but I actually did have the right idea.

Sheesh, next time I'll not worry about looking like an idiot and just type what I'm thinking, though I may be getting into dangerous territory doing that, the shadow of the valley of death, and whatnot.

Ciao,
John

[tedi88]

I know this is going to sound very arrogant, but i must say I had the same idea as Dragonwolf.

It seems "he who dares wins" is fully true.

[Major Pain]

lol...






I'm glad you guys were thinking... you must jump out there and seize the day when it is there...

Because my questions are for the purpose of sharing and education... you never know where I'm going with them...


I believe both of you...  so you get the Gold Star for the day...  50% for saying you knew the answer.... 50% for being bold enough to post...

[olaf66]

just an idea for the new buttons panel. COLOR

[Major Pain]

Did you create those or have i seen most of those before?

My memory does not serve me well at times...  


...so many add-ons and MODs where artists used their excellent talents to dress things up...


I really should get several opinions on this...  I am just a mere messenger... the game belongs to the community.  


That includes GEN II.

Would you be so kind and blow that image up a bit?

[dragonwolf]

I like the original icons myself, perhaps with a few additions in the same style.

I don't want to have to learn a completely different set of icons all over again just to be able to play.

My two cents.

Ciao,
John

[olaf66]

It's the buttons panel from "stalingrad" stand alone , i've just added some color .

[Grot]

I wonder how much space on screen is needed for all that buttons. If it covers to much space maybe use basic functions only and flip or slide open advance buttons to pop up if needed.

[Major Pain]

sztyrlic:  You are on the right track.


Some commands or functions will have submenus...

Think about Engineers when you select Build... a Submenu opens in the same display which allow Building Specific things...


I'm thinking that Ammo Selections must be their own subset for instance, but much expanded over what we currently have.   If we do adopt various AMMO Choices... the same routines handle the input from the player... the input is in the form of a number, based on the  row/column of the selection.  The routine simply passes the number for that row/column back to the function code which uses the table to select the function.  So in effect, each function has a number in the table which corresponds to a function code.

The function codes are designed specifically to the purpose.    But this data must be defined somewhere in the gamett.dll or inside the open code in the folders, usually the UI folder.  Since I do not want to overwrite the current .ddl files, I'm leaning to a new .dll or an open code that will overlay the contents and values in the gamett.dll, and perhaps the ailogic.dll.  The trick is working out how and when we read that data where it overlays and does not over-right.  This gives a greater option on what Titles might be able to be adapted later.

[Major Pain]

UPDATE:   


As the GEN II Project Members begin ALPHA TESTING this Winter...  The new changes could be patched to the RT Platform early next year.    I have already written the Interface Code for the Rolling Thunder PLATFORM for Multiplayer.  That code is ready to roll out now, but will be held specifically for GEN II under the RT Platform.   If there is overwhelming support for the RT MP, then I could change my mind and release it.

The Roll-Out Working Title is Blitzkrieg -Generation II "Raising The Flag".   Planned Release Summer 2015.

My hope is to include new objects in every category.... but this means your assistance is needed.   I want to complete the Series II models which all have been designed for GEN II.   New locator definitions, new animation and of course a major overhaul of the game tables and command functions will be included.    Because of the huge amount of resources that have been created by many of our talented artist and members, I will be requesting to include some of that content for GEN II... if we can modify the objects/models without issues.

---

I have discovered that some code can be written after the  ResEditor 'export function' that creates the 1.xml... this reduces the dependency on the ResEditor and A7 Exporters  for reorganizing (redefining) parts and locators.  A small patch code can modify the 1.xml just as effectively, meaning new locators can be defined on a model without MAYA or the ResEditor.

The ResEditor Exporter primary purpose is to create the 1.xml file and the image files.  The 1.mod that is created by MAYA and the A7 Exporter only changes the object.mb file to a 1.mod file.  Once a model has been exported, it can be changed externally, not the geometrics, but the source code.   The process uses existing code defined by the Exporter but can be used to add x,y,z coordinates to any model for a locator.   The Keyname Locators are defined in the new Library Source Code.

---

Currently I'm testing the new HP-TIER Based Damage System on 3D models using the same code system used for Sounds and Effects.  I have not found a limit to what the game engine can handle... meaning it can support 5 Tiers of HP/Damage for a 3D Model.   That was my goal and this has been reached.    Test models included changed geometry and textures customized for each TIER.  

As mentioned previously, the TIERS are 100%, 75%, 50%, 25% and 0%... these could change slightly depending on other functions under development.  One of course is a Model's Crew and how any truck/tank etc can be captured if the crew is not present and the unit is not within a set radius of friendly units.   Another is at what damage level the crew is forced to abandon a truck or tank... whenever it has reached a predefined HP level (defined in the 1.xml)  So this parameter can be changed and not a one size fits all.   

Dismounted Crews become Infantry units until they either get a new vehicle or their vehicle is recovered and repaired.  New type of Infantry Resource will cover Crew Assignments for captured vehicles and guns.   The crews will not come from Infantry Squads like now.    I'm testing another type of Truck or Support Vehicle to deploy Crews.  There will be some exceptions to the Case Rule System... meaning this function can be changed in the Map/Mission parameters, called CapturedVehicles (includes guns).   The Flag can be set to 0 = cannot be captured, 1 = Squad Capture, 2 = Crew Capture, 3 = TRV Capture (includes trucks capturing guns).  This is a LUA Code embedded in Current LUA Scripts for System AI, not only the Computer Player AI.

There have been a few issues with the Captured Code thus far.   This seems to be a binary code conflict that has not been cleared up.

I have been able to restructured the Binary codes that supply data to the GAME TABLES (ARRAYS).  I have been able to access all ELEMENT DATA used in Chapters that store Core Units and Player Performance Data.   I'm hoping to bring the Player Performance Data into the end of all SP Missions/Maps.   The Core Data would not be maintained for SP MAPS.  This particular function could be very useful in STEAM later down the road, during Tournament Type Competition.  But there is more data that can be manipulated already within the GAME OBJECTS tables that is quite useable.  

This can lead to Customized Models maintained within a single Folder using multiple replications of the same tank type (for instance) but each having it's own identity.   Commander names would come from a similar folder file system as is already in use.  But this data would actually read down to the table rather than accessed only based on need.  Currently, the file is read sequentially alphabetically.  The new system randomizes the names to eliminate predictability.     The Commander is key because he can be assigned certain traits which pertain to his crew and vehicle.  He also provides the base Moral.

Let me illustrate what this system may lead to.

I'll use a Standard Sherman Tank for this example.

UK_Sherman_IC_C

Let's imagine we need 4 copies of this tank.

So in the folder we will  supply:

One 1.xml Code File that will provide all of the BASE DATA for the tank model
One icon.tga that provide the mapeditor image 
One unit.txt file that provides the tank description (for in game)  = UK Sherman IC  "FireFly"
One desc.txt file that provides the tank data, weapons, crew size, speed, range, Horsepower, etc...

Specific Files per Replication:   (R = Replication Number) (S = Season)
R-1.xml-------------------> These provide any additional data that describes a specific tank replication.

HP Status Paired Files.
R-1.mod/R-1_S.dds --> HP = 100%
R-2.mod/R-2_S.dds --> HP = 75%
R-3.mod/R-3_S.dds --> HP = 50%
R-4.mod/R-4_S.dds --> HP = 25%
R-5.mod/R-5_S.dds --> HP = 0%
R-name.txt  --> Commander name and Data.  <----  This data comes from the Commander Selection Script
R-stats.csv  --->  game data about the model status.  Note: Excel Spreadsheet, comma delimited data in early run for debug.


If the Unit Folder includes:
0-.xml, 0-1.mod / 0-1_0.dds ~ 0-5_0.dds  <---  This is default model and skins used by all replications... for debug or streamline data.

The -h designation will be dropped... all Graphics will be high resolution only... GEN II will not support _c or _ l resolution.

So in our example we can define 5 of this tank on a map, all having their own Identity.   

I have not yet worked on the Season Types, but the code is flexible to add whatever defined... there is no limit here.

The Season can be defined by a letter and/or number, which would be interpreted by the DATA Collection Code that sets up the game.  The season can be overwritten in the Mission.xml (1.xml):   Season = value

So I'll throw this out for discussion:


Africa  = Binary 0
Desert-1 = 1 / D1   ~ 1
Desert-2 = 2 / D2   ~ 2
Desert-3 = 3/  D3   ~ 3
Desert-4 = 4 / D4   ~ 4

France (West) Binary 1
Spring   = 5 / E1   ~ 6
Summer =6 / E2   ~ 7
Autumn = 7 / E3   ~ 8
Winter  = 8 / E4   ~ 9

France (East)  Binary 2
Spring =  9 /  F1   ~ 11
Summer =10/ F2  ~  12
Autumn =11 / F3  ~ 13
Winter = 12/  F4  ~  14

Germany (West) Binary 4
Spring = 13/ G1~ 17
Summer =14/ G2~ 18
Autumn =15 / G3~ 19
Winter = 16 / G4  ~ 20

Germany (East) Binary 8
Spring = 17/ H1~  25
Summer =18/ H2~ 26
Autumn =19 / H3~ 27
Winter = 20 / H4  ~ 28


Russia (West) Binary 16
Spring =  21 / R1~ 37
Summer =22/ R2~ 38
Autumn =23 / R3~ 39
Winter = 24 / R4  ~ 40


Russia (East) Binary 32
Spring =  25 / S1~ 57
Summer =26 / S2~58
Autumn =27 / S3~ 59
Winter = 28 / S4  ~ 60


Pacific/China Binary 64
Spring =   29/ P1~ 93
Summer = 30/ P2~ 94
Autumn = 31 / P3~95
Winter =  32 / P4  ~96


Reserved Binary 128  
Spring =   33/ Q1~ 161
Summer = 34/ Q2~ 162
Autumn = 35 / Q3~ 163
Winter =  36 / Q4 ~ 164

36 Possible Seasons / Could be increased to binary code 255, but could require a possible restructure of seasons or terrains.


The Season Code can be written in Binary Code or Letter/Number Assignment:


The Season can be pushed to the Units for each Seasonal terrain.  So the S does not need to be defined in the texture files, unless you will use several different seasonal skins.  You can classify within the data which skin is used for a season.  This will reduce the number of skins needed for each replication of the tank.   A Sherman tank would not have that many different paint jobs between the seasons or theater.  Africa and Winter are the exceptions, but there could be a few others considered bu year and season.   So the Year Code could drill down a better picture of what could be used.  I see many options here and would like to hear thoughts on this.

The purpose for the Binary Code is both the Interpreter and the Game Engine work at their peak in Binary and HEX-Decimal.   This shortens the read time when loading maps.

If the binary is truly exploited, a total of 255 unique codes can be used... each with a predefined purpose.  This would be similar to the way the Command and Exposure Functions are applied.

The Binary base defines the Theater in the above example.  With that in Mind... we can support 9 Theaters with as many as 8 differentials that apply to the terrain or season, essentially double the number shown in the example.  Now this may be overkill, but the basic procedure could be utilized to better define theaters by a smaller region, coupled with the customized textures that may be required.   But all of this is up for discussion. If the Community is happy with the existing seasons, we can go with that.




Let me say this... I have a total mess on my desk and a special work system I put together for this project.  It only runs the test codes and ALPHA Models and objects under the Modified RT Platform.  I chose RT because it by far is the most stable Platform thus far, as well as the most widely released.   GEN II will eliminate the need for the 1.2, 1.3 and 1.3.x patches.  BH has not been tested nor do I plan to.   My feeling is BH maps could be brought over to the RT Platform for GEN II if anyone wishes to do so.  The bridging conversion should not be difficult since I have only made a few tweaks thus far to several RT maps for testing.      The MapEditor is still another issue... but within the scope of this project. 

---

Anyone who has fairly good C+ and LUA Skills and interested should send me a email.   Only serious coders should contact me... there is no time to train or hone your skills on this project.   Timing is very key.   Sorry...

---

Only Four ALPHA TESTERS will be required and in place in January.   Ten BETA TESTER should be selected by March and ready to go on April 1st.  Input from both groups will be vital to project.   There is the possibility that Code Changes and updates will be very fluid during this time.   





More to Come...

[keepitsimple]

There will be some exceptions to the Case Rule System... meaning this function can be changed in the Map/Mission parameters, called CapturedVehicles (includes guns). The Flag can be set to 0 = cannot be captured, 1 = Squad Capture, 2 = Crew Capture, 3 = TRV Capture (includes trucks capturing guns).

I liked this very much. I think is silly to see an enemy tank taken in battle (or even a gun) and turned on the enemy. Now I can easy script it. 
 

[Major Pain]

The tank could not be captured unless it has no friendly units within a radius... the radius can also be scripted.     I'm trying to cover all of the bases here...   sometimes it gets pretty deep.