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?

😀

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/pioneer

compile 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.

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.

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).

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!! 😆

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.

We can't. As I've said repeatedly, its more complicated than tweaking a few numbers.

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.

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.

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 Jumps

Once 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.

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.

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 ....

Watch this. I assure you I am human.

Also, that build was compiled on my computer with XP and VC++ 2010 Express.

Ron.

It's not just the executable. Rob's already flat-out told you why yours isn't working - you're using a different version of the data files. If we upload an executable especially for you, it still won't work unless you're also prepared to update your data files.

You have everything you need, in terms of compiler and build environment. You just need to make sure that everything you have from Pioneer is from the same version.

[/hr]

Oh, and I've been resisting until now, but for the record: The future of real life space combat almost certainly lies in missiles, because they're the only weapon which won't exert a reactive force on the vehicle that launches it (it uses its own reactive motor), and because a half-decent missile can correct its course en route over the thousands of kilometres that routinely separate vehicles in space. Don't play the realism card while looking for a dogfight. You need to put your case forward on the grounds of playability, rather than realism.

Quoted in agreement.

As I've stated before in IRC, people who say they want a fighter plane-style dogfight in space don't really understand the fact that aircraft dogfights in atmosphere are the way they are because the direction you're moving, the direction you're facing, and the direction you can fire bullets are all the same. This is why it's useful to do maneuvers like getting a line of fire on your enemy from behind. In space this is pointless because your enemy can just turn around on the spot without having to change their velocity, or better yet just keep their gun pointed at you at all times. If you really want to play laser dogfights in space, you are looking for games with simplified, non-Newtonian ship physics, such as Oolite.

https://github.com/fluffyfreak/pioneer/downloads

There's the downloads, the two with your name on are the full repository, or alternatively just the exe and dlls... the filenames and sizes are a dead give away as to which is which. You'll just need the exe one and extract it into the same folder as the "/data/" directory.

Now then, when you run that and it fails please - find the folder with those stdout.txt and stderr.txt files in it - there should be another folder called "model_cache", delete the folder "model_cache", not one like it, but that exact name only.

If you've got old data, and it looks like you do, then you need to get rid of that old data before anything is going to work.

Pioneer is "Alpha" stage software, it's only available for people to use at all because it's open source and both the content and format of the data changes regularly so old/newer data won't work with different versions.

That appears to be the cause of your issues.

Andy

Andy: Thanks. Good one - it runs perfectly on my system.

OK, my immediate take ... I got them just a little too fast. Probably realistic for any such future weapon that might utilize such technology (assuming anyone develops high-energy particle weapons, instead of concentrating on focused beams as all modern indications would direct), but faster than what classic sci-fi portrays, and so a little faster than what most people will expect. Still, it at least looks like weapons fire now ... so I figure I got them a little too fast, not a whole lot. Changes to rate of fire, also ... it needed to be a little faster, but I might have overdone it by just a bit. I'm not surprised by this ... it was a first guess, after all.

As for the AI, I was having little trouble maneuvering against it. It's not like the AI never misses, as we feared. I lost, but I lost before too, so that doesn't prove anything (except that I'm not 100% familiar with the controls). The fight kind of felt to be at long range ... not sure if this is a product of the weapons code, or just how the display is configured. (While that might be reasonable, it cuts into "playable" by a bit.) Might want to shorten the range on the guns by a bit, just so you can see your enemy better, for no other reason than just because people think you should. (Which number in those settings is the range? I'll try dropping it by a bit just to see how that feels.) Still, indications are that the combat AI is working just fine, and the fears of it going haywire with the new data seem totally ungrounded. That's good news ... one hypothetical problem nullified by just testing it.

Damage? I have no real opinion at this point. Think I would have to play the game for a while to really have much data on weapon balance, i.e. see how different weapons hold up against various ship types and shield levels. The little fighter took quite a few hits, but it was from a small weapon, so not a surprise.

