Brit

There's the image editor for loading images into the game. As far as the creation of the images in the first place, well, you'll need some third-party tools. I use 3D Studio to create 3-dimensional models of the units and animate them. I render them out to 2d images which I modify with scripts in Corel Photopaint. Depending on what you're doing, you may or may not need a 3d modeling package. It doesn't really matter what 3D/2D programs you use as long as they're in a proper 2d format for the image-editor to load. (I would've recommended Blender for 3D because it's free, but last time I tried to use it, it was a huge pain. Someone told me the latest version of Blender was a lot more user-friendly than previous versions, so maybe it's a little better now.)

"At target" means directly on top of the target (for example, aircraft move directly over the target before they attack). The "unit" distance means that the units overlap at the edges - this is what ground units do when they attack each other.

Oh no. Yes, please send me the .game file as well as the files inside the /PBEM directory. I'll put an email address in your private messages.

Notable Changes/Fixes: - Made changes to the PBEM system so it is more robust - including being able to tell users to update their application, recover if the game crashes, and not get messed up if a players internet connection drops or the webserver is offline. - Note: Players in a PBEM game should all update their version before continuing their game - Changed the way the random map generator creates mountains - they're more grouped together than they were in older versions - The scenario editor now lets users change the flags of units but keep the same owner (this would allow one player to control units under several different flags - e.g. British and American flags) (See image below*) - Added a distance tool to check the distance between places on the map - Fixed bug: couldn't delete units from the unitset 'free units / landlocked city' list - Fixed bug: the cost of upgrading units was displayed incorrectly if the unit was inside a unit-group - Fixed bug: the game would tell players that new research orders were needed even after all technologies had been researched - Fixed bug: when loading games that have ended, players couldn't switch to 'gods eye view' - Fixed bug: game crashes if the militia unit is not setup correctly in the rules editor - Fixed bug: attack satellites would sometimes automatically launch into space if enemies were nearby - Fixed bug in the airfield radar - radar detection was not setup correctly - Fixed bug in the combat simulator - it gives bizarre results if a unit has more than 100 HP - In combat, it's no longer possible for both units to simultaneously kill each other *Image: This will allow player 1 (on the right) to control units under the British, American, New Zealand, Australian flags and player 2 (on the left) to control German and Italian units.

It blocks an area slightly smaller than the circle around the base of the unit (but it extended up and down a little larger than the circle you see). Probably not.

Unfortunately, yes, you are correct.

Yeah, I do want to fix that. It won't be in the next update. Also, I've been getting a lot of bug reports and suggestions over the past few weeks. Most of them are coming in via email (rather than the forums), so I've got my hands full.

"Prone" is a special combat type used for landed air-units (aircraft, missiles, etc) and docked sea-units (ships and subs). They don't fight with their normal defense numbers. They're much weaker. It also allows units to attack them that couldn't normally attack them. For example, infantry can't normally attack ships or submarines, but they can attack them if they are docked in a city. The "can block and be blocked" is used by ships and ground units. It means units can't just pass through each other. Aircraft and submarines cannot be blocked. The sub-targeting is not being used right now. Originally, it was used to allow cruise missiles to target specific city improvements. I may turn that back on at some point, but there are some issues to work out (issues like: what if a city has a factory but that factory is destroyed, and player X doesn't know it was destroyed. What happens if player X targets a cruise missile on the factory? Nothing?)

I've seen the AI waffle like that before. I was hoping it doesn't happen often enough to be too much of a problem, but I'll have to look into it.

Oh, hey. Didn't notice you were in Breckenridge. 1. No, units can't construct fortifications. 2. Freighters were an idea I had that was partially implemented, but isn't functional. 3. Oh, that should be fixed.

Thanks. Glad you like the video. I was thinking the other day that I could probably create some tutorials - that would help people learn how to create some of this stuff, and also display some of the features of the game. I'm sure there's plenty of videos I could make if I started doing tutorials.

What exactly is going on here? You're playing a regular multiplayer game (not a PBEM game) and something is wrong with the submit/unsubmit system?

Hello. There is no update file you can download and apply. Updates can only take place through the update system. However, I can give you a download of the latest version with all the latest patches. The downside is that when the next update comes out, you'll be back to using the updater again. (Maybe I can come up with an update-file in the future.) Send me a private message.

I fixed this one today. What was going on here is that the city was showing the final production (not population) value. (For example, if a city had a factory, it's production value would be higher than its population.)

Could you send me a copy of your ruleset?

What's going on in cases #1 and #5 is that I'm not remembering these events as game-events. As a result, they aren't in the turn-replay, although, it would be useful to add them to the game-event system. As far as #2 "God's eye view" - I recently fixed a bug with the god's eye view that happens if you load an old (finished) game. (The fix isn't available until the next update.) Is the issue you're seeing related to loading a game that is already done, or are you ending a game and you're still unable to switch over to god's eye view? "3) During game playbacks, transports sometimes disappear, showing only their contents." This is happening with the latest build? Do you have any saved games where this can be reproduced? I'd like to take a look at them. I'm not sure what's going on with issue #4. Although, the unit bar doesn't necessarily get redrawn continuously, so it might be showing old information. Again, if you have any saved games where this happens, I'd like to take a look. By the way, I'll put an email address into your private messages if you want to send any files to me. (I'd post the email on the forums, but bots might harvest it.) [uPDATE: Nevermind - I couldn't send you a private message for some reason. I think you might have the email address from sending a bug report earlier, though.] Someone mentioned a problem with satellite launches a while ago, and I just got a bug-report yesterday about the same issue. I tracked this down and verified it. What's going on is that the field-orders of the attack satellites is set to "default (aggressive)". As a result, they'll auto-attack (which means auto-launching) when enemies are near. This is fine for most units, but attack satellites shouldn't auto-attack. I've changed this now, and the fix will be in the next update.

