Page 59 of 64

Posted: 08 Feb 2007, 12:38
by tombom
Lippy wrote:Is it just me, or does foxomaniacs Experimental mod just feel to be more balanced? He's fixed so many things & tweaked so many things that Noize/Day have just left out because they either have too little time or don't believe its a major issue. Can you not just suck up some pride & implement most of what he's done, especially as most people agree with his changes?
Have you ever heard the saying "history repeats itself"?

Yeah.

Posted: 08 Feb 2007, 13:37
by drolito
thanks a lot for this new 4.7 version ... i will be able to make my Vamps AA shield again ^^

Posted: 08 Feb 2007, 13:48
by 1v0ry_k1ng
why do subs do a default 5 damage to ground units, according to the stats page?

Posted: 08 Feb 2007, 15:01
by Machiosabre
its the other way around, so ground only does very little damage to subs if you forcefire into water.

Posted: 08 Feb 2007, 15:26
by EXit_W0und
what I want is for a Krow to be able to take down 4-5 hawks on its own before dieing (these are attacking it, not flying past quickly)
Or you could just build 4-5 hawks to defend it while it takes out ground troops en route to your base. Like normal sensible people.

Posted: 08 Feb 2007, 15:49
by TheFatController
Keep in mind that I'm talking about a very special 4758 metal 68088 energy unit, not just giving easy to spam gunships AA weapons...

Posted: 08 Feb 2007, 17:46
by tombom
T3 units are no longer transportable.
Why? T3 units aren't that great anyway, this just makes it a bit worse.
Intruder can no longer load enemy units
I don't have a problem with this, it just seems a little arbitrary. You may as well say the com can't be transported by enemy transports.
Implented Argh's Arm DT (someone should make us some for Core too. and maybe the floating DT's fortwalls as well)
Why not use the same model for all of them? (except fortwalls)
Fusions have their stats hidden to the enemy now, so decoys work
Just use the decoyfor tags and wait for next version.

Posted: 08 Feb 2007, 18:19
by NOiZE
MR.D wrote:its a what.. 25 tri model?
That should take about 5 mins to model/uvmap/texture each one for any competant modeler.
/me points
ralphie wrote:Seaplane torpedo bombers still aren't auto attacking. They'll just stupidly fly past enemy ships, while torpedo bombers from the land airport work fine.
Thanks for the first report on this issue.
Lippy wrote:Is it just me, or does foxomaniacs Experimental mod just feel to be more balanced? He's fixed so many things & tweaked so many things that Noize/Day have just left out because they either have too little time or don't believe its a major issue. Can you not just suck up some pride & implement most of what he's done, especially as most people agree with his changes?
We went through his changes and applied the changes we think are needed.
tombom wrote:
T3 units are no longer transportable.
Why? T3 units aren't that great anyway, this just makes it a bit worse.
Well it's just looks really stupid when your HUGE krog hangs under a transport. And T3 is supposed to be Really good when they reach the front, perhaps we should buff them a bit.
tombom wrote:
Intruder can no longer load enemy units
I don't have a problem with this, it just seems a little arbitrary. You may as well say the com can't be transported by enemy transports.
Ewhm no? all airtransports can still capture enemy units.
tombom wrote:
Implented Argh's Arm DT (someone should make us some for Core too. and maybe the floating DT's fortwalls as well)
Why not use the same model for all of them? (except fortwalls)
I thought we want different sides? Perhaps i should just rip out ARM?
tombom wrote:
Fusions have their stats hidden to the enemy now, so decoys work
Just use the decoyfor tags and wait for next version.
Done that already.

Posted: 08 Feb 2007, 18:59
by Lippy
NOiZE wrote:
Lippy wrote:Is it just me, or does foxomaniacs Experimental mod just feel to be more balanced? He's fixed so many things & tweaked so many things that Noize/Day have just left out because they either have too little time or don't believe its a major issue. Can you not just suck up some pride & implement most of what he's done, especially as most people agree with his changes?
We went through his changes and applied the changes we think are needed.
So from this i deduce that you think:

Metal generators are fine? (proved to be incredibly inefficient)
As is the luger?
As is the Merl?
As is the Pelican?
As are the prices of all underwater economy structures?

As much as I like what you've done with AA, its ignoring things like this that annoys me so much. These examples are not subjective things (like metal makers using 80 instead of 60 E), these have been shown to be unbalanced, and everyone agreed with Fox's changes.

Posted: 08 Feb 2007, 19:07
by NOiZE
Lippy wrote:
So from this i deduce that you think:

Metal generators are fine? (proved to be incredibly inefficient)
As is the luger?
As is the Merl?
As is the Pelican?
As are the prices of all underwater economy structures?
Well we didn't really had the time to carefully look @ those things, as the vamp bug was quite serious we were on kind of pressure

