darwin
Stariji vodnik
Boy, I can just imagine the look on my wife's face when she sees I bought this!
Posts: 63
|
Post by darwin on Jan 4, 2011 16:30:40 GMT 1
I know this question was answered in BKHQ, but I seem to have remembered it wrong and now I need to ask. How do you add units to BK? I moved the AFGUnits.pak file into the data directory and that didn't work. So I extracted the files and merged the modobjects.xml data into the objects.xml file and they still don't appear in the map editor. I'm trying to make my first map (set in France, 1940) and I'm learning just how talented you mapmakers and modders really are. So what am I doing wrong?
|
|
|
Post by Major Pain on Jan 4, 2011 18:10:10 GMT 1
Send me a PM with your email address. If you don't have the BK How To Tutorial, I'll send it to you. It covers the file system.
A brief version of what you need to do:
Units must be in the correct folder in the file system.
data
-----units
-----------technics
---------------------allied
----------------------------tanks
-----------------------------------US_M4A1(76) <----This is the unit folder
In the objects.xml.... the unit listing must have the correct path (location) so the game can add it to the database.
<item>
<name>US_M4A1(76) </name> <type>mesh</type> <game_type>unit</game_type> <path>units\Technics\allies\tanks\US_M4A1(76) </path>
</item>
If all of this is correct, the unit should appear in the game editor for use. One single typo will cause failure or crash.
I hope this helps.
MP
|
|
darwin
Stariji vodnik
Boy, I can just imagine the look on my wife's face when she sees I bought this!
Posts: 63
|
Post by darwin on Jan 5, 2011 6:46:14 GMT 1
@ MP. Well, everything looks okay. The only thing I could find was the words were not capitalized, but that didn't change anything once corrected. None of the units appear in the mapeditor. At least the game doesn't crash.
I guess I'll wait for the tutorial and see what I can learn from that.
Thanks for your help. I really appreciate it. ;D
|
|
|
Post by Major Pain on Jan 5, 2011 8:23:08 GMT 1
I just thought of another reason that you could be having an issue.
Which versions/addons of BK do you have?
If you have more than one, sometimes the mapeditor will not read from the correct data files. It stores a location of where it thinks the folders are and there is no way to reset that. So if you have two mapeditors... it may be reading the wrong files.
let me know on this... I'll tell you how to fix that.
MP
|
|
|
Post by altheogre on Jan 5, 2011 13:24:43 GMT 1
@major pain.
I am interested in your observation about multiple versions of BK and the map editors.
I use BK1 and RT, with versions of each on my hard drive and also versions of each on an external drive, so 4 in all. They all run different mods.
I have had odd instances of people not be able to load and run certain maps I've created when I have no problem at all, even when I re-install an instance of the game back to a vanilla state. I'm now wondering if this could be the root of my problem?
Could you let me know what issues you've discovered?
Many thanks.
|
|
|
Post by LouisXIV on Jan 5, 2011 14:35:20 GMT 1
Here's another thought: If you have two items with modobjects.xml files in your data folder, the game engine will only recognize the most recent one. You may have two or more modobjects.xml files in your data folder, and they conflict. This is why [BKP] always used to put a warning with any download item that contained an modobjects.xml file.
Also, if you are working with a mod, the game engine will not recognize any modobjects.xml files in the data folder. It will be looking in the mod folder. Your best bet there is to copy the items folders into the correct location in the mod, then add the contents of the smaller modobjects.xml file to the one in the mod.
|
|
darwin
Stariji vodnik
Boy, I can just imagine the look on my wife's face when she sees I bought this!
Posts: 63
|
Post by darwin on Jan 5, 2011 16:47:27 GMT 1
I just thought of another reason that you could be having an issue. Which versions/addons of BK do you have? If you have more than one, sometimes the mapeditor will not read from the correct data files. It stores a location of where it thinks the folders are and there is no way to reset that. So if you have two mapeditors... it may be reading the wrong files. let me know on this... I'll tell you how to fix that. MP I have the Anthology version which has two mapeditors. I have Achtung Panzer installed as well as numerous mods of all types. I also have a copy of CFCS which has it's own mapeditor. So I guess that gives me three copies in three subdirectories of my anthology folder. I have many .pak files of custom skins and units. I'm sure that many of those have a modobject.xml file included. But since I copied the .xml files into the object.xml file that shouldn't be the problem in this case, would it? I have the mapeditor set to "no/any mod", unless I am working with a specific mod. Once I'm done I revert the settings back to "no/any mod".
|
|
Ocelo
General
Map Artist/Eastern Front enthusiast
Posts: 1,400
|
Post by Ocelo on Jan 5, 2011 17:08:03 GMT 1
I'm sure that many of those have a modobject.xml file included. But since I copied the .xml files into the object.xml file that shouldn't be the problem in this case, would it? Just use a Thumbnail version of the object list when placing your units/objects. Don't touch ANYTHING that has no icon available. This is a very good indication that this entry has no files in the DATA folder, which is why it couldn't find an icon. If you try to place this on a map, the whole editor will crash to desktop.
|
|
darwin
Stariji vodnik
Boy, I can just imagine the look on my wife's face when she sees I bought this!
Posts: 63
|
Post by darwin on Jan 6, 2011 5:50:42 GMT 1
Just use a Thumbnail version of the object list when placing your units/objects. Don't touch ANYTHING that has no icon available. This is a very good indication that this entry has no files in the DATA folder, which is why it couldn't find an icon. If you try to place this on a map, the whole editor will crash to desktop. Oh yeah, I've been down that road before. I discovered that fact when I loaded an RAF vehicle set. The Austin trucks had the wrong path in the .xml file and I clicked on the gray square without an icon and the editor crashed and burned. But that was an easy fix. This one is not so easy. But I'm going back to work on it now. Wish me luck!
|
|
|
Post by Major Pain on Jan 6, 2011 12:46:01 GMT 1
Sorry for late reply... job has kept me busy for the last 24 hours.
The issue of several mapeditors is not well documented. Unfortunately, the MapEditor stores the location of the objects.xml and the data folders. There is no way to reset the path and switching to a different Map Editor does not get around the issue. They all share the same .dll file no matter where it is. The location is stored in resident memory within the MS .dll.
So the only thing you can do is maintain a master file that enables all versions of BK to share the same exact data files. Most times this means making copies in each primary version of BK.
In a nut shell, the data.pak and various .pak files must all be the same. An issue arises when you have the same units in different .pak files... the game and Map Editor use the version with the latest date... so it is possible to not have the one you want.
This is where a complete understanding is necessary of how to rearrange your .pak and source files for consistancy and sharing.
I rebuild all of the primary files into a master .pak file and then rebuild the object.xml around it. I have found it beneficial to keep a mirror file with all .pak contents uncompressed under a folder named data2. If I need to work on a unit, then I can make the modifications, test it, then move it into the .pak file when I'm done. I can access the entire data2 folder by simply renaming the folder to data. When finished, I rename it back to data2. Lately, since I am constantly working on and testing new models, I keep the data folder in place.
A trick that I use occasionally is to zip or compress a portion or selected parts of my data folder. For instance, if I don't expect to work on terrainobjects, I might compress those files, then name the root data with the file name terrainobjects. Then I can change the extension from .zip to .pak using the rename command.
Many users are not aware that you can actually uncompress all of the .pak files into the data folder. As long as each file is located in its root folder, they are completely operational in the game. You can run BK without a single .pak file. The use of .pak files is beneficial for reducing the amount of storage on the hard drive, as well as transferring files in a download or upload. A .pak file is nothing more than a .zip file renamed to .pak.
Now the issue of locating all of the versions of BK in a single directory folder. It will not work. Since each version is dependant on specific .dll files (Direct Link Library), issues develop when two game versions share those .dll files. Of course, it is impossible for two game.exe to exist in the same folder, but attempts have been made to rename them to gameRT.exe or gameBH.exe without success. There is a checksum within the .dll modules that verify the game version and name that is accessing the file.
The core game.exe and MapEditor share the same .dll files, but only specific portions with each. When you compare ,dll files, you might see a file size between two that looks the same, but once you look inside, you quickly see they are quite different. The file size is predetermined and loaded with nulls where data is not established. The loader file maintains a directory of the specific data locations in each file.
The game is built around module loading.... what we used to call (in the old days) bootstrapping. In this case, because of vast improvements in memory and task managing, todays modules are all loaded into specific memory locations and only called when needed. That has the benfit of reducing STACK filling and Memory Buffering.
The entire contents of .pak files, the objects, is stored in a relative database in memory. It is Relative because the game maintains a master file of where each object is stored, down to the parameters of each. This way, the game only has to reference what it needs when it has reason. So think of your .pak files as modules which load the database.
I have not found a limit to the size of the database yet, but I believe, based upon what I have investigated, that it can handle up to 1024 x 1024 objects. Why 1024? That is the basis for 1000 bits, 1000 kilobytes, 1000 megabytes, etc... Basically... one million. With the inclusion of binary codes, using Octals and Radix, the math and commands can be exceptionally carried out seamlessly.
If you recall your math class you all remember binary math, right?
Remember the 0s and 1s. Zero means OFF or no data, One means ON or data. There are eight data locations stored within an Octal, with eight Octals within a Radix... or 64 locations.
The eight locations within an Octal may look like this:
0 0 0 0 0 0 0 0 = Zero
1 0 1 0 1 0 1 0 = 85
Each of the locations has a value.
Location....Value ......1...........1 ......2...........2 ......3...........4 ......4...........8 ......5..........16 ......6..........32 ......7..........64 ......8.........128
All computer languages derive from this binary math... affectionally called binary code or machine language.
We can store numbers between 0 and 256 within one Octal, eight digits or locations. This is where the term 8-bit machine came from. Today we use 32 and 64 bit machines, which are faster and more powerful than the computers used by NASA to put a man on the moon.
A 32-bit machine uses 4 Octals to store memory locations as well as codes. A 64-bit machine uses a Radix or 64 locations.
Virtually all of the programming commands within BK are built into binary arrays or codes. This is how the developers could use 2-D sprites for infantry and buildings and 3-D models for tanks and trucks at the same time. The game can assess 100,000 necessary files and unit parameters quicker than you can blink your eyes.
The use of binary codes (or machine language) on a 32 bit machine is not 4 times fater than a 8 bit machine, but almost 4100 times faster. So those of us that began with BK in the beginning have seen major progress in both speed and graphics over the years. The original models used very low poly counts. Todays models which have more detail are not hampered by the graphic limitations from the past.
Sorry for the long post, but the more you understand the system, the more producitve you can become.
MP
|
|
darwin
Stariji vodnik
Boy, I can just imagine the look on my wife's face when she sees I bought this!
Posts: 63
|
Post by darwin on Jan 6, 2011 16:52:53 GMT 1
@mp, some of that I remember from a couple of DOS courses I had to attend back in the late 1980's. Things have changed.
So if I understand you correctly, I should only have one mapeditor? I knew about uncompressing the .pak files. Data storage is not an issue with me, so I uncompress each .pak file as needed and then leave it that way.
So I'll remove all the custom unit .pak files and unpack them one by one, merging the modobject.xml and object.xml files; running the mapeditor each time to see if the icon appears. That way I'll find each conflict. Laborious but effective. Unless you know of a better way.
Thanks for your knowledge and patience. I'll let you know the results.
|
|
|
Post by Major Pain on Jan 6, 2011 20:23:06 GMT 1
Perhaps someone can provide you with BK Pak Merger and BK Objects.xml Builder. I have them on another machine but not handy at the moment.
Easier to rebuild the objects. xml from the .paks or data directory.
|
|
|
Post by Major Pain on Jan 7, 2011 3:40:56 GMT 1
What I should add to my comments is in regard to the Map Editor ability to Browse for the map you want to work on.
The Map Editor can browse into other than it's home directory, but since it is dependant on specific .dll files, it may crash in another location.
What I usually do is put all of my working files (units, objects, maps, etc) in a single location with the master object files. That way I have total access to all of the latest data, if I should not update another versions system files. You must keep up with the objects or maps you create if they are designed for a specific version.
Once you complete anything, immediately make a copy, move it where you want it and test it. Be sure to make notes on your work so you can jog your memory if time passes between work sessions.
I keep a Project Journal with catagories pertaining to my projects. As I have become much older, my memory deserts me from time to time so the Notes help me get back on track when I don't remember what I did. This is especially helpful on maps and lua script files. The Lua Files can be confusing in their own right and without notes, I might not locate the code I need or remember what I was thinking when I wrote the code.
Keeping the Journal takes work and time, but it has paid dividends back many times. Of course, I might have as many as 20 projects going at once and days can pass between sessions causing me to lose my place.
One more Very Strong Suggestion...
Always make a copy of any file that you are going to change; this includes your .pak files and map files Put those copies in a folder in the same manner as the original system. Maps in Maps, Units in respective folders. It is easier to locate your files if you need them. Always rename the copy by including the data after the base name so you know which version it is. The time stamp is not enough since it updates anytime you access it.
Example:
data.pak renamed to data010611.pak
objects.xml renamed to objects010611.xml
I hope this helps...
Some may consider this a bit overkill, but when you get old and ugly... you will thank me.
MP
|
|
|
Post by LouisXIV on Jan 7, 2011 12:38:48 GMT 1
I have gone through the files of my own produced missions, and am now going through the hundreds - if not thousands - of other missions I have saved. I'm opening them up to see which side the player is and where it's located, so I can sort them out by player side and year.
While I'm doing this, I also can note which version of BK or mod it is for. Then I change the name of the game to indicate this. If I have no problem opening the game up in BK, then it's obviously for BK. If the mission is called Scilly, then I will rename it [BK]Scilly. That way I know in the future what game engine to use it with. If it has a modobjects.xml in it because of new units, I further rename it [BK]Scilly[ModO].
If it won't load with the BK MapEd, I try it with a mod. If it's a modded mission, it will tell me, Mod changed from .... Then I can mark it as, say, [HF]Scilly.
If it tells me, Mod changed from no any mod .... then I check the loadmaplog.txt, where I will expect to find some typical RT/BH units. Then I can label it [RT]Scilly.
Now if only I can get everyone to start labelling their missions like this to show the game engine that was used to make it.
|
|
darwin
Stariji vodnik
Boy, I can just imagine the look on my wife's face when she sees I bought this!
Posts: 63
|
Post by darwin on Jan 8, 2011 17:54:00 GMT 1
Sorry for the delay in posting, but work and family...
@mp, so I guess I'll leave the map editors as they are, since I do not believe the problem is there. I know this because I have been playing around loading, moving, and copying unit files without too many issues except for one which I'll touch on later. I've loaded units, buildings and bunkers from various modders without any problems, and modified some vehicle characteristics to bring them more in line with their actual use. I use firstobject xml editor and I have had no issues with it to this point. Thanks for your tutorial, it was a big help!
@ LouisXIV, That's a good idea. I like the [BK] in front of the map name. There is no guess work to determine which folder it goes into. Like MP wrote, the more notes you use, the easier it is to keep things straight.
Anyway, the problem I alluded to above concerns the P-38 Lightening. I wanted to make a fighter version and so I have. It works fine, but the checkerboard pattern is the only texture I get. My test map is spring. I copied the original files into a renamed directory, added the information to the objects.xml file, edited the unit's .txt files and the 1.xml file to reflect the new mission, location, etc. But all I get is the checkerboard pattern. The original version has the correct textures in the game. I cannot think of, or find, any other files that need updating. So what have I not done right? Would someone like me to e-mail a .pak file?
|
|