As for "realism" ... considering the results of modern prototype systems at destroying aircraft, missiles, and even incoming shells with focused lasers controlled entirely by radar, I would really expect completely automated beam-weapon systems to be key to actual space combat. For 20 or 30 kilowatts and 500 pounds of hardware (and effectively zero recoil), you can render missiles or any other solid object a zero threat ... and that's with today's technology, and inside Earth's atmosphere. A couple of megawatts more, you can tear up ships with pretty much the same hardware. That doesn't make a game - there's nothing to play. So we don't want "realism" - we want "reasonable expectations". We want everybody to think "space dogfight", not "what the heck?" So it has to be realistic enough to create suspension of disbelief, but not so real as to take the "WW1 flying ace" feel out of piloting the ship. That's not like a major decision about the creative process - that's just good old-fashioned literary analysis of a work of science-fiction. How exactly to go about doing that, well, that's what this is about.

That's my first take on the results. (Needless to say, I have no problem being critical of my own work, so I don't mind if you all are nit-picky as well. As long as you're critical of the work, and not just complaining that I'm a whining misfit. I know I'm a whining misfit - but I'm a misfit that does something, instead of just talking about it.) What does everybody else think? Agree with my assessment, or disagree? Any points I missed?

If you get me started on space realism, I'll bite... and I'll bite hard, and eat holes in your arguments. It's one of my favourite hobbies.

Lasers are great, but ineffective over hundreds of kilometres. Diffusion is going to be an issue; the inverse square law is going to hurt you hard, because you can't get a perfectly parallel beam. A target twice as far away has your beam spread over four times the hull area. Three times further, and it's spread over nine times the area. Distance is the enemy of beam weapons.

You can't just ramp up the energy levels, either. If you're using megawatts of energy, that means you're converting megawatts of stored energy into megawatts of heat - and don't pretend that your perfectly efficient laser will discharge all of that into a beam, because lasers can't work at 100% efficiency. Your weapon platform is going to get hot. Very hot. Losing heat is the biggest engineering challenge in space. An atmosphere can provide very efficient convective cooling. In space, you're going to have to either radiate your heat away, or heat some mass up and discard it. The latter isn't easy, because you don't have unlimited mass to throw away; normally, we call that stuff propellant, and like to use it for manoeuvring, and it's precious.

So, you're going to have to radiate megawatts of heat into space. You're going to glow. You're going to have a fairly hard time not melting.

