small updates for 1.7.0.3 ?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

small updates for 1.7.0.3 ?

Veqryn
Administrator
I have to make a new release with some bug fixes.  I'd like to do it in a couple weeks.

Does anyone have any bug fixes that I need to add in?

Does anyone have any ideas for very small or quick updates or features?  

I can not add any new XML things, since I want to maintain compatibility with 1.7.0.3 savegames for this release.

thx,
veqryn
Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

sneakingcoward
This post was updated on .
1. fuel
1.a. no fuel also for planes on carriers...

1.b. no fuel also for technology mechan. units for transported unit

1.c. when planes move to combat for primary fuel check the whole flight distance should be considered not only the way into combat (e.g. 4 for fighters and 6 for bombers).
when planes are destroyed in combat also the remaining fuel (total fuel subtracted by the way into combat) should be subtracted.

2. air battles
2.a. attacking and defending planes can retreat
this makes no sense because they can retreat only to the same territory and are not partizipating in the normal combat.
when normal combat is lost also the retreated planes are lost.
so a planes retreat should be possible only to adjacent territories for air battles, for air raids a retreat of course only to the bombed territory.

2.b. discussion for different air battles modus
existing:
now at first air battle some rounds BEFORE the normal battle, then planes are switching to normal battle.
proposal:
wouldnt it be better, that for every round of normal battle at first is only 1 round of air battle ?
air battle - normal battle (planes are included) - air battle - normal battle incl. planes - .... a.s.o.
always alternating....when planes are retreating at 1 end of an air battle they are retreating to an adjacent territory and not involved anymore.
this would be more realistic. also the parameter "air battle rounds" can be deleted, because its always 1. air raids should be anyway 1.

2.c. air battle rounds
with this parameter for air raids and air battles the round number is defined, but no difference.
so if 2.b. is not realized, can this parameter be splitted or for air raids be set fixed always to 1 ?

more to follow.....
Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

Veqryn
Administrator
1a. debatable

1b. i sort of disagree.  those units are not being carried, they are simply moving with other units.

1c. not going to happen.  users should verify themselves that their planes can return.  this is way too much work for me.

2a. actually i like it as is and specifically programmed it to be as it is right now

2b. too much work, and there is very little significant difference.  also ww1 1941's air battles happen entirely prior to the ground/sea battle

2c. maybe
Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

sneakingcoward
ad 1.b. no fuel also for technology mechan. units for transported unit

<-- "isInfantry" allows the unit to be transported by "isLandTransport" IF you have mechanizedInfantry technology -->

please make it, because its till now the only way to simulate a landtransport.
so for isInfantry units no fuel consumption when carried by isLandTransport units....the isLandTransport unit of course needs fuel. should be easy to code.
thank you..the next donation will be even higher ;-)


and anyway...is a landtransport system planned, with transportcapacity ?


------
the same also for below, but this is not so urgent....
 <-- "isAirTransportable" allows the unit to be transported by an "isAirTransport" unit, IF you have paratroopers technology -->
-------
Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

sneakingcoward
In reply to this post by Veqryn
1 more question to 1.7.0.1

is it already possible to operate more factories at a territory ?
existing:
till now 1 factory e.g. PU=5
you can place 5 units there.
even if bombed it can be repaired before production, so an interruption of production is not possible.
a bombing damage can be defined as a multipe of PU value...

question:
is it with the existing parameter set possible, to operate more factories at a territory ?
e.g. 1 factory costs 6PU.
max. amount of factories for a territory is the PU of territory.
1 factory produces 1 unit.
strategic bombing as usual, each factory can be repaired or destroyed.
existing number of factories in a territory defines the number of units that can be placed there.
factories of course can be rebuilt and placed in place turn.
this procedure handling will interupt the production process...

can this be done already...or when not, can this be planned to realized...
Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

Bung
In reply to this post by Veqryn
Don't know if this exists or was already listed by someone, but:

- Cacheing the maps list: This is a big file and laggy even for me on a decent connection. Create a version file for the list that the game can check quicker than downloading every time?

- Stay on maps list: Finishing a map download should stay on the list of maps. I appreciate that there are multi-install shortcuts but not everyone is computer saavy.
Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

Zim Xero
In reply to this post by Veqryn
Not sure if this one can be done without breaking saves:

Currently the Moore N Able AI has a really difficult time buying and placing units when any of its factories have have been damaged... if it repairs in a round, it wont place units.  Is just my experience or everyones?

