I'm having trouble uploading the file :/

How about using Git to actually clone the thing itself?

First you'll have to install Git, and then just clone the repro... this sounds complicated but honestly it's nothing at all 🙂

On windows I use TortoiseGit from http://code.google.com/p/tortoisegit/ . Just follow the instructions to get it installed with the other programs that it needs first.

You can then either go to the https://github.com/pioneerspacesim/pioneer Pioneer GitHub and copy the git read-only address (it's "git://github.com/pioneerspacesim/pioneer.git" for reference) then "clone" it into a local folder or you can learn how to get setup on GitHub and fork the project... which is the recommended route if you're going to try and give stuff back eventually.

Just take your time and ask plenty of questions on here 😀

As I remember, this a problem with the Debug and PreRelease builds. One of the libraries that the game links to was linked against the 2008 version of the MSVC debug C runtime, which does not come with MSVC 2010. Specifically, libpng15d.dll requires zlib1d.dll which requires MSVCR90D.dll. While Windows comes with MSVCR90.dll and VC++ 2010 comes with MSVCR100D.dll, the only way I know of to get MSVCR90D.dll is to install VC++2008.

The solution I used was to change to the library without debug info, libpng15.dll, for those build configurations. This is done by editing the Linker/Input/Additional Dependencies in the pioneer project Properties for those configurations.

OK, I've just tried pretty much everything suggested or hinted at ... including installing C++ 2008 just to get the other files ... and this is NOT working out.

Rather than generating more negative work trying to get my junkpile computer turned into a programmer's workstation, let's just work this the other way. We're only talking about a dozen numbers or so here, so I'll take my best guess at what I feel they should be, someone else can compile it and post it (set up a "combat test" branch or something), and we can all test and comment on it. Wash, rinse, repeat ... in about three tries, we should be close enough for this development phase.

