Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - taylor

Pages: [1] 2 3 ... 21
Tech Support / sendmail not working?
« on: September 29, 2009, 09:34:46 PM »
Quote from: Dorque;121572
Still getting the sendmail error, but now I get a login failed when I try connecting with FS2 insteading of a failed to connect error.  Good to see things are progressing.

Fixed, again. :)  There seems to be some missing configuration info for the new server though, so nearly all mail that is getting sent out is being rejected by the remote server.  Hopefully this will be resolved soon.

You won't be able to play FS2 in the meantime however.  The new FS2NetD setup requires that each user account is authenticated before it will let you play a game.  When mail is working properly again, you should be able to just go to your accounts page on the FS2NetD site (click on your username once you are signed in) and have it resend your registration confirmation email ("Resend Login Info").  Then just click on the link in that email and you should be ready to play. :cool1:

Tech Support / sendmail not working?
« on: September 27, 2009, 10:55:10 PM »
@Dorque:  When the website was updated to support the new FS2NetD code it was for the old server.  Now everything has moved to a new server and the old setup that I had is no longer valid.  The error you mentioned was reported and fixed earlier, so give it another try and report back if it still doesn't work for you.

FS2NetD is back up, but still in a sort of testing mode so that bugs can get worked out.  Feel free to play as normal, just be prepared for a few hiccups while we work out any remaining problems.  After the testing phase there should be some sort of public announcement letting everyone know that FS2NetD is back up, at which point you'll know for sure that it's safe to play again (if you don't want to use it in the meantime).

Tmp2 / FS2NetD
« on: October 04, 2008, 04:01:24 PM »
As part of a FS2NetD server upgrade last night I added a 3.6.10 daemon for BtRL.  The previous 3.6.9 daemon remains the same, it's just that now you have the option of using newer builds as well.  The port number for the 3.6.10 daemon is 12005.  The 3.6.10 daemon is not listed on the FS2NetD website but I'll add it if you guys want to make use of it (publicly that is).

If you have any problems with it please let me know.

Tmp2 / crash when using pulseaudio on linux
« on: April 01, 2008, 06:05:16 AM »
See this thread which covers the same problem:,52184.0.html

The basic fix was just to put "(define devices '(alsa))" in your ~/.openalrc file.  But that is only assuming that PulseAudio is setup properly and ALSA is set to use it.  That should be the case in Hardy though, so there shouldn't be anything else that you need to do in order to get it working.

Tmp2 / Problems with UBUNTU 7.10
« on: March 31, 2008, 12:52:06 AM »
Quote from: FatBob;95552
After installing the game it kind of works, but the command line says this:

" Couldn't run Beyond the Red Line Demo (btrl_demo.bin). Is FSO_DATA_PATH set? "

What does it mean and what do I do about it ?

Do you have the patch installed?  The bash script was modified in the patch to try and fix the problem with some distros (well, technically is was wrong before so it's not the distros fault).

I recommend installing the patch, and then let me know if that doesn't fix it for you.


When I want to make a Player it says theres not enough disc space. But this is a new setup system with loads of Gigabyte free. Probably it has to do with some rights (chmod stuff i guess) ?

Does the "Nugget" pilot show up?  If not then it is linked to the above problem, so install the patch and see if that fixes it.  Also check whether the "~/.btrl_demo" directory is owned by your user or not.  If not then just do this in a terminal:

cd && chown -R .btrl_demo

And that should fix the permissions.


What do I need for Multiplayer Mode ?

That should be covered by the documentation.  There really isn't anything special just because you are running Linux.


I have a Microsoft Sidewinder Precision 2 Joystick ... will it work with BTRL ?

If it works with SDL then it will work in BtRL.  I can't say for sure without checking on it, but I'm pretty sure that it will work fine for you.

Tmp2 / Force Feedback/Vibration
« on: March 15, 2008, 04:08:41 AM »
ForceFeedback is only supported under Windows at the moment.  I have it my todo list to add Mac support, but I don't currently have a FF device which is Mac supported, which really raises the difficulty level in coding in support.  :)

I keep hoping that someone else will volunteer to write the code for us, but no takers so far.

Tmp2 / List of coding tasks.
« on: March 11, 2008, 03:57:24 AM »
Quote from: karajorma;93774
There is an option for using scripting to trigger submodel animations. Its one of the things i have on my plate for testing. Besides turret firing works nicely as well as the door option. Also AFAIK VA has had success with docked and docking animation types. However none of these (except possibly scripting) helps with landing stuff.
That's a big improvement on my understanding of how it worked then. :)

That's because I rewrote the code a while back. ;)

The upgraded (un)docking triggers still only exist in my Xt builds, since I have one last thing to fix in that code and just haven't had the time.  As far as I know all other triggers work fine now (going by the tests I did for SoL a while back).

VA requested some additional work on turret related triggers to finally work with turret recoil (there a Mantis bug on it).  Changing the existing trigger to work with that can't be done without breaking anything that already uses it, so I'm going to add two new turret related triggers instead.  The first will be "turret fire-prep", which you can think of as a warm up animation (like the spin-up of a gatling gun for instance).  The second will be "turret fired", which gets triggered after a turret has fired (obviously) and will allow proper use of recoil type effects.

I had thought about not adding two, and just letting people use the forward/reverse of one new animation type (the "turret fired" one).  But I figured that someone might come up the with idea to have a galing gun with recoil, which would require two totally different types of animations.

Quote from: karajorma
However we have seen EMP in the show, both from the trick Apollo did in the mini and from the effect the Nebula had on Galactica in Crossroads pt. II. If we tried to replicate that in a mission we'd get the FS2 style EMP instead. When I use the EMP effect via SEXP (or even missile for atmospheric missions) I don't want to see the FS2 effect.

Remember that those arcs can be textured now (Xt builds only until I can commit all of the OpenGL upgrades), so it should be possible to use a transparent texture or something to just get rid of all but the light effects.  I don't actually remember what it was like on the show though, so perhaps it really is just something that can't be replicated enough with little texture tricks like that.

Tmp2 / debris problems
« on: December 07, 2007, 06:05:32 PM »

Tmp2 / debris problems
« on: December 06, 2007, 06:26:47 PM »
Quote from: karajorma;85942
Email it to me ( and I'll take a look. The solution basically involves running a new build of FS2_Open with Goober's code in it. If the model does have poor bounding boxes then the build should spit out an error along with information that can be added to the model using a hex editor.

The same code that will be in the Xt build. :)

That code will automatically fix the problem on model load, and issue a Warning() about the subobject which has the problem, but it obviously won't repair the model.  That hex code reporting is #if'd out by default though, and it only gives you the proper values, not the original values, and not where to put them when hex editing the POF.

Tmp2 / debris problems
« on: December 05, 2007, 10:01:35 PM »
There is a bug in PCS2 which screws up the bounding box for subobjects.  In particular, this kills the debris system quite efficiently.  With debris values screwed up it it then messes up collision detection, then physics, and causes objects to simply not render.  The bad debris values then start to propagate to anything that the debris hits, be it ships, weapons, etc.  So, I'm going to assume that this is the problem you are seeing.

My next Xt build (released tomorrow probably) will have the fix for this, but there is current no build of FSO or PCS2 which can handle the bug.  If it doesn't solve it for you then there is likely to be another bug in there somewhere.  But considering the results of the debug session to track down the bug previously in FSO, I'm confident that all you are seeing is the bug caused by PCS2.

Tmp2 / Source code repository for BtRL
« on: December 03, 2007, 10:17:12 PM »
I'm still fighting with the debug build for OS X, so I'm go ahead and upload just the release build for now.  I'll update everything to include the debug build later on this week (hopefully).  This has all of the updates that Turey and karajorma sent me, the right-mouse-button fix, the PBO fix, a fix for that "echo -n" problem (simply removing the "-n", like others have done, doesn't actually allow it to work 100%), and the new build setup that should work on 10.3+.

I uploaded the new Linux binaries Saturday night, but I still haven't had a chance to actually test them myself yet.  Someone will have to give them a try and let me know.  These binaries were built under Ubuntu 6.06 LTS, so they should be compatible for everyone (I hope).

I'll get that diff and a source tarball uploaded tonight or in the morning.

OS X release build:

Updated Linux binaries:

Tmp2 / Source code repository for BtRL
« on: December 01, 2007, 02:17:49 AM »
Quote from: Havner;85469
Any chance for it as well? :-) Is there anything more (but compile fixes) next to this dir?

