Jump to content


Photo
- - - - -

Camera icon in dogfight missions?


  • Please log in to reply
193 replies to this topic

#81 AnKor85

AnKor85
  • Posts: 1002

Posted 08 August 2012 - 04:49

So far everything works perfectly. I have yet to tet its behavior in Multiplayer with activating/deactivating of target areas, but I believe it should work already.

A few questions.

1. Should the icon be visible only when player is above target area?

I personally think "yes", because it will help to avoid taking useless pictures and won't aestetically annoy players wanting a clear view during the flight :)
Right now I made the icon show when player is close enough that a photo will cover at least a small part of an area. So when approaching at high altitude the icon will be seen earlier because or larger coverage.

2. Should the icon show current progress or any other info?

This is where I'm hesitant.
I think the icon should at least show the number of plates remaining, but what else?
Should it inform that the altitude is too low/high?
Should it shown the progress, i.e. "23% covered of 70% required". If progress is not shown then a player will only know if he succedeed after the landing. This is historically correct, but may be too harsh for players to spend 30 minutes flying only to fail the mission.
What do you think?

3. What is considered a successful landing?

Right now I detect a landing as being "not in air" in a radius of 1 km around a home marker or an airfield (for dogfight mode). Also player should not be "dead" or "jailed", but crash landings are acceptable.
Is this correct?
  • 0

#82 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 08 August 2012 - 09:57

So far everything works perfectly. I have yet to tet its behavior in Multiplayer with activating/deactivating of target areas, but I believe it should work already.

A few questions.

1. Should the icon be visible only when player is above target area?

I personally think "yes", because it will help to avoid taking useless pictures and won't aestetically annoy players wanting a clear view during the flight :)
Right now I made the icon show when player is close enough that a photo will cover at least a small part of an area. So when approaching at high altitude the icon will be seen earlier because or larger coverage.

2. Should the icon show current progress or any other info?

This is where I'm hesitant.
I think the icon should at least show the number of plates remaining, but what else?
Should it inform that the altitude is too low/high?
Should it shown the progress, i.e. "23% covered of 70% required". If progress is not shown then a player will only know if he succedeed after the landing. This is historically correct, but may be too harsh for players to spend 30 minutes flying only to fail the mission.
What do you think?

3. What is considered a successful landing?

Right now I detect a landing as being "not in air" in a radius of 1 km around a home marker or an airfield (for dogfight mode). Also player should not be "dead" or "jailed", but crash landings are acceptable.
Is this correct?

1. Yes I think so. No need to show the icon all the time. Will the icon be visible by other players? I guess so, but that isn't a problem as they don't know where the recon is; in fact there might be two active at the same time?

2. I think showing progress is ok. IRL, the pilot/observer would also know when they were ready. The difference is that in this case the photos will always be perfect, but that's not a problem. Compare it with the aircraft engines in RoF that always work while in real life there were a lot of failures….

3. That's perfect IMHO.
  • 0

#83 AnKor85

AnKor85
  • Posts: 1002

Posted 08 August 2012 - 10:56

1. Yes I think so. No need to show the icon all the time. Will the icon be visible by other players? I guess so, but that isn't a problem as they don't know where the recon is; in fact there might be two active at the same time?
OK.
The icon won't be visible by other players and there can be any number of them photographing at the same time. This was one of my main goals for this task.
Unlike current icons Media MCU for this new photo recon should be triggered every time a player's plane spawns. Then it just runs on each client PC independently and the logic for showing, hiding and clicking the icon is not controlled by the server anymore. The icon doesn't even "know" that there are other players around.

2. I think showing progress is ok. IRL, the pilot/observer would also know when they were ready. The difference is that in this case the photos will always be perfect, but that's not a problem. Compare it with the aircraft engines in RoF that always work while in real life there were a lot of failures….
OK. I agree.
One more point about showing the progress (i.e. an immediate feedback) is to allow any new player to quickly know whether he is doing something right or wrong.
I've asked just in case anyone is too hardcore to use any helpers in flight :)

3. That's perfect IMHO.
OK.
  • 0

