wdolson
Posts: 10398
Joined: 6/28/2006
From: Near Portland, OR
Status: offline
|
quote:
Original: Don
That, of course, would require a check based on specific base numbers. We are trying to reduce this, not add new instances.
Naval units that need refueling will search for the closest port of sufficient size that has enough fuel. If tanks are dry everywhere closer, it will indeed route to the ends of the earth (er, map).
It is obvious that such a long refuel detour is foolish, but it is not obvious what kind of generalized check would prevent it. And, if such a check were used and fired, what would be done instead. Then, of course, what would be the other ramifications?? Would the forum fill up with "Why won't my convoys sail??".
Sorry to end this one in mid-discussion, but I need to get on the road.
quote:
ORIGINAL: Snowman999
I wondered why I never get this behavior on a SF westbound auto-convoy (never goes to Karachi and doubles back.) Lots of fuel in the interim bases.
I'm not the programer you, and some others here are, but maybe a hack-solution would work to fix the most egregious auto-convoy behavior. Could you just put in an x-value (longitude) east of which a Karachi auto-convoy will not go? Make it west enough that any size or type cargo ship can make it if it's full at Karachi, and if escorts run dry on the trip that's tough and they finish at hex-a-day. It would cause some other problems, and probably gripes, but as it is now auto-convoy from Karachi is useless as early-war convoys merrily drive through the Marshalls or past Wake on their way to Pearl . . . and come back again if they survive the first trip. Auto-convoys from SF work to save a lot of clicks, but it would be nice if the other side were useful too.
I hate hacks. Ultimately, something will change in the code down the line and everything will go haywire because the future programmer didn't know about the hack.
I think this behavior could be fixed by just doing an extra check when deciding to refuel. If the proposed base is further away from home than the current location, return home instead, even if it means running out of fuel on the way back.
Ever since this discussion about this problem started, I've been brainstorming solutions. Though I have no idea if any of them will work because I don't have access to the code. I have heard rumors the existing code is spaghetti code, which means who knows what will work.
When code is a mess, all sorts of bizarre things can happen. One time I was on a team that was trying to add a lot of functionality to a major mess that we were handed.
We were getting an alpha test version ready for a trade show and one programmer added a few minor things and moved a bit of code to another module where it made more sense. The whole thing blew up and wouldn't work. I volunteered to stay late and figure out what went wrong. I took the latest changes out one by one and found that the code that was moved from one module to another was the culprit. I moved it back to it's original location, added all the other changes back in and everything worked. I put a huge comment there that basically said, "I know it looks dumb for this to be here, but if you move it, the whole system crashes."
If I had more time, I would have figured out why. There was probably a blown pointer* in there somewhere that was scribbling data somewhere non-critical before, but overwrote something important when moved. Those can be the toughest things to find. When code is sprawled all over the place without good structure, they become more common.
Some of the weird random things WitP does may be due to blown pointers. The behavior looks like it could be to me. Before you throw stones at Matrix and 2X3, Microsoft is more guilty of it than most companies. They have become better in recent years, but some of their old legacy code is so byzantine that nobody is willing to touch it. I heard there were plans to completely rewrite both Windows and MS Word from scratch in the last 10 years, but they gave up on both projects because they realized some of the code was so convoluted, nobody was willing (or possibly able) to decipher it.
For years Microsoft hired a lot of brilliant, but very young programmers. They could produce quite a bit in amazingly short schedules, but these people had little experience with large program development. They were used to hacking something together that worked OK. The old veterans who have been bitten by old code coming back to haunt them tend to learn and become more careful and not paint themselves into corners. Microsoft has more vets from the trenches now, but 10+ years ago, there were few gray hairs to be found on the MS campus.
Some of the features that should work like auto convoy and task force plotting are probably rat's nests of code that were never fully debugged (not necessarily blown pointers though). They don't crash the program, so they are largely left alone. It would probably take someone some time to figure out just what those portions of the program are doing now. As with most businesses, time is money. They are applying their development dollars into areas that can be fixed within the existing budget. People need to buy more games so they can expand the budget. 
Bill
*A pointer in the code that is supposed to point one place (like into one of the tables in the database for example), but points somewhere else the programmer didn't intend. If the somewhere else is non-critical, the program will work fine. If it points to someplace noticiable, it can cause weird behavior. If it points to something critical the program can crash. Sometimes these problems go from minor to major when code is changed because where the pointer is pointing can suddenly become something critical.
_____________________________
WitP AE - Test team lead, programmer  |
Printable Version
RE: I like pacwar. Should I pick this one up? - 
Excelent point
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread