|
Post by Major Pain on Apr 4, 2015 20:23:17 GMT 1
... ahahha ... major pedia Thank you for the Compliment... A compliment is an expression of praise, congratulation or encouragement.Source: Wikipedia
|
|
|
Post by ariete on Apr 4, 2015 21:21:28 GMT 1
yes i remember major ...
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Apr 4, 2015 22:02:38 GMT 1
An idea occurred to me while reading your post.
If we have the principle of fuel consumption of a vehicle, for its movement.
Why not move this same principle to units "soldier"?
If a soldier moves around the map in transportation or quiet movement, this is more rested therefore 100% fit for combat.
But what if we were feeling tired activated on a soldier who has moved to "forced march" by a map in a short distance, this would make fresh troops to a place of conflict, sometimes we launched upon arriving in the combat zone in a major attack on the defenses of another opponent, can give the possibility of being on the defensive, can counterattack with soldiers rested and have more opportunities to win.
I think this would make strategic moves to what battle and logistical concerns.
Of course this should affect when we activate the only movement "forced march" option or run more quickly.
It would also make squads that were dispersed, they have more wear, as many saved only "official or chief" in the rear to be cloned later after massive loss of soldiers in their attacks, would avoid massive releases on lines, besides the high cost of lost.
Greetings friend.
|
|
|
Post by Major Pain on Apr 5, 2015 8:38:13 GMT 1
I'm thinking about what you proposed... There are a couple of things that are worthy, but also a chance of chaos if squads try to refit in forward positions. So refitting a squad should only be considered well behind the lines, since any attack would certainly shatter the lines if not formed up.
|
|
|
Post by Major Pain on Oct 3, 2015 5:02:43 GMT 1
AFTER A TIME OUT PERIOD (VACATION)...
GEN II IS BACK ON-LINE...
WELCOME BACK EVERYONE!
|
|
|
Post by Major Pain on Oct 3, 2015 17:06:26 GMT 1
NOTE: A part of my post on the Major Pain's Projects Topic has been removed and added below. Several post that followed the GEN II Topic have also been moved here. All moved posts are noted within the Post.
Thank You for your consideration and patience.
Post by Major Pain originally on Sep 30, 2015 at 05:41
NOTE: Some of the original post has been edited.
GEN II has opened many doors of interesting things that I was not aware of before. Some things we discussed over the years already have a footprint within the Enigma Game Engine.
Think about houses for a second. Anyone paying attention or creating houses know there are three stages of each structure driven by a percentage of the HPs. A house with a HP between 51% to 100% shows us the house in good order. Between 5% to 50% we get the Stage 2 damaged house. Between 0% and 5% the house is Stage 3 and destroyed. I found code that clearly points to a damaged/burning house can actually continue to suffer damage until destroyed unless an Engineer brings it back yp to 51%. Why this has not been in force on every structure/house, I do not know. But it does appear that on some Structures... this is in full use. This seems to focus on some German and Some Russian models which have some component turned on. It is likely in the 1.xml file or perhaps the .san files. My own inspection of .san files does have some data that is not yet understood. But on structures they serves as the stitching commands to put the images together and when to invoke various layers; shadows, ground footprints, ground with debris, etc... The order of the Stages is preset in the Engine, and can be modified.
Question: has anyone actually seen a burning house continue to be damaged until it is destroyed? For some reason, I do recall seeing this years ago, but I could be thinking about another game and confused. I worked on Empire Earth (add-ons) immediately before BK 1 came out... so the mechanics while similar are not even related in any part of the code or structure.
Ok... so let's compare buildings to the 3D models which only have two Stages, alive and dead. Well there was at least one more Stage to be included which is the intermediate 50% damage image. That code is embedded with about 30 question marks around it... and not a single comment. So it got my attention. Why did buildings get 3 Stages, and the 3D models only get 2? It seems to me the code would be virtually the same with only changes to the type of objects and graphics and the process which makes it happen. After comparing the code face up, they are identical, but neither was finished. The 3Ds from what I can tell right now point back to the Table ELEMENT that is defined in one of the .dll files, that is read third in the strap, strap meaning order called and short for bootstrap.
So based on this information... I believed the number of STAGES could be changed. And this proved to be true. So, this brings up this question.... How many Stages of damage is desirable?
Ok, I know, this is not the GEN II Topic, but I'm not ready to open it back up yet. There is much more to discuss there once it is unlocked. The question does not require an answer right now, but I can tell you I have successfully tested 7 Stages. (But read down) So please think about this over the next few months and then I will ask for your thoughts. Its ok to respond to any of the GEN II info or recent news in this Post.
Before I leave this 3D Model Stage options thing-ie... I want to add this. If some of you recall, I was testing another concept that would allow a tank to have more than a single profile or identity. This goes to the Virtual Identity Theory that I was working on. We, yes it did work and allows as many profiles as you wanted to add into the folder. So let's do some math here.
The tank model re-cycled the original 1.xml file, using it as the base line values and commands. We'll call this the min/max benchmarks.
In the 1.xml file a new parameter called Identities is defined. This is where you enter the number of different tank profiles you can build, if the supporting files are in the folder. This parameter is added in the RPG section in the front end of the xml code. It has nothing to do with binary data, in that data set. This is raw data that can be manipulated within the game. We know some of that data is never is impacted at all, but some definitely can be and is.... more on that in another discussion.
For each profile we want to add, we need several support files:
1-1.xml Each profile has new xml file which is created based on the Sounds and Effects code which uses the random float function, but we order these sequentially within the code. These are considered children of the baseline xml file and draw data from that file as needed. The new xml file stroes the actually element data that we can set by Script or manually within the xml file. It uses new field names to not conflict with any other Blitzkrieg Data Sets. Nival usesd the keyword ELEMENTS in place of a actual names for a field in the data, so ELEMENT 23 might be the Sight Value found under the RPG data in the 1.xml. So in the profile xml, we can modify this by Script or hard coding in the xml. Ok, that works.
1-1_h.dds/1-2_h.dds 1-1a_h.dds/1-2a_h.dds 1-1w_h.dds/1-2w_h.dds
Looking at the image, UV, skin files above.... do you see the pattern? The number one profile is 1-= everything that follows refers to the support file. This applies to both the 1-1.xml and the skins 1-1_h.dds.
The Number two profile looks like this...
2-1.xml 2-1_h.dds/2-2_h.dds
Is this obviously clear to everyone what is going on?
I have successfully tested up to 10 different Identities within a single tank folder. There is a lot of room for massive mistakes with this method so the guy creating the folder and files, really has to pay attention and understand what he is trying to do. Because most members do understand how most files and folders work, this looks very familiar to them already. But when you throw in the human element, mistakes will happen and cause UN-intended consequences. I made several mistakes while I was building and then testing. Since I am human, it is my understanding that we are all exactly the same human elements. We do not have any Android members yet this year... no Mr. DATAs from the Enterprise. Which brings another discussion about my specific purpose in the community... if androids were already here... More on that later if you wish. But we are all human and not perfect... mistakes are easy to make.... A better method has to be designed.
Ok, so what have we learned so far? We can manipulate the number of STAGES objects can have. This is set as a UNIT TYPE value and not set within each Object folder. Sorry.... the code is the code and I am not going to rewrite that part. We can also set the STAGES where different things can be made to happen: Like death, the crew forced to exit, and other options along this lines. The most dynamic that comes to mind is catching the tank before it is rendered dead at 0-5% and redirecting this value where a base minimum only renders the a tank damaged to a specific criteria:
DEAD but can be towed in and parted out. No repair can be performed. Below 19% Damage-Severe Unknown requirement for repair -Depot Only 20%-39% Damage-Heavy-Defined requirement for Repair - Depot Only 40%-59% Damage-Moderate-Can be repaired - Depot or 50% Field Possible 60%-69% Damage-Light-Field Repairable 70%-79% Damage- Other Unknown until randomly defined and revealed. Working Condition various stages
(I suggest only two Stages showing no damage, with HP at 91%-100% and 80%-89%) Damage begins to appear at 79%)
Each stage can be set by the above parameters in the Parent 1.xml file. These are new values under the RPG Section on the front end code.
About Moderate Damage which suggest a Field mechanic can repair... this is a 50/50 chance... and is set established using the random function based on two outcomes. Yes or No, but really 1 or 0. So one point can make a huge difference if the tank can even be pulled back. Light damage includes tracks and transmission. Moderate means it must be towed in by TRV. Each Stage sets the criteria of repair status. Ok, great, this is wonderful, excellent, all of the compliments you can think of this moment.
BUT: To make this work, we need something else to go with these 7 Stages.... 7 Unique Skins showing the damage Stages, and for all three seasons.... 4 if I can get Autumn to work. Actually Spring may as well be called MUD, because that is exactly what you had to deal with in most areas. But I think there room for some options here also, already within the 1.2 code. We can rename the seasons right now, and change the definition of what they are.... right now... the necessary files are in the top level code. I do not know if anyone has already discovered this and played with it in the last 12 years or not, but it is wide open.... right now.
Back to the growing number of files in this single tank folder for 10 different IDs. Damn... do you count 10 identity xml files, 210 graphic files (10 ids x 7 stages x 3 seasons = 210), the baseline parent 1.xml file, the baseline default skin that covers anything missing (0-0_h.dds).... and then the icon.tga, name.txt, descr.txt and the other two graphic files if you add this tank to the dictionary.
227 Files in one folder!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
So what else can I say in this post?
Absolutely zero!
Be back later (BBL)
MP
|
|
|
Post by Major Pain on Oct 3, 2015 17:22:08 GMT 1
NOTE: THIS POST HAS BEEN TRANSFERRED FROM MAJOR PAIN'S PROJECTS
|
|
|
Post by Major Pain on Oct 3, 2015 17:44:19 GMT 1
NOTE: THIS POST HAS BEEN TRANSFERRED FROM MAJOR PAIN'S PROJECTS
Posted by Major Pain Oct 1, 2015 at 14:54
|
|
|
Post by Major Pain on Oct 3, 2015 17:50:12 GMT 1
NOTE: THIS POST HAS BEEN TRANSFERRED FROM MAJOR PAIN'S PROJECTS
Posted by vonosten October 2, 2015 at 08:28
|
|
|
Post by Major Pain on Oct 3, 2015 17:54:52 GMT 1
Posted by Major Pain October 3rd
I'll resume by trying to answer VO's Questions...
At the moment, The Code is the Number 1 focus. About half of the Code that has been adapted or modified is in testing right now.
We have transferred all of the GEN II Project Code to a LINUX Machine running Mint. It is much easier to write and check the Code in LINUX, then transfer completed parts to the XP System.
I solicited assistance from a Code Writer Student in the LINUX Developer Community. While he was not a BK Player, he has picked it up pretty quick. He is working on Code Routines and Sub-Calls while I'm working on the Primary Code. He is about half my age and in College in the New England area of the US. He has experience in Windows XP and Win 7, but he is primarily a LINUX guy. He has written some interesting Apps for Android, so he looked like a good fit on this project. He is very smart and picks up quick, which should help with the timeline to get to Alpha Testing.
But before we get to the WIN version of GEN II ALPHA-1, I need to have a two or three help us with LINUX ALPHA-1. So anyone who is running a LINUX machine with MINT, send me a PM. Do not reveal yourself since we have to maintain some secrecy on the Hard Code which will be released for the first time. We're are currently re-coding to C+ rather than C.
We have De-compiled the Blitzkrieg 2 Enigma Engine and looking at some of the new code they added. I'm deciding if some things can be used from this... path-finding looks like an improved Code, so we will be checking it closely. LUA 5.0 was the Script Language, but LUA 5.3.1 is the latest Stable Release, and I'm either going to use that, or the next version 5.4.0.
You ask if GEN might be released tomorrow (just theory). Actually, the LINUX Release for ALPHA-1 Testing will be in November if we don't have any setbacks. But it will not have everything included... much of the code is still pretty raw and we're cleaning it up as we work through it. It will be the 50% version with new Object Tables and about half of the new Command Functions. new vehicles have been designed and in the Load File already (objects.xml).
Some have asked if GEN II is a MOD. No, it is a Stand Alone Platform, which will support MODs.
Practice versus Theory: If you mean Practice as what is Possible, then we can stay on the same page here. You know, that is a subjective issue at the moment. At times, this leans mostly to Theory, but the more I dig into the Codes and working out the Command Binaries, I am of the opinion that what is Theory and what is Possible are not that far apart.
I have talked about the Moral Function. I restructured how this works, and it was much improved, but it still needs work. I need to tighten the Moral Points Collection say about 15-20% to keep the highest value possible at 200. This is perhaps the most difficult part of GEN II, so it is still a little early to declare victory on this. I think we are with range, and can make the thresholds required. I tried to strip the top if Points were +200 (over 200), and caused a crash, so that code did not work as planned.
I have talked about the Updated Medical Units. The Trucks and Crews are working perfectly, but the foot-medics are still somewhat in a continuous re-write. The solution is at hand but there are a couple of things that have to be worked out. I created a new Infantry Type, called Medic, and set many of the parameters based on the Officer Options, but it is designed to heal wounded. The problem is the Medic team can't find the Wounded Soldiers in a Squad. So obviously, that is not going to work.
I should advise that I have put the Resource Editor Upgrade on hold. It was laborious working back and forth when some things are in Flux. It will be updated and released after the Completed GEN II is released.
To complete this project, a lot of support would be appreciated. We'll need all kind of support, Mapping, some 2-D art and graphics, scripting, and internal overlays and back-grounds. The Resolution & Graphic Options will need to be tested on many kinds of Computers so we will be keeping notes on this as well. Much of this will be during the BETA-Phase after we have the ALPHA Phases finished...which means all of the code is working and the game tables are completed. Adding new objects will be as before, and can be added or REGISTERED within the objects.xml.
So here are some things that are most definitely in GEN II now, and working.
New Types of Vehicles:
I have listed these a couple of times....
New Engineer System with Sub Catagories TRV/ARVs, these are the vehicles that will tow anything... Mechanic Engineers - these guys repair vehicles Builder Engineers - This crew repairs Buildings and Structures. Bangalor Engineers - These guys send explosives through a long pipe. Mining Engineers - lay or remove mines. A new mine type... more on this later. Bridge Builders - These guys may get new bridge laying vehicles. This is in testing.
New Supply / Logistic Units Upgrade the standard Supply Trucks - Ammo Crates will be removed from the truck to the ground. This is a new Concept... Medical Team on Trucks works like Resupply Units but this Crew heals wounded Fuel Tankers will included... the supply versus distance ratios are still under development. No Fuel means No Move. Canteen/Food - in the works.... The Army moves on its Stomach - This is a new concept, and might be optional. Water Tankers - in the works... And the Army needs water to stay Hydrated - This is a new concept, and might be optional.
** A note about Supply Trucks: Trucks can either carry Soldiers or Supplies. Both have their own Structures on specific types of loads and will indicate each on the icon bar.
Some testing is underway on new Armor Options Armor can tow trailers and guns. Includes SPG units like the M3 Halftracks with Guns, AA or Howitzers New Rider Types, and Crews that can dismount... this applies to all vehicles.
Vehicles without crews cannot move, and it is possible to capture vehicles.
Aircraft This has been a tough issue... The AI controls this functions, but I'm trying to wrestle some of it away. Not sure what i hope to accomplish on this yet. These would be very difficult to manipulate.
And I've talked about the Water based units. This also is being tested as we develop the new terrain tile structure.
I'm sorry, but most of this has been outlined and discussed previously. Very little new information at this time.
What I really need is player feedback on things you all are thinking about. Since things are pretty open, still, and the code can be changed to do almost anything, this is the time to hear ideas from you.
Thank You
MP
|
|