Creating a computer-aided version of WCTO

Um, no, I think you could actually specify which missile you wanted to target with reserved fire. At least that would make sense, since in a team, you could order your wingman to take care of one missile while chasing another. This would require another "Orders" window for targeting missiles during end phase, but other than hindering game flow a bit, it probably wouldn't be much of a problem code-wise (?). And of course, each ship would only be able to concentrate on ONE missile at a time (barring flak, for obvious reasons).

For starters, I guess it would make sense to start out with the ship with the least opportunities (least reserved shots, worst firing arc) and possibly with the missile's target first. Since there aren't any rewards for shooting down a missile (other than eliminating a major threat to fighters/bombers), you can stop iterating through ships once the missile got "killed."
 
okay, then it sounds like we're on the same page; I've already coded a 'which missile to fire at' list. The only thing I need to track now, is if the missile passes *through* the arc at any time; at the moment I'm only looking to see if it is coming at you, and within the arc, I think.

I did see your note on incorrect opportunity fire; I'll address that next time I find time to code.
 
So, the combat alpha demo broke. It took me a while to realize why. We hit 'phase' 127. In truth, we should never hit a phase value greater than 3 (1=movement, 2=combat, 3= end turn) before the turn counter would increment and go onward. For the purposes of the testing we were doing, however, I let 'phase' just keep going "forever".... well we've hit the upper limit. Phase was a 'tinyint' to save space, since it never needed a value greater than 3. It has a maximum upper value of 127, hence why the demo broke.

Unfortunately, I don't know when I'll be able to work on this next; I have a conference for the later half of this week. When I come back, I'll fix the issues Ironduke pointed out above, and then start implementing the end-phase stuff. This will push us into a demo game '2' which won't have a problem with the maximum phase, since we'll actually have turns and such.
 
Okay, time for me to get to work on this project after a busy week - I went through all the ship charts Avacar published recently. Here's what I found:

Drakhri
- 4 DF missiles missing

Broadsword
- description: "Confederation's" and "bomber's" seems mixed up (font problem with the apostrophe?)

Epee
- description missing

Ferret
- description missing

Grikath
- description missing

Jalkehi
- typo in description: "this Kilrathi heavy armor" instead of "heavy fighter"

Waterloo
- description: again the issue with the apostrophe in "Confed's"

Yorktown
- description: another apostrophe in "Yorktown's" and "Concordia's"

Confederation
- description: apostrophe, "Confederation's" and "dreadnought's"

Bengal
- description: apostrophe, "Tiger's Claw"
- 6 AMGs instead of 5

Concordia
- description: apostrophe, "Confed's"

Durango
- description: apostrophe, "doesn't"

Fralthra
- description: apostrophe, "Fralthra's" and "doesn't," as well as a mixed up dash in front of "in fact"

The following ships seem to be missing in the current data set (although I'm pretty sure I edited them in):
- Dorkathi
- Kamekh
- Refinery and other depots and bases

You guys might also want to check if my history is correct in those ship descriptions, or if there's lore I made up or forgot to add. :p
 
I'm back, and going to do some development today. I am going to be weaving in the end phase initial work. Unfortunately this is going to affect existing files while I do, and the existing combat demo may temporarily not work.

Ironduke: I did note you found a case of broken opportunity fire; unfortunately I can't do maintenance on it because I have too many end-phase changes pending. I will try to come back to it down the road, but if you don't see me mention it, try to recreate the problem in the next test.

edit: minor update (not worth its own post). I've fixed the mis-coloured slide-out info windows issue we were having. Unfortunately, the fix has retroactively turned all old ship entries to confed (blue). I did a manual fix on the Ralatha, so it is back to red, but be not surprised that all of Game 1's other Kilrathi ships are back to blue. I've also started a Game 2, which I've stolen the last 2 turns of Game 1 as a basis.
 
Progress Report:

I need to write the missile-flight code, and the chaff-handling code, but otherwise the end-phase-engine is done. I've coded in the 'can you tail' checks, and it will let you know your success, but I haven't built the forward transport medium to have the movement phase handle the tailing reporting yet. (i.e., you can tail, and you'll know how well you did, but for now, you won't get any info out of it next turn).

Obviously, there is also debugging to do.

Unfortunately, my schedule is looking to be pretty busy for the next day or so. As such, I don't think you'll see me publish the demo, fully debugged, until Tuesday evening or Wednesday.
 
I know the text overlay is only a temporary measure, but I modified the CSS so that it correctly overlays on all major layout engines now. (Based on repository code only, revision 286, the text overlay was failing in standards-compliance mode.)
 
You should be safe to make any css/html changes you want at this point, Wedge. With the work I'm currently doing, we're back to using the pure phase4.php file as the basis; no more weird hacks or temporarily commented out pieces of code.

Additionally, while I'm not done with the end-phase-engine itself, I'm more or less done with the endphase_preengine, which contained the last bits of unique html/css/javascript for this particular phase. I'll try to keep the repository updated as I make changes, so I welcome you to continue keeping us standards-compliant!
 
I made the post by way of a statement, not a complaint that something was wrong. :)

What's in the repository now should be both compliant and displaying as intended. I'll continue to watch for updates and make adjustments if anything gets broken, but with the separation of style and content, I don't expect any major will be necessary.
 
You may want to investigate the preengines; I seem to recall basing the combat one on the movement one-- except I did the branching before you fixed up the movement preengine. Then, you haven't modified the combat preengine, and I used it to create the endphase preengine.

What I am trying to say is: I suspect the latter two are guilty of using paragraph tags wrong and other errors still... but maybe you've already checked and they're fine?
 
I haven't checked explicitly for paragraph tags, but automated validation didn't pick any new errors, and a brief check of the page at work seems okay. Any commits you've made should have been merged - any conflicts would have prevented you from committing. I did a quick check just now, and I don't see any misused paragraph tags, so it should be okay.
 
Game ruling:

if a missile detonates in a chaff field, causing half damage, do we want this to affect just the target, or everyone on the square?
 
Corrected syntax error in ship.php

Another missing closing brace in missile.php corrected (that's why I think good formatting is helpful in avoiding these errors). Also, you can't assign $this to null - if I understand what you're trying to do, I think you ought to write some sort of exit or closing method for the class instead.
 
In php there isn't a destroy command to mirror the new command, as such to destroy it, reassigning to null is as close as we can get.

I am in the middle of testing those very passages, which is why there are still typos.

If the $this = null; doesn't work, I'll pass out an exit flag, and then assign the missile as null from the outside.
 
Avacar said:
Game ruling:

if a missile detonates in a chaff field, causing half damage, do we want this to affect just the target, or everyone on the square?
Click to expand...
Hm, seems like I managed to overread that part...
I'd say just the target. There's nothing in the rules about splash damage, and I think that's okay. After all, the missile is very close to the target at this time - it might only affect another ship if it has currently docked with the target (before you ask: campaign stuff, not in the rules yet...). Other ships should never be in such close proximity to the target, even if they're in the same hex.
 
heh; yeah, standard practice would be to do that.... but the last 3 days have had me on my feet and out of my office a lot; to move the code between my machines I've been dumping up and down some partial commits. I deserve a good slap on the wrist for bad coding practices.

I do appreciate that you've been keeping up with it; fixing those typos likely saves me some time in fixing them myself.
 
Another ruling clarification: Do we want missiles with multi-turn target-chasing capabilities to be able to bank?
 
You must log in or register to reply here.
Back
Top