You're right. This is fixed in the next update. That actually sounds more like an issue with the AI attacking units it can't see. It would probably work differently with a person on the other end. Sounds reasonable. No, grouping units doesn't give an advantage.

I took a look at your file, and figured out why it was crashing. You've got the rules setup so that the default militia unit is "militia" (just like in the official rules), but you've got no unit named "militia" in your rules. I fixed the code so that it won't crash when this happens. (That fix will be in the next update.) But, in the meanwhile, you can avoid this problem by either removing "militia" from the militia list, or creating a militia unit. Also, the AI was getting a little messed up because you've got no air-units in the rules. I fixed this glitch in the code, as well, but I don't know if it will cause problems for you in the meanwhile.

Could you send me a copy of your custom ruleset? I'll try it with your file.

An update is now available that fixes the crash. Let me know if you have any other problems with crashes (just in case there were two crashes and I only tracked down and fixed one of them).

That's too bad. I have two other people who contacted me via the bug-report system to say that they had problems with crashes - although it was generally later in the game. I'll see if I can track this down and get a fix out soon.

Ah. You're right. The unitsubset was getting changed back to the first value. Fixed in the next update.

I created an update earlier, then had to take it down (after 2-3 minutes) because of a bug. Because of this, some people might get some validation errors when they try to update. Just wait and try again in a few hours. All players who are in a PBEM game should update before continuing their game. Update: A fix is available for the crash mentioned lower in the thread. You'll be updating to 1.01.9891 (demo version) or 1.01.9892 (full version). 15 Notable Changes/Fixes: - Fixed bug: the game wasn't remembering player's username/password and 'remember me' wasn't working - Fixed bug: new national borders appear briefly before the turn-replay happens (potentially giving away the results of combat, plus it was distracting) - Fixed bug: ground units were sometimes leaving cities to attack enemy units - Fixed crash: the game will crash if an AI-vs-AI game is setup with "random city locations" - Units/Cities selected in the left panel turn red - Added 'check for PBEM Updates' button to the reports window - this lets players in a PBEM game check for updates more frequently - Fixed a crash in the AI - Fixed a bug with city view range; some units weren't being spotted by cities - Fixed a bug with research spending - switching to the technology tree window can inadvertently reduce the research spending - Fixed a bug with containment events - sometimes units wouldn't show up during turn-replay, or sometimes units would appear to be in a city when it isn't - Changed some things with the game-event system; gave-save files should be 1/3rd smaller (which means smaller files, faster saves) - Changed the way enemy sightings are displayed - instead of the unit-name ("35th Infantry"), it shows the unit-type ("Infantry (Class 2)") - Fixed a bug in the map editor / player discovered map code that would black-out sections of the map - The game remembers the most recent playback speed, even when the application is restarted. (This is especially important when playing PBEM games.) - Fixed a bug that sometimes caused ranged units to spin when attacking enemy units

Your attachment isn't showing up. Combat randomness of 0.5 isn't truly random. A randomness value of 1.0 will give more random values and will probably give you some chance of doing 0HP of damage. A randomness value of 0.0 (or anything less than 1.0) will cause a certain regularity in the frequency of hits. Ah. I just looked up the code, and the combat simulator tracks upto 100 HP of damage. This isn't a bug in the combat calculator, but a bug in the combat simulator system which reports the damage. Sorry I didn't get that into the latest update. Is this a problem specifically with air units, or is this something that happens with all units when you turn down the combat randomness to 0.0?

It's important to keep all players on the same version of the application. The reason for this is because sometimes I alter or add game-events. (Game events are things in the game, like messages between players, or information about a unit's location at a particular time.) There can be problems if: player 1 updates to a new version, handles his turn (creating new game events), and then shuts down. Then, player 2 opens his game (without updating first) and he downloads and processes the game events. Player 2's application might not understand the new events written by Player 1. This situation is okay: player 1 *doesn't* update, handles his turn, and then shuts down. Then player 2 updates, opens his game, downloads and processes the game events. The reason this situation is okay is because new versions of the game understand how to process old events. (Although, in this situation, Player 2 is running a newer version, so any events that he sends back to Player 1 could cause problems.) One of the things I'm going to add to the PBEM system is that the game will force players to update if any game events were written by a newer version of the game. So, if player 1 is running version 1.01.9000 and he creates some game events, and then player 2 comes along using version 1.01.8000, and tries to process those events, his game will immediately stop and tell him to upgrade before continuing the game. Not all updates include changes to the game-events, by the way. However, the latest update does include new game-events, so players should update before playing their game.