Aircraft landed and shooting

[Jools]

How do we control aircraft land behaviour? I mean for instance that fighters can land and still shoot at enemies. Is there some unitdef tag that controls this?

It's not always a good thing, fighters become very op when they can do this.

[luckywaldo7]

You can likely control it through the animation script. Something like not returning any fire points when the unit is below a certain height above the land.

[Jools]

But that's a complicated solution. I observe that ba has fixed this by reducing the los of fighters (while keeping their air-los high)

[KDR_11k]

Normally it's just "hope that nothing enters the firing cone while the fighter is landed" because they use non-turret weapons.

[smoth]

I like when they land in front of their target and then shoot it to death. By like, I mean, I laugh at the bug.

[Silentwings]

Afaik this was never 'fixed' in BA or ever even thought of as a bug. Personally I have no strong feeling for or against it happening. If you want them not to fire while landed then I'd also say the unit script is the natural place.

[smoth]

Considering the unit script knows its id and that means no loop in game frame no table to maintain on create/death!

[Jools]

I thought this was a new thing, I don't remember that it happened before. But if it has matured into a feature then I think we can live with it.

Personally I'm not that good with cob and there is no code at the moment that handles targetting in the script, that i know of. So it's maybe easier to adjust the cones and the los radiuses anyway, especially since fighters maybe do not need large those anyway.

[smoth]

I am personally bothered by the fact that anything still uses cob.

[Jools]

Why? It's faster than lua and it can be compiled.

[FLOZi]

Why? It's faster than lua and it can be compiled.

Citation needed.

[smoth]

I am personally bothered by the fact that anything still uses cob.

Why?

• It doesn't have to be compiled.
  • which gives it the ability to be updated with luarules reload instead of being forced to restart spring with each change
  • which removes the need to use the antiquated scriptor
• It has access to waaaaaaay more than a cob script.
  • so you can do a LOT more with them due to acess to spring that cob simply does not have access to.
  • It is able to do more intelligent things like reading the unitdef, allowing me to do the generalized script which was near impossible with cob
  • it is lua instead of the exceptionally limited bos

Yes, I also second flozi's request. Do you have evidence or is this mere speculation?

[Jools]

It's not speculation, if I would speculate I would go to the stock market. Speculation is the wrong word. It's an unverified hypothesis.

However, it's logical to assume that compiled things are faster than things done in run-time. To me it sounds counter intuitive that the reverse should be true, that lua would be faster. But the difference in speed may be marginal anyway.

I like things that you can compile, it gives you faster feed back than runtime bughunting. In the environment I work in, I cannot reload scripts anyway during run time and have to exit and reload spring in any occasion, so for me the compile step is not extra work, rather it helps to spot obvious errors.

Extra acces to things in lua is a big plus though. I wasn't aware of that based on the existing documentation.

[smoth]

It's not speculation, if I would speculate I would go to the stock market. Speculation is the wrong word. It's an unverified hypothesis.

spec·u·la·tion
ˌspekyəˈlāSHən/
noun
noun: speculation; plural noun: speculations

1.
the forming of a theory or conjecture without firm evidence.

con·jec·ture
kənˈjekCHər/
noun
noun: conjecture; plural noun: conjectures

1.
an opinion or conclusion formed on the basis of incomplete information.

it is exactly speculation.

[smoth]

I like things that you can compile, it gives you faster feed back than runtime bughunting.

Not in the context of spring.

In the environment I work in, I cannot reload scripts anyway during run time and have to exit and reload spring in any occasion, so for me the compile step is not extra work, rather it helps to spot obvious errors.

but we are talking spring.

To compile something is to convert it to some sort of code that can be understood by the machine's hardware. Scripts doing this is silly as they still have to be read and then run by an engine. There is nothing gained outside of some possible optimization done during the compile process. Odds are this is not really an optimization for spring it was an optimization for OTA and I have no idea why they even felt the need to do it.

Extra acces to things in lua is a big plus though. I wasn't aware of that based on the existing documentation.

Why didn't you look at MCL or GBS? both of which easily demonstrate the power of unit scripts in lua.

[knorke]

The callins MoveRate () Activate () Deactivate () would be another way to check if aircraft is landed or in air.

http://springrts.com/wiki/Animation-CobLuaDifferences
Why anyone would be personally bothered because of whatever scripting in some years old mod I still did not understand.

So it's maybe easier to adjust the cones and the los radiuses anyway, especially since fighters maybe do not need large those anyway.

Please do not mess around with such things just to fix a problem that in 99% cases is purely cosmetic...

[Jools]

It's not a cosmetic problem.

[smoth]

I agree that it is not a cosmetic problem but there are ways to fix it. the thing is, unless it is considered a bug by that project, there is no way to fix it. I assume you are talking about ba/bar

[Beherith]

havent yall heard of /reloadcob?

[jK]

The callins MoveRate () Activate () Deactivate () would be another way to check if aircraft is landed or in air.

Yep, Spring.GetUnitIsActive() returns true when aircraft's engines are active