SpaceSimCentral

Ron wrote:
Now, is everybody with me? Or are you all just going to keep talking about needing fundamental changes but not doing anything about it? Because, honestly, a person could talk about this in theory until we all die of old age and nations start producing real starfighters, and never come to a conclusion ... I've seen this conversation before. If you want progress, we need to start making changes, systematically, until we narrow the problem down to something that's manageable.
Unless you find someone who is committed to helping you build and test stuff, then you're on your own. You will need to learn how to build and run Pioneer.I will accept patches around the combat system, but not without context. If you drop a patch that tweaks the weapon stats and you don't tell me how it fits into your broader plan, then I'm unlikely to take it because its not clear to me that it is an improvement overall.If you present a rough plan of attack (which I think you may have, but I prefer bullet points) so we know where you're going and how an individual patch fits in, then you have a better chance of getting something included. We need rough consensus about the model first though so if you're not able to see it through to completion, someone else can pick it up. There's too much stuff in Pioneer that has been left uncompleted with the original intent lost to history. As the maintainer, I will not add to that baggage.As noted, there are other things that need to be considered. Types of weaponry available, ship strengths, AI ability (both combat and script support), intercept mechanics, equipment/cargo models, and so on. I don't expect you to have the answers to all this stuff, but I need to see that you're thinking about it.All this is why right now you really need to be able to hack on the code. There's all these interlocking parts and you don't get a full picture unless you're in there. Yes, it sucks, but there it is. If you're expecting to come at this like a traditional game mod where all the foundational pieces are in place, you're out of luck - we're just not there yet.

