Creating a computer-aided version of WCTO

Um.. weird; I could have sworn that I had told it to make a left turn... I'm actually going to roll back the last 2 turns and do it myself to see if it will actually turn left.

edit: oops, that was probably my fault. The durango is ordering a turn right as it hits the map edge; it can't recover in time without further rollbacks. At the end of the day, this is okay; I'll just spawn us a more interesting capital ship anyway.

That said, this off-the-map test was another good one; it shouldn't have crashed, it should have just reported a map excursion and kept going.

Unfortunately I need to go for a bit; I'm going to leave the game in the broken state, as this will force me, when I return, to fix the off-the-map issue we just had.
 
The error message sure doesn't sound like it, but what if it wasn't the off-the-map movement that caused the crash, but maybe two persons trying to issue orders at the same time?
 
Sorry, got a bit distracted with RL issues. Map excursions now work properly. They were doing all kinds of fun things, including exploding off the map, and having the explosion check for valid targets to chase with its guns...

Anyway, those things are all fixed now. I've also made the pop-ups go over top of the ships, as requested a fair while ago by you guys. Still on the mouse-over-on, mouse-out-of-box-off system, however.
 
Haha! Using flak cannons like standard weapons is fun. I completely totaled that Rapier.

Darn, I did kind of need some targets for the turrets on the Broadsword; I had wanted to do the turret work next. I guess I'll need to spawn something new.

edit: calling it a day; I'll work on the turrets tomorrow.
 
AMG hits aren't funny for fighters. Poor Jalkehi...! :p
Talking about funny: The second half of the Jalkehi's info text is off. First I thought it was because the info pop-up got moved upwards (being too close to the bottom border of the screen) and the text was not, but it stayed that way even when I moved the Jalkehi away from the border. :confused:

The Broadsword's explosion is still there in turn 89 (got destroyed in 77), which should be okay. I just hope it's not firing its guns at anyone. :D (Maybe you should start to log the funniest bugs during during development. :p)
 
Explosions have only 1 turn where they might think they have weapons, and that's the turn they are created.

I noticed the Jalkehi issues too; not sure what is going on, but I also noticed that both the Jalkehi and Ralatha aren't showing their pop-ups in red, which the code should automatically do. This may or may not be related. I'll clean it up down the road.
 
Fixed the bug preventing missiles from displaying; this has made it apparent that the missiles have been dropped in the wrong location. I've now fixed that bug for future missiles.

edit:
The pop-ups are being thrown off because the image recognition missiles with the x4 are wider than anticipated. This is an easy-to-fix CSS issue.
 
In between daytime commitments, I made some minor tweaks to the CSS. The popup mainframes are now wider, meaning we aren't getting the text pushed off. Additionally, I'm now 50% done adding turrets to the preengine; I just need to now link the new turret fields into the order submittor, and then also write a bunch of new jquery to have their controls work properly. Once that is done, we should be able to fire turrets. The infrastructure necessary for the turrets has also laid down some good opportunities for the AMG and PTC as well as the flak cannon. Well, the flak still needs a lot more custom code, but with only some minor tweaks I should be able to take the turret code and turn it into the AMG and PTC code.
 
Actually, the PTC should work exactly like a front-mounted gun. I just found out that this isn't in the manual, because I thought it was "common lore" in the WC universe, but I should definitely include this in future iterations. Speaking of the PTC, I guess we should even restrict it further by not allowing opportunity fire... Only intense play-testing will show if it's still outbalanced with all these drawbacks. (It might well be, but then again, unintentionally self-destructing your own dreadnought might be enough punishment as it is...)
 
Man, it took me way more work than I expected to make turrets work, but they do now, I think. I'll put in another broadsword so we can test side turrets, but nothing says they shouldn't also function.

I ended up hardcoding a lot of thing in, which is always bad; it means the entire structure is falling apart a bit. Given there is only a discrete number of weapons, though, that should be okay, but I'm dissapointed I couldn't find a way (without a major rebuild) to put it into a database-driven format.

That said, I also solved another half dozen bugs too numerous to list while working this through, and made some efficiency improvements to the target_list weapon function, the bearing calculation function (go modulus!) and had to re-write about 15% of the combat preengine (weapons now pass in their own targets instead of worrying about a centralized target system; this makes a whole lot more sense). That said, I'm a bit worried I didn't leave myself a good spot for LOS calculations. Weapons are currently working exclusively on range/bearing numbers, with no check for LOS obstructions. I had originally planned to actually path-walk weapons fire and check each square for LOS blocking, but that's completely not coded in right now. LOS was already going to be delayed, but I'm going to have to seriously rethink how I do this. I know I can do it, but I want to also handle it in a way that doesn't add a lot of unecessary looping (which will slow the preengines down).

At various times through this process, we had main weapons not firing forward, turrets only firing forward, and everything in between.

Time to let you guys do more breaking/testing.

Note: Cap ship weapons are still completely coded.

edit: hmm, looks like I'm not done yet, my ship wants to target the explosion...

edit2: easily fixed.
 
