MINICOM testing: now open for everyone.

[bert_the_turtle]

I wouldn't call it sloppy in general; it is pragmatic. For a potentially growing project, I'd like it to have a more hierarchical object structure (All planes and ships share one common base class with gunshots, no intermediate class for Ship and Plane), but for the intended scope, it works fine. The code is well organised enough that you usually know what does what and it's usually just done in one place, that's all that matters. There are not many general design decisions and patterns I'd disagree with (use of plain char * and other plain pointers instead of smart managing classes which leads to most of the leaks, use of integer variables instead of typed enums). Even performance wise, the one thing that struck me as a horrible sin at first and certainly the first thing I'd have to improve turned out to be not so bad after all in profiles and only was the last thing I changed on the game code. And the performance improvements were the bulk of the changes and where the most new bugs were introduced; each fix usually is quite a limited and small change. Except for the map seam handling, that was all over the place.

[jon]

Is there any chance of making it quicker to rejoin a game when connection drops?

[Forever Young]

Performance improvements: game update and thus resyncing, reconnecting and late joins are over 100% faster.

it is a copy out of the minicom(website) bug fixed list.

[bert_the_turtle]

But that's just the simulation part. Can't do much about the fact the whole game history needs to get transmitted over the network first which may be the dominating factor. It could be possible to cache those on the hard drive, but that's a huge project since nothing is prepared for that. Games would first need a unique ID generated by the host (dedcons, too) so cached games can be found reliably, deleting old files needs to be implemented, the client needs to be able to tell the server it doesn't need the whole history (again, dedon and defcon), a disk format for the cached files needs to be developed and implemented (dedcon has one for the recordings, that would be convenient to take over). I'm not even going to promise that I'll look into it.

[Forever Young]

another good thing would be, especially for new players, the fighters are not longer shooting on nukes.
it is irritating and is has no effects, although i am not sure if the silo shooting combined with fighters on nukes elevate the shoot down rate.

[bert_the_turtle]

Done that. New build is up, subs can now launch anywhere, please test fleet pathfinding for oddities, it's changed a bit, especially around the seam area.

Also, you can now have all your beloved old bugs back Hope I didn't forget any important ones.

[Zorotama]

Subs don't launch everywhere

[bert_the_turtle]

Yeah, sorry, turns out I forgot to make the relevant config file load from the .dat file. Unrar main.dat and they should.

[bert_the_turtle]

There's a stupid crash if ImpossibleTargetTracking is 0, which is the default. To avoid it, play with one of the included mods enabled, they set that to 1.

[-- Tobias --]

An "easy" fix (?) that would preserve some reasonableness to many partially-completed team games:

When a player leaves a game with silos that are open but without targets, close the silos.

Perhaps this might cause some conflict if silos are auto-triggered too soon after auto-closing, but I do not know. If not, this change would eliminate many situations where hitherto well-played games just turn stupid.

Also: fighter autoattacks will mean fleets go down much faster. Do you want this?

Thank you Bert et al for your work.

[trickser]

Another easy AI enhancement: AI switches subs to active after firing them. Tobias mentioned it sometime ago.

[Laika]

I also wish to help in testing it, if still needed.

[Forever Young]

Forever Young: I'd be interested to know how you managed to get a carrier attacked.

it happened again in the normal version against a real player!
http://www.uploadagent.de/show-182541-1329128906.html
i don`t know why that happened but i think it was something like a double click on carrier with fighter.
game time: 2:17
http://defcon.lfo.fi/dcrec/2012-02/1v1totallyrandom-2012-02-12_12.45.zip

[bert_the_turtle]

That looks to me like it's landing. If it were attacking, the marker would be red, and I see no shots or impact explosions. Yeah, it says 'Attack Mode' and it's counting down, but that's normal.

The wwo AI improvements are noted for future investigation. Right now, I'm all about making the game parameters moddable. Unit properties are already done, attack ods, defcon timers and score modes are next. Due to a bug, I already experienced a game where fighters could just shoot installations, I want that to be possible.

Also: fighter autoattacks will mean fleets go down much faster. Do you want this?

It doesn't mean that. It means fleets will go down as quickly with no (IMHO silly) fighter micro than they do with it. I'm not a fan of the purely mechanical micro. I'm all for meaningful micro, setting waypoints and assigning targets, but units should not be stupid by default. If they can fire at something, they should. Don't like it? Mod it away.

Build 1.60.1.4 is up. For everybody now: http://minicom.simamo.de/
(The old releases before 1.60.1.3 are restricted and will be removed in the future, they accidentally violated a subclause of the license agreement.)

[-- Tobias --]

Also: fighter autoattacks will mean fleets go down much faster. Do you want this?

It doesn't mean that. ... units should not be stupid by default. If they can fire at something, they should. Don't like it? Mod it away.

Ouch. Unless I do not fully understand the issue (which is likely), slapping me down does not change the fact that not-yet-retargeted fighters (say, after a kill) are often delayed or shot down before they can get off any subsequent shot, even if they are in range of a new target; despite even the best efforts at attempted retargeting by micromanaging. The change will (automatically - without player intervention) increase actual fighter shots without any (obvious) offsetting effect. Unless I am missing something, that means fleets will go down faster (in general), introducing (possibly significant) game balancing issues imo.

I don't believe even the most ardent micromanager can retarget all active fighters in a major naval melee faster than autoattacking seems to promise. With autoattacking fighters a player might be able to devote more time to other activities I guess, but the change is way more significant than a mere matter of taste: "stupid" fighters are a drag on fighter efficiency and reducing this inefficiency involves game balance.

In addition, some players utilize the retargeting lag to strategically select a specific desired subsequent target. Autotargeting fighters will make this "second attack" targeting far more difficult (fighters will, for example, autoattack [and presumabably change direction toward] some (close) unit (possibly) already under attack by other fighters rather than moving on to a different unit or "deeper" space for scouting - where the original kill was). Again, this will effect game play imo.

There is also the recycling time from autoselected target (a bbs - the closest target) to player selected target (a carrier - only slightly farther away). Now that would be a stupid fighter.

Perhaps I also do not understand the full power of mods. What mods exist that players can use to change unit mechanics?

In short, this change should not be considered a simple "clean-up" or matter of taste at all. But whatever, you are doing the work so I will play with whatever you want.