I fully agree. I'm still trying to get the code to compile on my machine ... I keep thinking of stuff I haven't tried, try it, and that fails too ... it's getting to be a daily exercise in futility.You want bullet points. Works for me. Here goes... bullet points, not particularly in order unless otherwise stated:1. Shot speed. Set this first. Make it conform to some external standard, i.e. realistic ratio of target speed to weapon speed, or some slightly modified sci-fi classic variation of such. Fast enough to look like weapon fire, but not speed-of-light instant either. That, on its own, greatly improves the overall picture - at least it makes the combat look and feel like classic sci-fi movie space dogfights (which fits well with the rather retro-themed project, as well as everyone's expectations). By nailing this down, we eliminate one variable of the equation, and so make everything else easier to balance. (Not saying it can't ever be tweaked later, but it needs to be in the ballpark ... not like too slow by a factor of 8 to 10 like what we started with.)2. AI ... make it's hit ratio roughly the same as what a human with a mouse can get. Tweak to adjust difficulty. Once the shot speed is about where we want it, and reasonable-looking, the accuracy of the AI will determine if human players have a chance at all or not. This is probably some awfully complex code ... I doubt I can do anything with it, personally. But for now, it's just one adjustment - shot accuracy.... however that is calculated.3. Damage and rate of fire. This one is rather arbitrary - not only are we adjusting overall damage (relative to ship hull strength on smallish ships, for now), we can go higher rate of fire and lower damage, or more of a one-shot-kill model, somewhere in-between, or some of each. This will largely depend on personal taste and playability. I have no real preference here, and would figure to just try something and let everybody discuss how it feels. Again, with the shot speed nailed down, and fast enough to expect a reasonable hit ratio, it's just two variables to adjust (for any particular weapon).... so this can be done by trial and error, and/or popular opinion, from the feedback we get.4. Everything else last. Missiles, shield recharge rates, all those little tweaks that impact the overall playability, but are not core to the model. Once we have a playable baseline weapon fire model, these other tweaks will be natural progression. Some ships need to be stronger or weaker, whatever. They can be done whenever somebody thinks it needs a little tweak, months or years from now. Once you know how much damage direct-fire weapons do, you can use that as a baseline to calculate other stuff. A.I. for turret weapons, everything else ... you have something to base it off of.Now, I can do point 1 immediately. Already started ... just need to test it for feel, see if it needs to go up or down a little. I can make the adjustments for point 3, just as soon as we have some feedback. The AI, someone else is going to have to mess with ... but the feedback for the rest of this will also tell us which way it needs to be adjusted, so that shouldn't be a big deal if you understand the AI code (which I do not). It's basically just one adjustment for now, and that is accuracy of fire. Point 4 is for after everything else is working, and is only listed to make the point that this stuff is secondary and should be put off until the core model is good.Now if someone will just compile the blasted thing and post it (because, as stated, I can't get my system to cooperate, although I'm still trying), and a few other people will play a dogfight or two and give feedback, we can do half of this in a couple of days. Not sure what the AI will entail, but if those adjustments can be made with relative ease, we don't have to worry about how long anybody stays with the project ... it's a week of work, two tops, and combat is more-or-less playable. (Once combat is playable, it will be a lot easier to play-test the whole project, so everything else gets easier too.)How is that for bullet points?And since Microsoft C++ Express 2010 seems to hate me ... anybody have another software solution that will compile this thing? As I've said, I've done some game mods before, but I'm NO programmer ... so I'm willing to try just about anything, but somebody will have to talk me through it the first time. I mean, I would greatly prefer if this was simple ... I find it extremely frustrating to need somebody else to compile my changes.

Ron wrote:
And since Microsoft C++ Express 2010 seems to hate me ... anybody have another software solution that will compile this thing? As I've said, I've done some game mods before, but I'm NO programmer ... so I'm willing to try just about anything, but somebody will have to talk me through it the first time. I mean, I would greatly prefer if this was simple ... I find it extremely frustrating to need somebody else to compile my changes.
Well I have tried to walk you through the vs2010 but you balked at the few steps I posted to try and get the directories setup correctly.At the moment I thought you had it compiling (go to menus, "build" -> "build solution") but that it was running it that you had trouble with.

fluffyfreak wrote:


Ron wrote:
And since Microsoft C++ Express 2010 seems to hate me ... anybody have another software solution that will compile this thing? As I've said, I've done some game mods before, but I'm NO programmer ... so I'm willing to try just about anything, but somebody will have to talk me through it the first time. I mean, I would greatly prefer if this was simple ... I find it extremely frustrating to need somebody else to compile my changes.
Well I have tried to walk you through the vs2010 but you balked at the few steps I posted to try and get the directories setup correctly.At the moment I thought you had it compiling (go to menus, "build" -> "build solution") but that it was running it that you had trouble with.
OK! mi faccio una cultura, comincio a studiare basic e C++ Express 2010 ho scaricato Lua... cos'altro mi serve? non garantisco risultati..... però ci provo, spero in qualche suggerimento! sò creare siti web ma questa è altra cosa! Grazie thx OK! I do a culture, began to study basic and C + + Express 2010, I downloaded Lua ... what else do I need? I do not guarantee results ..... But I try, I'm hoping for some suggestions! I know to create websites but this is something else!

fluffyfreak wrote:
Well I have tried to walk you through the vs2010 but you balked at the few steps I posted to try and get the directories setup correctly.At the moment I thought you had it compiling (go to menus, "build" -> "build solution") but that it was running it that you had trouble with.
Yeah ... it builds, but then the newly built file won't run. (Setting up the directories as you initially described did get it to say it compiled ... for whatever good that did.) It crashes immediately with some bizarre error. And I've changed all the stuff you mentioned, two or three different ways (including installing 2008 to get that one file that was missing, and re-running it that way), and ... well, sometimes I can get it to give me a different fatal error. I didn't "balk" ... I just said that it didn't help. I tried it, no improvement on the initial problem ... the compiled file will not run. And it's not anything I changed ... I tried compiling the file with no changes on my part, same deal. Tried several versions of the code ... ditto. I can't explain it - it makes no sense.Maybe I didn't select my terms carefully enough ... "won't compile" and "says it compiled, but the file is garbage" are pretty much synonyms as far as I am concerned. I cannot turn the C++ code into a working .exe file. Since other people seem to be able to make it work, that means there is a fatal error in the process I am using to compile the code. By tweaking certain things, I can cause it to display different error messages, but I suspect this is generally more an issue of how Windows displays errors than a significant change in the situation (for example, if it is set to "debug" or "release" will produce different error messages, but the crash is the same). That's "I can't get it to compile", long version.And, needless to say, this is seriously holding up the show ... We all do kind of need to see the changes in play, to know what we're doing. At this point, I'm really thinking it would be easier if somebody else (who's running Windows... I know, some of you are running Linux or God-knows-what-else) would volunteer to compile the changes a few times and post the results somewhere, and that would probably cover everything that I can directly contribute. (Beyond adjusting a few numbers, I don't have the programming skill to do more than bug-hunt and make comments.) Then we wouldn't have to worry about the very real possibility that my antique box is a liability to any coding project. Messing with the computer has already taken more time and energy - both mine and other people's - than fixing the combat sequence in the game should.

I don't pretend to know anything specific about your compiler, but after you "set up the directories" are you quite sure that it wasn't putting your executable into a new location?You could always install Linux on your machine. It's way less complex than your description of MS Visual Studio sounds.

Ok that's more information, it is successfully compiled, linked and there is an exe built somewhere! So 2 things; what are the different error messages between Debug and Release and what OS are you running?Both my PCs are running Windows 7 and I have nothing else to test against so there might be something different that you're having trouble with because of the OS.Alternatively it could be s2odans suggestion about corrupt configuration/cache data that we output when Pioneer runs.Another possibility is that it's just not finding the correct DLLs or finally it's all a wonderful mystery that we can work out together Seriously the hard part is done, you have a compiler installed, the sourcecode has successfully compiled and produced an exe, this last step will just turn out to be a minor configuration issue or some crap data left lying around somewhere. That's nearly always the way with these things.Actually there should be three files produced by Pioneer when it runs called "stdout.txt", stderror.txt" and "opengl.txt". These should have been put into your "Documents/Pioneer" folder along with the cache/etc data that it creates. If you can attach those to your next post we might have more information to go on.Andy

Well, I found where it was compiling the program to ... so, yeah, it sent everything off to a directory of its choosing, but it wasn't hard to find. It wasn't hidden or anything.Since I have absolutely never tried to use Linux before, I somehow see this as a disaster waiting to happen ... particularly since this computer has more functions than just monkeying with code for games that are being developed. And I'm pretty sure the software involved in these other functions was not designed with Linux in mind. If I had a computer just sitting around with no other current function, I might be tempted to try that.I seriously get the feeling that Microsoft Visual C++ 2010 Express was expressly NOT designed with great consideration for projects that were being developed in multiple operating systems. There are probably tricks to get around these bugs, but you would need a really sharp C++ programmer with a lot of experience with the program to explain what all these little quirks are... and he would probably need to be sitting in front of the machine to work it out, not communicating in message fragments. Lacking that, it seems to be an uphill battle.Two days to fix the game ... six months to set up the machine ... typical.You said it worked in Linux, right? You have a working version with my first-round changes? At least post that version, so anybody running Linux can try it out and comment. It's a start. Then if somebody can compile and post a Windows version, that will cover the rest of us.Seriously ... if anybody can get this thing to compile a Windows version, just make the changes I give you and post it for testing - five minute job, about three or four times scattered over a couple of weeks, and we'll have it... at least close enough for this stage of development. It's a lot better than waiting for the gods of obsolete computer hardware to suddenly decide to smile on my machine ... that could take a while.

So.. what OS? what error messages? where was the exe created? and did you find those files I mentioned?:D

fluffyfreak wrote:
Ok that's more information, it is successfully compiled, linked and there is an exe built somewhere! So 2 things; what are the different error messages between Debug and Release and what OS are you running?Both my PCs are running Windows 7 and I have nothing else to test against so there might be something different that you're having trouble with because of the OS.Alternatively it could be s2odans suggestion about corrupt configuration/cache data that we output when Pioneer runs.Another possibility is that it's just not finding the correct DLLs or finally it's all a wonderful mystery that we can work out together Seriously the hard part is done, you have a compiler installed, the sourcecode has successfully compiled and produced an exe, this last step will just turn out to be a minor configuration issue or some crap data left lying around somewhere. That's nearly always the way with these things.Actually there should be three files produced by Pioneer when it runs called "stdout.txt", stderror.txt" and "opengl.txt". These should have been put into your "Documents/Pioneer" folder along with the cache/etc data that it creates. If you can attach those to your next post we might have more information to go on.Andy
Ah ... one possible issue, there ... I'm running XP. It's a long story ... some obsolete software I need to run, and I haven't had a chance to see if they ever built a Win.7 version for it.I'll look for those text files ... later ... first I'm going to have to get some sleep. (Not very coherent at the moment.)The difference in error message was that one gave some kind of memory address, while the "release" one gave the typical windows "The program encountered an error and was forced to close." useless line of nothing. As I said, how Windows handles error messages.But for now, how about you just pull this branch:https://github.com/RonLosey/pioneercompile it and see if it plays for you. If it does, post it for everybody else (myself included). Then we can worry about my daffy computer another time.

Ron wrote:
You said it worked in Linux, right? You have a working version with my first-round changes? At least post that version, so anybody running Linux can try it out and comment. It's a start. Then if somebody can compile and post a Windows version, that will cover the rest of us.
Mine would only work for users of 64 bit Linux, and we're in a distinct minority. Compiling for Linux is a complete doddle; I expect anybody interested in testing for Linux has already been building it for themselves.

Ron wrote:
But for now, how about you just pull this branch:https://github.com/RonLosey/pioneercompile it and see if it plays for you. If it does, post it for everybody else (myself included). Then we can worry about my daffy computer another time.
Compiles and runs just perfectly on my machine guess this must be an XP issue.

So put the compiled and working version into a .zip and post it somewhere, and problem solved ... we can all test the changes. Job done (instead of messing around for another week).

Ron wrote:
So put the compiled and working version into a .zip and post it somewhere, and problem solved ... we can all test the changes. Job done (instead of messing around for another week).
Uh, no, problem not solved. It's not at all likely that fluffyfreak's Win7 build is going to work on your XP operating system.In any case, making some changes, waiting for somebody else to make a build and upload it, and downloading it to test your changes is far from a viable workflow. If that isn't messing around, I don't know what is—if you have any experience with this stuff, you know that it's just simply not how programming gets done. Look, we all really want to help you compile the source so that you can start contributing to Pioneer, but there's a world of difference between helping you and doing every single thing for you. "Feed a man a fish," etc. I'm not sure if you're aware of how you're coming across, but to us it sounds like you think we have some kind of moral obligation to do all of this work for you because you have some ideas and want to mess with numbers. You are doing no favors to yourself with an attitude like that, whether it's intended or not. I personally can't help you (I run a Mac), but I suggest that since fluffyfreak seems willing to help you out for the moment, you listen to his advice and follow his instructions so that he can get you compiling the source yourself. Your computer is not some kind of special snowflake; if it's not doing what you want, there's a definite reason for it, nothing a little bit of sleuthing won't uncover. A couple of days' work to get the source compiling will pay off from the next day on, when you will be able to make changes and see their effect instantaneously and repeat the process any number of times. You will no longer have to wait a day for somebody to make a build so that you can test one change. So don't give up! Hope you find success soon.

Let's see:Stderr.txt reads: unknown token 'SOMEWHERE_SPACEPORT' at line 947 of 'data/lang/English.txt' That's the only thing in the file. Stdout.txt is blank. Opengl.txt is just a description of my video card driver. I believe these files were generated by Alpha 18, not the newly compiled but not running versions.WaveMotion:In general, I would agree with you ... for one, this computer is certainly not some "special snowflake" ... it's more in the "cowpie" category.But really ... If I was a programmer who intended to make a lot of changes on this thing, yes, I would absolutely have to get it working on my own machine. If my contributions are realistically limited to about four rounds of changes to a dozen different numbers, then we can make those changes and be done with it in less time than we can sort out my programming problems. And if, someday and by some miracle, I eventually get my computer to cooperate, fine ... but I say we shouldn't let that hold up the show. If we can have combat in the game running at a playable level within a week using a convoluted and inefficient workflow, or spend a year or a decade trying to get the work flow right ... which gives results? (I mean, it might make me feel like an idiot for not being able to get my stupid machine to work ... but heck with it, I can stand feeling like an idiot for a little while if it gets the job done.)I've already spent more time trying to get my system to work than it would take to fix the game, and other people here have already spent more time trying to talk me through it than it would take to work around my machine. I spent several hours today messing with it, and only became more frustrated. It's a black hole - effort goes in, nothing comes out. At some point, the whole concept of futility starts to sink in.If you're running Mac, pull that branch directory and compile it for Mac, and post it ... then you and everybody who uses Mac can check out the changes and comment. (I couldn't do that no matter how well my system might work. I just stare at Mac computers the way you might look at a moon rock.)Alpha 18 runs on Windows XP, 7, and who knows what else ... so it's reasonable to assume that a version properly compiled on Win 7 will run on XP. If not ... well, at least everyone using Win 7 will have a version to test.I'm not trying to be pushy, here ... but I think this is a great project and I would really like to see Alpha 19 to be 100% playable. Right now, Alpha 18 is all more-or-less working, but not playable due to the previously mentioned lack of work on the combat model. I can see the problem, and what needs to be done about it ... I'm just facing technical setbacks at making it happen.Even if I could get the thing to compile and run on my machine, other people still need to test it and give feedback - some of the decisions are arbitrary and need to be decided by everyone with a stake in the outcome (i.e. I'm not trying to take over the creative decision process - I didn't ask for that job). So it still has to be compiled for various operating systems, posted, downloaded and run by a number of people, and commented on. Fixing my workflow issues here would only take a few minutes off of this entire process, anyway.