#84 AnKor85

AnKor85
  • Posts: 1002

Posted 12 August 2012 - 10:38

So, the button is ready, or at least ready for testing. Delay between taking pictures is not implemented yet (I thought it will work out of the box but something went wrong). I will add it later, but it's actually needed only for "number of photos" mode, while in "coverage" mode it is in the player's own interest not to take photos too fast.
Plane-specific camera settings can also be defined (but I have to recompile the code for any change). For testing purposes I'm using generic ones:
Number of Frames - 20
Min Altitude - 500m
Max Altitude - 4000m
Max Pitch/Bank Angle - 10 degrees
FOV = 40 degrees, this results in R = SIN(FOV/2)*ALT => 342m radius per 1000m altitude.

I will write detailed description and specifications later.
For now, I just added a simple dogfight mission that shows what can be made with this new button. Start a server, run "Photo Recon Test" and see what happens.

Maybe we can test it together to see how it works for multiple players.

Attached Files


  • 0

#85 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 12 August 2012 - 10:58

Fantastic! Really busy atm, but will test this as soon as possible!
  • 0

#86 SYN_Haashashin

SYN_Haashashin
  • Posts: 384

Posted 12 August 2012 - 11:04

I will test it right now, taking a break from ME.

Quick Test:

1º- Taking the pics not leveled, turning and not waiting in between pics resulted in the use of all frames and only got 19% completed. (800m)
2º- Taking the pics leveled and following the road, taking couple of seconds between pics resulted in a completed recon after landing with 9 frames left. (800m)

Changed the airstar alt in ME, to test the top alt, to 4200m:

Icon show up way earlier than before. At 4200 the icon do not let you take the pic. Descended to 3500m and just needed 2 frames to get 100%.

As for I can see its works just nice. How many of this planes can we have in the air at the same time???
  • 0

#87 AnKor85

AnKor85
  • Posts: 1002

Posted 12 August 2012 - 11:59

It should work for any number of planes at the same time, though I haven't tested it.
The icon's logic is client side and is independent for every player. The button is shown/hidden independently too, so other players won't see it when you are taking pictures.

The only limit is 16 different recon areas in a mission because Media translator has only 16 different events, but I believe it is more than enough.
  • 0

#88 SYN_Haashashin

SYN_Haashashin
  • Posts: 384

Posted 12 August 2012 - 12:40

Yeah It should be more than enough, never seen 16 recon planes at the same time in MP ;).

Fantastic work!!
  • 0

#89 AnKor85

AnKor85
  • Posts: 1002

Posted 12 August 2012 - 14:07

Thanks!
This was an interesting but really tiresome task. I'm glad that it is finally nearing the finish and hope the result will be useful. I know there is an arty spotting icon that is also demanded for MP, but to be honest I want to finish this photo recon and never get back to flash programming again.

So, next step for me is to write a manual on how to use this new icon from mission designer's and player's perspective.
Of course, any ideas about tweaking numbers or small feature changes are welcome. I can also add translations into different languages for messages like "Too Low!", "X% of Y%" etc, but I need someone to translate them.

What I still don't like is the need to use marker objects. If only devs could provide a simple dummy object that isn't visible in game but works for flash button…
  • 0

#90 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 17 August 2012 - 19:35

Hi AnKor, I did some tests and all seems to work as promised. Very good!

Some questions:

-If player A takes off and starts the Media MCU, finishes only half of the line patrol, then player B takes off and photographs the other half I guess it won't work? Because logic is on client side and the Media MCU of Player A can't know about the MEdia MCU of player B? So if a plane starts one patrol he has to finish it himself?

-When a recon has been completed, can it be started over again or is it deactivated automatically?

-Please explain in short what these coded names mean, so we have some examples:

!PR E00-A r8 30% (first of three markers)

!PR E01 r2

!PR E01 r2 80%

!PR E02 r2 x5

I'm thinking of creating a mission where each side has say 8 two-seaters (with different names) and they are all assigned different recon objectives. This, so that we don't have three crews flying over the same sector. The 8 different recon objectives can all be active at the same time, right?

