Jump to content


Photo
- - - - -

Camera icon in dogfight missions?


  • Please log in to reply
193 replies to this topic

#41 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 24 June 2012 - 21:39

Here is a nice source of info:

http://www.oldmagazi...Photography_pdf" onclick="window.open(this.href);return false;">http://www.oldmagazi...ticles.com/WW1- … graphy_pdf

They talk about "many plates", so I still don't know how many, but probably more than 20 as they managed sometimes to take more than 2000 a day, bur for all we know that might have been all the photo's combined from several squadrons.
  • 0

#42 AnKor85

AnKor85
  • Posts: 1002

Posted 25 June 2012 - 04:46

Interesting read.
What I gather from it:
- Camera seems to be operated by a pilot. I think ingame it will appear for both pilot and observer and will work separately as if they both had cameras. It may be possible to add a restriction that only pilot can use the camera. But for gameplay purposes it may be better to allow observers take photos too.
- Altitude mentioned is 5000ft to 15000ft which gives us 1500m to 4500m. In game the upper limit is 2500m, but actually I can make altitude requirment variable for individual areas - camera icon will show the required altitude if player is too low/to high.
- One second delay between shots may be still to fast, especially if the idea is to make overlapping map images. However we may also assume that we are taking multiple images of the same object, then the delay is mostly about how fast plates can be replaced.
- Number of photos per sortie is still a question. I've also thought about something like 20… But the application of such limits will mostly depend of how many pictures for single area is required.

Many things may be variable (altitude, delay, number of photos limit) - the only problem is how to let GFX know the values.
For example adding altitude requirement for each photo recon area will change its name template to something like this, because it can't be longer than 19 symbols:
%PR 03 1200 10 2000
Event ID = 03
Radius = 1200m
Req. pictures = 10
Altitude = around 2000m

Global variables like picture limit per sortie may be encoded either into mission description text or using additional "dummy" objects with special names.

So far I see no problems with implemented anything mentioned.
  • 0

#43 Flashy

Flashy
  • Posts: 1078
  • LocationSouth Africa

Posted 25 June 2012 - 06:19

Hi Ankor,

I tried your test mission this weekend and it works well, thanks! There was one "bug" which may also be present on the standard photo flash dialogue - if you click the "Make a Shot" button when it is unavailable (has a red cross through it) then the event is triggered as soon as the button becomes available. So, for example, if you click it once when its crossed out, then fly into the zone again, you will get the subtitle without clicking again.

With regards to your ideas for improvements, cant we rather stick to checkzones instead of marker objects? In my experience, checkzones have very little effect on mission performance, whereas objects are heavily limited. If there are two marker objects per zone, and we have 16 zones, we already have 32 objects, which is getting close to the max for a busy MP mission already! Cant we somehow integrate the complex trigger into the logic of the media MCU? Complex triggers are great for detecting when specific planes are in specific spots as well as when they have landed etc. If we can use them instead of objects somehow, that would be the best solution IMO..

EDIT: Just thought of another problem with using objects. If there is an enemy or neutral object at the aerodrome, all the AI gunners (planes,ground defences, AA, etc) will open fire on it. Just something to think about..
  • 0

Just because I can give multiple orgasms to the furniture just by sitting on it, doesn't mean that I'm not sick of this damn war: the blood, the noise, the endless poetry...


#44 AnKor85

AnKor85
  • Posts: 1002

Posted 25 June 2012 - 06:59

There was one "bug" which may also be present on the standard photo flash dialogue - if you click the "Make a Shot" button when it is unavailable (has a red cross through it) then the event is triggered as soon as the button becomes available.
Yep, most likely standard dialog has the same bug. Thanks for letting me know.

With regards to your ideas for improvements, cant we rather stick to checkzones instead of marker objects? In my experience, checkzones have very little effect on mission performance, whereas objects are heavily limited. If there are two marker objects per zone, and we have 16 zones, we already have 32 objects, which is getting close to the max for a busy MP mission already!
With my latest specification the number of marker objects will be "number of recon areas" + "number of home airfields for recons". I understand that it may be a lot anyway, but the problem with GFX is that its logic cannot be triggered directly by any mission event. All it can do is to periodically check the state of AI objects. However, see below - these objects may be more than just resource hogs.

