Bridge damage

[69giaptushka]

Stenka,

Bloody April Mission 13 shows a bridge destruction event and another bridge being damaged. Unfortunately for what you want, the 'spans' are not mentioned. Only the entire bridge is mentioned, with its degree of damage and whether or not it is 'killed'.

You can see how the logs report hits on the bridges (set parser debugging to 101), damage to the bridges (set parser debugging to 102) and the kill (set parser debugging to 103). At each setting, run a report for Bloody April Mission 13 and 'find' 'bridge'.

You set debugging by editing Website/rof_parse_log.php and changing the $DEBUG variable near the top to something other than '= 0'.

I don't plan to make such debugging a feature of our boswar/rofwar GUI.

[69giaptushka]

My suggestion is that if we find a bridge is 'damaged' in the log we consider it impassible. My suspicion is that damage isn't reported until at least one span or entry is damaged... though I don't have direct evidence that this is the case.

To date I've ignored 'damage' reports and have only dealt with kills, but there is no reason that needs to remain true.

[69giapstenka]

Tushka,

Testing last night I was blowing up several spans. Searching the parse files for "Bridge 1" I found explosions registered with ammounts of damage eg. 0.07 0.25 and even 1.00 but no kill messages.

Now there are two settings against a bridge which may affect that. There is a sort of life value which defaults to 25000 points and there is a damage factor which defaults to 50.

I tried to reduce the former down to 1000 then 500 and the latter to 10 but still no kill message in logs. Maby I'm missing the message or I haven't changed the figures enough. It needs some thorough testing - but first I need to know what the kill message looks like. If I'm looking for the wrong thing all the testing is wasted.

Thx

