Balanced Annihilation 7.62 - Page 2

Balanced Annihilation 7.62

Classic game design, maintained to please you...

Moderators: Content Developer, Content Developer

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Balanced Annihilation 7.62

Post by knorke »

Here is a replay (not that short, sorry):
http://db.tt/WATTkECW
thanks but it is the same error as with the shorter replay i attached 2 posts up.

I commited a fix for the
LuaRules::RunCallIn: error = 2, GameFrame, [string "LuaRules/Gadgets/unit_air_release_manager.l..."]:26: bad argument #1 to 'GetGroundHeight' (number expected, got nil)
spam.

Logic/balance is unchanged but I do not know if everything was working like it should in the same place?
From what I remember, units in shot down T1 transports always died.
Currently a peewee will fall down and survive with 50 hp or so.
Is that the wanted behaviour?
Similiar sometimes ejected units do funny bounces. If wanted, I can make them die instantly. (like with releaseHeld=false transports)
0 x

User avatar
Beherith
Moderator
Posts: 4934
Joined: 26 Oct 2007, 16:21

Re: Balanced Annihilation 7.62

Post by Beherith »

The only reason the drop logic was added was so that if a comm got shot out of a transport juuuust before it was unloaded or right after it was loaded, it wouldnt die. Other than that, every unit dies on air transport death.
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Balanced Annihilation 7.62

Post by knorke »

Other than that, every unit dies on air transport death.
you mean should die? Because in BA 7.62, they dont.

also should units shot down in transport leave a wreck?
I think no, except commanders?

---
commited everything...

How it now currently works:
-commander in transport, trans dies -> com explodes as well, leaves wreck
-normal unit in transport, trans dies -> unit dies as well, no wreck
-no crash/errors as far i tested (repeatedly flying 20 loaded transportes into a group of AA trucks)
Attachments
20111216_174311_DarkSide Remake_84.0.sdf
stumpy surving transport death in BA7.62
(15.04 KiB) Downloaded 9 times
0 x

User avatar
Beherith
Moderator
Posts: 4934
Joined: 26 Oct 2007, 16:21

Re: Balanced Annihilation 7.62

Post by Beherith »

Thanks very much knorke for fixing this in the SVN!
0 x

User avatar
very_bad_soldier
Posts: 1371
Joined: 20 Feb 2007, 01:10

Re: Balanced Annihilation 7.62

Post by very_bad_soldier »

Yeah big thanks knorke!

How does a midair comblast deal damage now? In recent BA versions that damage was reduced to nerf combombs by air (which was neccesary imo). Is it still that way?
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Balanced Annihilation 7.62

Post by knorke »

How does a midair comblast deal damage now?
Should not be affected by my changes.

I thought there was maybe a potential for failure in the mo_fullcomblast_damage (or whats it called) gadget where it does:

Code: Select all

UnitPreDamaged (...)
if (weaponID == COM_BLAST)
When other gadgets use AddUnitDamage to damage units, weaponID might be nil(?) -> "attempt to compare number with nil value"
But since I never encountered that, it is maybe okay.
0 x

Pako
Posts: 174
Joined: 12 Jul 2009, 18:57

Re: Balanced Annihilation 7.62

Post by Pako »

knorke wrote:From what I remember, units in shot down T1 transports always died.Currently a peewee will fall down and survive with 50 hp or so.Is that the wanted behaviour?
I set the fall damage value so that one lucky PW could survive sometimes.
Beherith wrote:The only reason the drop logic was added was so that if a comm got shot out of a transport juuuust before it was unloaded or right after it was loaded, it wouldnt die. Other than that, every unit dies on air transport death.
Totally wrong, afaik it was originally made for core commandos and later modified to include commanders. In 84 engine there was two huge bugs:
-units didn't take damage from falling anymore just bounced around the map
-whole game always crashed when Level 2 transport carrying commander got killed
I removed the gadget to prevent game crash then rewrote it to add falling damage for units falling from killed transports and set commandos never take falling damage.
knorke wrote:also should units shot down in transport leave a wreck?I think no, except commanders?
What is the logic behind this infinite damage insta kill for carried units? Even humans can survive an aircraft crash.

Not everything needs to be 100% logical but I try to always follow pure logic and that is why I'm very rarely wrong.
Also illogical "retardness" and bad defaults are the biggest reason why most Open Source shit is not good.
Beherith wrote:Thanks very much knorke for fixing this in the SVN!
No thanks for fucking up my beautiful gadget.
very_bad_soldier wrote:How does a midair comblast deal damage now? In recent BA versions that damage was reduced to nerf combombs by air (which was neccesary imo). Is it still that way?
That was a totally BS change not only because it took great amount of fun away the game but it was a hidden switch, you could never know if combomb was a valid stratigic move or not. Any retard should know that hidden strategy options are bad in a strategy game. Just make it a fixed change or make a proper UI so that players always know how it is.
knorke wrote:(weaponID == COM_BLAST)
you can do: if (nil == 5) or (false == 5)
you can not do: if (nil > 5) or (nil == nil-10) or (h > y-10)