EDIT: Just thought of another problem with using objects. If there is an enemy or neutral object at the aerodrome, all the AI gunners (planes,ground defences, AA, etc) will open fire on it. Just something to think about..
You're right. Well, almost, because there's a checkbox "Engageable" in advanced properties that should prevent AI from attacking this object. Not sure if it really works though. Anyway the latest specification suggests another solution instead of what my example mission shows.

Now marker objects for recon area should actually belong to enemy side and won't be changing sides at all (except when objective is completed, but instead of changing the side we can destroy them, need to decide). Let's say we are flying *British* recon plane. Then our objective areas will be marked with *German* AAA and our home base will have friendly *British* AAA as a marker. Pretty natural I think. And this also means that "marker objects" may actually participate in a mission as real AAA guns defending their areas.
We only have to ensure that they aren't "accidentally" destroyed in a bombing raid :)
  • 0

#45 Flashy

Flashy
  • Posts: 1078
  • LocationSouth Africa

Posted 26 June 2012 - 09:26

Sounds really good Ankor, I cant wait to try out the new improved version! I think we can handle 20 or so objects, especially if we use them to do other things as well :)
  • 0

Just because I can give multiple orgasms to the furniture just by sitting on it, doesn't mean that I'm not sick of this damn war: the blood, the noise, the endless poetry...


#46 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 26 June 2012 - 10:54

After we did the optimizations on our server by running on specific cores only, we are able to handle more AI objects, so I don't really see a problem for now.
You could use AAA guns or other objects you need anyway (I often put a staff car on an airfield so it can fire flares) ,just make sure you repair them very quickly or make them invulnerable.
  • 0

#47 Waxworks

Waxworks
  • Posts: 630

Posted 26 June 2012 - 18:17

I have a copy of Terence Finnegan's 'Shooting the Front' which is something of a reference work on Entente aerial photography in the Great War.

p120 has a Table of Information for taking aerial photographs reproduced from the Gorrell Report. The altitudes used are between 1000m and 6000m. The time between exposures differs depending on lens, altitude and shutter speed. With a standard lens at 1000m the time between exposures is given as 9"-6" depending on shutter speed. At 6000m the time between exposures is 56"-44". With a larger lens the times are 6"-5" and 32"-27" respectively. With the very largest lens it is not used for altitudes below 1600m and at 6000m it is 14.5"-12.5" between exposures. So… only 1s between exposures is probably unrealistic?

Another issue that was brought up was the magazine, this varied with the camera, from as few as 12 plates to as many as 36, with the late war De Ram camera having 50. Different aeroplanes carried different cameras at different stages of the war. For example an RE8 in 1917 probably carried a semiautomatic LB type camera with an 18 plate magazine, and the LB could be used with interchangeable lenses with focal lengths from 4in to 20in. It was operated by the pilot: 'The 'LB' type changed plates and shutter setting in a single operation by the action of an air screw in the slip stream or by hand.'

Obviously I can go into more detail, unfortunately the reference is only about the Entente side, and only mentions the Germans in passing- they had the best cameras and the RFC were always scavenging wrecks for them….
  • 0

#48 AussiePilot

AussiePilot
  • Posts: 211

Posted 27 June 2012 - 03:18

Hey Flashy, my subtitles are working via complexe trigger now I've done the 1.026 game update. Weird aye.
  • 0

#49 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 27 June 2012 - 05:58

I have a copy of Terence Finnegan's 'Shooting the Front' which is something of a reference work on Entente aerial photography in the Great War.

p120 has a Table of Information for taking aerial photographs reproduced from the Gorrell Report. The altitudes used are between 1000m and 6000m. The time between exposures differs depending on lens, altitude and shutter speed. With a standard lens at 1000m the time between exposures is given as 9"-6" depending on shutter speed. At 6000m the time between exposures is 56"-44". With a larger lens the times are 6"-5" and 32"-27" respectively. With the very largest lens it is not used for altitudes below 1600m and at 6000m it is 14.5"-12.5" between exposures. So… only 1s between exposures is probably unrealistic?

