Alpha Test Game 5
- Thread starter Avacar
- Start date
capi3101
Admiral
15CP: Shouldn't Dead Meat have a shot at Sivar's Fist? Can't give him orders for some reason. QuailPilot, you might want to see if Meat's on Sivar's Fist's list of valid targets too.
I know we had a discussion on the opportunity firing arcs back in Game 4, when Ironduke made this handy little image... https://www.wcnews.com/chatzone/attachments/opp-fire-gif.4933/
Will wait on giving orders for now.
I know we had a discussion on the opportunity firing arcs back in Game 4, when Ironduke made this handy little image... https://www.wcnews.com/chatzone/attachments/opp-fire-gif.4933/
Will wait on giving orders for now.
Last edited by a moderator:
This also could be ramifications of any of the other many many changes I've made in the last month and a half. This could be a bug in the line-of-sight calculations, which are new. We also need to keep an eye out for any issues with combat orders not being what you ordered (due to the complete reworking of how I pass them around that was necessary to get flak orders to work).
I'll try to investigate this soon; do hold off on orders for now. Meanwhile, is anyone else affected?
Last edited by a moderator:
Not explicitly, I have to go in and breakpoint my way through the code, effectively.
capi3101
Admiral
That one's explained by the rules. When an Immelman fails...p. 15: "Failure: Ship executes a normal turn to port (even result) or starboard (odd result) at its full Turn Rate." Since a Rapier has a turn rate of 3, it would make a 180 degree turn anyway. All that the Immelman would've done would've been to let him stay on the same hex when he turned around; you'll note that Mike has moved over two hexes from where he was, so he did indeed fail the maneuver.
Quien
Rear Admiral
I didn't realise that, that actually ends up working out better than what I planned!
capi3101
Admiral
Yeah, the way the rules are written, the Immelman is fairly useless. With a sufficiently maneuverable craft, you can get the same effect by killing your speed and turning around (but, of course, this makes you a sitting duck for anybody shooting at you). Usually you can do just as well by reducing your speed to one and turning around; you avoid the TR penalty that way. For less maneuverable craft, the Target Roll on an Immelman is so high that your chance of success is no greater than 25% (8% if you've got something like a Jalkehi), so you can't rely on it to save your skin. It's a Hail Mary at best. Only time I can think to try it is if you've got a really maneuverable craft and you need to keep that one range increment to keep the target in range of your guns.
And now I think I've given away one of the key pieces of the strategy I use when I play this game...
Investigating now... will type here as I go and post at the end.
1. Looks like Dead Meat has had its order submitted flag set to 1. If you didn't do it, it means the end-of-movement-phase-do-I-need-an-order predictor misfired (should it be discovered that he should have an order).
2. Artificially forcing it back to 'I need to send and order in'.
3. With the flag on, I get a blank orders window, and the mesasge 'There are no forward targets in range'. This means that the predictor is in line with the orders window, so the predictor itself isn't the problem, if there is one. (It should be noted however, that you are offered the chance to drop an FF. From the looks of things though, there isn't a valid FF target, so that may be why the predictor didn't offer you up an order window on that account alone).
4. Now I need to manually step through your order window generation process to see what is going on w.r.t. if you should or shouldn't have an order.
5. Okay got to Sivar's Fist. Bearing to Sivar's Fist is 30deg exactly. This should be within the half-cone of a 60deg arc, a.k.a you're correct that you should be able to opportunity fire.
6. Aha. As I suspected, it got rejected on LOS basis. Well clearly that's a bug. Let's dive into that and see why.
7. Thinks we were on the same square due to an error in the length formula. Fixed.
Okay go ahead and submit your orders now!
In other news, i'd comment on the immelman thing, but Capi explained it correctly. As for the rules... well bring Ironduke in!
Also a big thanks and congrats to all you testers. WCTOO came in a (tied) 2nd place as Fan Project of the Year. You all deserve credit for all your help in finding bugs!
1. Looks like Dead Meat has had its order submitted flag set to 1. If you didn't do it, it means the end-of-movement-phase-do-I-need-an-order predictor misfired (should it be discovered that he should have an order).
2. Artificially forcing it back to 'I need to send and order in'.
3. With the flag on, I get a blank orders window, and the mesasge 'There are no forward targets in range'. This means that the predictor is in line with the orders window, so the predictor itself isn't the problem, if there is one. (It should be noted however, that you are offered the chance to drop an FF. From the looks of things though, there isn't a valid FF target, so that may be why the predictor didn't offer you up an order window on that account alone).
4. Now I need to manually step through your order window generation process to see what is going on w.r.t. if you should or shouldn't have an order.
5. Okay got to Sivar's Fist. Bearing to Sivar's Fist is 30deg exactly. This should be within the half-cone of a 60deg arc, a.k.a you're correct that you should be able to opportunity fire.
6. Aha. As I suspected, it got rejected on LOS basis. Well clearly that's a bug. Let's dive into that and see why.
7. Thinks we were on the same square due to an error in the length formula. Fixed.
Okay go ahead and submit your orders now!
In other news, i'd comment on the immelman thing, but Capi explained it correctly. As for the rules... well bring Ironduke in!
Also a big thanks and congrats to all you testers. WCTOO came in a (tied) 2nd place as Fan Project of the Year. You all deserve credit for all your help in finding bugs!
Last edited by a moderator:
On that note, a brief look ahead as you Game 5 people begin dropping off.
For the next 2-4 weeks I'm going to be insanely busy with more real work concerns. I'll still be here, and I should still have time to fix bugs, but it may take a 1-2 day delay like this last one did. At the end of that period, I intend to throw a full day or two's labour at this to finish off the End Phase Engine aspect of Flak Fire (a.k.a flak fire as a point defense). Once that is done, I'll launch Game 7, and possibly a Game 8. One of these games will be a medium-scale battle with 3 Capital-class ships and their fighter escorts. I'll launch another game at that same time if I feel we haven't sufficiently tested LOS or collisions yet. That second game would mostly likely be a true 'beta tester' game in that I'd only put 1-2 people in, and have them just run around smashing themselves into asteroids and trying to shoot past asteroids.
I'll post more on this plan in the future. In the meantime, keep dogfighting in Game 5.
I kicked it to process.
This is a bug where the predictor incorrectly counts how many orders need to go in, and makes the number one less than in reality. The system uses a <0 means we're already processed flag. The game itself always displays a '0' when we're less than 0. Example:
5 orders need to go in, but the hidden flag thinks there are only 4 needed.
3 players submit their orders. 1 player, still owns 2 ships, but the 'remaining orders' is at "1" since it started at 4.
This player submits both ships more or less at once (didn't refresh the page or go to index). We subtract 2 off of 1 and arrive at a 'remaining orders' of -1.
We skipped zero, and thus the turn wasn't processed.
I haven't found exactly why the predictor sometimes gets this wrong, but it is wrong most often going from CP into EP, and especially when a ship blows up. I need to keep looking though.
edit: in other news, it looks like the dumb fire was successfully point defenced!
While the system might be set up that way, at the moment I'm using the <0 flag to mean "has been processed". If I told it currently to process on any number <1 it would process every turn of every game every time... and that would be bad.
The real solution would be to add another variable to be stored, a 'has been processed' flag, that then gets flipped once processed. I was avoiding this for... esthetics, I guess, since I can't really argue that an additional database boolean is going to take a lot of space. Then we could go ahead with your solution. In truth though, when everthing is bug free and working properly, my 0=processed, <0=done system should also work without flaw.