Now look back to your fix and maybe see how shit it is. You managed to make a 10 second fix into a 10 minute fix and a complete failure.
There are at least 3 bad bugs in that fix:
- Spring.AddUnitDamage --adding damage to already killed unit
- h = Spring.GetGroundHeight(x,z) --x can be a nil and assinging a global h
- h > y-10 --using that global which can be still nil and crash
-table.remove(fallingUnits,k) --will skip the next table pos. with ipairs
And I actually fixed that gadget few hours after it was released:

Code: Select all

if x and Spring.GetGroundHeight(x,z) > y-10 then
Not perfect but less bugs than knorkes over complex fix.

And then knorke started bashing my Lua skill in a public chat like morons.
<[RoX]knorke> imo that whole gadget is a bit fail
<zwzsg[IRC]> also, fC = fC -1 makes me :(
<zwzsg[IRC]> I use #
Biggest problem for BA gadget crashing is the handler is not in safe mode and when a gadget crashes the rest of gadgets wont be processed for that frame.

Engine developers are not too keen for keeping backward compatibility for BA, rather they are removing the hard-coded TA values so things can break anytime. There are already dozens of small bugs because of recent changes.

Safe mode is easier than easy to set but I don't think it is the best solution. Maybe a good solution would be to add gaget.GetInfo().nonSafe for huge shitty gadgets like the mex upgrader.
0 x

User avatar
Niobium
Posts: 456
Joined: 07 Dec 2008, 02:35

Re: Balanced Annihilation 7.62

Post by Niobium »

Pako wrote:
Beherith wrote:Thanks very much knorke for fixing this in the SVN!
No thanks for fucking up my beautiful gadget.
I can't tell if you are joking or attempting to troll or what. The gadget is unarguably bad, it does a lot of things it doesn't need to and does a lot of things wrong. I'd list the problems but honestly I have an issue with almost every line/step of logic in it. Further in your post you even attack knorkes fix, quoting lines that were in the original and untouched by knorke... Strange.

Knorke deserves praise for improving it (even if it isn't perfect), BA needs people who are willing to put in effort.
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Balanced Annihilation 7.62

Post by knorke »

:shock: epic stupid forum rap battles of histoooooory:
Pakooooooooo vs knooooooooorke
what you think it looks like, what it actually looks like. :?
You managed to make a 10 second fix into a 10 minute fix and a complete failure.
There are at least 3 bad bugs in that fix:
It's funny because I told you first in lobby chat:
-table.remove(fallingUnits,k) --will skip the next table pos. with ipairs

<[RoX]knorke> yours crashes anytime a unit is killed in midair i think. and randomly from the removing while looping
<[LCC]Pako> "randomly from the removing while looping" any proof?
<[RoX]knorke> iam not 100% sure but i think table.remove shifts elements positions in the table?
<[RoX]knorke> which confuses ipair
<[LCC]Pako> I think that it is safe to do it with ipairs
<[LCC]Pako> I didn't seek example though
<[LCC]Pako> zwzsg said it is okay and I have used it many times before
<[RoX]knorke> removing last element is probally safe. from middle i dont know
<[RoX]knorke> but no idea really

That is why I added the ValidUnitID-check, because I was not 100% sure if that "removing element" stuff was reliable.
(better safe than sorry)
- h = Spring.GetGroundHeight(x,z) --x can be a nil and assinging a global h
because of the ValidUnitID-check, x,z can not be nil anymore.
(unless off-map coordinates but then you'd need to check for x~=nil in UnitUnloaded as well in case transport dies off-map. original gadget does neither and maybe its not even needed should engine clamp unit coords to map on unload)

- Spring.AddUnitDamage --adding damage to already killed unit
also lobby chat:
<[RoX]knorke> what i dont see in air_releaser, units only get removed from fallingUnits table when they reach ground
<[RoX]knorke> there are no checks if they were destroyed due to AddUnitDamage or normal shoting. how is that thought to work?
<[LCC]Pako> it works most of the time
<[RoX]knorke> units dying midair is not that unlikely
<[LCC]Pako> I haven't seen that ever happen
<[LCC]Pako> didn't think at the time
<[RoX]knorke> air drop 20 stumpies into 20 samsons
<[RoX]knorke> triggered it everytime for me
<[RoX]knorke> and whats worse, h > y-10 never gets true so it spams the error every frame
<[LCC]Pako> stumpies definetly should not ever get killed mid air
<[LCC]Pako> they have huge HP
<[RoX]knorke> err thats bad logic

Still those two lines:
Spring.AddUnitDamage(t[1], t[2])
table.remove(fallingUnits,k)

should maybe not be in the same if.
- h > y-10 --using that global which can be still nil and crash
I agree global is bad, uninitiliazed even more so.
Still it can not crash because the full line reads:
if (not unitAlive or h > y-10) then
When the first condition is false, the part behind the or is not checked.
Previous line is
if (unitAlive) then y = blabla
so should be safe.
(again, excep for off-map)

So from what I see, the only problem with that fix is "off-map coordinates are not checked", which is more a case of "the fix does not fix all of the original bugs"

I set the fall damage value so that one lucky PW could survive sometimes.
Introducing the kind of randomness you claim not to like (see your text about combomb. cb change at least was optionial)
Which I fixed in line with
Beherith wrote: every unit dies on air transport death.
(i kept the exception of "commando", who still gets damaged by your formula.)
And I actually fixed that gadget few hours after it was released:
if x and Spring.GetGroundHeight(x,z) > y-10 then
1) if you fixed it, why is it neither in current BA release or SVN?
2) That would introduce a bug where fC is not decreased and thus would always be > 0 once a loaded transport has died.
Does not really matter much except that this check becomes useless:
if fC > 0 then
for k,t in ipairs(fallingUnits) do


And then knorke started bashing my Lua skill in a public chat like morons.
That was the _only_ line I said about it in public chat. It holds about as much meaning as your "huge shitty gadgets like the mex upgrader."
(omgomg you bashed BigHead and DeadnightWarrior)
Engine developers are not too keen for keeping backward compatibility for BA, rather they are removing the hard-coded TA values so things can break anytime.
I am pretty sure stuff like unit bouncing physics are not based on TA, so they are hardly "TA values."
Any game is affected by this, not just BA.

In 84.0 units do still take falling damage from engine btw.
Maybe it got changed a bit but since bouncing/falling/sliding was pretty wacky in 0.82.7, I think that is okay.
0 x

User avatar
Niobium
Posts: 456
Joined: 07 Dec 2008, 02:35

Re: Balanced Annihilation 7.62

Post by Niobium »

knorke wrote:<[RoX]knorke> yours crashes anytime a unit is killed in midair i think. and randomly from the removing while looping
<[LCC]Pako> "randomly from the removing while looping" any proof?
<[RoX]knorke> iam not 100% sure but i think table.remove shifts elements positions in the table?
<[RoX]knorke> which confuses ipair
<[LCC]Pako> I think that it is safe to do it with ipairs
<[LCC]Pako> I didn't seek example though
<[LCC]Pako> zwzsg said it is okay and I have used it many times before
<[RoX]knorke> removing last element is probally safe. from middle i dont know
<[RoX]knorke> but no idea really
Removing entries from a table while you iterate through it sounds dodgy because it is, and in this case (with ipairs and table.remove) it doesn't work.

Code: Select all

local t = {} for i,v in ipairs(t) do echo(v) table.remove(t, i) end
1
3
5
0 x

Pako
Posts: 174
Joined: 12 Jul 2009, 18:57

Re: Balanced Annihilation 7.62

Post by Pako »

Niobium wrote:I can't tell if you are joking or attempting to troll or what. The gadget is unarguably bad, it does a lot of things it doesn't need to and does a lot of things wrong. I'd list the problems but honestly I have an issue with almost every line/step of logic in it.
I must have heard this before: "something is horribly wrong but won't tell what is wrong or how it could be fixed"
Niobium wrote:Further in your post you even attack knorkes fix, quoting lines that were in the original and untouched by knorke... Strange.
I try to accept my mistakes and learn from them, maybe you could try it too instead of blatantly attacking BA's progression.
Niobium wrote:Knorke deserves praise for improving it (even if it isn't perfect), BA needs people who are willing to put in effort.
I tried to tell Knorke his fix was broken before he uploaded it but he was busy telling zwzsg how my gadget sucks and when I need to repeat myself I try to do it so that any retard can understand.
knorke wrote: epic stupid forum rap battles of histoooooory:Pakooooooooo vs knooooooooorkewhat you think it looks like, what it actually looks like.
I stop fighting and declare myself winner when the opponent makes a bad mistake like: something illegal(direct insult or quoting private chat etc.), gets too emotional, gets too religious, makes too many logical mistakes etc. Otherwise it would just end up look like raping a child in public and seems bad for both.
Niobium wrote:Removing entries from a table while you iterate through it sounds dodgy because it is, and in this case (with ipairs and table.remove) it doesn't work.
Yes it is hacky, but there is not easier or faster way to achieve similar result so if it works it is fine.
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Balanced Annihilation 7.62

Post by knorke »

lol ba
0 x

User avatar
Niobium
Posts: 456
Joined: 07 Dec 2008, 02:35

Re: Balanced Annihilation 7.62

Post by Niobium »

Pako wrote:
Niobium wrote:I can't tell if you are joking or attempting to troll or what. The gadget is unarguably bad, it does a lot of things it doesn't need to and does a lot of things wrong. I'd list the problems but honestly I have an issue with almost every line/step of logic in it.
I must have heard this before: "something is horribly wrong but won't tell what is wrong or how it could be fixed"
  • Manually recording number of elements in a table
  • Using ipairs (It's slow, and you had the count anyway)
  • Failing to check if units have died
  • Failing to check if position is valid before using it
  • Possibility of calling Spring.AddUnitDamage with an invalid unit ID
  • Confusing lines of code (e.g. 'if h > y - 10 then')
  • Removing entries from a table while iterating it by index
  • Discontinuity in damage formula*
* A peewee dropped from a height of 24.99 will take ~625 damage, a peewee dropped from 25.01 will take ~23 damage.
Pako wrote:
Niobium wrote:Removing entries from a table while you iterate through it sounds dodgy because it is, and in this case (with ipairs and table.remove) it doesn't work.
Yes it is hacky, but there is not easier or faster way to achieve similar result so if it works it is fine.
It's hacky but it works so it's fine? Really? I have an issue with this kind of attitude to coding. There is rarely a reason to do something a hacky way, and in this case there are a few clean ways to do it:
  • Iterate backwards
  • Use a loop and a 'manual' iterator, adjust increments to account for removals
  • Use pairs() and 'table[key] = nil' (Which is safe while iterating)
0 x

User avatar
sillynanny
Posts: 125
Joined: 20 Jun 2008, 14:26

Re: Balanced Annihilation 7.62

Post by sillynanny »

Thank you Niobium.
0 x

User avatar
askuhn
Posts: 30
Joined: 01 Aug 2011, 19:06

85.0?

Post by askuhn »

Any news on a new release soon? Spring 85.0 broke custom formations for BA and I noticed its been fixed in the BA bugtracker for a few weeks now...just curious, thanks & Merry Christmas! :-)

(sorry if I missed something already discussed; didn't read all of this thread)

edit...
ok, going to make a liar out of myself...
there was just a commit about 4 hours ago that restored working custom formations from within the engine, lol
0 x

User avatar
Beherith
Moderator
Posts: 4934
Joined: 26 Oct 2007, 16:21

Re: Balanced Annihilation 7.62

Post by Beherith »

We are working on being ready for .85.
I just hope it comes after xmas :)
0 x

Pako
Posts: 174
Joined: 12 Jul 2009, 18:57

Re: Balanced Annihilation 7.62

Post by Pako »

Niobium wrote:Iterate backwards
Some fair points but mostly ideology, though ipairs seems more shitty than I imagined but I will still use it because it's a lot faster to code.
Niobium wrote:* A peewee dropped from a height of 24.99 will take ~625 damage, a peewee dropped from 25.01 will take ~23 damage.
That is totally natural physics, depends a lot on the structure and material.
Beherith wrote:We are working on being ready for .85.
Remove the bomber fix gadget, also air releasing could be totally removed therefore commandos and combomb full damage rule can go too.

The F3 fix widget could be fixed or removed, fixing would just keep the reverse traversal of F3 with shift.

I can't emphasize enough how shitty this line "ud.turninplacespeedlimit = ud.maxvelocity" in unitdef_post is, just remove it and use the engine default.
0 x

User avatar
Cheesecan
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Balanced Annihilation 7.62

Post by Cheesecan »

Please dont have highlight unit. xray etc widgets on by default. Breaks TA look. Also 7.63 with simple pathing modoptions update shouldve been out when 85 went live. Oh and adv player list is broken for many.
0 x

User avatar
very_bad_soldier
Posts: 1371
Joined: 20 Feb 2007, 01:10

Re: Balanced Annihilation 7.62

Post by very_bad_soldier »

Cheesecan wrote:Oh and adv player list is broken for many.
Could you give a bit more details regarding "broken"?
0 x

User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7017
Joined: 16 Nov 2004, 13:08

Re: Balanced Annihilation 7.62

Post by zwzsg »

This led me to think you can table.remove within a for .. pairs(..) loop. However I'm not sure about ipairs.
0 x

Post Reply

Return to “Balanced Annihilation”