Another issue that was brought up was the magazine, this varied with the camera, from as few as 12 plates to as many as 36, with the late war De Ram camera having 50. Different aeroplanes carried different cameras at different stages of the war. For example an RE8 in 1917 probably carried a semiautomatic LB type camera with an 18 plate magazine, and the LB could be used with interchangeable lenses with focal lengths from 4in to 20in. It was operated by the pilot: 'The 'LB' type changed plates and shutter setting in a single operation by the action of an air screw in the slip stream or by hand.'

Obviously I can go into more detail, unfortunately the reference is only about the Entente side, and only mentions the Germans in passing- they had the best cameras and the RFC were always scavenging wrecks for them….

Good stuff!

So what should we use as initial / simplified values?

5s per photo and max of 20 plates?

It's incredible how they were able to make millions of photographs with these specs!
  • 0

#50 AnKor85

AnKor85
  • Posts: 1002

Posted 27 June 2012 - 06:53

Waxworks, thanks! This is very interesting info.

Vander,
I can set plane-specific limits - like mentioned 18 frames for RE8 and more for later recons, but if we don't have historical numbers we can just settle with 20 for every plane.
I can even make altitude-dependent time between exposures, but I'm not sure if it is really needed for gameplay purposes.
This is just a balance between history accuracy and gameplay. 5 seconds delay seems small from history point of view, but may be OK for gameplay - 5 frames x 5 seconds + some delay for player to click ~ 30 seconds, and at 120km/h the plane will travel 1 km in this time. Is it far or not?
Though maybe the best way is to make first simplified version as you suggest and the see where to go next.

Right now I can't tell when the button will be ready for testing - I'm trying to balance my free time between different activities (including map editor) and days have only 24 hours in them. But I'll try not to delay it for too long, because this is actually the simplest of all things I'm busy with.

Hey Flashy, my subtitles are working via complexe trigger now I've done the 1.026 game update. Weird aye.
Maybe they have fixed/improved something? At least release notes mention that simple gauges bug is already fixed. Earlier than expected but I haven't checked it yet.
  • 0

#51 Flashy

Flashy
  • Posts: 1078
  • LocationSouth Africa

Posted 27 June 2012 - 07:31

Hey Flashy, my subtitles are working via complexe trigger now I've done the 1.026 game update. Weird aye.

Indeed! I also dont know what I did differently to make it work, but maybe something was quietly fixed in 1.025 already because I noticed this was working before 1.026. Or maybe we were just being stupid and doing something wrong ;)
  • 0

Just because I can give multiple orgasms to the furniture just by sitting on it, doesn't mean that I'm not sick of this damn war: the blood, the noise, the endless poetry...


#52 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 27 June 2012 - 07:38

Maybe you just hadn't turned on "subtitles" in the difficulty settings? It happens! :)
  • 0

#53 Flashy

Flashy
  • Posts: 1078
  • LocationSouth Africa

Posted 27 June 2012 - 09:06

Lol, yeah I had checked that, but thanks anyway Vander :P
  • 0

Just because I can give multiple orgasms to the furniture just by sitting on it, doesn't mean that I'm not sick of this damn war: the blood, the noise, the endless poetry...


#54 Waxworks

Waxworks
  • Posts: 630

Posted 27 June 2012 - 18:41

Even 5s seems on the low side, lower than any of the times presented even at the very lowest altitude. Were it possible, as a simplistic version I'd have a 30s interval for the RFC and Americans, 20s for the French and 10s for the Germans, assumed to be using the best lenses. Other than Zeiss only Parra-Mantois of France could make high-quality lenses from heavy crown barium glass. British optical glass manufacturing was almost non-existent. Lenses were donated but they were almost always too short. The British salvaged lenses from the Germans. The French began to share lenses in mid-1917, though they were reluctant and often failed to deliver any. The Americans were even worse off. If there has to be just one value how about 20s?