Here are my first thoughts: greatly increase speed, so the fire looks like fire, and also so it flies past you instead of just cluttering up the whole sky. Increased rate of fire, particularly for the smaller weapons ... larger guns can have a somewhat lower fire rate, but tweak the damage to compensate. Higher fire rate will make the guns heat, especially in anything too small to have a cooler unit, so fire will be in bursts by necessity. No idea on damage numbers yet, so for now, I'm really just working with the small weapons... changes to the others are just so we won't confuse ourselves about the ratio between the various sizes. (Don't want to double one thing and cut another in half and then try to remember how many times I did this for each weapon entry.)

So plug these numbers in, and see what happens:

const LaserType Equip::lasers[] = {

{

0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0,

Color(0.0f, 0.0f, 0.0f, 0.0f),

},{ // 1mw pulse

8.0f, 9000.0f, 1000.0f, 0.10f, 10.0f, 0,

Color(1.0f, 0.0f, 0.0f, 1.0f),

},{ // 1mw df pulse

8.0f, 9000.0f, 1000.0f, 0.10f, 10.0f, Equip::LASER_DUAL,

Color(1.0f, 0.0f, 0.0f, 1.0f),

},{ // 2mw pulse

8.0f, 9000.0f, 2000.0f, 0.10f, 10.0f, 0,

Color(1.0f, 0.5f, 0.0f, 1.0f),

},{ // 2mw rf pulse

8.0f, 9000.0f, 2000.0f, 0.05f, 10.0f, 0,

Color(1.0f, 0.5f, 0.0f, 1.0f),

},{ // 4mw pulse

8.0f, 9000.0f, 4000.0f, 0.10f, 10.0f, 0,

Color(1.0f, 1.0f, 0.0f, 1.0f),

},{ // 10mw pulse

8.0f, 9000.0f, 10000.0f, 0.10f, 10.0f, 0,

Color(0.0f, 1.0f, 0.0f, 1.0f),

},{ // 20mw pulse

8.0f, 9000.0f, 20000.0f, 0.10f, 10.0f, 0,

Color(0.0f, 0.0f, 1.0f, 1.0f),

},{ // 17mw mining

8.0f, 9000.0f, 17000.0f, 1.0f, 10.0f, Equip::LASER_MINING,

Color(0.0f, 0.3f, 1.0f, 1.0f),

},{ // small plasma accel

8.0f, 9000.0f, 100000.0f, 0.3f, 14.0f, 0,

Color(0.0f, 1.0f, 1.0f, 1.0f),

},{ // large plasma accel

8.0f, 9000.0f, 200000.0f, 0.3f, 18.0f, 0,

Color(0.5f, 1.0f, 1.0f, 1.0f),

}

};

Ron, there's no reason for you not to make these changes to your own fork of Pioneer on GitHub. Any Git users can pull in your changes, as you make them, and try them out.

Normally, this would be achieved by checking out the Git repository onto your computer, but you can make minor source code changes directly on GitHub.com and others can easily merge in your changes and compile them.

If you don't have an account, do go ahead and register. Fork the Pioneer project (this is a single click), then browse through the source in your clone and edit your values there. It's easy for you, easy for us.

I've seen a similar bug caused by the model cache, Ron its a long shot but try deleting the MyDocuments/Pioneer/Model_Cache and running it again.

You're right ... that WAS a long shot. Predictably, it didn't work.

Since the issue is that some combination of the code, the compiler I am using, and as of yet unidentified factors have conspired to make anything I personally work with non-functional ... do you have any reason to believe that this would improve the situation, instead of just creating more bugged copies that don't work?

I mean, if the problem revolves around my computer, and something going on with it, then the obvious immediate response (assuming that my part in this overall project is relatively limited) is to cut my computer out of the loop. Someone who has no problem making it work can add a few numbers to their copy, and we'll test that instead. That's the response that eliminates the negative work - spending a month trying to get my system configured to program on this thing, when my total expected contribution is only expected to be a few numbers. (I mean, I can help test and such, but I'm no programmer.)

Somebody just plug those numbers in, and direct me (and whoever) to a playable .exe we can test. Repeat this about three or four times, while we tweak it, and problem solved... fewer total keystrokes than I've just spent talking about it.

I was ruling out your computer, by suggesting you change the values in the file directly on GitHub. You know exactly where you want the changes to be made, and I don't have to open a text editor and break it at all.

Edit: I don't have any Windows systems, so while I could test it, somebody else would have to also make the changes to their copy of the source in order to provide a Windows build that could be tested. This is an immediate duplication of work - or, as you put it, negative work.

OK, so after checking every menu on GitHub, I cannot find any way to get myself registered so I can log in and do any of that stuff. The necessary command has to be hidden somewhere, but I sure can't find it.

But even assuming we can fix that, I don't see how it simplifies things anyway. Somebody else will still have to download the files and recompile it ... so how is downloading stuff to recompile any faster than just cut-and-paste that block of code off of a forum post? It won't recompile itself on the GitHub page, will it? I mean, I'll play along, but again, which one is just creating unnecessary work?

As usual, the devil is in the details.

The signup link at the top of the Github homepage gets you here: https://github.com/signup/free

This is a volunteer project. If you want a change made, you either do it yourself or you convince someone else to do it for you. You're not being particularly convincing - my personal impression (and it my just be me) is that you're getting pretty pushy, and for mine that's a huge disincentive. I don't want to work with anyone that doesn't appreciate the time and effort I put into things. If I was in a position to easily and quickly do a Windows build I'd still be faced with the prospect of having to do it several times over as you decide the values need tweaking further. That's not a worthwhile use of my time at the moment. Perhaps others feel the same way.

If you're unable to enlist some help, then you can either drop it, open an issue for a time when someone comes along and is interested, or spend the time learning how to get your own build working. I don't pretend its easy - the MSVC builds are difficult to work with; its very much a known issue. Again though, this is a volunteer project. If someone wants to make it easier I'll take the patch in a second. Until its important enough to someone it won't move.

This may sound harsh to you, but its the nature of things in this type of project. Many others have come before you wanting to contribute to Pioneer. Some haven't had the patience, but most have persisted and produced good quality work. We welcome any and all contributions to the project. We're just not so keen on people creating work.

Simple; on any of my machines, it's two commands. One fetches your changes (and only the changes, not the whole source tree) and the other recompiles those changed files. This process takes under a minute and doesn't require any concentration. If that sounds like magic to you, you'll be getting an idea of why it is that we use Git on GitHub.

Are they? It's really hard for me to tell because I've been using Visual Studio for over 15 years and, to be blunt, I just don't notice a lot of issues that are obviously stumping people. Do we have issues on the tracker? ❓

Well its not as easy as Linux, which is just "configure && make". There's copying stuff around, dealing with debug/release, dealing with 2008 vs 2010, and so on. I for one have never got a build I've done on MSVC to run. I haven't tried harder because I don't have to actually test it most of the time, I just compile to ensure that code I know works under MinGW builds under MSVC.

If someone with good MSVC powers could fix it all up so that you can just open the project and hit "build", that would be absolutely brilliant. Its not on the issue tracker so far because nobody has cared enough - MSVC is a secondary platform still, and the people who use it already have it working.

Ah it's the other way around for me, Linux "configure && make" has never worked yet for me 😆 and I can't stand the hacking that's always required to get SDL installed/configured/made etc, it just never installs clean or works on any Linux distro I've used.

That said I've started working on the MSVC builds and there's now a "SolutionFixUpPart1" branch based off the latest upstream master on my fork so I'll see what I can do with my MSVC-fu 😀

OK, done all of the above. (I couldn't find the sign up because it was mixed in with all that stuff about creating whole new projects, but finally found it ... thanks.)

Branched the file:

https://RonLosey@github.com/RonLosey/pioneer.git

Made changes to the weapons specs, sync to that file. Check.

I still have no way to compile it, so I can't test and see if this is working or not. Somebody else will have to build an .exe that we can test. Obviously, the first-round changes were a total stab-in-the-dark guess. Whoever does get around to building the .exe out of it, please tell me how to get it, so I can help test the thing.

I see your fork, but I didn't see any changes committed.

If you're looking at the files in your own fork, you shouldn't need to branch anything at all. Simply edit the file, and the commit the changes. If you only see "Fork and edit file" you're not on your own fork, but somebody else's.

My computer is all set up ready to compile any changes that you do commit to your fork, so you can get pretty much immediate feedback that your changes compile properly, if you like (and assuming I'm physically at my computer).

TortoiseGit said it committed the changes. It changed the little icons to show that it had everything in sync, just like I've seen on other SVN systems. I mean, it was a pain to set up, but once I got it running, it thinks it's doing the job. It has to be on the right fork - I copied the address.

Check equiptype.cpp on what you can get from that fork, and see if it has been changed to show shot speed of 9000 and a few other things. If not, then we have another mystery on our hands (like, where in heck is TortoiseGit sending this stuff?).

Git operates quite differently to Subversion. You have a fully self-contained repository on your local machine, which is where your commits go. Once you've finished committing things you need to synchronise your local repository with your remote repository stored on Github.

I don't know TortoiseGit but I suspect the sync step (known as a "push" in the Git world) hasn't been done. Look for a "push" or "sync" option. Once its done, you'll see your commit in your commit list.

Cool, you're Doing It Right. (-:

To push, right click on the repository folder. In the context menu, select TortoiseGit then Push.

Alternatively, git push from the command line in that directory.

Its odd as this is actually how it builds for me 🙂 I recently reinstalled my OS (Again) and I literally just had it build with a few clicks, however to debug I had to enter the project directory into the configuration settings this was the only change I had to make.

Ok ... sync, then "push" to actually send the thing.

Found it ... now it's actually on there.

There's just always one more step, somehow. Nothing is ever quite as simple as it sounds.

And one more time, for the record - version one is a shot-in-the-dark guess about what the numbers should be. But since the code is about firing weapons into the blackness of space, hey, a shot in the dark sounds like a good place to start.

It builds cleanly. Just giving it a quick play.

Follow-up: And I'm dead. They do look like red tracer rounds.

Well, let me see. Somebody post an .exe so I can play with it and see what else needs to be modified.

If they look like tracer rounds, that's good ... means they work like weapons. No more chunks of neon signs floating about in space, but also that they are not speed-of-light instant either. Step two is to balance the damage so that things don't just go boom in the first half a second ... and that likely means running some tests with shields and different sizes of ships. Also worthy of note, the AI may be too good - if it can pinpoint a target down to a single pixel at maximum range, then a human with a mouse has no chance against it.

You'll now need to wait for a Windows user to take interest. At least it's available to them now... I can only provide this 64 bit Linux version.

Hmmm maybe.. Nah on second thoughts I'd rather not waste my time with negative work... After-all its a "long-shot" you'll get it to run right?

Cute....

No, it's beyond "long shot" ... unless somebody else compiles the darn thing, it's absolutely assured that ten million things will conspire to make sure that I can't get it to compile for myself. I've done every dang thing I can think of, and it just does not like something on my machine. And if I can't compile it, I can't test it ...

However, odds are good that I can, with a working .exe of the modifications, mess with it long enough to get the combat sequence playable and feeling about right. Since the Alpha 18 release worked for me, I know it is possible to make this thing run on my hardware. But I have to see the changes for myself, to know which way to adjust.