Last question:

-For server performance reasons it is okay to destroy (some of) the markers at the start of the mission? They will still work yes?
  • 0

#91 AnKor85

AnKor85
  • Posts: 1002

Posted 17 August 2012 - 20:44

I'll answer other questions tomorrow, but the last one is the most interesting ;)

I haven't fully understood how inactive objects behave for a flash dialog. So far I assume that media mcu gets a list of active objects when it starts and then new objects are added as they appear. Deactivated objects are not removed from the list (at least not instantly), but their properties are no longer updated.
My button looks for new marker objects every 10 seconds, and once an object is found it is remembered and no longer needed. However you can't just deactivate markers after the start of the mission: new players will join (or old ones respawn) - and their copy of the button will need active markers again.
In other words - all markers for an area have to be active at least once after recon plane spawns and before it reaches the area, otherwise the button won't know about the target.
Now it seems like a challenge to follow this rule if you want to save resources.

I have asked Viks about adding a new kind of mission objects serving as helpers for flash dialogs - invisible in game and not eating CPU but providing a set of properties. He asked to show that there's an use for them first. Do you think this button worth it?
  • 0

#92 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 17 August 2012 - 22:10

I'll answer other questions tomorrow, but the last one is the most interesting ;)

I haven't fully understood how inactive objects behave for a flash dialog. So far I assume that media mcu gets a list of active objects when it starts and then new objects are added as they appear. Deactivated objects are not removed from the list (at least not instantly), but their properties are no longer updated.
My button looks for new marker objects every 10 seconds, and once an object is found it is remembered and no longer needed. However you can't just deactivate markers after the start of the mission: new players will join (or old ones respawn) - and their copy of the button will need active markers again.
In other words - all markers for an area have to be active at least once after recon plane spawns and before it reaches the area, otherwise the button won't know about the target.
Now it seems like a challenge to follow this rule if you want to save resources.

I have asked Viks about adding a new kind of mission objects serving as helpers for flash dialogs - invisible in game and not eating CPU but providing a set of properties. He asked to show that there's an use for them first. Do you think this button worth it?

Well I'm not sure if resources will be a real problem, I was just wondering. I will at least make sure the marker objects get repaired quickly if they get accidently destroyed.
  • 0

#93 AnKor85

AnKor85
  • Posts: 1002

Posted 18 August 2012 - 10:45

I see, yes if an object is destroyed just repair it after some time, several minutes will be ok - or even more depending on how long it takes for a recon to reach its target.

Now other questions.

If player A takes off and starts the Media MCU, finishes only half of the line patrol, then player B takes off and photographs the other half I guess it won't work? Because logic is on client side and the Media MCU of Player A can't know about the MEdia MCU of player B? So if a plane starts one patrol he has to finish it himself?
You are right. One player can't help another one to finish the recon task.
This also means that two players can complete the same recon objective at the same time and it will result in two "success" events (of course if the target is not deactivated after the first one).

When a recon has been completed, can it be started over again or is it deactivated automatically?
It stays active, you have to deactivate it manually. My example shows how to deactivate an area (for factory/plant) by changing marker's side to neutral (or friendly) and then (optionally) using Deactivate MCU to remove the object from the mission so it won't mess around.
One exception is that one player can't repeat the same objective during a sortie even after landing.

Please explain in short what these coded names mean, so we have some examples:
The structure of object name is
!PR - PR stands for Photo Recon, this is just to make sure that this is a marker object.
E00 - target number from 00 to 15. Corresponds to event number triggered by Media MCU upon successful sortie. There can be more than one marker for the same area.
Now, there is two options:
-A immediately after the number means that this is a waypoint for line patrol. Letters 'A', 'B', 'C', and so on define the order of waypoints. The order doesn't mean that player has to follow it, it just defines how an imaginary line between waypoints is drawn.
Otherwise, if there's no suffix after the number, the marker is considered to be a standalone circular area.
In my example I created a line patrol with 3 waypoints: E00-A, E00-B, E00-C.
And a circular area around factory as "E01"

r8 defines a radius of the recon circle (or half-width for recon line if there are waypoints). The number is hundreds of meters, i.e. 8 means 800m radius.

Then there are two mutually exculsive modes:

80% - coverage requirement for successful sortie. Once 80% of the area is photographed the counter will show "Completed!" and player can land.

x5 - requirement for number of photos. This is simpler mode when no coverage is calculated and even completely overlapping or barely covering the target photos are counted. In my example I used it for factory target where player has to make 5 photos of the factory.

Finally, a radius and a requirement only have to be specified in one marker for an area.
For example, full names for a line recon markers triggering event #00 with 3 waypoints, width of 1000m (i.e half-width=500m), and requiring to cover 75% of its area will be:
!PR E00-A r5 75%
!PR E00-B
!PR E00-C


I'm thinking of creating a mission where each side has say 8 two-seaters (with different names) and they are all assigned different recon objectives. This, so that we don't have three crews flying over the same sector. The 8 different recon objectives can all be active at the same time, right?
Yes, multiple recon objectives active at the same time will work. My example has 4 of them (two per side).
Though my button doesn't support assigning objectives to specific planes. Any one will be able to photograph any area. Unfortunately ROF truncates object names visible to Media MCU to 19 symbols and I can't make marker names longer, otherwise I could have added an option to restrict areas to planes with specific names.

Hope my answers help.
  • 0

#94 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 18 August 2012 - 13:06

All clear. Thanks very much!
  • 0

#95 Waxworks

Waxworks
  • Posts: 630

Posted 19 August 2012 - 17:07

Many thanks for this, it seems to be very successful and a great advance over previous recce logic.
  • 0

#96 AnKor85

AnKor85
  • Posts: 1002

Posted 19 August 2012 - 18:03

Heh… So it was too soon to celebrate. Game started crashing for a lot of people :xx:
Will have to investigate.
  • 0

#97 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 19 August 2012 - 18:07

Heh… So it was too soon to celebrate. Game started crashing for a lot of people :xx:
Will have to investigate.

Feedback:

We tested with 3 ppl…no problems (except the gunner issue).
Later on main server with over (5-10?) people there were rof.exe errors (without error message) when finishing flight, spawning or shortly after take-off….
  • 0

#98 WW1EAF_Paf

WW1EAF_Paf
  • Tester
  • Posts: 1458

Posted 20 August 2012 - 16:49

Great work here!
Just found this map showing the result of photographic missions for "Battle of Amiens"
Image
  • 0

#99 AnKor85

AnKor85
  • Posts: 1002

Posted 21 August 2012 - 13:50

WW1EAF_Paf,
for simplicity I've made an assumption that all photos are circular. This is of course unrealistic, but much easier for calculations. After all nobody is going to see them ;)
Also, historically photos had to overlap a bit, but I don't require it to avoid confusion for players. Although I believe that in some cases due to circular shape of photos the coverage may actually be reached faster (in terms of flying distance, not the amount of photos) if they overlap just a bit - and thus have smaller gaps between them, but most likely the effect is negligible anyway.

As for ROF.exe error I think I managed to reproduce it in my test mission, but I'm not sure yet about the cause. I just hope that crashes are caused by my code doing something wrong and not by one of ROF limitations which cannot be worked around.
  • 0

#100 WW1EAF_Paf

WW1EAF_Paf
  • Tester
  • Posts: 1458

Posted 21 August 2012 - 14:13

Hi AnKor,
I did not want to critic your approach. Its amazing!
I posted this photo in encouragement for the great job you are doing :)
  • 0

#101 AnKor85

AnKor85
  • Posts: 1002

Posted 02 September 2012 - 11:22

Looks like I've got a solution - just needed to remove two lines of code from SDK sources :)
Big thanks to Vitaliy from ROF team for his help!
However, since ROF is constantly evolving a future game update may make the modified icon incompatible again. We'll see.

Now I want to add a couple of fixes and features before releasing the updated version. Shouldn't take long.
  • 0

#102 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 02 September 2012 - 12:02

Looking forward to the new version!
  • 0

#103 AnKor85

AnKor85
  • Posts: 1002

Posted 04 September 2012 - 07:22

And here it is! :)

What was changed:
- Fixed (I think so) frequent crashes when many players are on the server.
- Observer/gunner bug is fixed… rather radically: camera icon doesn't show up for observer at all. Actually this is the best I can do. And I think it is historically correct as from what I know it was the pilot who operated the camera.
- Added 10 seconds delay between taking pictures.
- Changed operation altitudes: was 500-4000m, now 1000-4500m.
- Changed distance check for "take a given number of photos" mode. The camera will become available only when player's plane is inside the area regardless of the altitude. Otherwise on high altitudes it was just too easy to take N pictures flying quite far from the target. Note that "coverage" mode still allows to use the camera earlier as you go higher.
- When plane is on the ground the camera icon will appear telling the number of frames remaining. This is useful when you have landed to refill the magazine or just spawned and want to make sure that you haven't forgot the camera. Note that it shows "On the ground." before takeoff or when you landed in arbitrary place and "Landed!" when you actually landed on the home base (only the latter one will trigger success event or refill the magazine).

Nothing is changed in the usage or file names from previous version, thus existing missions are fully compatible.
It should work in Cooperative mode too, but I haven't checked it.
However it is not suitable for singleplayer because launching Media MCU prevents the use of time compression and pause.

Attached Files


  • 0

#104 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 04 September 2012 - 07:40

And here it is! :)

What was changed:
- Fixed (I think so) frequent crashes when many players are on the server.
- Observer/gunner bug is fixed… rather radically: camera icon doesn't show up for observer at all. Actually this is the best I can do. And I think it is historically correct as from what I know it was the pilot who operated the camera.
- Added 10 seconds delay between taking pictures.
- Changed operation altitudes: was 500-4000m, now 1000-4500m.
- Changed distance check for "take a given number of photos" mode. The camera will become available only when player's plane is inside the area regardless of the altitude. Otherwise on high altitudes it was just too easy to take N pictures flying quite far from the target. Note that "coverage" mode still allows to use the camera earlier as you go higher.
- When plane is on the ground the camera icon will appear telling the number of frames remaining. This is useful when you have landed to refill the magazine or just spawned and want to make sure that you haven't forgot the camera. Note that it shows "On the ground." before takeoff or when you landed in arbitrary place and "Landed!" when you actually landed on the home base (only the latter one will trigger success event or refill the magazine).

Nothing is changed in the usage or file names from previous version, thus existing missions are fully compatible.
It should work in Cooperative mode too, but I haven't checked it.
However it is not suitable for singleplayer because launching Media MCU prevents the use of time compression and pause.

Great!

Question: Did you rename the files? Otherwise I think players will get a download error when they join the server if they have already played the VM mission of two weeks ago….
  • 0

#105 AnKor85

AnKor85
  • Posts: 1002

Posted 04 September 2012 - 07:49

Question: Did you rename the files? Otherwise I think players will get a download error when they join the server if they have already played the VM mission of two weeks ago….
Ouch… And I was actually concerned about ensuring that filenames are unchanged.
I think only GFX one was changed, and DDS files should be the same. So perhaps you can just rename it to photoreconex2.gfx and change the reference in its Media MCU…
Crap. I'll have to check, but it will be later today.

[rant]And why this bug isn't fixed in ROF when it exists for so long?![/rant]
  • 0

#106 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 04 September 2012 - 07:53

[rant]And why this bug isn't fixed in ROF when it exists for so long?![/rant]

LOL, I'm not even sure it's on their list!
  • 0

#107 AnKor85

AnKor85
  • Posts: 1002

Posted 04 September 2012 - 09:15

Tried a couple of things.

I was right: dds are unchanged and you can rename GFX and it will still work correctly (you must also update file name in the Media MCU of course).

Tried putting older version of GFX on the client PC and newer one on the server and didn't get any errors. Though you should resave the mission so .list will get correct checksum for updated GFX so it won't be downloaded each time. But even with the wrong checksum it didn't produce any errors.

