|
|
Post by Nephilim on Aug 25, 2014 2:53:28 GMT 1
I wish you the best of luck with this project Major Pain. I will however say that is quite ambitious and has many goals and targets to reach.
Some of the ideas you mentioned I had similarly explored theoretically and casually many years ago along with other interesting ideas for Modern Warfare. I will however not disclose those ideas or the current ideas as they are theoretic and have not yet reached practically.
While I do agree that certain workarounds can be reached eventually it comes down to requiring far reaching game code changes which can be done but would require licensing or permission from Nival. Those changes can also be done on a low-level and not require a Framework or Infrastructure that one would envision as being complexly required for such a task. Many years ago I had explored programming and while I did not choose to pursue it I can honestly say that some of these ideas you mention are interesting. The main thing to look for is for classes, libraries and arrays and also their referencing since it is C+ based (C based as well).
I only chose to post right now and not initially because I wanted to further look into your observations and your initial analysis of what Blitzkrieg Gen II is. I remember a similar project and undertaking that the T-34 Mod forums also took with the TDA Source Code but found the changes would not be feasible due to the complexity of the source code. Certain Blitzkrieg enigma engine games worked around these limitations by introducing .dll files and others chose to pursue and recompile the main game binaries.
I would like to see what Blitzkrieg III offers in terms of modification development source development toolkits/tools as it may be the Third Generation development of Enigma (Blitzkrieg I/II/III). However at this point the release date is uncertain exactly.
Regards,
|
|
|
|
Post by ariete on Aug 25, 2014 12:07:46 GMT 1
see the appropriate files in the "Coyotes law of the desert" (if you do not know - this add-on engine Blitzkrieg) i never listen it ... and paradoxcally on the web i've just only found a video on youtube |
|
|
|
Post by gagarin on Aug 25, 2014 12:26:48 GMT 1
see the appropriate files in the "Coyotes law of the desert" (if you do not know - this add-on engine Blitzkrieg) i never listen it ... and paradoxcally on the web i've just only found a video on youtube Аriete, This Russian independent addition to the engine, Blitzkrieg-1. I have it on the disc, but we'll see links to download it, can find it. |
|
|
|
Post by Major Pain on Aug 25, 2014 12:28:31 GMT 1
Thanks Nephilim Actually BK3 does not use the Enigma Game Engine... it uses the Unity Game Engine. It is a Cross-Platform Engine. Unity is an Open Platform Engine without a Licensing fee for non-commercial low level use. It is also the Engine platform for Nintendo Wii and others. en.wikipedia.org/wiki/Unity_(game_engine)en.wikipedia.org/wiki/Blitzkrieg_3
Many of the changes I hope to accomplish are in fact solved in the Binaries and Tables (Arrays). Not all of the functions can be accomplished by simply changing or replacing the direct link libraries (.dll). Some of the code is on the Open-Platform side which has always been right in front of us. But there are some restrictions as to the Command Functions which create conflicts on some Unit TYPES. This is where the deep code must be pulled out and overwritten in new .dll files. By accessing the game tables and binaries from inside the engine, we can replace the data. This does not require a rewrite of the over-all C+ code. We accomplish this by creating a new push-pull conduit which exchanges the new code. Once we have the conduit, all of the code tables are exposed and can be changed. I have been able to solve most of the issues already by this method. Some of the changes were fairly straight forward but a few others were more of a challenge. I chose this time to announce the project since about 75% of the project code has been written already and my Alpha Testing has gone well. There are still many obstacles to over come. A few of the other BK Titles have already employed many of the things I have spoken about. TDA added another resource aspect caled Fuel, which added to the Purpose for logistics in addition to ammo and repair. gagarin offered his observation from " Desert Law" (2005), which in fact does have crews which can be unloaded and vehicles can be captured. It was this title that confirmed what I had long suspected. That code was already within the tables and not too hard to reach. As lame as 'Desert Law' was as a RTS game... it did utilize some interesting code in the Enigma Engine. So the team that created the game opened the door so to speak. I didn't realize others knew that 'Desert Law' existed... and used the Blitzkrieg game engine. It was never advertised as Blitzkrieg, so it would be easy to overlook. I decoded it several years ago. Thanks gagarin! There is still an issue removing a crew when the vehicle is under attack. Example: If a tank is under attack, and loses its mobility, it is pretty much a sitting duck. You can try to remove the crew, before the tank is destroyed, and save the crew. Once the tank reaches about 25% HP, the crew is killed. So if some crew has not yet been removed, they are lost. You might save 3 of the 5. While this is realistic in a battle situation... the likelihood is the surviving crew will be killed from the 'area 2 effects' of the attacking weapon. The crew will not move away from the tank until the other members unload or are killed. Because the tank crew is a squad, they try to assume the default or defensive formation (prone). So that still needs some work. Earlier I suggested that unloaded crews become infantry... well that is true, because all Soldiers are infantry first, and their specialty is 2nd. Another aspect of 'Desert Law' is their use of CUT SCREENS. The programmers actually overhauled the LUA Scripting with the xml code to accomplish the IN-MAP Cut Screens... this could have a new life in GEN II. Imagine in-coming messages from HQ by splashing a picture of IKE with his message in the center of the screen. I had not even considered this in the beginning and still need to work on this code a little to make it viable... but it is already in our reach. This was one of those low-priority things when I started the project in 2010. Some of you already knew that I had solved the TARV thing about 2001... when I showed a screenshot of a M32 towing a M4. What I had not solved yet was the crew issue. The vehicle effect is much improved when you remove the crew value. The same code that renders artillery un-manned and makes the gun capturable applies to all vehicles. I'm still working on tying up some loose ends in the code, but will likely show another screenshot of this soon, with the crew dismounted and loading onto the TARV. I am not too savvy on making videos right now... even though I have tried. With a little study on VLC I might get that to work in BK. As to Wittman's question. I have looked at this for several years. The issue is allowing a 3D model to load a 2nd 3D model on top or inside the first. I think it is possible, but we lack some of the code to make this work. First we would have to add another vehicle TYPES "SuperTransport" for example. Further--- we would have to create separate TYPES for different DOMAINS (layers) for specific uses: RAIL, AMPHIBIOUS, LAND and AIR. Then we would have to go back to MAYA and define a new 'locator' and 'part' to define what i call the 'load-platform'. Then the mechanics would have to be worked out as to how the carried vehicle is loaded, driven, pushed, towed, etc... followed by the mechanics to unload. There is no code that I have found that we can base this on, although, some of the code which tows vehicle might be employed. So out of the ideas that I have considered, this one seems to be the toughest at the moment. I'm not going to say it cannot be done, but it is not one I had been working on lately. This question has come up over the years specifically to rail cars and aircraft. But if you do it for both of those... you may as well do it for all Domains. Perhaps as I begin to complete many of the other codes, I can look at this again. It would be a good thing to have and add another level of realism. I can tell you that the same code that is used to remove a crew will be required... because the vehicle must be static and neutral-but flagged. Flagged means it is already owned, but can be captured. This code can be found in Calvin's Lua Guide as to the unit state. More later... |
|
|
|
Post by Quintaxel on Aug 25, 2014 12:29:59 GMT 1
see the appropriate files in the "Coyotes law of the desert" (if you do not know - this add-on engine Blitzkrieg) i never listen it ... and paradoxcally on the web i've just only found a video on youtube ariete, I bought this game some years ago. A Polish boxed version and an English boxed version. If you like BK then have not missed anything believe me. However as gagarin points out the code could be interesting. Edit: This thread is alive. I have been taken in speed by Gagarin and MP.  |
|
|
|
Post by gagarin on Aug 25, 2014 13:02:42 GMT 1
i never listen it ... and paradoxcally on the web i've just only found a video on youtube ariete, I bought this game some years ago. A Polish boxed version and an English boxed version. If you like BK then have not missed anything believe me. However as gagarin points out the code could be interesting. Edit: This thread is alive. I have been taken in speed by Gagarin and MP. Yes, this game is "the amateur" and is aimed at a specific audience (fans postapokalipsisa). I was interested in it for its resources and changes in the engine. --------------- Major laid out a link to download "Coyotes law of the desert". Now I'm on the phone to the network, and look for links to the game very difficult for me. |
|
|
|
Post by Major Pain on Aug 25, 2014 13:12:48 GMT 1
"Coyotes law of the desert" was also released as: Desert Law
Desert Law: Wojownicy Pustyni
Desert Law: Desert WarriorsDeveloper: ARISE StudioPublished by Cenega / 1C Company in 2005 LanguagesEnglish Russian Polish Authors• Fyodor Mukin (designer) • Peter Mukin (designer) • Pavel Ananiev (designer) • Mikhail Zhivets (programmer)
• Dmitriy Savin (programmer)
• Mikhail Sotnikov (programmer)
• Pavel Stasevich (graphics) • Igor Khomich (graphics) • Inessa Morova (graphics) • Gennadiy Ryzhkin (graphics) • Natalie Sidorevich (graphics) • Alexey Novikov (graphics) • Denis Rybakov (graphics) • Alexander Gorokh (sound) • Ivan Gergalov (tester) • Dmitriy Novitskiy (tester) • Tatyana Devyatkina (tester) games.1c.ru/desert_law/An interesting aspect of Desert Law was the first person game play... My CD was damaged some time back. If someone finds a download version let me know... it does not appear that they have a download version. |
|
|
|
Post by fallschirmjager on Aug 25, 2014 13:35:58 GMT 1
If Major Pain had finished and published his "MOD" that would be probably the best Blizkrieg Mod in the world  FJ |
|
atlas555
General
I know not what course others may take. As for me, give me liberty or give me death.
Posts: 1,072 
|
Post by atlas555 on Aug 25, 2014 13:46:00 GMT 1
If this mod becomes reality(hope,hope)-what does it mean for all BK 1\BHRT maps, chapters ect existing? Will they all become unplayable and all new missions and chapters ect. will need to be made? I worry that we don't have the number of mappers that we had back in the BKP days.
|
|
|
|
Post by Quintaxel on Aug 25, 2014 15:03:52 GMT 1
... My CD was damaged some time back. If someone finds a download version let me know... it does not appear that they have a download version. ... I'll check if I can dig up the my copy Desert Law. It seems that there is also a German version of the game. www.amazon.co.uk/HMH-Desert-Law-German-Version/dp/B000JMJZNW |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 25, 2014 17:04:32 GMT 1
Major Pain said: As to Wittman's question. I have looked at this for several years. The issue is allowing a 3D model to load a 2nd 3D model on top or inside the first. I think it is possible, but we lack some of the code to make this work. First we would have to add another vehicle TYPES "SuperTransport" for example. Further--- we would have to create separate TYPES for different DOMAINS (layers) for specific uses: RAIL, AMPHIBIOUS, LAND and AIR. Then we would have to go back to MAYA and define a new 'locator' and 'part' to define what i call the 'load-platform'. Then the mechanics would have to be worked out as to how the carried vehicle is loaded, driven, pushed, towed, etc... followed by the mechanics to unload. There is no code that I have found that we can base this on, although, some of the code which tows vehicle might be employed. So out of the ideas that I have considered, this one seems to be the toughest at the moment. I'm not going to say it cannot be done, but it is not one I had been working on lately. This question has come up over the years specifically to rail cars and aircraft. But if you do it for both of those... you may as well do it for all Domains. Perhaps as I begin to complete many of the other codes, I can look at this again. It would be a good thing to have and add another level of realism. I can tell you that the same code that is used to remove a crew will be required... because the vehicle must be static and neutral-but flagged. Flagged means it is already owned, but can be captured. This code can be found in Calvin's Lua Guide as to the unit state. More later... ________________________________________________________________________________________________ Thanks friend for your kind reply. I my question makes sense. We always receive reinforcements directly on the maps, but there are trains that provide infantry, so I thought to transport vehicles would be more fun. As you say add more realism to the game, which would attract players, it is a dynamic added to the game. Imagine sabotage stations. I have seen this at some video of Blitzkrieg III. Greetings. |
|
|
|
Post by keepitsimple on Aug 25, 2014 18:34:33 GMT 1
Major PainHow about seasons? Any changes here? We now have at present four seasons type. Summer, Spring, Winter and Africa. The latter two needed specific skins for units where for object it seems optional. Is possible to make the winter skin use for unit also optional? Have the standard base color if no specific skin is present? And could there be more then four seasons like a season called Pacific and hence have pacific skins? It would open the road to having summer1940, summer1941 etc skins. This would be nice especially with the optional choice of specific and base skin.
|
|
|
|
Post by hungaryblitz on Aug 25, 2014 18:45:29 GMT 1
Major Respect!
That's a lot of work!
Okay, I'm interested, it starts my fantasy.
These options are a new impulse, interesting missions etc..
Just a short question:
Is it possible models running animation? (To move the horses' feet and the wheels or tracks rotate .)
|
|
|
|
Post by Major Pain on Aug 25, 2014 19:48:21 GMT 1
LOL...Best MOD in the BK world... I like it but you guys are reaching pretty far.
About the past maps... yes that might be an issue with changes to the terrain layers. The models will not present an issue except perhaps the crew advancement.
What I envision is maps could be converted but that will of course take mappers and time. Do you guys think this issue might cause the project to fail?
What I am trying to do is solve many of the things that we have talked about over the years. Some of these changes have been talked about since the very beginning when we first exposed the open-platform code. When that was getting looked into, we were able to make major advancements in the game. Once many of us understood how the game was created, we looked for answers to some of these questions.
I'm not the only one that soon realized that we were handcuffed by the EULA and could not get to the deep source codes. But some of the changes in GEN II do not require that. I only have to create a new .dll file to get into the tables and binaries and overwrite some of the data. All of the data is referred to as Elements in the code. I can access much of it from outside of the game engine. I spent the last couple of years mapping exactly what each Element is and does. This also applies to how the game maintains the data for Campaigns to track Commander names and unit attributes. It also tracks how many killed and lost, and how many times you used aircraft and resupply. All of these Elements are referenced in the Open Code, but ignored it for years... now it is mapped.
But since I want to go much further, I remain hopeful that NIVAL will agree and let me open the code to the rest of the sweeping changes. As you all can see, there is nothing that I have talked about that has not already been applied before in the game engine. What I plan to do is bring it all to this Project, and much more.
There are a couple of very important .ddl files that provide much of the game play data: ailogi.dll and gamett.dll. These are key to how the game plays and define much of the table data. The ui.dll provides the data for the User Interfaces, like Menus and Player Prompts.
Other .dll files
mfc42.dll: A Microsoft Foundation Class (MFC) library required by some Windows programs to run.
msvcp60.dll: A .dll file (Dynamic Link Library) is a special type of Windows program containing functions that other programs can call. This .dll file can be injected to all running processes and can change or manipulate their behavior.
msvcrt.dll: It provides programs compiled with versions of Visual C++ as well as a typical set of library functions required by C and C++ programs. These include string manipulation, memory allocation, C-style input/output calls, among others.
gfx.dll: a type of DLL file associated with 3ds Max developed by Autodesk, Inc. for the Windows Operating System.
net.dll: A NET FRAMEWORK library. It is not a typical .dll file.
binkw32.dll: Controls how .bik files are to be played. (BINK files are a video files, such as the allies_in.bik)
anim.dll: defines how the 2D Sprites are displayed and operate
bugslay.dll: a windows registry that plays an essential role in supporting the successful and smooth running of different kinds of computer programs, and also has one or more functions on such parts as communicating the hardware and various applications, supporting computer users to open the associated file and programs, and hoarding the computer configuration and system settings on it.
fmod.dll: a library that used by many popular Windows games and entertainment programs to provide audio functionality, while the file of Fmod.dll is responsible for processing related audio settings and options.
image.dll: a type of DLL file associated with Nero developed by Ahead Software AG for the Windows Operating System.
input.dll: a library created by Microsoft that defines Cursor acton, animated icons and language support.
scene.dll: Created by NIVAL INTERACTIVE. The .dll controls scene changes as well as Alt-Tab controls.
sfx.dll: a file associated with Third-Party Software developed by Apache Software Foundation for the Windows Operating System. NIVAL INTERACTIVE created this specific file which expanded a bi-operational capability for several functions in the game to be shared by several processes simultaneously.
streamio.dll: a file associated with Pinnacle Studio Version 12 developed by Avid for the Windows Operating System. Provides support for MPEG file association. NIVAL INTERACTIVE created a add-on file for the purpose of Sound Card cross-platform access.
More later...
|
|
|
|
Post by Major Pain on Aug 25, 2014 20:20:04 GMT 1
Major PainHow about seasons? Any changes here? We now have at present four seasons type. Summer, Spring, Winter and Africa. The latter two needed specific skins for units where for object it seems optional. Is possible to make the winter skin use for unit also optional? Have the standard base color if no specific skin is present? And could there be more then four seasons like a season called Pacific and hence have pacific skins? It would open the road to having summer1940, summer1941 etc skins. This would be nice especially with the optional choice of specific and base skin. I have not looked much into seasons. I cannot think of a reason that work can not be done in this respect. The code is pretty straight forward and almost anything is possible from what I have seen. Seasons are defined within the open-code so as long as it is included in the table, with the correct associations, i would think it would be possible. I have long thought about changing the way unit skins are handled. Originally I considered using an array to store multiple skins on units and using a master .xml file that randomly selects the skin used. It would use the same code as how ack sounds are selected. Example: The .xml file defines several ack sounds. It also tells the game engine the chance in a percentage that any ack can be selected. The following is from a the Italian acks I'm preparing. These are the acks for Affirmative and each has about a 12.5 chance of being selected. <base> <RPG> <KeyName>italian infantry</KeyName> <StatsType>Ack</StatsType> <Types> <item Type="0"> <Acks> <item Probability="12.5"> <Sound>ack_italian_infantry_00_Positive_01</Sound> </item> <item Probability="12.5"> <Sound>ack_italian_infantry_00_Positive_02</Sound> </item> <item Probability="12.5"> <Sound>ack_italian_infantry_00_Positive_03</Sound> </item> <item Probability="12.5"> <Sound>ack_italian_infantry_00_Positive_04</Sound> </item> <item Probability="12.5"> <Sound>ack_italian_infantry_00_Positive_05</Sound> </item> <item Probability="12.5"> <Sound>ack_italian_infantry_00_Positive_06</Sound> </item> <item Probability="12.5"> <Sound>ack_italian_infantry_00_Positive_07</Sound> </item> <item Probability="12.5"> <Sound>ack_italian_infantry_00_Positive_08</Sound> </item> </Acks> </item> The same code likely can be used to select various skins for tanks for instance. The problem is storing that information in the table as each tank populates the game. I have not tested it thoroughly. I changed my mind about a couple of things on creating individual tank identities. My latest idea is based on how Core units are maintained in Campaigns. I'm thinking the same code could be applied in single player maps. Then each occurrence of a PzIV_h would be a separate identity. That has to be solved before random skins can be utilized. The other option is to use the Core code and provide a list of tank skins which would be used in order. So the chance of random selection does not create the same skin 5 times from the random seed, and each skin is used once. When you apply this to seasons... you can see that this could get pretty complex. We already have the three seasons, each require 2 skins, live and dead. If I integrate several more damage skins into the HP changes, then we would have three more skins between live and dead. This would work on the same codes used for buildings with the 2nd condition of damage. (That is another project I'm considering as well.) So now we have 5 skins for each season or 15 for all of them. So let's think about this a little for a moment. If I use the same script code to create a identity system for each unit, we could have several skins in one file for the same tank. So let's create a number of skins based on a tank platoon. Now we include the skins for another 4 tanks. So now the file has 75 skins to cover 5 tanks identities. See where this leads? I hope I explained this well enough. There really is not a limit to what we could do. Most of the code is already there to do this. Horse animations has always been possible. It is a matter of creating the images and frames for the sprite sheets. It will be a lot of work, but I have a few ideas where this can be added if I can gain permission from another game platform. There are already animated horse Sprites that use the same technology and support. It is a matter of converting the images and sprite sheets to BK. One issue would be mounted horses however. The horse and rider are one unit. The rider cannot dismount or a hose cannot be mounted. Horses that pull wagons would be the same code and process as infantry pushing artillery. The wagon would be a 3D but the horses would 2D. We simply add the code which defines gunner and call them horses. You know how this works... because you have already done it. Currently, you can already do this and just plug horses in instead of gunners. Of course that class and TYPE has not been created yet so there is a hitch. You would have to use one of the gun definitions to replace gunner with horses. The easiest would be howitzers. Then you would have to re-TYPE all howitzers to heavy guns. Create the horse team and you have it. I hope that answers your question. Thanks. More later... |
|
