submitted by timn <timothy@inst.augie.edu> 27 Nov 96
I wish for REAL passive sonar ... Currently passive sonar only detects sonar pings, if my wish was to come true, ships/subs/coastline could also be detected by a sub/destroyer of course with a much lower range then with an active ping, I'd suggest 1/2 range. This would allow subs at higher tech to hunt other subs ... currently this can only be done using missions, I would prefer it if everything I could do with missions, I could do by hand. Paul, submitted by Paul Nurse <nurse@wgc.rx.xerox.com> 07 May 96
For each sector of flight, a plane should have a chance of crashing based on it's efficiency (or flyability). This includes the flight home from a dogfight, even if it aborted out. This would eliminate the problem of stripping aircover with 10% planes, and make things a bit more realistic. I would suggest starting with the following formula. chance of crash = 100 - (eff+20) * .5 + 51) submitted by Eric James <ejames@iucf.indiana.edu> 06 May 96
You should start out with nukes submitted by Tim <?????> 06 May 96
Been said a thousand times, but I have look at the code a bit and think that perhaps a continuous update is possible. At the same time the server handles a player request it also updates one sector, placing the next time of update mark in the sector. The next time of update stamp is randomly generated in a deity defineable range. Example [12-13hours] or [16-30min] etc... Because it is randomly assigned any resource moved into a sector may or maynot receive an extra update but just as likely lose an update. Problems from earlier attempts at continuous updates: 'touching' a sector to early losses the update. this can't happen because of the update stamp. Update can't happen until at least specified update time has passed. player can overrun a non-logged in country. with units this point is almost moot. Also things that don't need sector support can be treated as a sector and receive that portion of the update as if it was a sector update. example: a 75% ship at sea autonaving. When the sector is updated the ship will gain or loss effieciency but NOT nav. When the ship is updated [the ship is like a sector its turn will come] it will be nav'd and then it will receive mobility. Advantages: The one everyone always complains about: UPDATE SCHEDULING. If you see any major holes in this basised on update process let me know. I would like to keep thinking on this. ALso second wish. MaxMarch units x,y thres command. Sends units in list to coordinate x,y but they only march if the result expects them to still have thres mobility LEFT. So you don't accidently strip you mobility. I would like to see thres added to reacting units. ie. mission units reserve base thres (puts units on reserve mission at base point specified BUT they react only if they have OVER thres mobility.) That way when you log in and see say a naval/air invasion that has already commenced your reserve units might actually have some mobility left. Ding Dong Doorbell. submitted by Timothy Sorenson <timothy@inst.augie.edu> 09 Oct 96
Wanted to add a point about continuous updates and global values like tech/happiness/research and global events like dist, deliver, etc.. each one can survive an individual sector update. The global values like tech/happiness/research simply use the same forumula the only problem being a lot of tech centers would allow for a lot of small point gains with no log taking effect. But that can be rectified if you know anything about solving partial differential equations. And about distributions/deliver etc... One has to plan warehouses a little more carefully based on the range of the update defined by the deity. And every once in a while a northeast sector may update earlier and get more resources than a southeast sector but it will be random. Ding DOng Doorbell submitted by Timothy Sorenson <timothy@inst.augie.edu> 09 Oct 96
I would like to play Empire but I wish there were pictures. It would make playing it a more enjoyable experience. submitted by Matt <finnesmr@miamiu.muohio.edu> 28 Jan 97
I would like to see a port to the DOS/Windows (probably Windows 95) environment. This would make more availability for home/BBS servers for the game. I think this would be a rather good BBS game for a multi-line fairly high power BBS. submitted by Karl Wilhelm <wilhelm@marlin.nosc.mil> 18 Oct 96
I wish someone would develop a more current client for Windows 95. submitted by <deleted at request> 23 Mar 97