However I got one file download error yesterday while testing. Unfortunately I haven't thought about it back then and just deleted both mission and swf.

So… I'm keeping the above archive as is. If you are going to rename the GFX - go for it.

I'll do more testing about file transfer errors later. Anyway I suppose you are going to put it on Sunday's mission so there's still some time to test before :)
Of course it will be good if you test it on your side somehow too.
  • 0

#108 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 04 September 2012 - 13:44

Tried a couple of things.

I was right: dds are unchanged and you can rename GFX and it will still work correctly (you must also update file name in the Media MCU of course).

Tried putting older version of GFX on the client PC and newer one on the server and didn't get any errors. Though you should resave the mission so .list will get correct checksum for updated GFX so it won't be downloaded each time. But even with the wrong checksum it didn't produce any errors.

However I got one file download error yesterday while testing. Unfortunately I haven't thought about it back then and just deleted both mission and swf.

So… I'm keeping the above archive as is. If you are going to rename the GFX - go for it.

I'll do more testing about file transfer errors later. Anyway I suppose you are going to put it on Sunday's mission so there's still some time to test before :)
Of course it will be good if you test it on your side somehow too.

Yeah, I will test allright!
  • 0

#109 Waxworks

Waxworks
  • Posts: 630

Posted 05 September 2012 - 21:05

The multiplayer artillery correction seems to have a global MEDIA_STOP instruction when the spotter is out of the zone. This might interfere with any recce camera operations? Is there any workaround?
  • 0

#110 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 05 September 2012 - 21:27

I have adapted one of our " from dawn to dusk" missions so that it uses the new GFX. It's the Late 1918 mission and it should be starting from 8 or 9 pm CET tomorrow. Let's test!

@ waxworks: which MP artillery spotting script are you referring to ?
  • 0

#111 Waxworks

Waxworks
  • Posts: 630

Posted 05 September 2012 - 21:41

Flashy's MP artillery spotting logic from a few threads down. I couldn't set up a 15x15 grid as I suggested later, it seemed to use far too many resources, instead I compromised by using 3 superimposed grids and selecting one at random every time a battery is ready to fire. That seems to fix the random spawn element I had problems with, and also prevents players simply knowing which squares the targets are in. I've already destroyed some stuff, so I've sent you a first mission.
  • 0

#112 AnKor85

AnKor85
  • Posts: 1002

Posted 06 September 2012 - 07:03

The multiplayer artillery correction seems to have a global MEDIA_STOP instruction when the spotter is out of the zone. This might interfere with any recce camera operations? Is there any workaround?
You are right, stopping the media works globally and will break the photorecon script.
Well… Let's strike while the iron is hot.
With my new knowledge of Flash I can modify the artillery spotting icon even without having its source codes. Nothing fancy of course, but at least I can make it side-specific so the enemy won't see the icon. Also I believe I can make a special script that stops any media by ID instead of all of them at once.

I have adapted one of our " from dawn to dusk" missions so that it uses the new GFX. It's the Late 1918 mission and it should be starting from 8 or 9 pm CET tomorrow. Let's test!
I'll try to be there. :S!:
  • 0

#113 Waxworks

Waxworks
  • Posts: 630

Posted 13 September 2012 - 15:52

Have you made any progress with the global Media_Stop?

There is another possible approach to the artillery shoot. The flash dialogue only seems to last about 20 mins unless reactivated by script. If it is to be reactivated by a loop anyway, it could be up all the time that the spotter is spawned, so that messages could be sent and just the firing would not occur unless batteries had been activated and the spotter was in the firing zone.

This might avoid the need for a media_stop at all. Would there be a frame rate consequence? Of course a specific media_stop would still seem the better approach.
  • 0

#114 AnKor85

AnKor85
  • Posts: 1002

Posted 14 September 2012 - 08:41

Have you made any progress with the global Media_Stop?
Not yet. I've tried a few things, but results were… weird. It should work in theory, but in practice all that media stuff is unpredictable.
The same goes for side-specific arty spotting - while it seem to work as I wanted I still can't understand some strange effects and thus don't want to release it.

