Questions about shield and jammer behavior

[jamesbigmac]

Hey everyone, I'm new to the forums and to developing for Spring, and I just have some questions about what Spring's shields and jammers can do. Sorry if I'm asking duplicate questions.

1. Can a shield be linked to a toggle button without a gadget?
1.a. If so, can the shield and jammer be linked to the same toggle button just so I can have a nice visual animation of the area being jammed on the map without having two toggle buttons?

2. Is there a simple way to make the jammer tail off in strength (like a BeamLaser) the further it gets away from the unit, or is a gadget needed? The jamming strength could just be calculated through a function by using distance.

The idea of having the jamming power decrease over distance would be used to calculate a unit's ability to transmit to something outside of the jamming radius so that the unit inside could receive further orders from some command unit. The overall point is to build a simulation of real-world tactics in jamming and transmission of orders.

[knorke]

1) yes, in the unitdef: onoffable =true, adds a on/off button.
that button toggles radar,jammer,shield at once.

2) no, jammer strength is either "jammed" or "not jammed"
Since a unit is either visible on radar or not, I am not sure what effect strength would have.

The overall point is to build a simulation of real-world tactics in jamming and transmission of orders.

possible with gadget. you do not need the engine jammer thing though, just define your own variables.

[jamesbigmac]

I've been using the on/off button for the jammer, but the shield stays constant. Do I have to mess with the energy consumption or some other variable to get it to switch on and off with the jammer?

[Google_Frog]

...without a gadget?

What do you think a gadget is? Why do you want to do this? If you set out to make a game for Spring just by tweaking unit stats you're doing it wrong.

You need a gadget to do most things TA couldn't do. You even need a gadget to write nice unit animation scripts.

I think a transmission of orders system is possible. It definitely requires gadgets.

[jamesbigmac]

I'm still having trouble finding a way to disable and enable the shield. I've been trying to use the Activate() and Deactivate() callins in the animation script, but hiding pieces doesn't do anything, and setting the shieldalpha to 1.0 or 0.0 does nothing because I'm assuming the weapon def is only read when the unit is created (so if it is changed after the unit is created it has no effect on the current unit).

Is there a way to alter the jammer drawing so that I can visualize it better without using another animation? Should I draw a sphere that updates every frame and follows the jammer instead of using a shield?

[FLOZi]

Spring.SetUnitShieldState
( number unitID [, number weaponID = -1] [, boolean enabled] [, number power] ) -> nil


Can be called either by a gadget or directly from your unit script (LUS).

[Google_Frog]

Take a step back and tell us what you're trying to do. I get the impression that you are trying to visualise jammer range with a shield. This is really not the way to do it.

You can draw anything with lua and drawing a sphere is certainly feasible. Here is a picture with a bubble drawn on top of a hill.


But to step back even further it sounds like you don't want jammers at all. Jammers do not block unit orders. Jammers simply hide radar dots in an area. Command blocking is easy to do with a gadget.

[jamesbigmac]

Thanks so much Flozi!
I had been trying some other functions and they were not working. That fixed the visualization problem I was having.

Now I'm going to have state variables that denote receiver thresholds and sending thresholds on units to calculate whether or not they can receive commands, and how far they can send a command from inside the jamming.

[jamesbigmac]

Google Frog, I know that jammers do not block command orders, but I'm thinking I can use the jammer to tell whether or not something is inside jamming range. If it is being jammed (aka inside the jamming threshold), then you calculate the distance to the jammer to see what the jamming power is.

[Google_Frog]

As a general rule of thumb avoid using Spring features to implement unrelated behaviour.

Get an idea of what gadgets are capable of. A basic thing that they can do is read unit position, this is enough to determine the distance between two units. There is even a function that specifically determines the distance between two units for you.

[jamesbigmac]

That's what I had planned on doing. I just wanted a way to visualize exactly where the jammer's radius was and it seemed like a shield was a nice way to do it.

[Google_Frog]

Then what is the jammer for? Shields are visible to opponents and toggling them is synced and their visualisation is fixed as a sphere. I wouldn't worry about it now (probably better to do mechanics) but with lua you can probably draw something more appropriate for your mechanics.

[jamesbigmac]

Right now the jammer is being used to tell whether or not something is being jammed. If it is, then calculate the distance to the jammer. I thought it would save the game some calculations because that way you can check if you even need to do the power calculations (the power calculations are not trivial since it is a simulation). Otherwise, you would be calculating the the jamming power, receiving threshold, and other things no matter what.

[SinbadEV]

Maybe we aren't being clear.

What you are currently doing:
Having the engine handle radar jamming for all units.
Testing each unit in the game to see if a unit is jammed
Calculating the distance between the unit and each jammer
Doing your advanced calculations if the unit and a jammer are close enough to each other.


If you just used Google_Frog's you would be:
Calculating how close each unit is to a certain other unit
Doing your advanced calculations if the unit is close enough to the other unit.

[Google_Frog]

Right now the jammer is being used to tell whether or not something is being jammed.

I don't know if this can be done. Just guessing I think it would be slower to do 1 engine call for each unit and then 1 additional call for each unit within a radius.

If your jamming system is for order receiving you only need to check jamming when an order is given.

In any case don't do heavy optimisation before the system is implemented, especially if you don't have a feel for lua speed in Spring. Believe me when I say that a manual distance check without any prior sorting should be fine. There is a slim chance that eventually you have performance issues but I would leave them until you are more experienced and have a better idea of the system you want to implement.

[jamesbigmac]

Well that's not what I am doing. When the AllowCommand() gets called in my gadget:

Test if the unit trying to receive the command is a quad rotor unit
Test if it is being jammed (Isn't there a boolean for isjammed or something like that?)
Calculate distance, jamming power, etc.
Return true or false depending on if the jamming power is too much and will cancel the command or not.

Edit: I might just do the distance calculations between the quad rotor and all jammers since there won't be more than 5 jammers at one time.

By the way, I appreciate all of the input and the quick responses.

[Beherith]

Fyi, jammer is global, it jams enemy radar as well.