| |
- Are there any plans to make it so we can add civilizations rather than having to replace existing ones? Currently, the civilizations are hard coded (enumerated). We can add civilizations now but only by replacing one of the civilizations that come with the game.
You are correct, the actual number of civilizations and regions is hard coded in the game. So modders can go in to change an existing civilization, but they can't add a new one. The good news is: we took this key community request into consideration and have addressed the issue head on. The expansion pack’s Civilization Editor allows you to add civilizations! Enjoy.
- Is there an importer/exporter or other application that can be supplied to allow us to add Gamebryo format models and textures into the game? Currently, there have been modelers expressing interest in creating new community made units and buildings, but the proprietary format of Gamebryo is preventing this.
We certainly know how important getting the mod community an exporter is, and we’ve been working hard to address this need. The exporter is ready to go and is now in the final stages of clearance. This should be your way soon, we’ll keep you posted!
- When importing new ICONS into the game the coloration is all incorrect. We suspect this is also Gamebryo related but, the question is: can you tell us how to create icons so that the colors will not be altered by the game?
To address this issue, we’d need to have exact information, as well as exacts on what you’re doing here to debug it. We could then have a member of our team check this out.
- In the Map Editor we can set how many territories we want to appear in a map. However, in a random map in multiplayer or skirmish, this option is unavailable. Is there a way to extend this into the multiplayer and skirmish options? (This will make it so we can play large maps with larger sized territories which are fewer in number. This is a request we have seen several times).
There isn't any way to do this currently, it’s certainly something we can keep in mind for the next patch. However, we believe there is a way to change it globally in one of the config files (setting target tiles per territory).
- Currently, when modding this game it is easy to cause exception errors that can result in HOURS (even days) tracking down a very simple problem. Can you add a little more verbosity into the error handler so it at least tells us what file had the issue? This is more an issue after patch 1.1. When 1.1 was released it broke some mods that existed. It was difficult to determine why they broke. Since this may happen in future patch releases it is a reason NOT to attempt to mod this game. With more verbose error messages this would not be as much a barrier.
Well, we certainly want to help you to our best! We really tried to make the error messages as useful as we could. If there are some that aren’t - this was not a malicious attempt to make things difficult for you. Having no idea which errors you are seeing, we don’t know where you need more information. Again, we would need to be given particular cases to test, we have to have more information here.
- Are there any plans to let us get to the lower level AI routines and perhaps enable us to create our own DLL files to modify the AI significantly?
Yes, we’ve done some work on the scripting system. This is in patch 1.2. You can’t modify the dlls, but you can make mission-specific dll-compatible text files for scripting.
- Currently the RPS system stored in dbcombat.csv has hard coded enumerated RPS groups. It would be extremely beneficial to enable us to add our own RPS groupings. Is this at all something you can work into a future patch? We can adjust it unit by unit currently but, that results in a HUGE file. Simply, being able to add more RPS categories will make balancing or rebalancing this game much easier to accomplish.
Unfortunately, at this late stage of the game development process, this change cannot be implemented.
- Did you include the updated ZIPS files with patch 1.1? If not, can we get them? (This may be part of the reason one of the latest major mod attempts failed).
Not all files needed to run the game were included with the patch. Only those things which CHANGED in the patch were included, so modders will need to unzip the original files and add anything new on top of that.
- If some serious modders get going on some large projects, is there anyway to facilitate quick communication between those modders and a developer? This usually proves to be a vital step in any serious moddable game title. It can make a huge difference.
We’ll certainly do our best to meet your needs. We’re here for you and for Empire Earth II long term. As you requested, the VUG team created a special place on the Empire Earth II boards dedicated specifically to the mod community and its needs: (Click Here). The Empire Earth II Mod Maker Forum awaits us! We’ve alerted the Mad Doc team to post to this new spot – and we’ll do our best to help out here.
- Is there any way in the future releases to make units able to path through trees and over mountains? This was possible in Empire Earth and could have a major strategic advantage. I know some of this can be done by editing dbmovement.csv, but units still cannot path through forests and such. Rivers works great though.
No, sorry.
- For there to be support for the modding community we need a way to choose from multiple mods or no mods so that we do not have difficulty joining games with people using mods.
Unfortunately, this is largely just not feasible. It would likely require an unreasonably large amount of design and programming work to make this happen for this iteration of the franchise.
- Currently, when dealing with required technologies, if a tech requires another tech that occurs later in dbtechtree.csv the game crashes. This can be dealt with by shifting things around in the file but, this would be a nice place to have a slightly improved parser/interpreter/etc that can deal with out of order requirements. Furthermore, if we say require a TECH from (crown techs) to be researched before Archers are available. It works great except for two cases. CASE #1 - You never research the tech and you advance to EPOCH #2. The archer and its upgrades will no longer be available to that player for the remainder of the game. CASE #2 - You start the game at an epoch past the epoch where that tech is available. The archer and its upgrades will be unavailable the entire game. Are there any plans to resolve these issues?
No, there are no plans here.
- In the DBVisualLOD.csv and db_texture_convert files, we need element definitions, What are those elements?
This question is not quite clear to us. What are “element definitions?” If you want to know what the different columns do, we can get back to you with that information.
- Is there a way we can change a unit's movement style? Example: Leaders who act silly when they move?
No.
- Is there a way we can tone down the movement of heavy artillery which seems to move even when the target is still easily within range?
This is one we’ve addressed and has been improved in Patch 1.2! (Units will not move when ordered to attack, move if their target is already in range).
- Is there a way to get units to maintain formations better? Formations break down much too quickly in this game. If yes, where do we start?
No. Formations are all code driven.
These next two questions are related…
- Is there a method to change the graphical image of the UI. If so, how?
- spr_flag_lose_left_0,"AnimWinLoseFlag_01.tga",0,0,96,82,(FlipU) found in dbsprite_uianim_packed.csv. Please explain FlipU and the purpose behind it. Example: When to use this and when not to. Please explain the 0,0 elements within this line.
Regarding the (moddable) appearance of the UI:
The appearance of the UI is primarily driven by sprite tables, in the folder db/UI/PackedSprites. The sprites themselves are primarily referenced in the widget tables (which you are highly recommended to avoid modifying), but you should be able to get a good bit of mileage out of editing the entries in the sprite tables (don’t add or delete new entries; only modify).
A sprite entry looks like this:
<NAME>, <FILENAME>, <OFFSET U>, <OFFSET V>, <WIDTH>, <HEIGHT>, <FLAGS>
<NAME> is a reference name and should not be changed.
<FILENAME> is the .tga file to use – just throw stuff in run/Graphics/UI somewhere, and it should be found. The sprite specified a rectangular area within the .tga to use in texturing the UI elements, specified by pixel offsets from the upper-left(<OFFSET U>, <OFFSET V>) and <WIDTH> and <HEIGHT>. The rectangle will generally be stretched to fit some other size area, but it is probably a good idea to keep the same size in most cases.
<FLAGS>specify some additional flags. Generally just leave this as 0, but you can also specify:
FlipU (flips the texture horizontally).
FlipV (flips the texture vertically).
Rotate (rotates the texture 90 degrees clockwise, done *after* flipping). (There are other sprite flags, but these are really the only ones that are applicable to UI) usage looks like this (parentheses included):
(FlipU) // a single flag
(FlipU | Rotate) // multiple flags separated by |
The combination of these three flags is enough to specify arbitrary 90-degree increment rotations and reflection of a texture sample (though it sometimes involves a bit of head-scratching).
GDbHdrs/GDbSpriteDefs.h offers some additional documentation on this stuff.
Additional tweaks to the UI can be made by editing db/dbwidget_framestyle.csv, which specifies the appearance of the rectangular framing elements which appear on many of the UI elements. GDbHdrs/GDbWidgetStyleDefs.h offers a fair amount of documentation on this topic. Additionally, here is some copy-pasted text from an earlier query on the topic of frames:
Frames are made up of a set of screen polygons, the simplest case being four trapezoidal polygons (like a picture frame).
The WIDTH column specifies exact pixel widths at the set of supported screen resolutions.
The POSITION column can be one of Outer, Middle, or Inner (Outer is the default). Basically, given the nominal screen area of your actual widget, the frame may go entirely outside that area (Outer), entirely inside that area (Inner), or it can split the difference (Middle). This can be a bit confusing when it comes to positioning other widgets relative to the frame. Given a widget and its frame, there are potentially three different screen areas we need to consider -- the widget's actual screen area, the outer area of the frame (which will be different from the widget's area given an Outer or Middle frame) and the inner area of the frame (which will be different from the widget's area given a Middle or Inner frame). In my experience there is not a ton of use for Middle frames, but I switch between Inner and Outer depending on what I am doing.
The FRAME TYPE column specifies one of a variety of frame types. Basic will give you a four-polygon trapezoid frame using the eight color columns (each poly gets an outer-to-inner color gradient; this should be fairly intuitive). If using a Basic frame, the SPRITE column is ignored. For the other types, the color columns are ignored, and some form of texturing is used (the available choices are: SimpleCornerStretchedEdge, SimpleCornerTiledEdge, ExtendedCornerStretchedEdge, ExtendedCornerTiledEdge, and FourCornersFourTiledEdges). GDbWidgetStyleDefs.h has some ASCII art diagrams of these, and comments in the enumeration indicating how many sprites you should specify, and in what order (the SPRITE column will specify the first in a contiguous set of sprites -- I assume you are somewhat familiar with our sprite database…). All of the sprites must use the same texture (ie. the same actual .tga file).
Hopefully this will provide a good start for those interested in modding the UI.
As a side note, I would advise modders to add this line to their myconfig.cfg, which will provide improved error feedback (for UI tweaks and the game in general): g_warningsEnabled = 1
- Currently when units are given percentage bonuses it is typically a percentage based value. This can produce wide variances in hit points between units which can unbalance units that were otherwise balanced. Is it possible to make these percentage bonuses a fixed/static bonus so that all units that receive the bonus are awarded the same fixed amount? This generally applies to hit points.
Yes, we believe so. If you look at upgrade_factors.csv, you’ll see a column with entries which say either tt_tt_factor_percent or tt_tt_factor_simple. Simple is a straight add.
- Is it possible for additional epochs to be inserted between and after the current epochs? If not, are there any plans to enable this?
No.
|
|
|
|
