vossiewulf

Looks like this was fixed by removing and re-instancing the mini-map and ship list during this sequence where the second ship info screen will overlay them. No clue what caused it but happy it has gone away, clearing me to release a new alpha version. I'm not sure you guys have given me any answers to these questions, but that's because I either figure them out or I solve it a different way. Bottom line is I come here with a problem and I leave with a solution and I'm good with that.

Not the ship list, no- it's 430 x 800 or so. I wasn't aware of that limitation, I'm not sure I understand that - do you mean total size covered or the size of the bitmapdata being tiled? Because my main map is 1k x 1k tiles, final size set by number of rows and columns in scenario file, and I've tested up to 20k x 20k successfully. Wait on this error - I think what I'm going to do is remove the minimap and the shiplist during the combat sequence and then reload them after we remove the ship info screens, I'm guessing that may solve the problem and is probably the smarter thing to do anyway. Let me try that, I'll post the results either way.

Am getting this in testing now: ArgumentError: Error #2015: Invalid BitmapData. at flash.display::BitmapData/ctor() at flash.display::BitmapData() at com.greensock::BlitMask/_captureTargetBitmap()[C:\Users\Vossie\Documents\Fex Line of Battle Project\trunk\line_of_battle\com\greensock\BlitMask.as:240] at com.greensock::BlitMask/update()[C:\Users\Vossie\Documents\Fex Line of Battle Project\trunk\line_of_battle\com\greensock\BlitMask.as:297] at com.greensock::BlitMask/set bitmapMode()[C:\Users\Vossie\Documents\Fex Line of Battle Project\trunk\line_of_battle\com\greensock\BlitMask.as:591] at com.greensock::BlitMask/set target()[C:\Users\Vossie\Documents\Fex Line of Battle Project\trunk\line_of_battle\com\greensock\BlitMask.as:660] at com.greensock::BlitMask()[C:\Users\Vossie\Documents\Fex Line of Battle Project\trunk\line_of_battle\com\greensock\BlitMask.as:189] at Function/LOB_Core/$construct/updateShipList()[C:\Users\Vossie\Documents\Fex Line of Battle Project\trunk\line_of_battle\LOB_Core.as:1562] at Function/LOB_Core/$construct/applyDamage()[C:\Users\Vossie\Documents\Fex Line of Battle Project\trunk\line_of_battle\LOB_Core.as:12942] at Function/LOB_Core/$construct/calcGunDamage()[C:\Users\Vossie\Documents\Fex Line of Battle Project\trunk\line_of_battle\LOB_Core.as:10895] at Function/LOB_Core/$construct/broadsideConfirmButtonHandler()[C:\Users\Vossie\Documents\Fex Line of Battle Project\trunk\line_of_battle\LOB_Core.as:6767] Cannot display source code at this location. First screenshot,below is where it happens, it's triggered by clicking on either the fire at rigging or fire at hull button. The second screenshot shows that the ship list BlitMask it's complaining about is behind the Spanish ship info screen at the time we get the error. Note that the minimap right above the ship list is also a GSAP BlitMask but whatever is happening causes no issues with the minimap. The strange thing is that it doesn't happen until somewhere after turn 6 but before turn 10, and the operation we're doing when it fails has been done dozens of times already successfully before this one fails. There's nothing unusual about the shots, the damage isn't crossing any thresholds that would send us down different paths, as far as I can see right now this click of the fire button is no different than all of the previous successful ones. EDIT - thinking about this more- you should see updateShipList() in the call stack - it's called every time during gun combat, after applyDamage(), for the obvious reason of updating the ship list display to reflect the damage. Looking at the ship hull damage, it's possible this shot is crossing a threshold that so that ship's hull damage will switch to three yellow squares from four green ones. The updateShipList() function always blows away the previous ship list and builds a new one from scratch, so I'm not sure why it would matter, but thinking about it in detail the ship list we're trying to draw this time is slightly different than all of the previous successful ones - this is the point in a scenario where for the first time those four green squares under each dam category in the ship list start shrinking in number and turning yellow orange red etc. Previous testing had involved forced values, this is first testing with those values changing real time in game. The result is the ship list dialog dies a horrible death, and even though the game itself doesn't crash it's going to throw null object reference errors until the game progresses to the next turn step and the shiplist is rebuilt. I don't have the slightest clue what the issue could be or what to do about it, other than possibly killing the minimap and shiplist dialogs while a gun combat sequence is active and we are displaying a ship info screen on the right. Do you have any suggestions?