There is another possible approach to the artillery shoot. The flash dialogue only seems to last about 20 mins unless reactivated by script. If it is to be reactivated by a loop anyway, it could be up all the time that the spotter is spawned, so that messages could be sent and just the firing would not occur unless batteries had been activated and the spotter was in the firing zone.

This might avoid the need for a media_stop at all. Would there be a frame rate consequence? Of course a specific media_stop would still seem the better approach.
That's an interesting idea.
Media translator has "Base Time" parameter which defines a number of seconds for which the media is active once started. When the time is out the button is hidden. It can be up to 10,000 seconds (which is more that 2.5 hours) but you can also make it relatively short and really avoid the need to stop the media.

As for frame rate - I don't see anything to worry about. AFAIK arty spotting dialog doesn't do anything at all while it is idle, it only "works" when player selects a cell in the grid.
I personally would imagine the use like that:
- Player enters the area -> dialog is started for let's say 5 minutes, additionally a 5 minute timer is started which restarts the dialog.
- When player leaves the area - the timer is stopped and dialog will timeout on its own.
The only problem is that if the player stays in the area the dialog will reset for him every 5 minutes - this means that "X" marks on previously fired cells will be reset too.

I will try to find some time to do more experiments later, but all this flash programming and especially testing is really tedious.
  • 0

#115 Gadfly21

Gadfly21
  • Posts: 1081

Posted 18 September 2012 - 19:23

You guys are doing a really great job getting these features to work. Hopefully, the devs at 777 can rework the code to make things easier for the mission builders :S!:

I mentioned this before, but I would really like to see the removal of an upper-bound on the ability to take pictures. Some recon planes are fast, but others can only escape pursuit by flying higher than the scouts (such as the late 1916 DFW C.V for instance, with an operation ceiling of 5000m; others could go even higher).

The photographic plate was also very large, maybe 10x12 cm, and therefore had incredible "resolution" (think of how many photographers still prefer 35mm film over CCD chips).

However, due to the nature of the "photo-mosaic" work of overlapping photos, pilots had to maintain an altitude and speed. If he descended, for instance, objects in the next shot might appear slightly bigger. He had to maintain a speed and the observer used a stopwatch to ensure the correct exposure time to optimize the overlap layout. Pitching or rolling would also be impermissible. If the observer was defending the aircraft, he wouldn't be able to perform any of his other duties. There was probably a standard operating altitude to allow photo-mosaics of the entire front to be built from all the flights that day. In this case, 4-5km altitude restriction would be OK for online missions.

Different cameras could be used, with different focal lengths. Short focal length gives a wide angle of view, and long focal lengths give a narrow angle of view (greater magnification). If focused at infinity, the image will retain sharpness at anything greater than about 30m or so. A photo pass at 1000 meters shouldn't be any more or less "blurry" than one at 6000 meters, but because of the greater distance, atmospheric distortion and "resolution" of the photographic emulsion may affect sharpness. Using a high focal length camera at 2000 meters would give unprecedented detail on a specific target, but short focal length cameras were used to make photo-maps of the entire front, twice daily, at high altitude to maximize area of coverage. The shorter focal length system in the SPAD 13 would probably be used within 200-500 meters as it would be harder to aim a narrow-field of view camera to get an accurate and detailed shot.

http://albindenis.fr...rs/page3.1.html" onclick="window.open(this.href);return false;">http://albindenis.fr...rs/page3.1.html

I personally think 15 or 20 seconds would be better for time between each shot. If I'm not mistaken, for each shot you had to insert a covered glass plate, remove the cover, make the exposure, re-insert the cover, then remove the covered glass plate, stow it safely, and then repeat. It could be especially complicated at cold temperatures with thick gloves on. The SPAD might only get one shot since there is no way to access the camera in flight.
  • 0

#116 Waxworks

Waxworks
  • Posts: 630

Posted 18 September 2012 - 22:49

The shorter loop is what I'll try, I imagine that it is acceptable to have the previously fired 'x' mark only where the battery is currently firing, rather than all the places it has fired.