The exposure intervals were calculated so that they gave 50% overlap. I'm not sure how they would apply to single target objectives like stations or aerodromes where you might want more overlap, but then the vast majority of reconnaissances were done over the lines or slightly beyond, in order to assist the artillery. The Western Front was only very crudely mapped in 1914, when the Entente relied on Napoleonic maps- by late 1917 aerial reconnaissance had advanced sufficiently that artillery could fire from the maps that had been made (the preregistration technique). Photographing the defenses was an objective in itself, whether there was anything there or not. It was much rarer for Entente areoplanes to be assigned deeper reconnaissances. Of course this was based on doctrine rather than effectiveness, and it was to catch the Entente out somewhat in 1918 when the rear area signs of an offensive were repeatedly ignored, although the Entente generals were perhaps not wrong to assume that the German offensives had to be in decisive sectors or they would fail.
  • 0

#55 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 27 June 2012 - 18:56

I'm fine with 20 seconds. But how will we simulate the task of making photographs? You have to repeatedly fly over the same target, because you can only make 1 photo per run? I'm not sure if we can simulate mozaic photographing realistically.
Maybe we could show the icon for the player the moment it spawns and the player has to decide themselves when to make the photo? And only when he lands do we reveal if the photos are okay? :)
  • 0

#56 Waxworks

Waxworks
  • Posts: 630

Posted 27 June 2012 - 19:38

Can you just sequentially activate objects then delete them along the 'track', a single MG for instance?

From what I understand a photo machine would fly a single prearranged track from start to finish, you wouldn't fly over a target twice. I can simulate this using a 'track' of complex triggers, but I am not fond of using the number of triggers required. Having a single MG per track active at any one time and ending with them all deleted seems an improvement in terms of resources, as well as having the proper camera functionality.
  • 0

#57 AnKor85

AnKor85
  • Posts: 1002

Posted 27 June 2012 - 20:47

Waxworks, if you will define the values I can make country/plane specific settings for delays and viable altitudes. Lots of options are possible, not a problem to code them, but it maybe difficult to explain everything to players.

As for simulating mosaic photographing - I like the idea. I've also thought about showing the camera icon constantly, but it seems too cruel to let player take photos at any moment and then tell him that he just wasted half an hour flying over a wrong area.

Defining a 'track' instead of a single area is possible without triggers or too many markers. I can program the camera to calculate a straight line between two markers - and this line will define the track. Or tree markers to define a triangle, etc - just like influence area. Also the camera may remember what places were photographed during current sortie to force players take different pictures along the track. I won't say that it is easy to make, but possible.

If it works then we can use marker objects to define relatively large targets (just need a way to show these areas on minimap) and then tell players: "Fly above one of these areas and take as many different pictures as you can". Instead of simply counting the pictures taken the camera will be "smarter" and will calculate relative area that was covered. Perhaps it should also show percentage while player still in the air - something like a text below the icon: "NN% covered". And finally the "success" event in mission logic is triggered only when player returned and coverage is larger than some value.

With this approach we can get rid of some artifical limits:
For example - enforced delay between exposures is no longer needed as it is in the player's interest not to take pictures too fast or the coverage will overlap too much.
Also, flying higher should naturally cover larger area in one shot and the limit here is camera optics instead of some arbitrary numbers.

Heh… my imagination seems to work in the evening. If only it was as easy to implement as to imagine :)
What do you think?

And one more word about defining the areas. I don't want to increase overhead by using a lot of markers… There are other approaches, but every one has different drawbacks. Maybe if we get it working at least with maker objects - devs will agree to extend the SDK to allow using influence areas or other objects directly.
  • 0

#58 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 27 June 2012 - 21:05

Waxworks, if you will define the values I can make country/plane specific settings for delays and viable altitudes. Lots of options are possible, not a problem to code them, but it maybe difficult to explain everything to players.

As for simulating mosaic photographing - I like the idea. I've also thought about showing the camera icon constantly, but it seems too cruel to let player take photos at any moment and then tell him that he just wasted half an hour flying over a wrong area.

Defining a 'track' instead of a single area is possible without triggers or too many markers. I can program the camera to calculate a straight line between two markers - and this line will define the track. Or tree markers to define a triangle, etc - just like influence area. Also the camera may remember what places were photographed during current sortie to force players take different pictures along the track. I won't say that it is easy to make, but possible.

