As I progress through this design, I am starting to see a few spots where, once *everything* is working, we may want to consider a rebuild.
At the moment, most of the critical code is actually in the pre-engines, with the actual engines simply assuming only valid moves can come in. That would be fine, except that, based on the current code, the pre-engines are run pretty much every time someone clicks 'orders'. This is starting to add noticeable-fractions of a second delay, and I fear with the end-phase engine, where I need to do pathing of all the potential missiles that *could* hit a given target (to determine if you need to evade) this may become multi-second delay.
I can think of 2 ways to fix this, which should be addressed in order:
1. Currently, every time you click 'orders' it destroys the old orders window completely, replacing it with the current one. This is necessary because much of the html tags involved are using 'id's which must be unique. This can be fixed by appending incrementors to all the id's (and updating all the javascript). This would mean the older orders windows could be hidden, but not destroyed, in the background. This allows an interesting possibility: from the moment when the page first loads, at that time begin a silent ajax request to build all the orders windows; the second someone takes just looking around the map and mousing over the already-loaded data, we can probably do all the pre-processing we need. of course, if you click on 'orders' and your window isn't done, do it immediately, but most of the time, that shouldn't be the case. This doesn't actually add any speedup, but does some things in parallel.
2. Much later down the road, we should update the actual engines to build some form of 'preturn' data. Then have the pre-engines pull that preturn info out of a new database table. This would be a much more detail scenario, because it dumps most of the work where we expect it: on the actual engines that run very seldom, and it also means that we're now just doing database queries to determine available orders/incoming target/etc. Unfortunately, this is obvious with hindsight, but would require a complete rebuild of the preengine system, something I'm not even done yet and has already taken me 3 weeks, so I think I'll put it off for now until we at least have all the features in place.
-----------------------------
Second point, as we are approaching the eventual end of phase4, I do need help from everyone. Attached to this post are 3 pdf dumps of the database. because of the upload limits, I couldn't get it to fit any other way. I need volunteers to go through and determine where the errors are (if there are any). Most columns should be self evident, but I need to enumerate a few:
- The 'name' field is actually the model. Spaces are okay.
- fighters = bombers from the point of view of the game; frankly we probably have more divisons than we need, but I'm forseeing future issues
- race 0 = confed, 1 = kilrathi
- Weapons should be in the following format: weaponname,orientation,count,0| Where the last should always be 0 in the template, and orientations are 0:forward, and going up in a clockwise manner. (4 is all directions)
- At the moment fighers = 0 also means no hanger bay, this will likely change in a ship-component-damage model (which is a major recode anyway)
If you guys see any errors, please point them out.
---------------------
Finally, I'm having a hard time finding a good way to determine missile pathing. if anyone knows a good approach or algorithm, I'd appreciate it. At the moment, I'm looking at a potential target, calculating range, and then firing the missile through every possible speed/turn combination until it either hits the target, or can't. Clearly, this is a slow approach. Baring me not thinking of something obvious, the only information we have to work with is:
The position of the target, the position of the missile, and therefore the range and bearing between the two.
This also assumed a few rule clarifications:
1. Missiles of speed X can still only turn at the halfway point in their movement.
2. Missiles of speed X have infinite acceleration, and so can decide that their speed for the turn is any value less than their actual speed.
3. Missiles can hit their targets even if it isn't in the last cell along the path a given speed/turn combination produces, as long as it is along that path somewhere.
I believe these rule interpretations are within the spirit of the WCTO rulebook, and how it would have actually operated in Wing Commander. That said, if missiles can turn at *any* point in their movement (even if only once) that would actually turn the algorithm into one of simply counting out range radii, and putting the turn at the appropriate place; the exception being for shots that are hitting targets near the craft; this would also allow rediculous things like shooting at targets behind yourself with turn_rates >1... but an initial bearing check could fix that.