The information I have is from 'Shooting the Front' which only deals with Entente reconnaissance. It includes a 'Table of Information for taking aerial photographs' which is from the Gorrell Report, which is available online. The time between exposures on the table varies widely with altitude and focal length. The lowest time is 3s, for a telescopic lens at low altitude. We could perhaps differentiate between types of camera but unless we can alter the time between exposures by altitude 10s seems a reasonable compromise, 15s might be an improvement. Some of the cameras used in 1917 and 1918- like the successful British 'L' type- were semi-automatic and could be operated by the pilot with the plates being changed automatically.

The trouble with distortion was that what was being examined was the length of shadow: p119 'Without the shadow, he could hardly tell an embankment from a trench; and he certainly couldn't hope to distinguish between a gun emplacement and a haystack, unless somebody told him that one of them was shooting.'

Assuming that the Germans were using better quality optics I wouldn't consider it unreasonable to have German coverage higher, from 1500-5000.
  • 0

#117 Gadfly21

Gadfly21
  • Posts: 1081

Posted 19 September 2012 - 00:57

It could be an exaggeration, but I've seen it mentioned that German optics allowed them to pick out boot-prints in the mud from 3000 meters. If true, 5000 meters wouldn't be too high to deliver good quality shots.

An interesting trend to look at is how Entente two-seaters are built for speed. Even the RE.8 is quick in a straight line, but it climbs very slowly. The DFW on the other hand, has a high aspect ratio, and a prop built for climbing. It's slow, but has a high service ceiling for a 1916 aircraft.
  • 0

#118 AnKor85

AnKor85
  • Posts: 1002

Posted 19 September 2012 - 06:31

OK, that's interesting.
I can alter exposure by altitude, but the delay between shots now simulates the camera reloading rather than requirement for correct overlapping of pictures. If the goal is coverage % then 10 seconds at high altitude is too fast - you will waste your shots because they will be overlapping too much and the coverage will grow slowly. So it is up to player to account for altitude.
I already posted it: the diameter of each photo is 680m per 1000m altitude, at 120km/h you travel 330m per 10 seconds which gives you about 50% overlap @ 1000m. Then at 4500m each photo is 3060m and at the same TAS you will get about 90% overlap (well, actually less in both cases because the shape of photos is circular, but you get the idea).

However, as Waxworks noticed in Syndicate thread - point recon may be harder due to exposure delay. It is up to mission author to define the requirements - and I agree that 10 photos of the same small area is way too many. As for having different targets in single objective - I initially wanted to allow so, but it was difficult to implement. The only way now is to add more objectives with smaller number of photos each.

As for altitude - I can raise it for Germans, I remember it was discussed earlier. No need to increase the lower limit, I can just set it to 1000-5000 or even higher.

Spad 13 definitely needs some "nerfing", but I still want to keep it viable as recon albeit limited :)
I think 200-500 is way too low? Maybe up to 1000?
And what about loading it with, say, 5 frames (with only one frame it will be really useless). This way it will be able to complete small point objectives, but unable to go for bigger coverage without landing to refill.
  • 0

#119 Gadfly21

Gadfly21
  • Posts: 1081

Posted 19 September 2012 - 06:41

Sounds like a big stride in the right direction!

I noticed that the % coverage with each shot seems to vary inconsistently, so I think you've just answered my question as to why.

I think 1000 meters is OK for the SPAD, but it would be less detailed of a shot, naturally. Again, I don't know enough about the specific camera the SPAD carried, so it may have had a roll of film with an automatic frame advance function. I think 5 frames would be fair so that folks don't complete all the PR missions with scouts alone.

Thanks again. I wish I could convey how satisfied I am just to have this new functionality at all.
  • 0

#120 SYN_Vander

SYN_Vander
  • Tester
  • Posts: 4708

Posted 19 September 2012 - 11:23

Good plan! I'll make sure that in the missions for "point photo reconaissance" you only need to make three photos or so.
Another disadvantage with the SPAD is that you can't use a bomb sight to aim properly and may need some extra time to find the correct spot, so I think it's good as it is now.
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users