If it works then we can use marker objects to define relatively large targets (just need a way to show these areas on minimap) and then tell players: "Fly above one of these areas and take as many different pictures as you can". Instead of simply counting the pictures taken the camera will be "smarter" and will calculate relative area that was covered. Perhaps it should also show percentage while player still in the air - something like a text below the icon: "NN% covered". And finally the "success" event in mission logic is triggered only when player returned and coverage is larger than some value.

With this approach we can get rid of some artifical limits:
For example - enforced delay between exposures is no longer needed as it is in the player's interest not to take pictures too fast or the coverage will overlap too much.
Also, flying higher should naturally cover larger area in one shot and the limit here is camera optics instead of some arbitrary numbers.

Heh… my imagination seems to work in the evening. If only it was as easy to implement as to imagine :)
What do you think?

And one more word about defining the areas. I don't want to increase overhead by using a lot of markers… There are other approaches, but every one has different drawbacks. Maybe if we get it working at least with maker objects - devs will agree to extend the SDK to allow using influence areas or other objects directly.

About Markers: Squirrel managed to "sneak in" some custom luscripts in the 1.026 release. One of them is the flag as used in CTF, but then without the 3d model. This way we can have several markers (you will see a flag icon on the map) that can change sides. I think this will be a very elegant solution, no need to use Influence Areas anymore. I'm testing this on Syndicate server tomorrow (thursday).

EDIT: actually, not sure how this helps because I don't see a different colour of the flag when I change sides…needs some more testing.
  • 0

#59 Flashy

Flashy
  • Posts: 1078
  • LocationSouth Africa

Posted 28 June 2012 - 06:24

If it works then we can use marker objects to define relatively large targets (just need a way to show these areas on minimap) and then tell players: "Fly above one of these areas and take as many different pictures as you can". Instead of simply counting the pictures taken the camera will be "smarter" and will calculate relative area that was covered. Perhaps it should also show percentage while player still in the air - something like a text below the icon: "NN% covered". And finally the "success" event in mission logic is triggered only when player returned and coverage is larger than some value.

With this approach we can get rid of some artifical limits:
For example - enforced delay between exposures is no longer needed as it is in the player's interest not to take pictures too fast or the coverage will overlap too much.
Also, flying higher should naturally cover larger area in one shot and the limit here is camera optics instead of some arbitrary numbers.

This sounds like teh best solution by far. Defining the areas on the minimap is easy with icons etc, so dont worry about that. I really like the idea of having to cover a certain % of the traget area before success is achieved, and I also really like the idea of altitude being important to get a wider area. I also think a delay of at least 10s would be much more realistic, but we will have to fix the current bug where clicking the unavailable icon triggers the event as soon as its available. Also, I still think complex triggers are the best bet for defining paths because they seem to have very little impact on mission performance. One of the missions I made had hundreds of them and I never noticed a decrease in performance from them. Also, you can keep them deactivated most of teh time and only activate them when you need them, so I dont think we need to come up with too many clever solutions for detecting the recon plane because we have a good one already..
  • 0

Just because I can give multiple orgasms to the furniture just by sitting on it, doesn't mean that I'm not sick of this damn war: the blood, the noise, the endless poetry...


#60 AnKor85

AnKor85
  • Posts: 1002

Posted 28 June 2012 - 08:28

I may have many fancy ideas in the night, but mornings make me think more clear :)
And now I agree - defining complex geometry for target ares inside the flash may be redundant when we can use complex triggers to let markers "follow" the planes, activating only those areas that have a recon above them. This may actually reduce the overhead of having multiple AI objects as markers.

Just one note: instead of simply deactivating the marker when nobody is around we will also have to change its side to neutral first - I said before deactivated objects are still listed for the flash code. I have only two params that can be reliably modified and checked while mission is running: object's side (not even the country, but just side) and whether object is damaged or not.

As for using dummy lua scripts - that may be something useful! I haven't thought about that and never dug in that direction. Will take a look if I have time.

OK. I really like what we've got so far. Still need to define exact numbers but this can be done later, with all the data Waxworks has.
I will update the specification with current ideas later today when I have time. As for programming - can't tell yet when I'll be able to implement it.
The positive side about the delay is that we may find even more good ideas :)
  • 0

#61 Waxworks

Waxworks
  • Posts: 630