Like I said, don't play the realism card. Present your arguments as benefits to gameplay. That way, you won't distract me and derail the thread. (-:

Right on, Commander! 😎

Realistic or not, this thing's gonna fly! 😀

As for modern laser technology, the new systems are not a single laser - they're using mirrors that can be re-shaped on-the-fly, so that the beam is focused exactly at the target point. Like killing ants with a magnifying glass, if you could control the focus angle and put the hot spot at whatever range you want it. That way, the thing is only moderately warm at the source (i.e. not burning up the weapon itself, even running huge volumes of power through it), but where it hits the target, it can be focused as tight as desired (even a hundred miles or more out, and through atmosphere). U.S. military has been testing these things significantly, including a few field tests now - they're deploy-able, today - and most other major countries have at least been suspected of developing similar systems (although most of them have done a better job of keeping their secret weapons projects a secret). This has been a game-changer in terms of weaponizing directed-energy weapons ... just a few years ago, lasers were fine as industrial cutting torches or pointing devices, but the thought was that they could never really be weaponized (and I certainly thought so too) ... now it's looking like they're going to make long-range projectile weapons and missiles obsolete (by simply shooting down the projectiles and/or launching platform before they reach the target). This has been a pretty big rhetorical change among those who try to predict the future of technology - nobody really saw this one coming (probably because the current systems that re-shape the reflecting mirrors are so darn complicated - just a few years ago, they didn't even have a computer that could handle the job).

One thing history teaches us is that predictions based on what we know now are usually thrown off by some major change that we didn't see coming. Lasers that focus wherever you want them to - that's just one example. If, say, somebody develops a superconductor that can be used as armor, and all energy-based weapons would be immediately obsolete and we would be 100% back to bullets. An energy field that will bend light efficiently, and space war suddenly would be all about stealth. (This too has been tested but is currently not efficient.) Which thing like this will happen first is just anybody's guess. (Fiction writers generally just make a guess on this, and then see where it leads them.)

But back to the point ... realistically, future tech tends to be going toward more automated systems (apparently combined with speed-of-light directed energy weapons). That's no good for a game - my ship computer engages his ship computer, to see who has the most laser power and/or the thickest hull. So we can't use actual realism as it is anticipated to develop over the next few years ... it's what you would call "unplayable". What we want, from the perspective of science-fiction, is "suspension of disbelief" ... it has to look reasonable enough that people will think "space dogfight", not "what the heck is this?" For that, we need not "realism", but the perception of realism ... that is, weapons fire needs to look like what people think weapons fire should look like, based on their knowledge of bullets here on earth plus what they have seen in other works of fiction. Same way space ships need to look like sleek fighters (while it would be more efficient to use a lot of bulk freighters that were never intended to enter an atmosphere - re-entry and atmospheric flight are probably unnecessary luxuries for most commercial activities), because that's what people expect.

Now, dropping that point, getting back to the job. What does everyone think of the changes? And my initial analysis of them? Agree? Disagree? Did I miss an important point?

I, too, look forward to a future where the laws of thermodynamics have been repealed.

As to your game changes, I have to say that I'm indifferent (sorry).

The laws of thermodynamics are not being replaced ... just messed with in ways that make those of us (I include myself in this group) who learned physics back when it was comprehensible want to cringe, pull out our hair, and move to a log cabin in the forest. It started with microwave ovens ... making sane, analytical people want to scream "how in heck does this thing work? Space magic?" Then it was magnetic resonance induction - common in wall heaters (often termed a "heat pump") and some cooking appliances these days, but when you see it rigged up in a lab experiment, it messes with your head ("wait ... temperature is magnetic?") . Fact is, any sufficiently advanced technology (relative to your current level of understanding) is indistinguishable from magic anyway. Science fiction generally tries to set just at the edge of that, trying to play off what is already understood against what could, for all the viewer can tell, be magic.

But I'm not kidding about those new laser weapons. The U.S.-made suckers look like a big search light, generally paired with a phased-array air defense radar (the same ones used for the Patriot air-defense missiles). They're freaky ... they turn the inverse square law on its head - a variable parabolic mirror that focuses the beam at whatever point and range they choose, so that it is relatively easy to dissipate the heat at the firing point but the impact point gets a LOT of heat at a VERY confined point (i.e. making holes in it... in a hurry). Nobody has ever seen anything like it before ... except for kids killing ants with a magnifying glass, who have always understood the concept. Just that now they have one big enough that people and missiles and planes and ships are now the ants. (cringe)

Now back to the point ... indifferent? Yeah, me too, right at the moment ... again, I got them a little too fast, so it still doesn't feel right. A little less strange than before, maybe, but still not right. Question was, agree with my analysis that I got them a little too fast? Are there other critical issues that I failed to mention? Just want to see round two, to find out if my "little too fast that last time" assessment is correct?

And what code controls range on the weapons (or time shot spends in flight, or however it is calculated)? The faster shot speed means that range is critical to the game play model ... just because humans need to be able to see their target to shoot at it. A simple enough thing to modify, surely, but I need to know what number measures that and what units it is measured in.

Consideration ...

Always been the control of the territory is a specific human. So in future, the space will be a territory for the man. the question arises of how to do. Given the enormous distances, and limited acceleration to which we are forced, the electronic control will be crucial. (It is already at sea).

So we're used to fighting in the frontier, in my opinion, should not be eliminated, but should serve where the "hypothetical future weapons" were not valid and enforceable.

in a collision in Earth orbit, just a stray bolt of a few grams, to destroy a satellite or a shuttle. let alone a laser weapon!

Yesterday to defend myself from an imperial courier without shields, I had to put in the middle of too many hits to bring it down. This is fun to play, but unrealistic. I think you correct

1 Recalibrate the points attack / damage.

2 Reduce the diameter of "pipes" lasers.

3 graphics board if I can .... fade toward the tail pipe, or give the elongated teardrop. more pleasant ..

Thank you! I admire you

excuse the strange translation 😳