This turned out to be another race condition, just a more subtle one; later after I call this tween I call the reposition function that moves the parent ship and then the turn switchboard, and later in the turn step transition code I was refreshing the minimap, and that would redraw the mini ships using the current locations of the parent ships, which hadn't changed before we redrew and blew away the object the tween was supposed to operate on. Only odd thing here, and the reason I had ruled that out, was that earlier I thought I had tested for that by setting the tween duration to zero. But even with it set at zero, I hit the minimap refresh even though there are 50 lines and an entire function between where I call the tween and where I refresh the map. I'm sure of the cause though, edit out the map refresh and it works fine.

Actually not sure that makes sense, I will look at this too.

Yeah, I should have mentioned I tried that to. When I include that after the problematic tween it always snaps to the correct rotation. So at the moment it looks like a TweenMax issue but it's so weird that that is a low confidence guess. Hmm well actually I tested it with integer values not the variable, that's worth a try, but I didn't use the variable because every time I've watched it the value is right. Oh also, I was wrong in the description - when a mini-ship fails to revert position a rotation is always involved, but they also do not move their x/y values either. They just stay where they were at the end of the turn phase, it's like TweenMax or something it invokes fails totally silently. That gets amusing during the movement playback sequence, because ships in this condition walk backward through their moves until they intercept a theoretical mini ship moving forward, and from that point move correctly in the playback sequence. Actually they're moving correctly always in the playback sequence, that walking backward weirdness is just what happens when the ship isn't where the code thinks it should be. When a rotation is not called for in the revert sequence, the mini-ships change their x/y correctly and revert to the beginning of turn position. The thing about it is its consistency, I'm testing with four different scenarios with differing numbers of ships and ship types and side involved etc, (it's supposed to be a realistic simulation) and it always works the way described above no matter if it's a 1v1 ship duel or a 30 ship per side fleet engagement. It's not intermittent in any way, 100% reproducible as long as I have a functional scenario file input.

No luck so far. I am not seeing what the difference is, only delta in the three calls is the delay and both values that we see in the three calls work, so that's not it. Otherwise it looks completely identical in the debugger even in the fail case - e.g., mini-ship rotation is 0, newMiniShipRotation is like -60, we go to tweenmax and the position of the mini-ship changes but the rotation doesn't. And then I watch the exact same values get passed in but called from a different source and the min-ship rotates. ConfusedDog.jpg

In hopes that by asking this question I will again see the blatantly obvious thing staring me in the face, I'm going to ask another question that has me for the moment stumped. In this game players plot movement of ships on screen, then hit a go button to move to next turn phase, when that occurs the ships are moved back to their original locations before the player moved them. After player 2 does the same, the movement sequence is then played back with a ship from one side making one move, then a ship from the other side makes one move, etc. until the sequence is complete. So there are 3 movement cases: 1. Player plotting movement for a single ship at a time. Call this the movement case. 2. All ships from one side simultaneously revert to beginning of turn positions. Call this the revert case. 3. Individual ships are moved by code when executing the movement playback sequence. Call this the playback case. All of that works fine for the "real" ships but I'm having a problem with the minimap, which is a dynamic representation of the main map with mini-ships that make the same movement as their big brothers, mostly in sync. The problem is that the mini-ships move correctly in the movement case and the playback case, but in the revert case they change their x/y position but seemingly ignore the rotation value of the tween. And the stumper is that all three cases are calling the exact same mini-ship movement function. Move case. WORKS: var newRotation:int = selectedShip.rotation + incrementRotation; var newX:int = selectedShip.x + incrementX; var newY:int = selectedShip.y + incrementY; miniMapContent.updateMiniShipLocation(selectedShip, newX, newY, newRotation, .15); Playback (playbackMode == true) case and revert case (same code, but (playbackMode != true). PLAYBACK WORKS, REVERT FAILS TO ROTATE //call one of two repositionShip functions depending on if we're in movement playback mode or ships are being reverted to original turn locations by revertShipLocations() //movement of ships during the movement plotting phases (by the players) are handled in the moveShip class if (playbackMode) { //update mini-ship location to match big brother. Last param is delay to sync with big brother on screen movement miniMapContent.updateMiniShipLocation(ship, newShipX, newShipY, newShipRotation, .8); //tween ship, update counter values repositionShipPlaybackMode(playbackMoveObj.ship, playbackMoveObj.newShipX, playbackMoveObj.newShipY, playbackMoveObj.newShipRotation, playbackMoveObj.shipRotationIncrement, playbackMoveObj.moveType); } else { //update mini-ship location to match big brother. Last param is delay to sync with big brother on screen movement miniMapContent.updateMiniShipLocation(ship, newShipX, newShipY, newShipRotation, .15); //tween ship, update counter values repositionShip(ship, moveType, newShipX, newShipY, newShipRotation, shipRotationIncrement); } As you can see, all are calling miniMapContent.updateMiniShipLocation(): public function updateMiniShipLocation(updateShip:Ship_1, newX:Number, newY:Number, newRotation:Number, tweenDelay):void { var newMiniShipX:Number = (newX * .20) - 3; var newMiniShipY:Number = newY * .20; var newMiniShipRotation:Number = newRotation; TweenMax.to(updateShip.miniShip, .4, {delay:tweenDelay, ease:Power4.easeOut, x:newMiniShipX, y:newMiniShipY, rotation:newMiniShipRotation}); } I've debugged it a dozen times and every time there's a rotation case, the newMiniShipRotation value is correct and is passed to TweenMax and that value is different than the current rotation value of updateShip.miniShip. But in the revert case, the mini-ship doesn't rotate to the passed-in value.

Yes, missing something called race condition. For some reason I thought the resetting of the properties and the duration of the tween on screen were separate. So never mind here.

This is what I seem to be seeing, and it's causing a bug, I start by moving a main playing piece (ship) on screen, resetting column/row/direction values as well that are used to track that playing piece's on screen location. TweenMax is then use to move the ship on screen, and it does exactly as expected. However, the x/y/rotation values that we just tweened that ship to aren't reflected in the tween objects' properties, which remain unchanged. Therefore when I pass that ship to a function that moves its miniature version on the mini map, the mini ship doesn't move anywhere. Only reason I haven't caught this before is there's a later step that explicitly resets x/y/rotation values based on the ship's column/row/direction properties. Here's my breakpoint in the debugger, showing we've just tweened x/y/rotation on selectedShip to newRotation, newX, and newY values. And as mentioned, the ship moves onscreen as if the x/y/rotation values have been updated. The disable/enable onStart and onComplete functions do just what they say, setting a boolean value false/true to disable keyboard/mouse input listeners while we move the ship on screen. However, as you can see the ship's Y value doesn't match newY - that's the only expected change for this move. So then I go to: miniMapContent.updateMiniShipLocation(selectedShip); This is where we update the minimap's version of this ship by updating its x/y/rotation values based on the supposedly-updated selectedShip's x/y/rotation values. But since those haven't changed, the mini ship doesn't move. Note that I just walked through a series of other places I use TweenMax to tween object location/rotation on screen and all of them work as expected, the tweened object's values change to match the on-screen motion, EXCEPT this one. Any idea why this is happening? Or am I missing something?

Bah still not correct. It's using the target's current top left x/y values as the reference point. I had forgotten I HAD moved the target vertically. miniMapOceanBackground.x = -424; miniMapOceanBackground.y = 15;

Explained a bit wrong above, the minimap frame is offset left but of course so is the ocean sprite, and that's the target. scrollRect's starting x and y values are registered from top left of the target sprite's current position - you can set whatever x/y values for the target you want, your mask will start from the target's current top left point. BlitMask, on the other hand, apparently registers from the origin point of the parent sprite and therefore needs to be offset if the target sprite has been offset. miniMapOceanBackground.scrollRect = new Rectangle(0,0,417,228); var miniMapBlitMask:BlitMask = new BlitMask(miniMapOceanBackground, -425, 15, 417, 228); //offset x by -8 and y by 15, it's reading from the parent sprite //both positioned identically on screen

...and yep, that's it - it was off screen to the right. If I give the blitMask call a negative starting x I can see it. Oddly though is that it looks offset vertically too, even though when I made the minimap frame register top right I didn't move it vertically, it's still at y = 0. Anyway, now that I can see it I can position it correctly. And I have to toss all the scrollRect code I got working last night to correctly scroll the minimap when mousing over map edge areas. It works, but doesn't look very good, very jerky, so no real loss. Flash mouseover is weird too, if I leave the mouse over a listening object I get three mouseover events and then nothing. Always. Makes continuous scrolling tricky. Thanks for the idea of turning the ocean off, that got me here. I understand about the support, that's why I first said I know it's gone, a personal project in a dying language doesn't require the instant support of someone working under a deadline.

Good idea about turning the ocean off, I did and I get the same result. Still tells us something, that the blitMask is clearly present and active, but it seems to be masking the target everywhere we can see. My first guess then is it's simply not where I want it to be. Is there any way you can think of for it to show where it thinks it is, like turning the mask opaque? I'll see what I can do to create a test version. Probably a reasonable chance I will figure out the problem in that process, I just thought I might be doing something obviously wrong that you would see. Going back to position, I think the area we want to see might be off the map to the right. The minmap outer frame movieclip is offset by its width to the left so it's registering top right corner to make it easier to handle screen resizing. Starting at 0,0 works for scrollRect, it still seems to register from current top left on the MC. Maybe blitMask is different? I'll try that too.

Fact that AS3 is going way of the dodo isn't relevant here, this is a personal project. Trying to use BlitMask and I must be doing something obviously wrong but not sure what, this is a simple stationary rectangle masking a much larger sprite. ScrollRect works fine, BlitMask doesn't although I get no errors. This is a minimap implementation, sits top right over the main map. I build a 20% scale version of the main map (all I've done so far is the ocean background, however) and then mask. public function getMiniMapContent(currMiniMap:LOB_MinimapShiplist_Frame, activeSide:int, scenarioData:Object, useOcean:Boolean) { //testing useOcean = true; var miniMapOceanBackground:Sprite = new Sprite(); miniMapOceanBackground.x = -424; miniMapOceanBackground.y = 15; //Ocean background. Match scenario ocean if (useOcean) { var miniMapOceanSource:LOB_Minimap_Oceans = new LOB_Minimap_Oceans(); miniMapOceanSource.gotoAndStop(scenarioData.oceanString); var oceanBitMapData:BitmapData = new BitmapData(miniMapOceanSource.width, miniMapOceanSource.height); oceanBitMapData.draw(miniMapOceanSource); //calculate map width and height from number of columns/rows specified in scenario file var mapWidth:int = Math.ceil(scenarioData.mapNumColumns * MAP_COLUMN_WIDTH * .20); var mapHeight:int = Math.ceil(((scenarioData.mapNumRows * MAP_ROW_HEIGHT) + MAP_ROW_INCREMENT) * .20); miniMapOceanBackground.graphics.beginBitmapFill(oceanBitMapData); miniMapOceanBackground.graphics.drawRect(0, 0, mapWidth, mapHeight); miniMapOceanBackground.graphics.endFill(); miniMapOceanBackground.buttonMode = false; } else { miniMapOceanBackground.graphics.beginFill(0x333333, 1); miniMapOceanBackground.graphics.drawRect(-1, -1, 417, 228) miniMapOceanBackground.graphics.endFill(); miniMapOceanBackground.alpha = .33; } currMiniMap.addChild(miniMapOceanBackground); //miniMapOceanBackground.cacheAsBitmap = true; //miniMapOceanBackground.scrollRect = new Rectangle(0,0,417,228); var miniMapBlitMask:BlitMask = new BlitMask(miniMapOceanBackground, 0, 0, 417, 228); //miniMapBlitMask.autoUpdate = true; //miniMapBlitMask.bitmapMode = true; } Screenshots, as you see when I toggle on the blitmask the minimap ocean background disappears. Again no errors, so it thinks it's doing the right thing, and I'm probably not telling it the right thing.