Posted 28 June 2012 - 20:54

I only have data for the Entente aeroplanes though, none for the DFW?

Mozaic photography was the most common type of sortie- as I outlined earlier the concept was to map the front entirely every day, rather than to have specific photographic targets, a rarer type of sortie unless an attack was suspected or in progress.

The pilot and observer would pre-plan the track to be flown during the sortie, get approval from the photographic officer and take a lens appropriate to the altitude. The principal targets were of course the first and second trench lines, also the areas behind them up to the balloon lines. The artillery needed to know the current state of trenches they were firing on, to determine if they had been sufficiently destroyed, or were being repaired. I'm not sure that it was the practice to roam an area taking pictures, though I have read of a sortie where the observer saved the last plate and instead of taking another on the assigned track photographed a suspected German troop concentration.

I'm not sure how what is possible will differ from the ability to place a track of complex triggers, except that it will be useful to have a means of ensuring the recce is straight and level?
  • 0

#62 AnKor85

AnKor85
  • Posts: 1002

Posted 29 June 2012 - 06:35

Not a problem if you don't have German data, having only Entente is better than nothing. We can't and don't need to pursure full accuracy anyway.

Shouldn't be hard to setup triggers with markers to follow a specific track, and since camera won't count repeated images of exactly the same place players will have to follow this track. Of course it won't prevent them from taking pictures in some odd way by flying back and forth along the track or not maintaining the same altitude between exposures but it is up to them to play "historically".
Anyway mission designer will be able to decide whether recons take photos for a line of trenches or a specific target. I think complex triggers will be suitable for both.
  • 0

#63 AnKor85

AnKor85
  • Posts: 1002

Posted 02 July 2012 - 19:25

Waxworks, does your book tell anything about possible length of recon route? Or maybe what length makes sense for gameplay purposes?

I'm asking because I need to estimate how many marker objects are needed to define a single track?
It seems that due to technical limitations it may be required to briefly activate all markes along the track so GFX can load them. This should be done for each player, probably by defining a larger complex trigger that covers whole track.
  • 0

#64 Waxworks

Waxworks
  • Posts: 630

Posted 03 July 2012 - 16:54

It varies considerably. For a 1917 RE8 with an LB camera with an 18 plate magazine, each plate covered an area about 2 km long at 3000m. At 2000m each plate covered about 1.3 km. For a Breguet with a Gaumont 50cm camera with a 12 plate magazine the area covered by each plate at 3000m was 1.3km long and at 2000m it was 0.9 km. The typical overlap was 50%. The distortion on the edges of the photograph would be greater with the short focus lens used by the RE8.

The time between exposures varies with zoom, the longest time with min zoom in the first RE8 example is 28s, the shortest in the last of the Breguet examples is 9s. The time between exposures has me slightly confused as the table does not reference air speed at all, it depends on zoom and altitude. The altitudes covered by the table range from 1000m to 6000m. The full Gorrell Report is available online if clarication is required.

Some recce aircraft had lines painted on the sides of their aircraft to indicate the area covered.
  • 0

#65 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 07 July 2012 - 12:33

Just checking in to see if there is any progress?

I think using a special photo Icon, the logic of completing the photo objective is processed on the clients computer and when it's done it is transmitted to the server using the outlets of the Media MCU. This is in my opinion a very elegant solution and it would make our missions much less complex and also easier to have several two-seaters going for objectives at the same time…
  • 0

#66 AnKor85

AnKor85
  • Posts: 1002

Posted 07 July 2012 - 13:05

I agree that I want to put as much logic inside the icon as possible. I want to avoid the scary amount of triggers or target links similar to artillery spotting one :)

I was working on map editor again so not much progress here.
Good news is that I've discovered that AI POI mcu is available for flash button, I suppose they are less taxing on resources than actual objects. However they have some limitations. Instead of listing all existing AI POI the game provides information only about the nearest friendly one. This means that there is no way to know if there any additional ones. The radius is also unavailable and needs to be encoded in object's name.

Another very useful discovery is that I've found a way to get friendly airfield locations and other data without using marker objects.

Basically the only thing blocking further progress is the case of "recon along the track". I may need to either rethink required features for this kind of recon or get back to idea of using marker objects at waypoints to define lines between them.
  • 0