Noticed (especially in turn 110 for the Broadsword) that there's a "Turret (Aft)," "Turret (Starboard)" and a "Turret." Have to observe if there's any "Turret (Port)" at all... Everything else worked fine so far - fighter gun fire absorbed by phase shields, I launched another FF missile, fired at the first FF missile... Looking good!

One bug in turn 112, though: The Sabre shouldn't be able to target the Broadsword with its guns. I guess this is either an opportunity fire or a bearing issue. (The Broadsword is one hex too far off to the right to be eligible for opportunity fire. It should only work if the Broadsword was one hex ahead of its current position.)
 
I fixed the port turret issue; another minor typo.

Still working on the opportunity fire issue. I had to re-write the opportunity detection code; it is working properly now, but I need to un-list non-opportunity targets on the fly, and just need to work that out in jquery.
 
Okay, I believe opportunity fire is now working.

Barring building more cap-ship weapons, or dealing with LOS, I think the only things that need testing now are:

More opportunity fire testing.
IR missile firing.

In anticipation of this, I'm going to start working on the end_phase_engine, end_phase_preengine, and its order submittor. Hopefully we can round out phase 4 this weekend, but more likely mid-next-week.
 
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:

  1. The 'name' field is actually the model. Spaces are okay.
  2. 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
  3. race 0 = confed, 1 = kilrathi
  4. 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)
  5. 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.
 

Attachments

  • ship_templates2.pdf
    96.4 KB · Views: 120
  • ship_templates.pdf
    99.3 KB · Views: 135
  • ship_templates3.pdf
    99.2 KB · Views: 115
Rules Clarification: Point Defense

I should know this, but I can't remember, nor do I want to go back through the older turns at the moment from the manual WCTO games.

With point defense, are the missiles "within the firing arc" the ones in their initial position (i.e. as launched or whereever they are after multi-turn flight) the ones you can fire at with point defense, or is this giving you an opportunity to hit them as they fly in (meaning I'll have to track if a missile is passing within the firing arc of a ship as it comes through)? do we want to give pilots the opportunity to select which missile to fire at (if there is more than one) or should it be automatic (and in that case, based on what criteria for selection?)

edit: Hmm, using a manually worked out map of all possible missile movements, it appears like the maximum possible missile approach that goes through the front hex of a ship originates from a 60 degree cone at max range if the missile has a turn rate of 1, or a cone of 105 degrees if the missile has a turn rate greater than 2, and coming in from a strange angle (but the actual range between the missile and the target is half as far as the distance the missile travels).
 
If there are multiple incomming missiles, can they divide up the reserved fire among multiple of them, or are they all fired at 1 target? (The latter makes more sense to me, and is easier to code, but I can go any way).
 
Sorry, I'm performing tonight and just came on to check this thread. I'll answer all of your questions tomorrow after I've had a chance to "cool down" a bit! Hope that's okay, but I'm really busy today... :(
 
Just an update (since I've been silent for a number of hours) I sort-of finished the endphase pre-engine, but haven't built the actual engine or the submittor yet. Unfortunately, my time is about to get busy again, as I have a few real-life projects with upcomming due dates, and then a conference for the latter half of the week.
 
Opportunity fire still seems to be problematic - in turn 126, Tango 2 should be able to fire mass drivers at Bravo 1.
Now for the questions:

I'm with you on all of the rule clarifications for missiles. Which means you should also be right with the math part of things. We'll see if it actually works out in the game once the end phase is up for testing. ;)

As for point defense, I always used it as a last-ditch attempt to take down a missile on its way from its current position to the location of the target. This is why ships can get splash-damaged if they destroy the missile a bit too late, i.e. too close to the target. As far as game mechanics go, I'm sorry to say that this means you'd have to check all fire arcs along the path of the missile.
(If only the targeted craft used point defense, you could treat it as if the missile was one hex away from its target - but since other friendlies also have the chance to take down enemy missiles, you'd probably miss quite a few of those opportunities.)

I'll take a look at those charts soon, but I'm having another busy week as well, so it might take me until Friday or Saturday.

Also: Yay for front news update! :D
 
The charts are a low priority, and I also extend the invitation to look at them to everyone who is reading this forum.

Okay, so just to fully clarify on point defense: it is automatic, in that if you've reserved point defense, you'll attempt to shoot at *any* missile that crosses into your path until you've used up all your refires?

This does pose a small coding problem, in that I have to iterate through each ship, and then each ship goes through each missile... but let's build a scenario.

Ship A and Ship B both have refires reserved. There are Missiles 1 an Missiles 2 coming inward, both at Ship B. Ship A has opportunity chances on both missiles, but Ship B only on Missile 1, based on the angles. If I iterate through, let's say Ship A uses all its reserved fire on Missile 1, but successfully kills it. Ship B now cannot defend against Missile 2, and gets hit. In reality, had they coordinated, Ship A could have fired at Missile 2 and Ship B at missile 1, and then the odds of defense would go up...

Is this how you want it to play out? Can anyone suggest a better way to do automatic targetting?
 
You must log in or register to reply here.
Back
Top