Creating a computer-aided version of WCTO

Sorry, you can ignore the black on the bottom. I was using raw text, and I guess I forgot to remove the extra.
 
Personally, I could do without the italics. And maybe add up all hits and misses in one line. The two different colors should be enough to make this clear, and it won't take up as much space in the reports. Just my $.02, though! :)
 
Okay, now I'm trying it without italics and with hit/miss on the same line. What do people think now?
 
General progress update: I've now put in a rough form of a movement-phase field report (seen during CP phase). It's completely untested and pretty basic; hopefully it looks okay. I've also started roughing in the code for tailing. It still doesn't do anything visible to you, but it is now trying to pass forward some info to the movement phase from the end-phase. Let me know if you see any side effects, and especially watch out for processing error messages on the turn selection screen that you reload to detect new turns on.
 
I am please to announce that tailing is now fully functional! After a fully successful test case of 1 trial, I am 10% confident there will be no further problems!

Unfortunately, like many of the phase5-based updates, only a signed-in account can properly witness how this will change things. As you probably should expect by now from my 'design intent' during a Movement Phase, an extra tab appears at the top, and should theoretically list all the tailing information you have available.

I also implemented one other subtle UI upgrade. On the 'intercepted communications' tab, there are now 3 colour codes. Green means orders submitted. Red means everyone is waiting on that person to submit an order, and orange means that while that person *could* submit their orders now, they are waiting for someone else first, since they are owed tailing information to make their decision. If the person you are waiting for submits (goes green) your status will change to orange (upon page reload).

Among things needing to be tested about this system, the one thing I am least confident on, is how it will react to multiple-ship ownership with multiple tailing. In theory, if you own 2 ships, and both tail enemies, you should receive 2 reports. We need to ensure this is true.

I'm taking a coding break for now, but sometime in the next 24hrs, I'll set up Alpha Game 4, and we'll go from there!
 
Good job! Looking forward to see how tailing will work in-game. I especially liked that part about your 10% confidence. :p
 
I am incredibly pleased to announce that, after 4 hours of work, and a fair bit of diving into the inner workings of the jquery-ui widget I was trying to use, I have made a vast improvement to the multi-selector! I honestly didn't think I'd be able to understand what was going on well enough to fix this, but I think I finally pulled it off. Ironically, we're now using a bug-fixed, more improved version of the selectmenu jquery UI over anyone else on the internet! Sadly, I'm simply not interested enough in jquery development to go open up a github fork of the current selectmenu-ui tree, and put in a pull request to that community.

Okay enough blathering, let's deal with this from a WCTOO point of view: the select menus should now disappear when you mouse away from them. I haven't fixed the 'you have to pick something new' bug yet, however, but I believe that this was the key annoyance with them.

Note carefully: these changes are unrelated to the UI test I'm doing on regular ship pop-ups, which causes them to disappear as soon as you mouse away from indicator icons. That is a Game 4 test for opinions of users only, and can easily be reversed without affecting this fix.
 
Quick suggestion: this is something more for the player's benefit. I was wondering if there could be a little warning if afterburning will send you off the map. During the current game I miscounted the hexes and flew off the map. Hahaha.
 
Quick suggestion: this is something more for the player's benefit. I was wondering if there could be a little warning if afterburning will send you off the map. During the current game I miscounted the hexes and flew off the map. Hahaha.
Hmm... I'll have to think on the best way to do that. It would probably involve pretending to fly for you behind the scenes and warning you that you'll go off the map... that calculation would probably have to happen on-the-fly when I make the orders window.... yeah, that is possibly doable.

In other news, I've added the missile pop-up. Suggestions are always welcome.
Note carefully: It took me about 1 hour to get it to where it is now. I then fought for 3 hours to try and get the name of the target to show up. It won't. I have no idea why not. I've tried everything. I can even tell the program to crash and dump the target name variable, and it will successfully tell me the target name. I can even, earlier or later in the same script, have it just dump the target name onto the battle field as floating text without problems... but as soon as I tell it to put the target name into the field where it would be actually displayed correctly...nothing comes through.

For instance:
Code:
 $output = $pieceset[$this->target]->name;
works fine, but
Code:
 $output .= $pieceset[$this->target]->name;
only works when it isn't in the context of the exact place I want it. I really can't describe how incredibly strange and frustrating this particular bug is. It just doesn't make sense. With my luck, tomorrow it will magically work for no apparent reason.

Aside: Wedge, if you're still reading the WCTOO updates, I'd appreciate your help with making sure my css is still up-to-par. There should only be new missile-pop-up related changes in the css files. Similarly, if you could glance at line 43 of missile.php and see if you can make it display the targetname, that would be amazing since I can't diagnose the problem.
 
For instance:
Code:
 $output = $pieceset[$this->target]->name;
works fine, but
Code:
 $output .= $pieceset[$this->target]->name;
only works when it isn't in the context of the exact place I want it. I really can't describe how incredibly strange and frustrating this particular bug is. It just doesn't make sense. With my luck, tomorrow it will magically work for no apparent reason.

Did you check to make sure the $output was instantiated before you tried to extend it? What version of PHP are you running? (It is PHP, right?)
 
Yeah, I did check, and yes, it definitely is. I could put
Code:
die($pieceset[$this->target]->name) ;
and it would happily drop the target name.

Anyway, I think I've isolated the issue. In fact, it is actually working! I just didn't notice. Coincidentally all the missiles I checked had no targets, and thus no target was listed. It is supposed to display 'none', so clearly the blank target is returning either a null or a blank character and my current check can't identify this, but ultimately I was frustrating myself for hours yesterday because I wasn't taking a full survey of all missiles on the field, and assuming a 2 missile test case reflected them all.

Anyway, thanks for the suggestion! And yes, it is php, I just don't like how the php tags look, so I use the code tags.
 
I'd appreciate your help with making sure my css is still up-to-par. There should only be new missile-pop-up related changes in the css files. Similarly, if you could glance at line 43 of missile.php and see if you can make it display the targetname, that would be amazing since I can't diagnose the problem.
Ugh, don't know why I left this till late to have a look at this. The CSS is mostly fine - just made a couple of corrections that you should probably double-check to make sure it's what you intended (Subversion revision 487).

Also, the target name is displayed if there's an actual target name to print. I can see it working fine on turn 6 phase 2, the right-most missile.
 
Also, the target name is displayed if there's an actual target name to print. I can see it working fine on turn 6 phase 2, the right-most missile.

Yeah.... I finally realized that was the case the next day. Probably because I was staring at it too long and looking at the wrong missiles. I'll try to put in a 'none' word in place next, so that it is clearer.

Thanks for the help with the CSS. It is my main Achilles heel.
 
No worries. I'd focused on the PHP changes before, and realised you're mainly working on the actual PHP game code, not the HTML rendering, nowadays. I'll try to remember to keep a closer eye on the CSS - if you hear nothing further from me, it most likely means I haven't found any issues.
 
This came out of Alpha Test Game 4 thread. We realized that I was allowing barrel rolling during all movement types. With a bit of code change, I've theoretically made it so that you can only barrel roll during regular or bank movement. Change is live.
 
"In theory" I have just added the pilot skill level system. For alpha game 4, I've set all pilots as regulars, so no benefit or detriment. In theory this should change nothing on the game as-is.
 
Happy to announce I have finally spruced up the End-phase turn reports. They should now be better spaced and more colourful, much like the combat reports. That said, it will only kick in for future reports, and the formatting is still up the air. Feedback is always appreciated. This is just a first cut at it too, it may change going forward.
 
Back
Top