chamber, I have good news, Now I'm able to use the editor, but I don't understand nothing. how can I open a particullary file? I think tath the editor opens himself the main.pack file, but how can I open another pack?
chamber, I have good news, Now I'm able to use the editor, but I don't understand nothing. how can I open a particullary file? I think tath the editor opens himself the main.pack file, but how can I open another pack?
Last edited by ♔Lord Sean Cappone♔; August 11, 2009 at 08:17 PM.
The editor opens all .packs I think. I'm having trouble saving changes in unit_stats_land files though... I need help with it.
I had a look at this tool, but I really can't work out how to use it. It'd be much better if I was able to set which pack file was active that I was working on, and see the various layers of mod, since i always work on changes to my mod in a seperate mod pack (to distrobute for beta testing purposes).
It has some useful features, like not having to extract/import all the files i need, and the suggestion type thing for data entry, but atm I'm going to have to leave it I think, until it's a little less gimped, and stick with the razorblade that is PFM.
Could it somehow be integrated into PFM instead of the DB editor in that? I would certainly use it then.
Last edited by Mooncabbage; August 12, 2009 at 02:43 AM.
Just to say this again: I like the tool and think it's highly useful. The right-click to take you directly to the defining table is great, I just discovered that
It has a few teething problems but that's to be expected, so keep up the good work
For those of you who have trouble using it: Use PFM to create a pack containing the files you want to modify, save it, then open DBEditor. The file you're currently editing can be selected in the dropdown box at the top (below the menu). CA files will be greyed out and are read-only while the files you can mod are black. Select the file you want to change and proceed as usual. I believe most of you may still have problems with understanding how the DB files work in general and not specifically with the DBEditor.
I have huge problens with this, i am not able to add posts in the stats table, it says something about data has been removed and can be added trough something blah blah blah. I have tried copying rows from vanilla, but that doesnt work either.
Cant add my own units because those tables are required.
I understand perfectly well how the data files in general work, what frustrates me is the "safety razor" nature of this application. I understand how files override, I don't edit the default files anyway. It's great to be able to see the base, but can I set a specific load order? I'm still not clear on how you tell the app which file you'd specifically like to be working on. What concerns me is being forced to update to this after the next patch, as I can see it adding a lot of time to my release cycle, to try to work out how to use it and how to get around all the annoying safety features.
I understand that this is Lt Chamber's work, and noone is paying him to do it, but as a user of PFM I am very concerned about my future ability to mod if I am forced to use this tool.
Perhaps a decent tutorial would help to alleviate some of the problems? Certainly the ability to tell it what specific order to load the files in, and what file you want to edit, would help. Forgive me if these abilities already exist, as I said, a manual would be very helpful.
Ok so im using the my_starterpack.pack, i managed to create a unit under the units_tables\newunits_tables by over writing the custom unit thats called Irwins Privates( just going through and replacing the values with the ones i want) I got it to save the unit in that table so now i want to edit its attributes(range, reload, etc)
but when i go into the unit_stats_land_tables\my_unit_stats_land and try to add in my new unit it lets me go only so far before its gives me an error...
I get the same error every time i try to save, What does this mean?
Also how do you clone a row, everytime i highlight a row and go up to Edit to copy the copy option is grayed out...
If you understand perfectly how the data files work and how they override, then why do you want to load files in a specific order (different from the way that ETW does it)? I can only see that option confusing people.
It seems obvious to me how to tell what file you're working on. You make the table name reflect which mod and/or file it's part of. If you have generically named tables, then of course it's going to be confusing and that's more or less by design (the title bar still says which pack the current table belongs to though). This is why there is a Rename Table option!
If a 3rd party pack has overridden an ETW table, then whichever pack with that table that was loaded last will be the pack you edit when you select that table. At least that was my intention, I haven't tested that. To illustrate this situation:
- main.pack contains unit_stats_land_tables/unit_stats_land
- patch.pack also contains unit_stats_land_tables/unit_stats_land so the entire table is overridden
- some-mod.pack might also contain unit_stats_land_tables/unit_stats_land so the patch.pack's table is overridden
- at this point, if you view/edit unit_stats_land_tables/unit_stats_land, you will be viewing/editing a file table in some-mod.pack
- the current table's pack file is in the title bar; would it be much easier if it was also in the table selection combo box?
How many cases are there where overriding the ETW tables is necessary? Certainly it is not necessary for units and stats. I use override to mean completely replacing a table with another table of the same name. AFAIK, mods should almost always be "augmenting" the existing tables by adding new rows or overriding existing rows in tables named like: unit_stats_land_tables/some_mod_unit_stats_land
When rows are copied to the clipboard it's a simple HTML table, so Excel should be able to handle that. However, I don't think copying from Excel back to DBE will work. Why don't you do some research about how it works with the clipboard. I am not particularly eager to have another import/export file option like we had in PFM. Copy/paste to/from Excel should be sufficient.
I need more details about the error. Like others have done, post the meaningful part of the error message.
I don't know what kind of icon you're referring to. Post a screenshot? When the size column is "missing" I suspect you have "Freeze key columns" enabled and you aren't scrolled all the way to the left in the unfrozen section.
Did you just volunteer to learn the editor and then write a tutorial? You're too kind!
Perhaps I can reproduce this if I get the exact AUM pack file you're trying to edit. Is it small enough to attach to the post?
During development my mod consists of 3 files, the "base" or most recent stable, official release, a "beta", and a working version, that I make changes to back and forth. These are all mod files, so how does DB Editor know to load them such that the beta overrides the base, and my working version overrides the beta?
Furthermore, my mod, being as it is, a balance mod, does totally overwrite unit_stats_land, and another of other files. Infact changes to unit_stats_land for me usually consist of batch changes applying to an entire "genre" of unit, such as cavalry, light infantry, infantry.... you get the picture. As such it's generally easier for me to make my changes in excel, using the entire table. This keeps all that data in one file, rather than spread across 5-6 smaller files, overriding parts of unit_stats_land. To understand why this is important, imagine trying to increase the reload speed of all units by 10%, with the units spread out across a number of files. Perhaps better yet, imagine if I had made changes to lancers only so they were in one file, and then I wanted to change the unit size of all light cavalry, I would then have to change several files, and the problem cascades every time I want to make changes to a different unit, if I create a new table each time.
Almost ALL of the tables in my mod are designed SPECIFICALLY to override other tables. Whilst I could rename them, to make the mod tables unique, this seems needlessly complicated to me, and additionally then only overwrites the rows and not the entire table, which is the desired effect. Sounds like bad practice, but it drastically simplifies the process of making people's installations MP compatible.
is it possible to use pack file manager anymore? mine says that it has been superceted by DBeditor and then nothing. cant edit the db`s. bummer. is there a solution for that?
If you keep all these files in your data directory, then yeah that's a problem. Right now you would swap out the files with whatever variant you want to use before you start up DBE. I've already acknowledged that some kind of control over which directories are searched for pack files should be a good feature, but I don't know when I'll get around to implementing it.
It's fine to keep all your changes in one table (I never suggested fragmenting the table by unit class, dunno where you got that idea), and even to include all the rows of the original table, but your mod's table shouldn't be named the same as the original table unless you need to delete rows from the original table. I don't see how changing the name, which is very easy to do in DBE, makes things "needlessly complicated". For one thing, it makes editing the table in DBE a lot clearer!Furthermore, my mod, being as it is, a balance mod, does totally overwrite unit_stats_land, and another of other files. Infact changes to unit_stats_land for me usually consist of batch changes applying to an entire "genre" of unit, such as cavalry, light infantry, infantry.... you get the picture. As such it's generally easier for me to make my changes in excel, using the entire table. This keeps all that data in one file, rather than spread across 5-6 smaller files, overriding parts of unit_stats_land. To understand why this is important, imagine trying to increase the reload speed of all units by 10%, with the units spread out across a number of files. Perhaps better yet, imagine if I had made changes to lancers only so they were in one file, and then I wanted to change the unit size of all light cavalry, I would then have to change several files, and the problem cascades every time I want to make changes to a different unit, if I create a new table each time.
Almost ALL of the tables in my mod are designed SPECIFICALLY to override other tables. Whilst I could rename them, to make the mod tables unique, this seems needlessly complicated to me, and additionally then only overwrites the rows and not the entire table, which is the desired effect. Sounds like bad practice, but it drastically simplifies the process of making people's installations MP compatible.
As for editing the table in Excel, once I manage to get copying from Excel to the DBE table working, you'll be able to easily copy rows back and forth and edit however you want.
Ahh good news that
I was using hyperbole to see if I could get on the same page as you ^^
The reason I have all 3 files in the Data directory is because as they are all required to run the right version of the mod during development. This means the beta testers can simply remove the beta, and play the official release online, and I can remove my working version, to test with the beta testers... I also don't release a "single" version with all files contained until the first of the month, which is the stable base, to save time uploading and downloading (the mod files are quite large). So as I hope you can see, all the files have to be loaded in the right order, to see what the final mod should look like. It seems you are aware of this problem, so hopefully you get it fixed before the 1.4 patch comes out and breaks everything for me
Quite a few of my files do require me to "delete" rows from the vanilla game, so in general it is simpler for me to not rename the core files. In some cases (unit_stats_land for example), overwriting rows, instead of the table, could lead to unexpected behaviour if through some miracle, the mod is compatible with the next patch. New rows added by CA, but not adapted by me to suit the mod gameplay, would become available and have an unexpected and gamebreaking effect on the mod. So generally speaking I think it's a better idea to totally replace the table. Probably something I can find a way around but it's probably important for you to know this sort of thing when you are developing the tool, as it might not otherwise occur to you. I guess my point is not all mods are mini mods that add units/flags/skins
I am positive this has been asked before, and I am sure someone will quote an answer for me, but I will ask again, and yes I did read the entire thread or skimmed it. But I am wondering how to sort through to find the specific files tied to a mod pak (in this case Darthmod) besides looking through all possible files.
Also I was wondering if there is a way to alter all the values in a column (specifically construction/recruitment time)
Last edited by g-gaels; August 19, 2009 at 10:15 AM.
Somebody please help! I can't save any changes in any unit_tables files. I get this each time I click save!
Spoiler Alert, click show to read:
DBeditor issue... When using the dbeditor, only a few packs are showing up (mod packs) but not all.
I edited the units_tables\communal_land_units table in imperial splendour and saved it to my own mod, but when I came back to edit that mod later, it's not showing up AT ALL. Even if I re-edit the file and go to save it TO my mod, it still isn't showing up. All that's showing up, oddly, is two versions of the same table from imperial splendour, even though I only have one copy of IS in the data folder. I've tried EVERYTHING (moving mods in and out etc) to try and get the dbeditor to find my mod, nothing. It pretends it doesn't exist.
I can open the mod with the pack manager, but the pack manager cannot edit units_tables\communal_land_units for some reason, only the dbeditor can... so I'm basically stuck, unable to edit my mod further :/
My mod is saved AS a mod, not as a patch or anything... I can't think of anything obvious for why it's not working.