The luger will get changed.
Merl, not sure
Pelican, probally will get changed a bit
Underwater economy structures aren't that badly priced, they also have the huge advantage of being underwater, also floating/underwater metalmakers are more efficient then landbased ones.

Posted: 08 Feb 2007, 19:10
by Neddie
The metal generator shouldn't be efficent, from a logical standpoint. Think about it - you are generating metal out of, functionally, nothing. It shouldn't be more efficent than metal makers, which involve the application of energy to matter to generate metal...

Posted: 08 Feb 2007, 19:26
by QMan
Found another few discrepancies. MaxSlope for all units is in degrees, and thus should be in the 0-90 range, so units like the flea with 255 and Karganeth with 160 don't make sense. (160 means he can walk on the ceiling!) :)

Posted: 08 Feb 2007, 19:40
by imbaczek
actually maxslope is not in degrees AFAIK.

Posted: 08 Feb 2007, 19:40
by Guessmyname
odd, I had a unit or two with Slope Tolerances above 90

They couldn't be built by mobile units

Posted: 08 Feb 2007, 19:40
by Pxtl
neddiedrow wrote:The metal generator shouldn't be efficent, from a logical standpoint. Think about it - you are generating metal out of, functionally, nothing. It shouldn't be more efficent than metal makers, which involve the application of energy to matter to generate metal...
Well, I think the idea of the metal generator is that it's a solar-collector energy supply with a built-in metal maker. Which would logically be _more_ efficient since the energy is not being transported.

Besides that, while the generator is more convenient and space-efficient(less micro to build them) it's less versatile. Power + MM can make either, a generator is metal-only. Considering the MMAI, that's very significant.

Considering the trade-offs, I think the generators should be roughly equivalent in cost to their more complex counterparts.

Posted: 08 Feb 2007, 20:07
by Lippy
NOiZE wrote: Well we didn't really had the time to carefully look @ those things, as the vamp bug was quite serious we were on kind of pressure

The luger will get changed.
Merl, not sure
Pelican, probally will get changed a bit
Underwater economy structures aren't that badly priced, they also have the huge advantage of being underwater, also floating/underwater metalmakers are more efficient then landbased ones.
Cool, thanks for the update. (Main issue with pelican is turn rate IMO)

Posted: 08 Feb 2007, 20:17
by Lippy
Pxtl wrote:
neddiedrow wrote:The metal generator shouldn't be efficent, from a logical standpoint. Think about it - you are generating metal out of, functionally, nothing. It shouldn't be more efficent than metal makers, which involve the application of energy to matter to generate metal...
Well, I think the idea of the metal generator is that it's a solar-collector energy supply with a built-in metal maker. Which would logically be _more_ efficient since the energy is not being transported.

Besides that, while the generator is more convenient and space-efficient(less micro to build them) it's less versatile. Power + MM can make either, a generator is metal-only. Considering the MMAI, that's very significant.

Considering the trade-offs, I think the generators should be roughly equivalent in cost to their more complex counterparts.
Well, As every1's speaking from logic, I'll use mine:

We know Einsteins famous E=MC^2 equation. Now if we apply this to BA, E = Energy, M = Mass & C is speed of light. Now to find out how much energy it takes to make 1 Metal, we substitute M=1 and c = 3x10^8

E= (3x10^8 )^2) = 9x10^18 = 9000000000000000000

Now ofcourse this process is not 100% efficient, but say it was a more realistic 50% efficient it will require twice as much energy.

Therfore by using faultless logic, I DEMAND that you make metal makers use 18000000000000000000 Energy per second!

Posted: 08 Feb 2007, 20:58
by el_matarife
Catapults and Juggernauts are not EMP resistant. They remain the only T3 mechs not to be EMP safe, even the Marauder/Shiva amphibious mechs are EMP immune.

Posted: 08 Feb 2007, 20:59
by QMan
As to the metal generator thing, at the end of the day, the total metal/energy put into the system should be fairly balanced.

Using my "logic", metal generators would have a long build time and large upfront energy requirement, but provide free metal afterwards. Metal makers are quick build, low upfront cost buildings, but with high usage costs. Using this logic, at some point in time T > 0, the total energy put in and metal taken for both buildings will meet. Using a MetalMaker for a shorter time period than this time T will be more efficient than the generator, wheras using it longer will be less efficient than the generator.

You basically pick a point T, factor what the energyCost/energyUsage/metalMake should be based on this time, and you're done. :)

Posted: 08 Feb 2007, 21:12
by QMan
As to the maxSlope thing, here's the code that pulls the maxslope from the unit file:

Code: Select all

tdfparser.GetDef(ud.maxSlope, "0", "UNITINFO\\MaxSlope");
...
ud.maxSlope = cos(ud.maxSlope*(PI/180));
That looks like it expects degrees to me. :)