Jump to content
Rolling Thunder Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About jpd

  • Rank
  1. No, but I didn't lose the will to continue to play until the very end. The last game I played I had to struggle with the rail capacity until the very end, and that would not have been funny, at all, if I had to do that with the official order entry program. Same goes for the spending budget and the treasury contents. That would have become very ugly, very fast, if I hadn't been able to (let it) calculate the projected turn expenditure to see if it would exceed the treasury contents.
  2. Just realised I forgot to include a few, rather essential, details What I've build for myself is basically a one-stop-shop for both generating turn orders (like I said, I don't enter, not do I *want* to enter, any orders manually). This includes completely reading and parsing all of the tech/database files, the turn result file, and the turn orders file that's based on said turn result file. So I not only can produce a new turn file quickly, I can also update/edit it effortlessly. Because all the underlying data is at my disposal inside my application, I can do things like: - showing all provinces and sea zones bordering a selected province or zone, so when entering a route I basically just double click from border to border until the destination is reached - calculating the costs for new builds and repairs on-the-fly. I have no need to rely (or even look at) the AR/IR/AIR damage numbers inside the result file. - calculating the amount of damage an army group, air force or naval force dishes out on-the-fly (either before or after repairs or a reorg). No need to peek at the listed numbers in the result files. - do damage assessments (like: if I sustain 30% damage on this army group, how much AR/IR do I need to build to repair it next turn). This comes coupled with the AIC management matrix, so I can just issue all the repairs I want to do, then hit a button to provide for the needed AR/IR's, and instantly see in the matrix how much ARM points I need to transport to cover all that. - In said AIC management matrix, I see all my AIC-1 centers, and all of the resources. And I can initiate transports from one to another from within this same matrix using the predefined transport routes mentioned earlier. Basically, it's a one-stop-shop to handle my empires resources, where the goal is to get rid of the numbers flaring up in red - The program knows how much fuel and supplies all of the units combined burn each turn, and can line that up against the total production of both. So I don't run into nasty surprises when the time has come to do supply draws. - To prevent forgotten supply draws, the army and navy managers show each force in color code. The forces in red must draw supplies next turn, those in orange within two turns. - It knows how to calculate the costs for upgrades, so when I plan to upgrade units, the costs are automatically charged against the correct AIC hub, and thus being incorporated in the transport matrix overview. - The city/province browser can be sorted and filtered by numerous conditions, so I can quickly zoom in on those of particular interest Of course, the next step would be to use a bit of AI witchcraft, and automate the transport matrix, so it goes from a one-stop-shop to a one-button-push-shop Do I need to mention how much I hate micro managing an empire?
  3. Entirely correct. Ten years ago, I started out on the Excel route, but quickly abandoned it as too slow, and too cumbersome to help me in making turns. So I went a different route, and made my own turn "entry" program instead. Note here that entry here is marked in quotes as I don't actually enter a single game turn order in it. Instead, it shows me my empire in various lists and matrices, and in the UI I simply specify what I want to change. The program then spits out the necessary orders needed to make these changes happen directly into the turn file. But here's the catch: It auto-sequences the individual turn orders to my personal taste and preferences, which isn't exactly universally applicable What is does do, is constantly recalculating the known state of my empire with every adjustment I make. And this includes things like resource stockpiles (and, more of interest: shortfalls), used railway capacity, both on a city level and on a route level, next turn production projections, things like that. And, since I was fed up with manually entering a transport route through specifying the chain of cities each turn, I made support for predefined transport routes. So all I have left to do is select a target city (for outbound transport), or a source city (for inbound transport), and it fills out the MCR city chain automatically. I've even made a start in empire level functions. So I can add research orders for my entire empire with just one push of a button. Or auto-check and raise ADL/IMDL in my entire empire with just one push of a button. It removes the mind numbingly boring handling of empire management in the turn entry
  4. jpd

    game 93

    Windows RT is not Windows and will not run normal Windows programs. Well, technically it *is* Windows (same Microsoft source code base), but it's compiled for an ARM processor. Which is the standard processor of choice for any mobile gadget that's smarter than a wrist watch.As such, the only (app) code it can run is ARM based code, or stuff that's interpreted at run time (such as Java).The Victory order entry programs are all compiled for x86 (meaning an Intel 8086 or derivative processor), and thus can't run on a different type of CPU without some sort of emulation. And that's something Microsoft has not included in it's ARM based Windows-RT operating system. It's not that they could not do this (technically, it's possible), but they chose not to, in order to force any user wanting more apps than out-of-the-box present to go through the Microsoft APP store, and collect the 30% off the sale of each copy.
  5. Heh. Handling the versatility of orders like OMA and OMN is not difficult, not in an order entry program anyway. Just treat each variant as a separate, unique order in the front end, and let the order streaming code handle the reading and writing of all the variants. That's how I've solved it. That works both ways, actually. I'm treating all the different army move orders as a single order in the front end, which just has a few configurable parameters. The order streaming code knows which parameter combinations map on which specific movement order. And that's the point I'm trying to make here. The data format of the various orders, as stored in the turn file, is largely irrelevant. Unless, of course, players insist on entering that raw format directly. I'm in the group that doesn't like that, or do that. In fact, I haven't manually entered a single order since 2005. For most orders, I wouldn't even know what the exact syntax, parameters or variants are. I've looked at them once, coded and implemented the order streaming to handle it at that time, and since then just use my own front end to specify my orders.
  6. I respectfully disagree with that last assessment, being one who has learned around two dozen programming languages to date.Yes, if you've only ever learned one, number two will look daunting. But if you've learned a few already, you will have noticed that, basically, at the logic level, they're all pretty much the same. The biggest differences are always in the libraries that come with the language, but with the proliferation of Windows (and, to some extend, the Macintosh) that latter point has become moot. Because, ultimately, all the languages use the same OS API as platform library, and that remains the same. As for language to use. The current victory is most likely written in Pascal (which was, for a long time, the language of choice for Apple). Most Windows stuff to date is written in c/c++. Either of these would be a likely choice. I myself use a combination of the two. The VCL part is in pascal. My own code (which is on top of that) is in c++. As for complexity. Most of that resides in the order entry programs, as those need to be user (input) friendly. The game server is pretty much a batch oriented system. You have a database with the current game universe state. You have a turn file with a sequence of orders. Each order is processed, one order at a time. Each order can, or cannot be performed. And if it can be performed, it just alters the state of the game universe. That's about it, in a nutshell.An order entry program (well, mine anyway) has to deal with what/if scenario's, which means it needs to keep and retain multiple states concurrently. Which makes it a lot more complex. The real game server does not have such problems.
  7. jpd

    Game 87

    Not if they wish to survive until turn 73......the waters in and around Iceland, Great Britain and Ireland are so hotly contested and such a heated war zone right now, those ships probably wound't last very long. Our Navy and Air Force has standing orders to shoot first nowadays. As in : "If it floats, and doesn't say 'quack', sink it" ?
  8. That goes from the assumption that every single one that plays this game is using e-mail. It that's the case, then no problem. If not, then you're putting the players with the snail mail option at a disadvantage. Sort of like with good old DEC-War, where the players with access to a VT100 terminal could shoot the crap out of a player using a TTY terminal, before his initial empire status even had been printed ...
  9. On the other hand ... Random in a typical computer isn't random at all, *if* you have the code for the random number generator function (which isn't hard, as it's usually just the library routine that comes with the compiler), and the seed value that's used to start the number sequence. Heck, I've made encryption/decryption routines based on this very principle. Source and destination have the same random generator code, and the same encrypt/decrypt sequences. Encrypt the date, send it to the destination, and transmit the seed value used. With this, the receiver can decrypt the data. Short version: if Russ would hand you (or anyone else) the source code for the random generator and the battle code, then you have half of the key to accurately evaluate (aka predict) the outcome of any battle, thus eliminating the random factor you currently "enjoy"It's also the mechanism that Firaxis (for example) uses in Civilization to prevent different outcomes to happen after a save game reload.
  10. For now, I can think of only one (which is a bit of a pet peeve for me). Do away with the AR/IR separation for army unit repairs, and just repair them with ARM (like air force units). I can understand what the original motivation likely would have been to separate repairs into AR points and IR points (call it the 'hardware' and the 'software' if you will), but game mechanics wise they don't work like that. You create both the AR and the IR out of the same ARM points, so all you really are doing is this: - produce a resource - split said resource artificially into two components - bring both components in a certain mix back together for the repair orders I can fairly accurately calculate (more to the point: my computer can) how to split my ARM into AR and IR so there are no leftovers after the repair order has gone through, but it's cumbersome and really not necessary. Separation would only really make sense if IR's came from a different source as AR's, or the conversion from ARM to AR and IR would be in a different balance than the current 1 ARM = 1 IR and 1 ARM = 1 AR
  11. Heh, That's why I use a different approach to security. I use a software firewall with per-application TCP/IP authorisation, alongside a separate hardware firewall. Needless to say, Internet Explorer and Outlook are denied access to access the internet. I do use FireFox, and run it with AddBlock Plus and NoScript permanently active, and screening all URL's and links in each HTML page. E-mail is accessed through FireFox, and setup in such a way that only the standard, 7 bit ASCII message body ever reaches my end of the connection. That pretty much guarantees that any junk is kept out It also means that I can't read any email that has it's contents in word document formats or anything else fancy, but I have a very simple solution for that. I sent a reply with as body "If you want me to read what you wrote, send it as plain text"
  12. That ought to work. The software our company makes (which is an ERP package) is entirely based on this principle, where the entire data environment hooks in to the entire front end using the producer - consumer/viewer principle. A change in even one value on one record in one table triggers hundreds of cascaded updates, in dozens of forms concurrently. This includes refreshes in virtual list views (which includes on-the-fly recalculation of scroller sizes), refreshes in drop down lists in combo boxes, automated lookups in thesauri, on-the-fly recalculation of calculated fields and what not. There are even parts of the front end that trigger all of this updating on each key stroke the user makes. And all of this is near instant, hardly any delays noticable. But then again, our software is build on top of the Delphi VCL, and thus fully and natively compiled to pentium machine code.
  13. That's odd. Changing controls shouldn't really cause even a noticable delay. I have at least a dozen list views, literally dozens of edit boxes and a whole lot of check boxes, buttons and what not. All of those are constantly updated after each data entry, and that's after a full recalculation of the state of the nation. All of which happens near instant ....
  14. In any case, the speed is, of course, directly proportional to the amount of information you extract from the file. Right now, I'm grabbing everything but the battle reports. Loading time for for all of the vic data files (all the tech files and the province borders) is around half of a second. Loading a result file + turn file is near instant. The 60 seconds/2 seconds comparison was made on my old Athlon system. Current times come from my core 2 due. Don't have times for excel anymore. Don't even have that installed currently.
  15. Isn't VB (like FoxPro, or Java) compiling merely to an intermediate language, which is then interpreted by a runtime engine? sort of a virtual machine configuration.
  • Create New...