#67 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 07 July 2012 - 14:26

I agree that I want to put as much logic inside the icon as possible. I want to avoid the scary amount of triggers or target links similar to artillery spotting one :)

I was working on map editor again so not much progress here.
Good news is that I've discovered that AI POI mcu is available for flash button, I suppose they are less taxing on resources than actual objects. However they have some limitations. Instead of listing all existing AI POI the game provides information only about the nearest friendly one. This means that there is no way to know if there any additional ones. The radius is also unavailable and needs to be encoded in object's name.

Another very useful discovery is that I've found a way to get friendly airfield locations and other data without using marker objects.

Basically the only thing blocking further progress is the case of "recon along the track". I may need to either rethink required features for this kind of recon or get back to idea of using marker objects at waypoints to define lines between them.

Oh, I'm okay with some marker objects. Keep it simple.
  • 0

#68 AnKor85

AnKor85
  • Posts: 1002

Posted 11 July 2012 - 18:45

Please take a look on my latest spec: https://docs.google....a-dDNeMDw/edit#" onclick="window.open(this.href);return false;">https://docs.google....document/d/1JXn … eMDw/edit#

If everything seems ok I'll start implementing the new icon in next few days.
Additional data like plane specific limits may be defined later.
  • 0

#69 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 11 July 2012 - 19:27

Hi AnKor,

I have read the specs and I think they are pretty good.

My proposals:

TODO: define these numbers.

Let's take 20 as generic number of photos

TODO: define FOV for plane-specific cameras.

Guessing here, but if we stick to the 4 inch / 100 mm lens mentioned earlier so a FoV of around 30-40 degrees?

I'm also interested if this will also work in Co-op or Single player? The only diffence I can think of is that in co-op or sp you do not use airfield objects, but these might work just as well…
  • 0

#70 AnKor85

AnKor85
  • Posts: 1002

Posted 12 July 2012 - 07:13

Good point about SP and Co-op! I was so focused on dogfight that completely forgot about them.
I think airfield objects won't really work in these modes. Not a problem though, I'll just allow using marker objects as I wanted initially as well as airfields where they are available.

One question though: do we always require a landing for recon sortie? I mean, won't there be a scenario where success event should be triggered immediately after taking all photos?
Perhaps I'll be able to add such option, but I can't guarantee.

Agreed about 20 photos. As for FOV I actually have no idea how to derive it from camera spec's, so I'll start with 40 degrees as you proposing and then we'll see how it works.

Now I need to stop being lazy and recall some analytic geometry formulae. I always liked the subject but it was just too long since I needed anything like that :)
  • 0

#71 Flashy

Flashy
  • Posts: 1078
  • LocationSouth Africa

Posted 12 July 2012 - 07:15

Hi AnKor,

I have read the specs and I think they are pretty good.

My proposals:

TODO: define these numbers.

Let's take 20 as generic number of photos

TODO: define FOV for plane-specific cameras.

Guessing here, but if we stick to the 4 inch / 100 mm lens mentioned earlier so a FoV of around 30-40 degrees?

I'm also interested if this will also work in Co-op or Single player? The only diffence I can think of is that in co-op or sp you do not use airfield objects, but these might work just as well…

Agree with Vander - Lets set generic values for things like FOV and number of shots for now and get a proof of concept out. If it all works as expected we can start adding fancy stuff like different values for different planes etc, but for now we just need to see if we can actually get this to work..
  • 0

Just because I can give multiple orgasms to the furniture just by sitting on it, doesn't mean that I'm not sick of this damn war: the blood, the noise, the endless poetry...


#72 Flashy

Flashy
  • Posts: 1078
  • LocationSouth Africa

Posted 12 July 2012 - 07:18

One question though: do we always require a landing for recon sortie? I mean, won't there be a scenario where success event should be triggered immediately after taking all photos?
Perhaps I'll be able to add such option, but I can't guarantee

I cant think of any scenario in which you wouldn't have to land. There was no way that I know of to transfer the photo plates to ground crews without having to land, so I think we can safely assume here that the player ALWAYS has to land..