Uh, yeah, I'll post it here at some point later tomorrow.  Just look for a file called "btrl_patch.diff".

Whats the point for 10.3 release? If someone still has PPC MAC it can use universal with Tiger. Or are there some old macs that wont handle Tiger?

There are various people that have tried to run the game with 10.3, either because they don't have/want Tiger, or that can't use it because of having an older Mac.  And there is no technical reason not to support it, just the extra effort.  There aren't many people that need/want it, but it's enough for me to justify the time spent on it.  Plus, it's a general FSO thing so all mods benefit from the slightly larger (ie, 10 or so ;)) user base.

I had the OS X build for BtRL done last weekend, but then Turey sent me a code update, so I've to refresh the build before I can post it.  An updated Linux build will be available soon as well.  Look for both of those this weekend (probably tomorrow afternoon/night).

Tmp2 / Source code repository for BtRL
« on: November 30, 2007, 08:47:01 PM »
Quote from: Havner;85467
EDIT: But the code you gave me still uses ~/.fs2_open dir.
You patch it everytime you make release?

Yup.  I do actually have a diff with the changes, and then just apply that to the code tree that karajorma sends me to make a release from, so it's not that big of a deal.

That hardest part is the OS X release, since the project file and frameworks are a lot different now than they were for the original 3.6.10 release (since I changed everything to allow for 10.3+ on PPC for the Universal Binary).  The 10.3 SDK is a bit fubar (thanks Apple!!! :mad:), and I actually have to make changes to the system OpenGL headers to even get it to compile (not an issue with the 10.4u SDK, thankfully).  For the project stuff I basically have to copy over and modify the project to work on the older code tree, which is pretty annoying.