If this is the case it would be nice to have AI repair and place so that strafing their capitol each round doesn't KO their whole game.(an exploit in the games i've tried it).  

Also, MooreNable AI blows its entire placement if it detects an inability to place every unit it can buy with all of its money.  If you give 1000 PUs to a MooreNable nation, it will never buy a unit the whole game.  Can it be made to buy what it can place.... buy retrying its buy process using 80% PUs if 100% fails, 60% if 80% fails, 40% if 60% fails, and 20% if 40% fails, and dumping its PUs if 20% fails?
'thats the way it is' makes it neither desireable nor inevitable
Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

Rolf Larsson
Can we get a method to get rid of the End of Turn Report?
Maybe integrate it the exact same way as Skip posting for pbem.

Reason is: The endturndelegate does a lot of other things than make a player collect anything. If combined with negative objective....and since the NoPUEndTurn will no longer allow to produce/collect have objectiveincome....would be nice to not be forced to see the End of Turn Report. A global option would be fine also, default true or something.
We now have custom dice!
Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

sneakingcoward
In reply to this post by Veqryn
regarding 1.c. fuel consumption for planes

-------------
"1c. not going to happen.  users should verify themselves that their planes can return.  this is way too much work for me. "
-------------

already existing as also for other units:
when moving in combatmove only the flight into combat is subtracted from fuel.
in noncombat the remaining flightfuel is reduced.

problem:
remaining fuel has to be handchecked that the planes are not ending as kamikazee in noncombat move.


solution:
easy and simple.
I. when planes move in combatmove (excluding planes moved together with carrier) not only the way into combat is subtracted from resource fuel, the whole plane range is subtracted.
e.g. for bomber range is 6. not only as example 2 flightfields, all 6 fields for the bomber range is reduced, for fighter 4, etc... depending for each plane unit option "movement".

II. when plane is lost in combat, whole fuel is also lost, no program change necessary, because fuel already subtracted.

III. at the end of the combat phase when all battles are done and as next step noncombat move starts:
available: for all planes used in combat the remaining flight moves for noncombat are stored.
program change:
planes have been in combat AND planes have survived --> remaining flight fields fuel is rebooked to resource fuel.
that means in combatmove the whole plane-range fuel is subtracted, at the end of combat the not used fuel of the surviving planes is rebooked.

IV. in noncombat move the fuel handling is subtracted by the actually moved fields, no program change.


so there are only 2 easy steps to change:
I. planes move into combat --> the whole plane range fuel is subtracted, not only the actual travelled fields. program change easy.
II. when plane is lost in combat, all fuel lost, no fuel changes. no program change.
III. at end of combat phase before switching to noncombat the not used fuel for surviving planes is rebooked. program change easy.
IV. in noncombat move no program change.


------------------
"not going to happen.  users should verify themselves that their planes can return.  this is way too much work for me."
------------------

this would be very unsatisfying, the fuel option otherwise would work nice, as my WAW mod shows and it would enrich the strategy setups...

but the fuel for transported units (sea, air, land like mechan. inf and planes on carrier) should be corrected.
also the fuel handling for planes see above.


THANK YOU....you are our best and only one ;-)




Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

Edwin van der Wal
In reply to this post by sneakingcoward
Veqryn wrote
1a. debatable
1b. i sort of disagree.  those units are not being carried, they are simply moving with other units.
1c. not going to happen.  users should verify themselves that their planes can return.  this is way too much work for me.
2a. actually i like it as is and specifically programmed it to be as it is right now
2b. too much work, and there is very little significant difference.  also ww1 1941's air battles happen entirely prior to the ground/sea battle
2c. maybe
1a. Planes on carriers should use Fuel... typically the planes will swarm around the carriers canvassing the seas and protecting the carriers. NB: the planes also use up "movement range" while the carrier moves for this reason. so: NO.

1b. If you have a foot-only unit you shouldn't have it use up fuel (and hence it will also not use fuel when carried) -- most real INF units in ww2 actually had truck convoys / mechanized support units etc if that INF unit would hitch a ride with a MECH unit.. the foot units could move but the trucks / jeeps etc still would use up fuel... so: NO.

1c. having planes fill up their full tanks when taking off is quite typical... also when they get shot down they will of course use all their fuel. And usually they will drop their tanks when entering in early combat (being intercepted) and make sure they are empty when landing (so they can land safely) -- so having planes use their full consumption each mission is a realistic idea (make it an option) and shouldn't be too hard to implement.

Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

HuskerMike
In reply to this post by sneakingcoward
"and anyway...is a landtransport system planned, with transportcapacity ? "

The Total World War Mod has this in the form of trucks that move two in the non-combat phase with their cargo.

At this scale, you don't need to draw a rail net. Just make rail units and give them bigger capacity and more movement - say carry 2-4 infantry (or their equivalents) 4-8 spaces.

SPI's Invasion America does this and it has worked great for 40 years.
Go Big Red!
Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

Rolf Larsson
While testing the new features, I set up a system very similar to the one used in Shgoun/Samurai Swords/Ikusa boardgame. Ranged units do fire first, in every battle, attack and defense. This works nice and I havenĀ“t realized any bugs.
My request now is more about the way it gets displayed. I have set my Archer units to be AAs on attack and defense for every round of battle, without a normal attack and defense value, so in the battle window they are just listed on the very left, due to their 0 normal value.

It would be nice if the display would be updated for each battlephase, means during AAs are roled, these units get placed at the positon they roll at.
Another possibility would be to see 2 values for the unit like (0/4).
So instead of the one value for normal combat, a unit with 0 normal attack but 4 AA attack would still get displayed at position 4.

Maybe just part the screen above for AA rolling units and normal fighting units, like this would be best and hopefully easy:


Maybe have "First strike" instead of "AA". Units with both, AA rolls and normal values maybe have to jump up and down, depending on the phase.

This can become complicated easily, given the fact that rounds of AAs may be different, not firing if unit x is present...

For the current standard maps it seems fine, AAs fire first and only one time, but this great new feature allows for a lot of customization, taking range, initiative/speed, rate of fire, mobility, shockeffects etc. into consideration.
So new maps will probably make a lot of use it and when there are more than just 2 or 3 units working like this, it gets cramped very fast.
Another thing is the auto casualty suggestion, Archer example from above makes these the best units, but with a normal combat value of zero, they are suggested as the first units to die.
We now have custom dice!
Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

sneakingcoward
In reply to this post by Edwin van der Wal
Edwin wrote:
1a. Planes on carriers should use Fuel... typically the planes will swarm around the carriers canvassing the seas and protecting the carriers. NB: the planes also use up "movement range" while the carrier moves for this reason. so: NO.
1b. If you have a foot-only unit you shouldn't have it use up fuel (and hence it will also not use fuel when carried) -- most real INF units in ww2 actually had truck convoys / mechanized support units etc if that INF unit would hitch a ride with a MECH unit.. the foot units could move but the trucks / jeeps etc still would use up fuel... so: NO.

----------
regarding 1a.
the parameter "movement" is a time and way limitation, this doesnt mean a unit is really travelling, when it is transported.
planes on a carrier are not all swarming when transported, only a few reconnaissance units will do this job and their fuel is negligible.

so this should be a clear NO FUEL.

regarding 1b.
till now no landtransport feature for aaa.
the tech mechan.unit has to be exploited for it.

<-- "isInfantry" allows the unit to be transported by "isLandTransport" IF you have mechanizedInfantry technology -->

so for isInfantry units no fuel consumption when transported by isLandTransport units....the isLandTransport unit of course needs fuel.
every unit can get the attribute "isInfantry", independent if it is consuming fuel.

so this should be a clear NO FUEL.

Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

sneakingcoward
In reply to this post by HuskerMike
HuskerMike wrote:

"and anyway...is a landtransport system planned, with transportcapacity ? "

The Total World War Mod has this in the form of trucks that move two in the non-combat phase with their cargo.

-------------

this is not a landtransport system, the tech mech.inf is exploited for this.

<-- "isInfantry" allows the unit to be transported by "isLandTransport" IF you have mechanizedInfantry technology -->
<-- "isLandTransport" allows the unit to transport "isInfantry" on a one-to-one basis, if you have the mechanizedInfantry technology -->

and thats the problem, you cant define a transportcapacity, the transport (tech mech.inf) happens only at a one to one basis, so only one unit can be transported, when it has the option "isInfantry".

Reply | Threaded
Open this post in threaded view
|

Re: small updates for 1.7.0.3 ?

Zim Xero
In reply to this post by Veqryn
For the next release is it possible to add a sound effect entry for dice roll: diceroll.wav

Maybe a bigger dice roll for four or more dice would be nice too... ie a smallroll.wav and bigroll.wav
'thats the way it is' makes it neither desireable nor inevitable