Gentlemen! I shot the eagle!It 'just a matter of armaments.from the point of debugging, I docked at the space station, I sold the iperdrive, missiles and shields atmospheric, and lasers.I purchased the system for laser cooling, and double-pulse laser.Then the chase began, and I suffered little damage.you just run away, and wait for the lasers to become heated rivals. with some adequate shield and arms the game is wonderful!!

Ron wrote:
Stderr.txt reads: unknown token 'SOMEWHERE_SPACEPORT' at line 947 of 'data/lang/English.txt'
That's you trying a new build against Alpha 18 data. And this is exactly why replacement binaries don't work - the data versioning is intimately tied to the binary. The game will abort on startup with unknown tokens in English.txt, so you may very well have found your problem.You've been making a lot of assumptions about how Pioneer works internally. You should probably stop doing that.
Quote:
If we can have combat in the game running at a playable level within a week
We can't. As I've said repeatedly, its more complicated than tweaking a few numbers.
Quote:
If you're running Mac, pull that branch directory and compile it for Mac, and post it ... then you and everybody who uses Mac can check out the changes and comment.
I know of three people who use the Mac build. Two of them are developers that I speak to every single day. I'm sure there are more, but its not clear there's enough people in line to make it worth a 180MB download being produced.
Quote:
Alpha 18 runs on Windows XP, 7, and who knows what else ... so it's reasonable to assume that a version properly compiled on Win 7 will run on XP. If not ... well, at least everyone using Win 7 will have a version to test.
The Windows build of alpha 18 (and all alpha and nightly builds) was built on Linux using a build system specifically designed for the job. You might recall that I said MSVC is a second-class platform for PIoneer? That's what I meant. It probably can produce binaries for older versions of Windows. I wouldn't know. But don't assume you know how things work without either specifically asking or figuring it out by yourself.
Quote:
I would really like to see Alpha 19 to be 100% playable
You're kidding, right? There's at least 207 things wrong with Pioneer, and that's just the what's in the issue tracker. Almost every gameplay mechanic you see in the game right now is a placeholder - combat, crime, politics, economy, missions, UI, HUD. You name it, its probably not more than a hope of what's planned.I've already said this, but lets go through it in steps. So you make laser projectiles go faster by tweaking some numbers. Now you've got an autopilot that doesn't miss, because right now your only chance of survial is to dodge its shots, but you won't have time for that. Sorting that out is something that can't be just tweaked, due to the way the combat AI is currently written. There's only one person that actually understands the AI (jaj22, the original author) and he's both incredibly busy and not a big talker, so not much is going to change in the ship AI until someone takes the time to study it and understand it.Of course the AI isn't just about pointing and shooting. How do AI ships fire missiles? Do they use countermeasures? What about tactics? How should the AI respond and learn from the player's actions? What if its getting pummelled - does it run away or keep fighting? Oh, and we should also keep group tactics in mind - can AI ships operate in packs? Can the player get AI support?So lets say you get through all that sorted out, and you can have a good one-on-one shooting match. That's all well and good for the debug start point, but how are you actually finding combat situations? Did you know that there are pirates in almost every populated system you visit? Probably not, because you've never seen them. The ship AI simply has no idea how to intercept a moving target. These pirates will fly from their random spawn location to the place where you emerged from hyperspace. By the time they get there (typically days), you're long gone already.The problem of how to do intercepts is massive. Hours have been spent discussing and coming up with a plan to make it work in a way that makes sense. We think we're getting pretty close now; we're mostly just waiting for someone to find time for an implementation. Feel free to read more about it: Wiki topic: FTL JumpsOnce you get all this settled, you possibly have a reasonably good combat system. Unfortunately, combat is really just a mechanism for resolving disputes. We still have to think about the reasons that people are getting into fights. Boring old piracy? Revenge? Territorial disputes? Part of an epic military battle? And a hundred other things at least.Perhaps you think all this stuff is irrelevant. If so, then I strongly disagree. I don't yet know which parts of the above will end up being implemented in the end, but everything I've mentioned has been discussed positively in the past. There's been a lot more crazy ideas besides.To say that Pioneer right now is anything close to working is laughable.
Quote:
some of the decisions are arbitrary
Since about the middle of last year the dev team has placed a very strong emphasis on internal consistency. Every "arbitrary" decision has tried to be balanced against the rest of the game. I don't pretend we're getting it right, but we're trying hard and learning about the game we're creating. As I said earlier, if you're assuming a bunch of data tweaks will be included in the game without any consideration to the broader context (only partly outlined above), then you're dreaming.
Quote:
and need to be decided by everyone with a stake in the outcome
Pioneer operates as a meritocracy. That is, the people who work the hardest and prove themselves get the biggest say in what happens. That's why I keep saying that its up to you to drive this. Many people in this thread that have pushed back against you (off the top of my head, Brianetta, WaveMotion, fluffyfreak and s20dan) have put countless hours into Pioneer already and have done it the right way - worked with the other devs, experimented, tested, listened to and accepted feedback, and so on. If that many of the established dev team are telling you you're doing it wrong, chances are good that they're onto something. You should listen.If I sound like I don't want your input or don't think you have anything to offer, you're wrong. You're clearly passionate about this, and we need passionate people. So far though I feel like all we've seen from you is demands that others do the work for you and an unwillingness to listen. That's not a good use of my time and energy, no matter how good your ideas may be.That's the state of Pioneer right now. If your abilities are such that you can't do more than tweak data in tables, then you should wait a couple of years, as it will take at least that long before enough of the game core is stablised and exposed to scripts. If you want something to happen faster than this then I suggest you take the time to learn about your environment, your compiler and the Pioneer code. We would all be quite happy to help, but please remember that we're all volunteers choosing to spend our extremely limited spare time on this project. As an example of that, this message has taken two hours out of my evening to write, which is almost all of the time I have for Pioneer today. I was going to work on squashing a fairly important bug, which now isn't going to happen today. That's my choice, and I don't begrudge it, but you do need to recognise that this is not free.I've said enough. I hope you decide to get involved in Pioneer the right way. And if not, I wish you the best and hope you'll try Pioneer again in the future when hopefully its more to your liking.