Everything will be officially in CVS with 3.6.10 though, so I will no longer have to go through all of the crap I do now.  The only holdup for all of that is just to get everything situated in order to be able to build on OS X without modifying system headers to do it, and without including a full copy of the 10.3 OpenGL headers. :doubtful:

Tmp2 / Source code repository for BtRL
« on: November 30, 2007, 06:41:39 PM »
Quote from: Havner;85452
Doesn't WCS has its own switch in command line for WCS features?

Yes, although things like this are slowly being replaced with mission or tbl options instead.  Several of the WCS features have already been moved to tbl settings, and the rest will probably be as well before long.

Still, anyone knowing internals of BtRL code I'd like some confirmation if there are only general fixes against 3.6.9 branch or some BtRL custom features. If I can use plain fs2_open with success or it will be limited.

It's really fixes specific to BtRL, but you could consider them general fixes as far as the FSO as a whole is concerned.  But those things are also in the stable branch of CVS, so if you use that then you should be ok using one of those CVS binaries with BtRL.  There are issues with the stable branch though, mostly because of how much new code I have done over the past year (in excess of 120,000 lines), and that I've committed only a fraction of it so far to CVS (lack of time, code still in flux, etc.).

The OS X and Linux binaries for the mods are a bit different though, but only because of some defaults that I  change.  For instance, a normal FSO build will default to 640x480 resolution, but WCS and BtRL require 1024x768, so I changed the binary to default to 1024x768 and require at least that as a minimum.  Another build specific issue there is the user location for game files.  So the BtRL binary on Linux will use ~/.btrl_demo instead of the usual ~/.fs2_open.  And the OS X binary does something similar.  This allows you to run clean a lot easier, and avoid any issues with other mods (things that aren't total conversions like TBP/WCS/BtRL are).

Things like that are going to die out soon though, since I'm going to make all of that stuff runtime options instead, with the settings stored in ini files.  That isn't going to happen until 3.7 or so, but it should make things far easier on everybody (both mods and users alike).  The goal is to easily use a single binary for everything.  That isn't easy right now, but we are slowly getting there.

Tmp2 / Benchmarking proposal
« on: November 06, 2007, 05:02:08 AM »
Alright, had some more time to go over that Colonial Movers issue.  I'm in the process of rewriting all of the shader stuff (both the code and the shaders) from scratch.  Right now things are pretty basic, and very fast.  But a quick test of the same mission gives the exact same results as before.  I haven't determined a cause yet, but I did notice one thing of particular interest...

Filling the screen with the entire front half of the model (with everything still docked) I get about 520 FPS.  Looking at the back portion of the model (the entire engine section, just after where things are docked) I get about 420 FPS.  But, and this is the interesting thing, looking at the rear docking portion (where the Vipers are docked) I get about 180-200 FPS, with nothing docked there.  If the Vipers are there the FPS is below 100, but killing them off should take me to at least 400 FPS, and it doesn't even come close.

So, I'm starting to lean towards a model problem for this.  In a fresh profile I still don't see anything out of the ordinary with the code, so there doesn't really appear to be a slow function at work here.  My only guess at this point is that it's either a geometry or mapping problem that's throwing a wrench in the GPU.  I can't say that I see anything obviously wrong though. :doubtful:

Maybe someone can just take a close look at that section of the model and see if perhaps there is some hidden problem.

Pages: [1] 2 3 ... 21