That's everything from my first runthrough. Will do some running around on small divide mountains tomorrow. The tracers for small arms fire are going to be a huge graphical improvement, can't wait to see it happen. (and I'll finally be able to spot artillary rounds coming at me, instead of them getting lost in the general stream of gunfire)Footprints
...are largely okay. Only a few problems, and likely to do with the resizing done with this version.
1) Infantry. Their footprint is about 4x the size of their model.
2) Mines. Both anti-personnel and anti-tank, on both sides, are very small, with a large footprint.
Factories
Everything built everything. Obviously, aircraft are excluded from this build, so I don't know about the issues with them. All factories/barracks/bunkers/gun positions built everything in their build menu.
A few problems were:
1)The M4A3 (DD) Sherman (the amphib tank) is not able to leave the depot. It gets stuck, the depot has to be reclaimed in order to free the tank.
2) The concrete gun position. The guns give a LOT of "cannot reach destination" responses as soon as they're built/ordered to fire. I believe that all of them fired, but not always on the first command. It seemed like they responded to attack commands placed nearer to the position, and ignored long ranged attack commands, unless they were already pointed in that direction.
Water Depth
Most things seemed to be okay. With a lot of micro I could squeeze an infantry into water up to his face. No deeper. The Deep Fording tank looked okay, but the amphib units (transports, tanks) drove on the bottom of the sea. I suppose this is an engine issue for some, while intentional for others. One thing popped out:
1) The Pzkpfw VI Tiger E can go ~2x further underwater than other German tanks. Is this intentional?
Other
Some random things:
The Panzerjager Marder has a visible black groundplate.
The AT obstacles (dragons teeth) have spacing issues: If you tell a con unit to build a row of them, only the first and last ones are built.
AATA Beta 0.9
Moderator: Moderators
Alright, here's the first report. I did footprints, factories, water depths for all units.
Okay, I played with this idea a bit, using SWTA droids as the testing units.Nemo wrote: Edit: Masse mentioned something in the lobby today that might prove useful for truely limiting unit production/use.
Apparently, Spring can handle negative resource storage, even below a total storage of 0. So, for example, if a resource tent provides 1000 E storage, and each AT infantry has -100 storage, you can only build 10 of them until you're digging into your other storage..and eventually have none at all. This is different from simply using energy in that once you use up all of your storage, you can't build anything..not just that you build more slowly/nanostall - all production ceases completely, and I'd imagine that any energy using unit would halt. I'll have to play around with it a bit.
The droids use -2.0 energy constantly. They use more to fire.
I built 5 of them told them to patrol, then blew up the factory and commander, then .gave my -1000 energy storage unit.
The worst issue is here: units that use energy by default stop using energy when there's none to be had..without any change in actions.
Ie, the droids that use -2 energy all the time, were able to patrol with -1000 energy storage just as well as when there was 1000 energy in the bank. The only difference was in firing - they could not fire without energy.
This strikes me as a Spring bug, if units that use energy to move can still move even when all the energy is gone (not only gone or being drained, but in a huge deficit) then why have them use energy to move in the first place?
If you test it yourself, you'll see that the droids have -2 while there's energy to be had, but 0.0 energy production/consumption when there's a deficit - movement performance is unaffected.
Still useful for AATA though - tanks aren't much good without shells to fire, now are they =)
Infantry and mines have a 1x1 footprint - it can't be made any smallerFootprints
...are largely okay. Only a few problems, and likely to do with the resizing done with this version.
1) Infantry. Their footprint is about 4x the size of their model.
2) Mines. Both anti-personnel and anti-tank, on both sides, are very small, with a large footprint.
This is one issue I have against the resizing. I think there are probably a few rectangular footrpints out there, which need fixing.Yay! Aircraft pits are built on top of geothermals.Factories
Everything built everything. Obviously, aircraft are excluded from this build, so I don't know about the issues with them. All factories/barracks/bunkers/gun positions built everything in their build menu.
One for Spiked to fixA few problems were:
1)The M4A3 (DD) Sherman (the amphib tank) is not able to leave the depot. It gets stuck, the depot has to be reclaimed in order to free the tank.
There are plenty of thigns wrong with the gun positions, and even when fixed they will still spam the 'cannot reach destination' messages, I might suggest doing away with them entirely.2) The concrete gun position. The guns give a LOT of "cannot reach destination" responses as soon as they're built/ordered to fire. I believe that all of them fired, but not always on the first command. It seemed like they responded to attack commands placed nearer to the position, and ignored long ranged attack commands, unless they were already pointed in that direction.
The amphib units waterlines need adjusting, they were *perfect* at full scale. The second issue i have with resizing. The Tiger had fording equipment, hence its ability to handle water better.Water Depth
Most things seemed to be okay. With a lot of micro I could squeeze an infantry into water up to his face. No deeper. The Deep Fording tank looked okay, but the amphib units (transports, tanks) drove on the bottom of the sea. I suppose this is an engine issue for some, while intentional for others. One thing popped out:
1) The Pzkpfw VI Tiger E can go ~2x further underwater than other German tanks. Is this intentional?
Marder is a simple fix (funny how it only just turned up though!) No idea what causes the dragon teeth problem, ran across it myself recently.Other
Some random things:
The Panzerjager Marder has a visible black groundplate.
The AT obstacles (dragons teeth) have spacing issues: If you tell a con unit to build a row of them, only the first and last ones are built.
Cheers.That's everything from my first runthrough. Will do some running around on small divide mountains tomorrow. The tracers for small arms fire are going to be a huge graphical improvement, can't wait to see it happen. (and I'll finally be able to spot artillary rounds coming at me, instead of them getting lost in the general stream of gunfire)
Nemo - it worked that way in TA, too. AATA units do drain (and considerably), but at the minute logistics (energy) is too easy to get and so the drain isn't noticed.
No, the aircraft factories are not in the current build - the luftwaffe and USAF engineers don't have them. luftwaffe builder has early warning radar and the gun position - which, if we could make it work, would be fantastic. Its a great idea. I think there are a few mods that currently have something similar (perhaps if the units in the gun position were 'special editions' of the normal towed artillary and whatnot with the same model/buildpic, but were actually stationary turrets rather than mobile units?).
As for the energy, I think you misread my post <.<
When I added my unit, it wasn't draining energy, it was creating negative storage. This is far above and beyond the normal nanostall, my energy bar was stretching backwards across the GUI, and the counter was at -2000.
The problem was that the units that needed energy to move, still moved, even when there was no energy. I'll keep poking around, maybe the SWTA droids aren't dependant on it to move.
Edit: The only footprints that really didn't match the model were with the units who had multiple models. The various logistics centers, I think - the problem here is that the footprint matches some of the models, but not all.
As for the energy, I think you misread my post <.<
When I added my unit, it wasn't draining energy, it was creating negative storage. This is far above and beyond the normal nanostall, my energy bar was stretching backwards across the GUI, and the counter was at -2000.
The problem was that the units that needed energy to move, still moved, even when there was no energy. I'll keep poking around, maybe the SWTA droids aren't dependant on it to move.
Edit: The only footprints that really didn't match the model were with the units who had multiple models. The various logistics centers, I think - the problem here is that the footprint matches some of the models, but not all.
They are in the build - they just don't have buildpics.
Indeed. Can't say I'm a fan of all this 'negative storage' hype.
As for units stopping when there is no energy, Spring does now support altering unit max speeds via the script, but afaik there is no way to detect the amount of energy available via the script.
Some of them may fit the model, but then the unit turns. In Spring, unlike TA, the selection square doesn't turn with the model (as it is actually the footprint, not a face on the model, which didn't turn in TA, either)
Indeed. Can't say I'm a fan of all this 'negative storage' hype.
As for units stopping when there is no energy, Spring does now support altering unit max speeds via the script, but afaik there is no way to detect the amount of energy available via the script.
Some of them may fit the model, but then the unit turns. In Spring, unlike TA, the selection square doesn't turn with the model (as it is actually the footprint, not a face on the model, which didn't turn in TA, either)
*kicks himself for not trying to click inviso-buildpics*
Sorry about that, its aircraft time.
As for the negative storage...I think it could certainly be useful (especially if units that need it to move actually stopped when there's no energy to be had) but until then, units do more or less stop firing when there's a large drain.
Sorry about that, its aircraft time.
As for the negative storage...I think it could certainly be useful (especially if units that need it to move actually stopped when there's no energy to be had) but until then, units do more or less stop firing when there's a large drain.
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
Nemo, when things are at -storage, does everything stop building? Or can people build, except it is entirely based on income (ie: if income is positive, things build, if it is negative, things stall)?
We might be interested in using this for SWTA, if it works out alright, because we have been struggling to balance the droids in a way that weakens them, but doesn't defeat their purpose of the game.
As far as I understand it, it is impossible to make a unit stop moving from a lack of energy through the script. At the moment, making units cost energy to move only harms construction at home; but doesn't reduce the efficiency of the units using that energy, even if they need it to fire. I think weapons that fire in little lots of logistics (such as machine guns) work far better in this circumstance then big tank cannons that use a hundred or so logistics in one shot.
We might be interested in using this for SWTA, if it works out alright, because we have been struggling to balance the droids in a way that weakens them, but doesn't defeat their purpose of the game.
As far as I understand it, it is impossible to make a unit stop moving from a lack of energy through the script. At the moment, making units cost energy to move only harms construction at home; but doesn't reduce the efficiency of the units using that energy, even if they need it to fire. I think weapons that fire in little lots of logistics (such as machine guns) work far better in this circumstance then big tank cannons that use a hundred or so logistics in one shot.
When your overall storage is below zero, all construction stops - paused, as it were. Things currently being built will freeze, but not decay as abandoned construction does. As for income, it acts the same way as if you were maxing out your storage in the positive end.
For example: having two fusions and one energy storage building, you're going to have 2000 energy, with +2000 per tic. However, if that storage building blows, you're reduced to 1000 energy, while keeping +2000 per tic. Works the same when its negative: if your storage is at -20, you can be producing with 5 XTA +3000 fusions, but your energy will never go above -20.
My disappointment with Spring comes with units that require energy to move. Remember in OTA, when nearly all units used 1 energy to move, but produced enough to keep itself moving? Brawlers were +1/-1. That wasn't just for show; if you had a huge energy drain, the brawler would stop moving and land.
I fired up SWTA, built 5 droids, then self-destructed the factory and commander, then .gave my unit that had -1000 energy storage. The droids could move just as well as before, except that their normal energy drain of -2 wasn't showing (they were just 0/0). However, they were completely unable to fire. Energy-using weapons can't fire with negative energy, obviously enough.
Hope that helps.
For example: having two fusions and one energy storage building, you're going to have 2000 energy, with +2000 per tic. However, if that storage building blows, you're reduced to 1000 energy, while keeping +2000 per tic. Works the same when its negative: if your storage is at -20, you can be producing with 5 XTA +3000 fusions, but your energy will never go above -20.
My disappointment with Spring comes with units that require energy to move. Remember in OTA, when nearly all units used 1 energy to move, but produced enough to keep itself moving? Brawlers were +1/-1. That wasn't just for show; if you had a huge energy drain, the brawler would stop moving and land.
I fired up SWTA, built 5 droids, then self-destructed the factory and commander, then .gave my unit that had -1000 energy storage. The droids could move just as well as before, except that their normal energy drain of -2 wasn't showing (they were just 0/0). However, they were completely unable to fire. Energy-using weapons can't fire with negative energy, obviously enough.
Hope that helps.
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
Mmm, that is significantly less useful.
The problem with that is that if a player ever gets himself into negative storage, there is no way for him to get himself out, short of self destructing whatever it is that is chewing into his storage.
You can't really expect players to do that, it would just be unfeasable. Stalling is one thing, because things still work to a degree, so players are able to dig themselves out of the resource stall.
The problem with that is that if a player ever gets himself into negative storage, there is no way for him to get himself out, short of self destructing whatever it is that is chewing into his storage.
You can't really expect players to do that, it would just be unfeasable. Stalling is one thing, because things still work to a degree, so players are able to dig themselves out of the resource stall.
One simple way to get around that would be to have energy storage buildings that only cost metal to build (or even better, cost -energy to build, so you gain a bit of energy..not enough to be worthwhile, but enough to help the stall) as you build it.
However, losing energy storage (without going into negatives) is still an issue: even if the cheapest droids only dropped -30 storage each, if you build a decent group of them, your resource flexibility drops quite a bit.
Of course, if you go overboard you might have to send them on a suicide mission, but that I think this could be balanced well enough. It just restricts construction that bit more, so someone who goes for a droid rush has to balance resources and droid production more carefully than someone who goes with the normal infantry route.
However, losing energy storage (without going into negatives) is still an issue: even if the cheapest droids only dropped -30 storage each, if you build a decent group of them, your resource flexibility drops quite a bit.
Of course, if you go overboard you might have to send them on a suicide mission, but that I think this could be balanced well enough. It just restricts construction that bit more, so someone who goes for a droid rush has to balance resources and droid production more carefully than someone who goes with the normal infantry route.
Exactly why I don't see what all the hype is about, if anything to me its a bug that needs fixing... 
Anywho, done some long-winded work today that I expect none of you will notice - but it's there. Some units had a puff of smoke from the exhaust when they start to move; now ALL ground vehicles do this - with physically accurate exhaust pipe locations. Oh yes. 
(this also cleaned up a few scrips a little)
Also made a quick addition to my ever handy Python script to ensure all mobile unit footprins were square, so testers no longer need check for that.
One question, does everyone see buildpics for the current version (except airpits, obviously)? Everything but infantry is actually missing the buildpic tag, yet they appear in mine, making me think the tag is now redundant...
Next up I'll be fixing it so smallarms only fire on infantry (no more observation vehicles giving away their position by firing on a King Tiger because you forgot to set them to hold fire
) and once Spiked has finished working on the new Spring-ised aircraft (using the Spring aircraft tags for more realistic movement/general behaviour) I'll also make sure that aircraft AT rockets only fire on gound vehicles, i managed to strafe half the map (including much of my own base) in a game not so long ago when I had a ground-attack P-51 chasing one of heroes' (i think) P-47s.
After that perhaps I will add the track laying decals to units, but that will probably be quite an arduous process... so I might persuade Spiked to do it.
I think currently the issues holding back a public release are:
1. The annoying crash bugs which I don't know the source of (I think I've seen an engine bug mentioned, it could, perhaps, be that. i hope.)
2. The mess that our wonderful balancing has become (1st step I will take is to halve flag production, and play some games without tanks)
3. Aircraft (spiked is working on fixing them up, obviously)
I think that's it really. Everything else is a minor graphical issue (like the things I've been fixing recently) which aren't all-important. Adding in missing units isn't hugely important, yet, either.
Anywho, done some long-winded work today that I expect none of you will notice - but it's there. Some units had a puff of smoke from the exhaust when they start to move; now ALL ground vehicles do this - with physically accurate exhaust pipe locations. Oh yes.
(this also cleaned up a few scrips a little)Also made a quick addition to my ever handy Python script to ensure all mobile unit footprins were square, so testers no longer need check for that.
One question, does everyone see buildpics for the current version (except airpits, obviously)? Everything but infantry is actually missing the buildpic tag, yet they appear in mine, making me think the tag is now redundant...
Next up I'll be fixing it so smallarms only fire on infantry (no more observation vehicles giving away their position by firing on a King Tiger because you forgot to set them to hold fire
) and once Spiked has finished working on the new Spring-ised aircraft (using the Spring aircraft tags for more realistic movement/general behaviour) I'll also make sure that aircraft AT rockets only fire on gound vehicles, i managed to strafe half the map (including much of my own base) in a game not so long ago when I had a ground-attack P-51 chasing one of heroes' (i think) P-47s.After that perhaps I will add the track laying decals to units, but that will probably be quite an arduous process... so I might persuade Spiked to do it.
I think currently the issues holding back a public release are:
1. The annoying crash bugs which I don't know the source of (I think I've seen an engine bug mentioned, it could, perhaps, be that. i hope.)
2. The mess that our wonderful balancing has become (1st step I will take is to halve flag production, and play some games without tanks)
3. Aircraft (spiked is working on fixing them up, obviously)
I think that's it really. Everything else is a minor graphical issue (like the things I've been fixing recently) which aren't all-important. Adding in missing units isn't hugely important, yet, either.
Could do with another tester as i end to have to stay up quite late to get a game and I start back at uni on monday, so, any UK folk interested?
I've discovered that the 'OnlyTargetCategory' tags for weapons onlyaccept one category, not a string. This means we need some careful consideration of what categories to have. F. ex. Infantry smallarms would obviously have an onlytargetcategory of infantry... but, they actually do a *small* amount of damage to open top and softskin vehicles (jeeps and trucks and such). Obviously infantry should be prioritised above these... so that gives 2 categories, 'smallarms' - the OnlyTargetCategory and, 'softskin' which would be a BadTargetCategory, so infantry prioritise other infantry... I'm not sure if this approach will actually work, mind.
EDIT: did some more thinking, here's what I came up with - please point out any glaringly obvious flaws you spot!
EDIT2: After checking through Springs code, I discovered that it supports the old TA FBI tags for weapon-specific BadTargetCategorys (but only for the first 3), I'm not sure if these work in the same way as the unit BadTargetCategory, but if they do then we can add:
And all AA weapons will have a unit-wide BadTargetCategory of 'Ground', although they will mainly still be able to fire at ground targets.
I've discovered that the 'OnlyTargetCategory' tags for weapons onlyaccept one category, not a string. This means we need some careful consideration of what categories to have. F. ex. Infantry smallarms would obviously have an onlytargetcategory of infantry... but, they actually do a *small* amount of damage to open top and softskin vehicles (jeeps and trucks and such). Obviously infantry should be prioritised above these... so that gives 2 categories, 'smallarms' - the OnlyTargetCategory and, 'softskin' which would be a BadTargetCategory, so infantry prioritise other infantry... I'm not sure if this approach will actually work, mind.
EDIT: did some more thinking, here's what I came up with - please point out any glaringly obvious flaws you spot!
Code: Select all
Categories:
SmallArms
OpenTop/SoftSkin
Canon
Structure
General Category Assignments:
Infantry - SmallArms
Towed Guns - SmallArms
Light vehicles - SmallArms, Softskin
Flags - SmallArms
Tanks - Canon
SPGs (excluding fully armoured TD/AG) - SmallArms, Softskin, Canon
Buildings - Canon, Structure
General Cases:
Infantry - SmallArms OnlyTargetCategory, BadTargetCategory Softskin
AT Infantry/Towed Guns - OnlyTargetCategory Cannon, BadTargetCategory Structure
Tanks (main gun) - Canon OnlyTargetCategory, BadTargetCategory Structure
Tank Destroyers (main gun) - Canon OnlyTargetCategory, BadTargetCategory Softskin
Explanation of Special Cases:
Flags - SmallArms
BUT Tank machinegun weapon does reduced (if any) damage
SO infantry are the only units capable of taking flags
Self Propelled Artillery - SmallArms, SoftSkin, Armour
AS Softskin BadTargetCategory for infantry
SO infantry prioritise enemy infantry first
AS SoftSkin BadTargetCategory for tank destroyers
SO TDs prioritise enemy tanks and TD over non-AT SPGsCode: Select all
Tank (CoaxMG) - OnlyTargetCategory, BadTargetCategory Softskin-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30