Spring RTS Engine

Auswaschbar wrote:I dislike the new anti-combomb rules. Imho its stupid and unintuitive.

It's not anti-combomb rules as it doesn't affect your day to day combombing.

It should only go off in the event that the game has ended (ie only 2 coms left, com-ends is on in some form, both explode), even in FFA this will only go off on the last 2 commanders.

The only idea is that instead of noone winning there's a clear winner hence the 'Prevent Draw Mode'.

I do agree it's a little unintuitive and I should probably just spawn a new invisible commander under the map or something rather than leaving the com alive I suppose but since the game's over it's not too important.

TheFatController wrote:It should only go off in the event that the game has ended (ie only 2 coms left, com-ends is on in some form, both explode), even in FFA this will only go off on the last 2 commanders..

This is the point. Why does everything which works for all the 14 commanders ingame doesn't work for the last 2? Why do the abilities of 1 commander depends on how much of the other commanders survived?

Auswaschbar wrote:This is the point. Why does everything which works for all the 14 commanders ingame doesn't work for the last 2? Why do the abilities of 1 commander depends on how much of the other commanders survived?

If there are exactly 2 comms left, and it is comm ends, then it only makes sense for only one commander to survive and that commander should be the one that didnt just blow up next to the other. i.e the surviving comm should be the one that would have died 'second' due to the other comm dying.

One problem with it though. You cant dgun the opponent and retreat to a hovertrans.

I realised that after I uploaded 7.01 and i'm not sure whether to fix it or not..!

Can you change how coms dgunning eachother work atm? The dgunner usually gets the 2500 metal from his own wreck and the other player often only 1250...I don't think there should be an incentive towards dgunning other coms.

TheFatController wrote:I realised that after I uploaded 7.01 and i'm not sure whether to fix it or not..!

DO IT

Ive never seen it happen in an actual game, but i would want to

I very nearly pulled this off on a DS Island game with a boat trans. I missed by pixels.

TheFatController wrote:

hoijui wrote:still has the

Code: Select all

[      0] gf1 = LuaRules/Gadgets/unit_shield_watch.lua
[      0] gf2 = LuaRules/Gadgets/areaattack.lua

spam.
not done any further tests yet.

Hmm, what spam? Just in infolog?

yes, just there. see this:
http://springrts.com/phpbb/viewtopic.ph ... 04#p372604
99% of bug reports are with BA, of course, and the infologs get longer and longer.

HLLT costs more than beamer, but beamer is better than HLLT

the beamer has higher dps and more importantly, longer range

if the two are placed within range of the HLLT, the beamer wins.

the superior range and dps of the beamer make it much more effective vs attacking raiders than the HLLT

core needs sum luvin'

"That is just a factional strangth;Core makes up for it in other areas."
Just repeating one of the most used mantras...

Maybe consider http://springrts.com/phpbb/viewtopic.php?f=23&t=19672 for coop mode

Found a pretty annoying bug yesterday. I built a vehicle lab on a slight slope (the part next to the geo spot near the water on Tabula) and units couldn't leave the lab -- they'd just stand there stupidly.

Turns out the auto-smoothing from when I laid down the lab created a slight ridge in front of it that was then impassible to the vehicles that it produced. It took me a while but I eventually figured out I could order my commander to restore the area so they could leave.

I'm not sure what a good fix for this is -- maybe reduce the auto smoothing from lab placement?

YokoZar wrote:Turns out the auto-smoothing from when I laid down the lab created a slight ridge in front of it that was then impassible to the vehicles that it produced. It took me a while but I eventually figured out I could order my commander to restore the area so they could leave.

I'm not sure what a good fix for this is -- maybe reduce the auto smoothing from lab placement?

Some new players don't figure it out at all and end up building another lab, and/or getting very frustrated.

Implement a gadget which automatically restores ground infront of factory when it completes?

Two bugs:

1) T1 fighters should probably have transports in their priority target list. See http://springrts.com/phpbb/viewtopic.php?f=44&t=20429

2) I've seen crashing bombers still drop bombs when they happen to fly over their target. This is even more annoying than them still having vision -- both should be disabled.


Thank you for making BA kick :)

so wait if i rezzed a few coms in an ffa game and combombed the last enemy com with a rezzed commander that would still work right?

YokoZar wrote:Found a pretty annoying bug yesterday. I built a vehicle lab on a slight slope (the part next to the geo spot near the water on Tabula) and units couldn't leave the lab -- they'd just stand there stupidly.

Turns out the auto-smoothing from when I laid down the lab created a slight ridge in front of it that was then impassible to the vehicles that it produced. It took me a while but I eventually figured out I could order my commander to restore the area so they could leave.

I'm not sure what a good fix for this is -- maybe reduce the auto smoothing from lab placement?

that happens in dsd too sometimes, left bottom spots. maybe make the auto-smooth do the smoothing with a bit more of a falloff distance so the slope has a smaller angle?

YokoZar wrote: 2) I've seen crashing bombers still drop bombs when they happen to fly over their target. This is even more annoying than them still having vision -- both should be disabled.

thats not a bug thats a feature you need to fps them to do that and i think its one of the coolest ways to fuck with your enemy

YokoZar wrote:Two bugs:

1) T1 fighters should probably have transports in their priority target list. See http://springrts.com/phpbb/viewtopic.php?f=44&t=20429

2) I've seen crashing bombers still drop bombs when they happen to fly over their target. This is even more annoying than them still having vision -- both should be disabled.


Thank you for making BA kick :)

I think all forms of AA should have transports in their priority list

1v0ry_k1ng wrote:

YokoZar wrote:Two bugs:

1) T1 fighters should probably have transports in their priority target list. See http://springrts.com/phpbb/viewtopic.php?f=44&t=20429

2) I've seen crashing bombers still drop bombs when they happen to fly over their target. This is even more annoying than them still having vision -- both should be disabled.


Thank you for making BA kick :)

I think all forms of AA should have transports in their priority list

As should commanders