WCTOO: Phase 6

Avacar

Vice Admiral
Hi Everyone,

So it has been a while since my last big coding update, and I also know both Game 5 and Game 7 have been fairly stagnant.

That said, I did learn the lessons I needed to from those two games. Game 5 has pointed out a number of flaws with the UI in relation to large maps. I haven't found a fix yet, and I suspect some reworking of the way windows and positioning work will be needed to fix the Game 5 issues. As such, they're being shelved for now, to prioritize game functionality on 1-page maps and get toward a finished game.

Game 7 helped find and fix all kinds of bugs related to line of sight, flak, collisions, missiles, and I think was overall a success. There are probably still some lose ends, but overall I'd say the game is in a fairly playable state right now. One of the only gameplay features that I believe to still be missing is Friendly Fire, and before I can include that, I need to give the game the concept of teams. Teams, while useful, are a lower priority than letting you guys run your own games, though.

This brings us to Phase 6. Throw out all my old timelines and schedules; I've lost track of what was supposed to get done during the Alpha Phase 6. This is the new plan:

  1. Create a new overlay which allows "game managers" to edit ship stats on the fly, add new ships, delete ships, etc.
  2. Update the "game" database to include more information about who runs a game, who has permission like a manager for a game, etc.
  3. Update the user table to enable reverse game lookups, i.e. have games you're members of listed for you.
  4. Rebuild the front area to no longer be like the old WCTO page, but instead better reflect the fact that this is a dynamic site with updating games. Add features like "your games" "watch games" "create games" etc.
  5. Call for suggestions on the UI from users (all those ideas i've told you to hold on "until the future") and try to implement them.
While 2 through 5 are probably more important, they are a lot easier (in my mind) than 1. Part 1 will likely take the most time. I also cannot commit that I'm going to get through all this in a short period of time, like I did for most major code updates; this is likely going to be a slow and drawn out phase, based on my real-world commitments.

You can access Phase 6 through http://www.agespast.org/avacar/phase6/phase6.php. As with all new phases, you can continue to access Phase 5. They both read the same database, and both will process the games just fine. If more combat related code updates do come up, I may make those changes on the Phase 5, and then, once tested, port them up to Phase 6, as appropriate. That said, Phase 6 should be perfectly safe for playing and testing.

To start working on Phase 6 Part 1, I have adopted a new plugin, jeditable. This jquery plugin has solved most of the initial challenges with doing the edit-in-place concept for ship editing. At the moment, I haven't updated any of the permission layers, nor have I hardcoded it so only I can see the new features. This means that anyone on Phase 6 can "cheat" and edit ships. I've done this on purpose to both make testing easier, and to allow you guys to see the new feature and test it without hassle.

At the moment, you can edit ships in any turn, at any time, but realize that editing a ship in a past turn is useless and won't carry forward. I'll likely just make the current turn editable in the future.

The following features are already proven to be editable:
  1. ship name
  2. ship hp
  3. ship shield strength
  4. ship afterburner count (if the ship has an afterburner)
  5. ship speed
To edit any of the above, simply click on them on the popup window in Phase 6. At the moment, there is no indications that you can edit any of these fields, you "just need to know", but I plan to add either a tooltip or other reminder in the future to let people know they have editing powers.

My short term plans are to tackle missiles next. This actually brings up the first point where some feedback would be nice. I can do the missiles in one of two ways:
  1. In the case of "Dumb-Fire Missile x2" you could click on the 'x2' and a drop-down lets you pick how many missiles you want the ship to have. This has a problem, however. At the moment, when a ship runs out of a missile type, it simply drops it from the popup. To make this work, I'd have to add back in a "x0" to be clicked on for empty missile slots. This change would NOT be retroactive either, and would only apply to future turns.
  2. When you click anywhere in the "Missiles: " block, a side panel slides out, listing *all possible missiles* whether or not the ship can use them, with a counter beside each that can be set to any value. When you collapse this panel, the ammunition gets updated. This solves the problem of 1, as when you run out of missiles of a given type, it can still disappear from your list, but you're also able to add them back in. It has the additional advantage that you could equip missiles that shouldn't be on certain ships on them for specific scenarios. That might also be viewed as a disadvantage though...
I would have to say 1 is slightly easier to code than 2, but I could be wrong. 1 has a lot more 'behind the scenes' changes to make than 2, but is easier on the UI. 2 is a bigger UI change, but probably wouldn't impact the already-in-place missile firing code. Which would you prefer?

After I get missiles working, I'll try to tackle rotating ships, then moving/adding ships, then pilot associations, in that order.
 
Forgot to mention above that I also had chaff pods already working too.

I took about an hour today and also just got the PTC and AMG multi-turn counters to be editable with a click as well. Seems to work great. (Best demonstrated using Game 6).
 
Okay, I went with option 1 for missiles. Missiles will now list as x0 when empty, instead of dropping them. This will need some verification: I already know it works fine when I set the missiles to 0, but I need to verify that if we fire all our missiles empty, they will display as 0. This will also only work if the order to fire (and the processing of that order) is done using Phase 6, as I didn't make the change apply to the previous code branch.
 
I double-confirmed manually setting the missile count to zero works, but I dare not take over anyone's ship, so I left the ammunition-running-out test alone.
 
Ship rotation now works. You'll find rotation buttons available on all popups now. As always, this will eventually get hidden away again, and only be visible to "game managers/runners", but I've left it open for everyone to try, for now! Report bugs if you find them.

I pulled some creative commons licensed rotation symbols off the web to use, but they don't really fit in with the current motif. If anyone reading this has art skills and wants to provide some improved rotation icons that fit the scheme better (you could even offer Confed and Kilrathi versions...) I'd be more than happy to put your icons into the game!

As a suggestion for the future, I'd ultimately love for the rotation symbols to actually be on the map and appear on hover, but I think that's best left for a far future update after I've reworked the position system. For now, putting them inside the popups was easy, and a no-brainer as far as modifying existing code.
 
The arrows don't look that bad and the colours don't clash too badly with the red and blue. But certainly, if someone submits something nicer, it's probably worth making the switch.

The new code seems to work well - I just have a concern about possible over-flow, but as you say, it's not meant to be for regular users. I'm looking at Iron Duke's Left Claw and Right Claw ship pop-ups, as an example of the constrained space issue.
 
Good point and an excellent catch; those names were "long" I suppose, and definitely caused the overflow. At the moment they are positioned statically; I could switch them to relative, and put them on the bottom-right corner of the popup. Can you think of an example where this will interfere? The only thing I think it might overflow into at the moment, could be the 'orders' button in some cases. The 2nd column of data in the window doesn't usually change in length (whereas the left column is different ship-to-ship based on armament).
 
Bottom-right might be a better place for the time being. Again, I don't think it's worth worrying too much about if it's something regular users won't have access to.
 
I've moved the rotator icons to the bottom right, as discussed.

I've also made a first cut at moving ships and objects. I haven't tested it too far yet. You simply drag an icon and it will be dropped. There are a number of known issues:

  1. The tile in which the ship drops is under the cursor, NOT under the ship. This is especially problematic with capital ships. I haven't come up with a good workaround because I can't find a way to have functional a-priori knowledge of the width and height of the div within the scope I need (despite having it one scope level higher). To compensate, I've changed the cursor to a crosshair, so this should make it more obvious to focus on the mouse, and set the offset to a constant, but arbitrary 20 by 20 px into the icon. This seems to "cut the difference" on most fighters/bombers, but will be a problem on capital ships and stations
  2. After moving a ship, all jquery seems to become unbound. It will not open the popup, won't show its dogtag, and it can't be moved again. Reloading the page fixes the issues (as the jquery gets rebound). My initial thoughts were to use the jquery .on() function to bind on the events, but I am not very familiar with it and despite using it as listed in its help file, the events don't seem to be binding to the future inserted instances of the new icons within the context of the same page load.
  3. Indicators will not play nice with piles. At the moment, if you drop an indicator on another, it'll just supersede it until a reload. Upon reload, it should join the pile indicator. Additionally, the old pile will still be confused as to the existence of the previous position of the icon. This problem is more solvable, and I've roughed in some of the code to fix it (although it'll involve twisting my head around the issue again since those selectmenus are a pain to work with). I was aware of this problem before I was aware of problem 2, however I believe this is a moot issue as problem 2 will also apply to problem 3: i.e. even if I did re-write the code to do on-the-fly regeneration of the piles and have the icon put into a new pile (or removed from an old one) if the click/mouseover events aren't being properly re-bound, there isn't much point anyway as a page load solves both issues.

Problem 1 is going to be accepted as-is, and left for some nebulous future fix, I think, unless someone has a good suggestion. Problem 2 is an issue that I'm not pleased with, and I'll need to do more reading/research to address it. Problem 3 may be a bit of a pain, if more straightforward than 2, and I may leave it as a down the road polish update.

There are a number of customizable options we can mess with, so opinions are always welcome. For instance, at the moment, I have any open popups also-close temporarily while dragging, and then auto-open again after. Do people like this? There is also a minimum drag distance to trigger the move, currently set to 50px. Is this too long/too short? Finally, I have the ship on the cursor set to 70% opacity; should it be more or less opaque?

Feel free to mess around, and any feedback is appreciated.
 
I noticed the scripting seeming to stop after moving a ship. I'm treating this as an experimental feature - which it obviously is - so I'm not too concerned about this at the moment.

Dropping the pop-up while moving the ship is a good idea - the pop-up may be covering the spot you're wanting to move to. Am I right in thinking that it's only possible to move ships when the pop-up is active? Because I don't think I can just move ships as-is. The opacity while dragging seems fine, it's not too intrusive but still useful. I'm just wondering about what's the best drag-distance-to-trigger-move setting - if one is just intending to move to an adjacent cell, it almost seems as though you have to move beyond that to trigger the move. But too short a distance may not allow filtering of accidental drags. I haven't checked what the distance is between cells, but at the moment, I'm thinking it could be worth trying a more sensitive trigger.
 
I noticed the scripting seeming to stop after moving a ship. I'm treating this as an experimental feature - which it obviously is - so I'm not too concerned about this at the moment.
Yeah, this is "problem 2" above in action. The other ships' scripts should still be working though.

Am I right in thinking that it's only possible to move ships when the pop-up is active? Because I don't think I can just move ships as-is.
Actually, you can (read: should) be able to move the ship with the popup closed. If not, let me know, because I am able to.

I'm just wondering about what's the best drag-distance-to-trigger-move setting - if one is just intending to move to an adjacent cell, it almost seems as though you have to move beyond that to trigger the move. But too short a distance may not allow filtering of accidental drags. I haven't checked what the distance is between cells, but at the moment, I'm thinking it could be worth trying a more sensitive trigger.
The current inter-cel fudge factor I've got hardcoded all over the place (I really need to centralize it) is ~42px by 49px. I had set the initial drag length to 50px. I've dropped it to 40px. Does that feel better? (to Wedge specifically: if you want to adjust it yourself and see how this number affects things, you can find it on line 20 of ship_popup.js)
 
Actually, you can (read: should) be able to move the ship with the popup closed. If not, let me know, because I am able to.
Okay, double-checked this one: yes, I can move without having the pop-up open.

I've dropped it to 40px. Does that feel better?
Not sure if I notice any difference, but it's probably good enough. I accidentally move an explosion and noticed it came up with an error message, although a reload will produce the right result. Moving asteroids does the same thing - presumably any non-ship object, but not sure about missiles.
 
Not sure if I notice any difference, but it's probably good enough. I accidentally move an explosion and noticed it came up with an error message, although a reload will produce the right result. Moving asteroids does the same thing - presumably any non-ship object, but not sure about missiles.
Hmm, interesting. While I'm not too worried about explosions, asteroids are definitely something we'd want game makers/managers to move around when setting up. Among other changes I had to put in when I added the movement of ships, is that I changed all the icon tags from #ship_<databaseid> to #<object class>_<database_id>. In the past, even asteroids were contained in <spans> that had id='ship_<id>'. Now they would be in ones labelled id='environmental_<id>'. This helped me address issues with moving asteroids that didn't have popups, etc., but it may have introduced a few new bugs. Also, the way this was introduced, it will retroactively apply to all webpages that are generated on the fly; we may see things misbehaving during order-giving now in currently live test games.

Making sure we can move non-ships correctly will be what I work on next; this is even more important than fixing the "Problem 2" lack of scripts attaching after move.
 
I had 15 minutes today, so I fixed that error message for non-ship objects. I've confirmed it works for ships, flak fire, and asteroids. I haven't explicitly checked an explosion, but it should work. Missiles are another question; but I think they'll be fine, since they're pretty close to ships.

I had to update the database to create compliance for environmentals. There is a risk that while I updated the code, I didn't correctly set up the future entries; i.e. we might find that future flak and/or asteroids won't work, but the current ones do. This is a small risk though, as I was looking for this particular problem and tried to address it where I could.
 
Back
Top