Thanks. The explanation is clear! Now I understand the complexity, and because the game while being fabulous, still does not understand a lot of aspects of the frontier. Congratulations to all! As a player,,,, I will follow you step by step. although I would try to get started, you never know!

For the record, I said "playable", not "right" or "good". That is, with a combat dynamic that would allow the game to be tested as it is played, instead of purely having to set up tests. If it feels like you're playing the game, testing stuff is a lot more pleasant, even if you can't get far. It feels like progress. If the game is like you can only go until a combat sequence, and then it goes totally freaky with the sky full of neon sign parts and there being no way on earth to hit anything with a weapon ... well, that screws up the ability to play-test the whole thing. I didn't say I even thought Alpha 19 would be ready to call it a Beta version ... just that it would be "playable" in the sense that you could go for more than a few minutes without noticing that a major part of the game (in this case, the entire air combat thing) was inexplicable, bizarre, and humanly impossible to do.And your list of problems ... I gave the bullet-point list, by request, a few posts earlier, and said most of the same stuff. First nail down one thing, then move to the next. Start with something you can nail down as a starting point - in this case, making weapons fire look and feel like weapons fire. Then adjust from there. If you fix the projectile speed and rate of fire, and the AI comes out too hard ... that's a less serious problem than having "weapons" that look like somebody is launching neon sign fragments. Missiles are a relatively minor component, in the sense that unlike modern air war, they are likely not going to be the primary focus of the damage model ... so adjust them AFTER the primary guns are working. Fix things incrementally - start somewhere (preferably something that can be referenced to an outside source - in this case, real weapons and classic sci-fi sources), and build from a foundation.The alternative is to just say that a serious rework of the combat model is in order, but then either do nothing, or attempt to work out a six or seven variable formula all at once and confuse yourself. I know about this - I've done some game mods for other stuff, and have done this to myself and seen others do it before. It's bad - you create problems for yourself. I think that's how the current ("placeholder", as you put it) combat model came into being.I'm making some assumptions and stating some things I suspect ... but I try to preface it, as in "I suspect that x is going on." If the suspicion was wrong, well, that's why I prefaced the statement - to make sure that nobody thought I really knew for sure. But when bug-hunting, suspicions (and just outright guesses) are a lot of what you have to go on ... particularly when the bugs seem to make no sense. Assumptions like the thought that Win 7 programs will likely work on XP ... the only way to know for sure is to try, unless somebody knows for sure that it will not (and if so, a simple "I know for sure that this will not work" ... then we find some other way to deal with it).Yeah, it's a few uploads and downloads ... which is frustrating, I agree. Probably more so for me than most, as my internet connection is as shoddy as the rest of my hardware (and that download will take hours). But try it, and see. Because I think I can see the core of the problem here, and it's not as bad as it first seems ... like many computer games that simulate combat or other real-life activity (actual or imagined), the issue seems to be not the model, but the data that was plugged into it. If you plug one very bad number into a perfectly good spreadsheet, the whole thing comes out way off. This is true of games, or scientific or economic models designed to analyze or predict something, or anywhere else ... you make one bad data entry (like figuring that bullets move slower than aircraft) and the whole thing goes to heck. I can probably see this just because I haven't been on the project since the beginning, so I'm looking at it from a fresh perspective - but to me, the primary issue is glaring and the solution obvious.Compile it for yourself, and test it. Upload it so more people can test it (myself included, thanks to the now much discussed technical issues). If I'm wrong, and the whole game engine can't handle these numbers ... fine, that happens... no pressure to keep the changes. But if it's an improvement - hey, fixed your "combat is a placeholder and needs a major rework" issue, or at least made serious steps in that direction. All it costs is a couple of uploads ... which would be necessary to get everybody's input anyway. If I'm wrong, at least you know what doesn't work.So don't "believe" me ... try it and say what you think about the changes. Not what you think about my approach to the problem or the fact that I'm not really a programmer or that my computer system is a joke held together primarily by luck ... those things don't matter. Try the changes I made, and tell me what you think. Post them somewhere so other people (who are not compiling this for themselves either) can check it out too. Because it really doesn't matter what you think about me ... I'm not trying to get my name in the credits. Test the changes to the numbers, and see what it does, and comment on it (specifically what was changed, not hypothetically what might happen if this or that were also changed ... deal with those things later, unless they are issues that cripple the game engine or something). It takes less time than telling me that the situation is complicated, as everyone seems so eager to do ....

Ron wrote:
just that it would be "playable" in the sense that you could go for more than a few minutes without noticing that a major part of the game (in this case, the entire air combat thing) was inexplicable, bizarre, and humanly impossible to do.
Watch this. I assure you I am human.Also, that build was compiled on my computer with XP and VC++ 2010 Express.