ZSU-23-4 "Shilka"

27 Apr 2015 19:57 #23129 by Tomaskom
The ZSU-23-4 "Shilka" is a self-propelled lightly armored vehicle equipped with radar-guided anti-aircraft cannons. It was developed around the year 1960 and was considered very dangerous for low flying aircraft, outclassing all similar weapon systems at the time. While being rather ancient by today's standards, it can still pose a major threat to lightly armored aircraft within it's range. It is still in service in many countries and is considered very reliable.


I intend to use this model , but I need to wait for the green light from the author.

I'm planning to use YASim FDM and I've been already thinking about how to simulate a vehicle with tracks with it.
I'd like to use minimum of 6 wheels, 2 with fixed orientation in the centers of the tracks (with thrust applied on those) and 4 of them placed in the front and rear end of each track, able to rotate freely and with weaker springs. I saw a wheel able to rotate freely on some taildraggers and this will allow me to for example turn on a spot. I will probably add more of those wheels without fixed orientation for more realistic behavior on edges if the approach proves to be useful.
All the wheels would have rather high friction coefficient, so braking would be rapid like it is with anything on tracks in a terrain.

The Shilka would be fitted with a tracking script originally developed for the Phalanx, but instead of being controlled by the central systems of the ship, the user would have a dialog window with all necessary controls at hand, including options of autonomous operation or manual picking of targets from a list.

"There are no problems in the air. The only problem is hitting the ground."

Please Log in or Create an account to join the conversation.

27 Apr 2015 22:28 #23134 by Warty
Once the tracks are sorted, we could try it out here :cheer:


Mac 10.10.5 Yosemite, FG3.6RC

Please Log in or Create an account to join the conversation.

28 Apr 2015 07:46 #23137 by geed
OMG Warty - why did you hide this for so long???? This is awesome!!

Btw - if you want this sort of flying - come and join me whenever you want. :) Busdriving is for everyone - low level for the crazy ones. I don't consider myself a bus driver..

Please Log in or Create an account to join the conversation.

28 Apr 2015 08:55 #23138 by StuartC
Need more MP heli Cockpits...........
Dont think I have a Scout Model, but Im sure we have a Wasp that can be brought to life for you Warty.

Please Log in or Create an account to join the conversation.

28 Apr 2015 10:04 #23139 by Warty
Geed: part of the need to practise this kind of flying was the very real fear that, one working day, you may be on the receiving end of a ZSU. I also thought it appropriate because it shows the type of terrain that a tracked vehicle is expected to cope with.

Stuart: externally the only really obvious difference between the two was the undercarriage, though the cockpits were waaay different. And, of course, the role equipment. This Flight article is a good backgrounder. Maybe a new topic for Scout/Wasp? Much more info on this but I'm trying no to go off topic - yet again :)

Mac 10.10.5 Yosemite, FG3.6RC

Please Log in or Create an account to join the conversation.

28 Apr 2015 11:16 #23140 by geed
I get where you were coming from. It's a perfect example for a very realistic simulation using Flightgear and I'd like to see some kind of more realistic scenarios with the right equipment. Maybe those ZSU's could even be AI and try to fire at you so we could have a nice challenge. (mixed with human controlled ones this could get VERY interesting)

Btw, I love flying low and I understand the tactical advantage it gives. :) Just wanted to express that :) Been there at both ends (the barrel and the cockpit)

Hmmm, could be a nice work to add trees and stuff to Sailsbury in FG so that everyone has the same experience every time. Might just be hard to find the right spots in the UFO without a real landmark in the Flightgear terrain.
Maybe its time for an object editor over a map. As far as I understand, placing objects requires UTF coordinates and if you place them at -9999 they are being placed at 0 altitude, right?

hmm... that now is off topic like hell - sorry Tomas I will shut up ;D

Please Log in or Create an account to join the conversation.

28 Apr 2015 11:37 #23141 by Tomaskom
AI scenario is certainly not a problem, just the ZSUs would be probably not moving. But adding the code directly to the model nasal part defaulting to automatically search for targets and open fire is really simple, then you just scatter multiple of those in the desired area.

"There are no problems in the air. The only problem is hitting the ground."

Please Log in or Create an account to join the conversation.

28 Apr 2015 11:42 - 28 Apr 2015 11:58 #23142 by Warty
I'll have look at the area around Hildesheim to see if I can add some features. There were Scouts, Gazelles and Lynx there at one time and it is pretty close to the former East/West German border. If it actually had kicked off, this area would probably have seen the first encounters with a ZSU.

Edit: it's still there! EDVM
....../Objects/e000n50/e009n52/3105675.stg

Mac 10.10.5 Yosemite, FG3.6RC

Please Log in or Create an account to join the conversation.

28 Apr 2015 12:57 - 28 Apr 2015 12:57 #23143 by geed
In a perfect world I would think of supporting and doing recon in a helicopter together with ground forces partly controlled by AI and human. :)

Just like this one:

(This is Steelbeasts Pro PE)

The video also shows nice AI unit movement in a tactical scenario as ell as the needed visual quality for ground units.

Please Log in or Create an account to join the conversation.

28 Apr 2015 14:27 #23144 by Warty
So, Hildesheim gets over-run on day zero :(



Interesting to see US forces in the BFG/BAOR area. Coming to our rescue, I suppose :huh:

Mac 10.10.5 Yosemite, FG3.6RC
Attachments:

Please Log in or Create an account to join the conversation.

28 Apr 2015 15:58 #23147 by Warty
Tomas: a request from me, though I realise that it may be impossible to implement. I noticed the other day that the system can see through rock (as in the Rock of Gibraltar). It can also fire through it. So there is really "no hiding place" from it.

So, my question is: would it be possible to prevent it from locking on and (especially firing) when it doesn't have a visual? My understanding, from wayback, is that it could continue to track at the same rate when it lost you (behind the trees, for example) which is fair enough.

Mac 10.10.5 Yosemite, FG3.6RC

Please Log in or Create an account to join the conversation.

28 Apr 2015 16:21 #23150 by Algernon
I'm also thinking about something similar, as I'm trying to work out how to hide returned radar signatures when there is a landmass in the way (the Rock is a good example here). Although I haven't even gone near experimenting with it, I intend to make a marine radar that detects land mass in a similar way to the moving map we use.

I'd imagine it's a case of seeking out ground elevation data along a straight line, repeated over a number of scan increments within the radar's scan scope. It should be possible, but what the drain on the system will be I don't know - apparently pulling out geophysical data is relatively system-heavy, so doing it enough times to build a landmass picture and keep the scan rate realistic might be a challenge.

Please Log in or Create an account to join the conversation.

28 Apr 2015 16:38 #23151 by Tomaskom
Actually, that is possible and I remember reading someone tried implementing it for a radar system. However, reading and processing geodata in such way would totally kill performance. Still, there might be a way to do a rough approximation...
I will try to benchmark how long it takes to get a single geodata entry, and if it completes within acceptable time, I could for example read out 4-10 points on the line towards the target (number of points depending on distance) and watch whether any of them is above the direct line. If I do this only for targets within range that fulfill all other conditions first, I feel it might work just fine. However, any thin obstacles could be easily ignored by such simplistic check. How fine sampling can be used will depend on the results of the performance benchmark I will perform. And of course, it should be possible to turn it off in situations with too many targets.

reference to the geodinfo() function:
wiki.flightgear.org/Nasal_library#geodinfo.28.29

Thank you for the idea! I noticed it too, but immediately thought of it as an almost impossible thing, also not very often needed for a ship :P
But ZSU operating in a terrain is a different thing and this would definitely add a bit more realism :)

"There are no problems in the air. The only problem is hitting the ground."

Please Log in or Create an account to join the conversation.

28 Apr 2015 17:02 #23152 by Tomaskom
Good news everyone!
Did a fast benchmark, one execution of the geodinfo() function takes below 50ns and when looping it several times, even less per one execution.
So doing say 100 of those with many targets present will be 5ms max, which is absolutely fine for execution in every target search loop :)