For Visual recon, there could be an early-war argument for not having to land, but for Photo recon its a no-brainer IMO.
  • 0

Just because I can give multiple orgasms to the furniture just by sitting on it, doesn't mean that I'm not sick of this damn war: the blood, the noise, the endless poetry...


#73 AnKor85

AnKor85
  • Posts: 1002

Posted 12 July 2012 - 07:31

Flashy, sure I understand that historically a landing is a must :)

I'm thinking about gameplay scenarios. Basically I want to let mission author choose: either rely on button's internal logic that requires a landing or check success conditions manually after receiving an event that all photos are taken.

I was also going to make landing a requirment until Vander mentioned Co-op mode. I haven't played it really, but know he runs a server with "Instant action 15-min Co-ops". Now, to fit into 15 minutes and focus on the action we may ignore take-off and landings parts by having an air start and "air finish", like a trigger defining a "safe area" where recon should return after taking a photos.

Actually now when I think about it - it seems easy to implement. So I'll do it anyway. And then everybody will be free to ignore this feature :)
  • 0

#74 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 12 July 2012 - 09:59

Flashy, sure I understand that historically a landing is a must :)

I'm thinking about gameplay scenarios. Basically I want to let mission author choose: either rely on button's internal logic that requires a landing or check success conditions manually after receiving an event that all photos are taken.

I was also going to make landing a requirment until Vander mentioned Co-op mode. I haven't played it really, but know he runs a server with "Instant action 15-min Co-ops". Now, to fit into 15 minutes and focus on the action we may ignore take-off and landings parts by having an air start and "air finish", like a trigger defining a "safe area" where recon should return after taking a photos.

Actually now when I think about it - it seems easy to implement. So I'll do it anyway. And then everybody will be free to ignore this feature :)

About Co-op: I'm asking because we run a coop event now and then with other squads. These last long enough for realistic photo recon scenarios. For the 15 min quick action stuff the current logic works well enough….
  • 0

#75 AnKor85

AnKor85
  • Posts: 1002

Posted 17 July 2012 - 08:51

Small update.
I already started coding for the new button and made some progress over weekend. First step was to implemented both modes for detecting target area - via separate circles and via lines between markers. It works already.
Next step will be actual photographing and coverage calculation. As it appeared the calculation of overlapping area of multiple circles worths a scientific article. But with some simplifications which won't be really noticeable it can be made easier. So so far everything seems good.

However, I'm far from my main PC for a couple of weeks so don't expect any news soon. Afterwards I really hope to finish this button pretty quick.

PS: I think I've already said it, but programming in flash is huge PITA! Especially since I have to restart ROF to test each small change, I was spending more time looking at its startup screen than doing actual testing.
  • 0

#76 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 01 August 2012 - 15:26

Bump so we won't forget :)
  • 0

#77 AnKor85

AnKor85
  • Posts: 1002

Posted 01 August 2012 - 15:49

Sure, sure :)
I hope to get back to this task tomorrow. Was busy for a few recent days with yet another ROF-related project ;)

Coverage calculations are almost done. I've figured out a relatively simple way to get a suitable approximation of overlapping area for multiple circles.
Won't bother anybody with details, but just for "nerdy fun" sake – a circle divided into 100 equal area parts:
Attached File  circle100.png   9.62KB   272 downloads
Beautiful, isn't it? :ugeek: :lol:
  • 0

#78 AnKor85

AnKor85
  • Posts: 1002

Posted 03 August 2012 - 18:53

One more picture, you may also consider it meaningless, but actually it shows really good progress:
Attached File  photo-coverage-debug.png   119.93KB   255 downloads
Two recon areas are defined. Not obvious from this pic, but one is a simple circle and one is a "path" with 3 waypoints. Now I'm flying around the first are and taking pictures (I disabled altitude check to avoid long climbs) and the system calculates how much of an area was covered.
  • 0

#79 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 03 August 2012 - 19:23

Looking good! Am I correct in assuming that the execution of the logic is done on the client PC?
  • 0

#80 AnKor85

AnKor85
  • Posts: 1002

Posted 03 August 2012 - 19:36

Yes, all logic is client-side, so no effect on the server. I also spending time to make sure it won't slow down player's PC.
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users