----- Mail original ----- De: "=69.GIAP=TUSHKA" notifications@github.com À: "69GIAP/69GIAPBosWar" 69GIAPBosWar@noreply.github.com Cc: "69giapstenka" ptthome@free.fr Envoyé: Lundi 14 Octobre 2013 05:51:38 Objet: Re: [69GIAPBosWar] Bridge damage (#40)

My suggestion is that if we find a bridge is 'damaged' in the log we consider it impassible. My suspicion is that damage isn't reported until at least one span or entry is damaged... though I don't have direct evidence that this is the case.

To date I've ignored 'damage' reports and have only dealt with kills, but there is no reason that needs to remain true.

— Reply to this email directly or view it on GitHub .

[69giaptushka]

The best way to look at the logs would be to run them through the parser. Create a new campaign to to this, say bridgetest, place the bridge test log in the logs directory and make sure that the log prefix matches what you have named your logs. For example, if your logs are missionReportbridgetest1, missionReportbridgetest2, etc, your log prefix should be set to missionReportbridgetest in campaign_settings. We don't yet have a web page for setting these settings so you'll need to do this by hand. e.g. UPDATE bridgetest.campaign_settings SET log_prefix = 'missionReportbridgetest' or something like that.

Then you are all set to parse the logs, and by editing rof_parse_log.php as described above, get partially decoded logfile lines so you can see what the logs contain and how the parser inteprets those contents.

Just search for 'bridge' (case insensitive) to pick up all references.

[69giaptushka]

In another thread Stenka wrote: My tests show that it's possibly impossible to get an atype3 An atype2 is proof of destruction of one span track them in stats and we will disable the bridge and measure rebuild times from there

Nonsense, see Bloody April Mission 13 for an example of an Atype 3 (kill) on a bridge: The Central Powers suffered 11 losses: 13:06:47 a German tent01 (Block) 13:10:36 a German bridge_hw150 (Bridge) ... DUMP OF SLIGHTLY PROCESSED PARSING RESULTS BY AType DEBUG = 103 AType:3 KILL Ticks, AID, TID, POS Clock Time, Attacker Type, Attacker Name, Attacker Pilot, Target Type, Target Name, Target Pilot, Position ... 211804 325645 1981440 (194351.000,73.950,81199.500) 13:10:36 R.E.8 R.E.8 LvA***Biggles bridge_hw150 Bridge Bridge within sight of Hermes ...

The first line shows what the log line has... Ticks, Attacker ID, Target ID and (Position) and the second line shows the parser's interpretation of the log line.

This shows it is possible to get a kill on a bridge. It isn't easy. Typically you have to destroy more that half the spans and approaches.

[69giapstenka]

Maby Bloody April was at another patch level, maby damage is only summed at a nicely terminated mission.... In test I blew up every span and the two ramps all i got was lots of Atype 2s

Still Atype 2 is what we need as with one span down you can't cross bridge

Next I need to check if an engineer column is less than 500 metres from the bridge

----- Mail original ----- De: "=69.GIAP=TUSHKA" notifications@github.com À: "69GIAP/69GIAPBosWar" 69GIAPBosWar@noreply.github.com Cc: "69giapstenka" ptthome@free.fr Envoyé: Jeudi 17 Octobre 2013 05:10:47 Objet: Re: [69GIAPBosWar] Bridge damage (#40)

In another thread Stenka wrote: My tests show that it's possibly impossible to get an atype3 An atype2 is proof of destruction of one span track them in stats and we will disable the bridge and measure rebuild times from there

Nonsense, see Bloody April Mission 13 for an example of an Atype 3 (kill) on a bridge: The Central Powers suffered 11 losses: 13:06:47 a German tent01 (Block) 13:10:36 a German bridge_hw150 (Bridge) ... DUMP OF SLIGHTLY PROCESSED PARSING RESULTS BY AType DEBUG = 103 AType:3 KILL Ticks, AID, TID, POS Clock Time, Attacker Type, Attacker Name, Attacker Pilot, Target Type, Target Name, Target Pilot, Position ... 211804 325645 1981440 (194351.000,73.950,81199.500) 13:10:36 R.E.8 R.E.8 LvA***Biggles bridge_hw150 Bridge Bridge within sight of Hermes ...

— Reply to this email directly or view it on GitHub .

[69giaptushka]

Stenka, let's leave bridges and bridge repair for a later release. We have more important things to work on at the moment for the first release. Bridges and bridge repair is certainly not very important for RoF because WWI doesn't have much movement. Stalingrad is also largely a static meat-grinding campaign. It isn't Kursk!

We need to get your code integrated with ours and we need to work on configuring the campaign parameters for a new campaign and getting the logic built in to track the stage of missions and what functions are available at each stage. We can't release until we have those. We can release without bridge logic.

[69giapstenka]

Tushka & Myata,

Bridge management can be done later, but for the moment while Myata is plugging the front end onto my scripts and tables I have been trying to avoid changing them and the way to do that is for me to work on new objects.

Cutting of supply lines was a key aspect of Stalingrad - and there are 100s of bridges BUT no problem to do that later.

Now we have to consolidate at least one key parameters table for a campaign, which will no doubt finish with several sub tables.

If you agree we can make cam_param the master table and I will consolidate your campaign table(s?) into that.

You give me the list of your table(s?) to consolidate (I can guess but might miss something).

I will then provide you with a .xls with the cross mapping for you to go update your scripts.

Also I will provide the sub program which puts all the camp param fields into memory as constants.

So you just require this at start of program and then you have it all in memory. If I remember right I just convert field names to be in capitals and you have the constant.

OK?

----- Mail original ----- De: "=69.GIAP=TUSHKA" notifications@github.com À: "69GIAP/69GIAPBosWar" 69GIAPBosWar@noreply.github.com Cc: "69giapstenka" ptthome@free.fr Envoyé: Vendredi 18 Octobre 2013 05:49:53 Objet: Re: [69GIAPBosWar] Bridge damage (#40)

Stenka, let's leave bridges and bridge repair for a later release. We have more important things to work on at the moment for the first release. Bridges and bridge repair is certainly not very important for RoF because WWI doesn't have much movement. Stalingrad is also largely a static meat-grinding campaign. It isn't Kursk!

We need to get your code integrated with ours and we need to work on configuring the campaign parameters for a new campaign and getting the logic built in to track the stage of missions and what functions are available at each stage. We can't release until we have those. We can release without bridge logic.

— Reply to this email directly or view it on GitHub .

[69giapmyata]

STENKA, why, if there are still changes required, don't you start working out of the Website environment on your scripts ? That would take load from me constantly adapting your changed scripts to fit them in again. Rgith now, you are the only one of the three of us who is working from a completely different dev environment. I don't wanna be harsh here but this would be the best and fastest way to progress from here on. Especially as you then would get familiar with the current layout and give your inputs on the goods and bads of it.

I'd like to chat about that tonight if any possible please come on TS.

[69giaptushka]

Stenka, campaign_settings is a keystone of what we have already developed and already contains everything that cam_param contains (except supply points which is a separate table) plus much more, so it makes much better sense to drop cam_param and just use the data that is already available in campaign_settings as I've said twice earlier.

I'll do it myself.

[69giapstenka]

Myata,

I can answer that quite simply,

When a release of software will not get through a login and creation of a test database I won't touch it.

Otherwise I would have to start hacking the user controls to get further and you don't want me doing that.

You and Tushka are working on moving code but the databases and their data are sitting on separate separate machines living separate lives.

The net result is that you may have a script that works in your environment with your test data that has evolved through endless permutations and works for you but when installed on my system it doesn't get beyond the first screens. And vice versa no doubt.

I don't believe it can work like that.

The way we develop complex systems in my job is that each object, be it script, database structure, test data has an owner and once that object is checked out to somebody onto their development environment nobody else touches it.

When they have developped to the point where they need to deliver to integration testing or hand over to someone else they make a delivery package. Which includes the program scripts scripts, the database change scripts, the instalation procedure, the test plan including either description of or data load routines to create the test data environment.

This is delivered onto a separate test environment where one or more people start testing.

So deliver a package with matching scripts, database, data, test procedure together at one point then I will be able to install it, start it and it should work.

Then when I've made my changes I will deliver it back.

Do you see the problem or do you think that github miraculously solves this?

Thx

Stenka

----- Mail original ----- De: "=69.GIAP=MYATA" notifications@github.com À: "69GIAP/69GIAPBosWar" 69GIAPBosWar@noreply.github.com Cc: "69giapstenka" ptthome@free.fr Envoyé: Vendredi 18 Octobre 2013 16:37:08 Objet: Re: [69GIAPBosWar] Bridge damage (#40)

STENKA, why don't you start working out of the Website environment on your scripts if there are still changes required? That would take load from me constantly adapting changed scripts ad you are the only one of the three of us who is working from a completely different dev environment. I don't wanna be harsh here but this would be the best and fastest way to progress from here on. Especially as you then would get familiar with the current layout and give your inputs on the goods and bads of it.

I'd like to chat about that tonight if any possible please come on TS.

— Reply to this email directly or view it on GitHub .

[69giapmyata]

Github is working perfectly fine on my side - all changes TUSHKA introduces do actually work. The problems we had at the beginning were due to different base situations and of course we had to get used to work colaborative through Github. Now as we alignned the DB user names and are working from a base db called boswar_db everything is fine. I don't know about your dev enironment and it wouldn't make a difference if I knew. What I would like to know is what do you need from us to syncronize it to our systems so we can actively start colaborating? I guess I can deliver the scripts to setup the DB the way it works. I do my best to present a working test scipt to you by tomorrow with a full installation package. Lets do our first test build, why not :)

Are you interested? I'll be online tomorrow afternoon till evening and on TS.

[69giapstenka]

Well mine does a wonderful "Loading commits fail you may want to open a shell and debug"

You might be able to see the following in github or not.

I built a complete new installation from scratch.

The menu sequence for creating a campaign now works and I can see that you can change the status.

Now we have two types of active users an admin which creates and runs a campaign and a planner who just inputs planning information.

I cant work out your menu system so here is a draft menu for an administrator.

It takes him through the tasks needed to create a campaign in the right order and then the tasks required to run the campaign.

It also has at the bottom the planner's tasks because an admin will need to be able to test plan or correct a plan.

Some of the options are not needed now but we should put them in as place holders so you know what the finished system will look like.

A planners menu will just have the bottom.

The campaign setup option is detailed. Effectively I am building in not just input of data but what the user should be doing in the Mission editor.

Now this is content and sequence with a very rough layout.

Where do you want me to stop?

I can stop at this level and start detailing each option or I can code input and database writes?

These are just really the update tasks, we will need some display options.

For example if I have just updated static objects I might list them on screen and give a number count. Alternatively we could have a separate reports window with it's own reporting menu and filter selection.

How do you want to address reporting?

Thx

Stenka

----- Mail original ----- De: "=69.GIAP=MYATA" notifications@github.com À: "69GIAP/69GIAPBosWar" 69GIAPBosWar@noreply.github.com Cc: "69giapstenka" ptthome@free.fr Envoyé: Vendredi 18 Octobre 2013 22:52:04 Objet: Re: [69GIAPBosWar] Bridge damage (#40)

Github is working perfectly fine on my side - all changes TUSHKA introduces do actually work. The problems we had at the beginning were due to different base situations and of course we had to get used to work colaborative through Github. Now as we alignned the DB user names and are working from a base db called boswar_db everything is fine. I don't know about your dev enironment and it wouldn't make a difference if I knew. What I would like to know is what do you need from us to syncronize it to our systems so we can actively start colaborating? I guess I can deliver the scripts to setup the DB the way it works. I do my best to present a working test scipt to you by tomorrow with a full installation package. Lets do our first test build, why not :)

Are you interested? I'll be online tomorrow afternoon till evening and on TS.

— Reply to this email directly or view it on GitHub .

[69giapmyata]

We need to talk this through really - I have to understand what you expect and I don't from this post.

To solve your sync issue do the following: open the GitHub application (not webasite!)

once the application logged you on choose 69GIAP on the left by clicking once

Now you see the two repositories assigned to 69GIAP - right click 69GIAPBosWar

select "stop tracking this repo"

Now go to your desktop and remove the folder GitHub was storing files to (on my system this is: C:\Users[UserName]\Documents\GitHub)

If you have things in there that you want to sync once this issue is resolved keep them somwhere and delete the rest

Now you can reload a fresh copy with the latest information fro the 69GIAP - 69GIAPBosWar repository.

Go back to the GitHub application

click 69GIAP on the left to display the repositories

Hover over 69GIAPBosWar and click CLONE

Wait a minute to download the latest content

Now the error is gone and you can start syncing your stuff again. UnfortunatelyI did not investigate in how to resolve this with the cmd shell but I suspect it would be easier Nevertheless this method works and it takes basically less then a minute to things up and running if this happens btw, the reason for it is a conflict - somebody worked on the same file as you did at the same time and GitHub does not know which one is the actual valid version.

When will you be online today?

[69giapstenka]

Myata,

I can be online at 19:00 or 20:00

Thx

Stenka

----- Mail original ----- De: "=69.GIAP=MYATA" notifications@github.com À: "69GIAP/69GIAPBosWar" 69GIAPBosWar@noreply.github.com Cc: "69giapstenka" ptthome@free.fr Envoyé: Dimanche 20 Octobre 2013 14:26:16 Objet: Re: [69GIAPBosWar] Bridge damage (#40)

We need to talk this through really - I have to understand what you expect and I don't from this post.

To solve your sync issue do the following: open the GitHub application (not webasite!)

once the application logged you on choose 69GIAP on the left by clicking once

Now you see the two repositories assigned to 69GIAP - right click 69GIAPBosWar

select "stop tracking this repo"

Now go to your desktop and remove the folder GitHub was storing files to (on my system this is: C:\Users[UserName]\Documents\GitHub)

If you have things in there that you want to sync once this issue is resolved keep them somwhere and delete the rest

Now you can reload a fresh copy with the latest information fro the 69GIAP - 69GIAPBosWar repository.

Go back to the GitHub application

click 69GIAP on the left to display the repositories

Hover over 69GIAPBosWar and click CLONE

Wait a minute to download the latest content

Now the error is gone and you can start syncing your stuff again. UnfortunatelyI did not investigate in how to resolve this with the cmd shell but I suspect it would be easier Nevertheless this method works and it takes basically less then a minute to things up and running if this happens btw, the reason for it is a conflict - somebody worked on the same file as you did at the same time and GitHub does not know which one is the actual valid version.

When will you be online today?

— Reply to this email directly or view it on GitHub .

[69giapmyata]

Bridge insertation while importing the template fails as the damage field is not beeing delivered with '0' but ''

REPLACE bridges SET Name='Bridge 1', XPos='104091.000', ZPos='112973.000', YOri='224.00', Model ='bridge_hw70', Country='101', CoalID='0', damage_1='', damage_2='', damage_3='', damage_4='', damage_5='', damage_6='', damage_7='', damage_8='', damage_9='', damage_10='', Description='' ; importBridges query error [Incorrect integer value: '' for column 'damage_1' at row 1]

[69giaptushka]

That is an interesting error. I'll make the default value for damage NULL rather than 0.

On Thu, Nov 21, 2013 at 3:46 AM, =69.GIAP=MYATA notifications@github.comwrote:

Bridge insertation while importing the template fails as the damage field is not beeing delivered with '0' but ''

REPLACE bridges SET Name='Bridge 1', XPos='104091.000', ZPos='112973.000', YOri='224.00', Model ='bridge_hw70', Country='101', CoalID='0', damage_1='', damage_2='', damage_3='', damage_4='', damage_5='', damage_6='', damage_7='', damage_8='', damage_9='', damage_10='', Description='' ; importBridges query error [Incorrect integer value: '' for column 'damage_1' at row 1]

— Reply to this email directly or view it on GitHubhttps://github.com/69GIAP/69GIAPBosWar/issues/40#issuecomment-28966284 .

[69giapmyata]

Can't insert with 0 which means undamaged?

[69giaptushka]

Could insert with 0. Either way should work. Try this one and let me know. There is a subtle difference between NULL and 0. NULL means 'undefined' and 0 means 'known to be 0'. Bridges don't report spans that they don't have (and some are very short), so to my mind those spans should remain undefined because they don't exist.

On Thu, Nov 21, 2013 at 11:51 AM, =69.GIAP=MYATA notifications@github.comwrote:

Can't insert with 0?

— Reply to this email directly or view it on GitHubhttps://github.com/69GIAP/69GIAPBosWar/issues/40#issuecomment-29001104 .

[69giaptushka]

Unfortunately my system doesn't repect that distinction and inserts 0 when I want NULL. :(

On Thu, Nov 21, 2013 at 1:13 PM, Tushka 69.GIAP 69giaptushka@gmail.comwrote:

Could insert with 0. Either way should work. Try this one and let me know. There is a subtle difference between NULL and 0. NULL means 'undefined' and 0 means 'known to be 0'. Bridges don't report spans that they don't have (and some are very short), so to my mind those spans should remain undefined because they don't exist.

On Thu, Nov 21, 2013 at 11:51 AM, =69.GIAP=MYATA <notifications@github.com

wrote:

Can't insert with 0?

— Reply to this email directly or view it on GitHubhttps://github.com/69GIAP/69GIAPBosWar/issues/40#issuecomment-29001104 .