Tomorrow I will start implementing it ;)

"There are no problems in the air. The only problem is hitting the ground."
The following user(s) said Thank You: Algernon, Warty

Please Log in or Create an account to join the conversation.

28 Apr 2015 17:16 - 28 Apr 2015 17:17 #23153 by Warty
Just an off-the-wall idea here from someone who knows absolutely nothing of the programming side of this. If the sim cannot "draw" you on the screen, from its own viewpoint, then the ZSU cannot see/track you, no?

Mac 10.10.5 Yosemite, FG3.6RC

Please Log in or Create an account to join the conversation.

28 Apr 2015 19:53 #23155 by Algernon
Good timing. I'd like to talk about the radar before any of our radar-centric projects go too far...

As I said in another post recently, I'm really keen to go up a level in the way radar works on FlightGear, because it seems only fair that you should have a chance of foiling the radar-based systems - at the moment, the chances of surviving an attack by a Phalanx or Shilka would be pretty much nought. This seems like the right time to push for incorporating that goal into our thinking in the current projects.

Please join in the discussion in that thread , so we can start thinking now about a bit more realism in the detectability of radio signals. :)

Please Log in or Create an account to join the conversation.

28 Apr 2015 20:41 #23159 by Warty
No can do on the radar discussion, I'm afraid ("ACCESS DENIED: You do not have permissions to access this page."). Meanwhile, on what was the old eastern front, although the area around Hildesheim is a bit sparse for buildings it has plenty of pylons and the wooded areas are well marked. So, by turning up the "Random vegetation density" to 2.5, there are a fair number of trees to dodge/hide behind. Much higher than this 2.5 slows my fps down too much for my liking, but it should appear similar for all on MP without having to plot trees in the .stg files.



Could really do with a rad-alt on this :)

Mac 10.10.5 Yosemite, FG3.6RC

Please Log in or Create an account to join the conversation.

28 Apr 2015 20:47 #23160 by StuartC
Little box on top is for the Rad- alt, but I forgot to set it up.

Please Log in or Create an account to join the conversation.

28 Apr 2015 22:05 #23161 by Warty
Sorry if I’m being a pain on this subject, but it has occurred to me that the algorithm for the Phalanx may not work so well for the Shilka.

Theoretically, a Scout or Lynx could take out a Shilka with an SS11/TOW - not that most aircrew would consider getting involved with a duel of this nature to be a very clever idea. Ideally, a Gazelle would have spotted the ZSU and told the Scout/Lynx about it. The anti-tank crew would then plot a course to get within firing range, staying out of sight of the ZSU as much as possible. They would then pop up above the tree-line and engage it. But they certainly wouldn’t head towards it. Apart from being pointless and suicidal, there’s the issue of where the trailing missile wires might end up. So how would the current algorithm identify this as a threat?

Mac 10.10.5 Yosemite, FG3.6RC

Please Log in or Create an account to join the conversation.

29 Apr 2015 00:28 #23163 by Tomaskom

Warty wrote: (...) They would then pop up above the tree-line and engage it. But they certainly wouldn’t head towards it. Apart from being pointless and suicidal, there’s the issue of where the trailing missile wires might end up. So how would the current algorithm identify this as a threat?

The geodinfo() function tells me apart from other things the type of the terrain. So I could easily add a few tens of meters simulating the trees whenever the terrain says it is a forest. You would be then simply undetectable when low enough (I will probably add a few m for any type of terrain too). FYI, the tree models have no significance in terms of terrain other than just being visual features. I think they are not even "hot" (meaning you can't crash into them).

So that's what I can (and will) do about your ambush scenario.
However, I can know nothing about aircraft types and equipment, so I can't weigh threats by any other means than by position and movement. And hardcoding certain types of aircraft as priority targets would be just ridiculous.

"There are no problems in the air. The only problem is hitting the ground."
The following user(s) said Thank You: Warty

Please Log in or Create an account to join the conversation.

Time to create page: 0.186 seconds
Powered by Kunena Forum

PM Mailbox

You are not logged in.

Forum Search

Keyword