The General BugFixing/Playtesting thread for FFED3D+mods

[Steve]

I've been having a bit of a FFED3DAJ (v1.04 large address) session this afternoon and am generally very happy with the way the game plays. It's particularly good that I can switch to the desktop and back to the game without any problems, and that all the models pre-load

One thing though. I'm still having problems with me buttons!

They keep disappearing, although I can still click where they should be. It happens quite randomly; it's not always the same buttons that disappear. Even more oddly, the issue survived a switch from Windows Vista to Windows 8 and updates from v1.02 to 1.03 and 1.04.

Andy, I think it's fair to say you have a pretty good grasp of the game's code so would it be at all possible to address a few minor bugs which seem to have been with FFE since forever?

1. If you've scrolled the map to another system and then press "C" to jump back to your current system, the system info sticks with the other system. You have to move a little in one direction then click your home system to get the info to lock on to where you are. Could this be rectified in a future build so that pressing "C" makes the system info update as well?

2. On the bulletin board, when you select a message and subsequently go back to the board, the program remembers where you are in the list of messages. When you're doing military missions though, when you read a mission's details and then go back to the list of messages, it always puts you back to the top of the list, rather than where you've scrolled to. Any way of making the program remember where you are in the list of missions?

3. When you're asking questions of people who want to travel in one of your cabins, the people who reply "The Police want me to help them with their enquiries" never pay up. Surely that should happen when you take the people who reply "I owe someone money"?

These are not huge issues, of course, but would make me a happy, if slightly cheeky, chappy if they're fixed

Now, back to the game...

 

[Zak Gordon]

@zak it's worked quite well for other Newtonian physics games like i-war and Terminus, but I've gone back to using the keyboard, since 90% of the flying feels like it's being done on Autopilot anyway.

Thanks anyway, Eid

Oh. I was meaning if you mapped the keyboard+mouse control in FFE (or FFED3D) into a joystick it probably wouldn't control well. I am aware other games that came with joystick control designed into the game can be done fine. It was more you question about FFE, i don't think it can be done, not in a way that would 'fly right' at any rate.

Still who knows what magic AndyJ might rustle up? maybe it can be done?

I've been having a bit of a FFED3DAJ (v1.04 large address) session this afternoon and am generally very happy with the way the game plays. It's particularly good that I can switch to the desktop and back to the game without any problems, and that all the models pre-load

One thing though. I'm still having problems with me buttons!

They keep disappearing, although I can still click where they should be. It happens quite randomly; it's not always the same buttons that disappear. Even more oddly, the issue survived a switch from Windows Vista to Windows 8 and updates from v1.02 to 1.03 and 1.04.

Those buttons. Another reason i play default FFED3D+AndyJ, rather than use Ittiz build. They just feel too 'Pearly King' for my aesthetic tastes! I didn't know they could disappear though, annoying.

 

[AndyJ]

hello!
There is analogue joystick button support + 1 button I think, be it from the original or JJFFE/GLFFE, but I've not tried it myself to see how well or if it works. AFAIK though, individual thrust inputs such as from the keypad (with engine in 'off' mode) are digital - either applying thrust at a constant rate or not... so I don't think that a rudder or throttle would have any functionality other than a key press to map against.
I have wondered about looking to map keys to extra buttons on the mouse or joystick but to be honest it's far down the list. Many joysticks come with their own mapping software, or there are free alternatives available, so would it be a good use of time replicating that in the .cfg file? most likely not...
Given that you do need to be in engine-off mode to use the individual thrusters, rather than the pseudo 'fly-by-wire' assisted mode, perhaps it would be useful at some point to support direct setting of mode via individual keys instead of having to cycle through them with Tab? (I don't think this can be done at the moment?)

Regarding the other points:
The missing buttons - I think that I may have found & fixed the cause today. I was able to replicate a similar situation when switching from the Battle Computer view either to the System Menu, or straight to the Stock Market screen via the Services view. There was no 'tidy up' code at the end of a frame-render, probably for performance concerns, but it's likely a 'no display' value was occasionally being inherited and preventing the buttons from being drawn. I could see it happening with the first button sent to display on the screen, but have never seen others fail to display. (but my actual 'play' sessions are quite short!)

Regarding the other 3 long-standing issues - the first two would require some long adventures into the underlying JJFFE assembly code, areas that are largely unknown and undocumented. Not sure how brave I feel about trying that!
I do know where the 'C' key is processed as well as the function that draws the system map, so might be able to track it though and see what data is (or isn't) being updated. Not sure what happens though when you scroll onto or click another system... no doubt something 'extra', and is probably the cause of the selected system info not updating.
And I think that the menu 'GUI' code is generally as clear as mud. I think it would be very hard to add any functionality to the assembler and its data without spending a LOT of time or at risk of breaking something.
The 3rd one is probably just an incorrect string index - I think JJFFE or ANISO might have fixed some similar issues already?

Moving the default game settings into the .cfg is I'd agree something to look at in future. Need to beware of the detail settings though which may disable others (e.g. star dust) and perhaps update data values elsewhere.

I've also been looking at the "z-fighting" issues and have for the most part fixed the bio-domes and labels on ships/stations now - there is still an issue at a far distance due to precision if the shape/text is still visible.
I'm continuing along this path to also restore the missing stripes and decals on the original 'primitive' ships (e.g. the Cobra MkIII shark-teeth) and have also figured out how to add filled circles to the supported polygon draw-commands. Ships that use them for their engines have them again. (lynx, falcon, tiger, boa) - but haven't quite sussed out yet how to get two of the four church tower clock faces appearing...
Despite FFED3D allowing new models to be added, it would be great I think to be able to run it relatively glitch free with just the original models and as an alternative to GLFFE, which has some of its own display issues...

And finally... just to revisit one of the earliest screenshots/queries:

{snip!}
Also in that second screenshot i want to talk about new textures and why going Hi-res is not always the best option. I've highlighted (very badly in 'paint') that pylon behind my landing spot, and you can see that bit of architecture in various space ports. Notice how it seems 'blank' or with little actual visible detail on it. I think is just due to the Hi-res texture that replaced the deault one.

So i just wanted to mention that, so when using a hi-res texture replacement it might be good to ensure it contains interesting detail to stop it looking 'blank' when rendered in the game. There may be a number of these type of hi-res textures that could probably do with being adjusted to make the texture stand out a little more, while keeping the hi-res setting?

I think that the hi-res textures tex400->420 and tex422->427 specifically need to be closer to the original versions with regards to colours and 'chunkiness' of detail. I think that it's probably 425 that's being used on the spike in the screen-shot (which is an original polygon model)
I've noticed while looking at fixing the flickering fields in the bio-domes that the textured fields were overly grey, and that the large solid fields were completely grey when using the high-res textures. In original FFE they are dark-green.
For a moment I thought 'uh-oh, is there still a colour issue?' but fortunately tried dropping in the original texture tex424 from the FFED3D beta 1.12 build first - and Bingo! Dark green textured fields appeared, but also solid dark green ones too. It must just use the top-left pixel of the image I think when filling these polygons.
So yeah, more detailed doesn't necessarily equal a prettier end result... and it saves memory too!

(tex421 is the wing texture of the Argent's quest & Wyvern in case wondering about the gap)

 

[Zak Gordon]

hello!
There is analogue joystick button support + 1 button I think, be it from the original or JJFFE/GLFFE, but I've not tried it myself to see how well or if it works. AFAIK though, individual thrust inputs such as from the keypad (with engine in 'off' mode) are digital - either applying thrust at a constant rate or not... so I don't think that a rudder or throttle would have any functionality other than a key press to map against.

Really? Ahh, 'analogue'. Wow, it's been a while since i had a PC with an analogue joystick port! I think this will be redundant for most people today! Certainly my usb connected Joystick does nothing in game.

Moving the default game settings into the .cfg is I'd agree something to look at in future. Need to beware of the detail settings though which may disable others (e.g. star dust) and perhaps update data values elsewhere.

Cool. So why does the default game not start in the highest graphics option? Is that just a hangover from the original FFE days when maybe a PC would struggle with it's highest graphics setting? it would be great to have all this set at game start via the cfg file

Just fyi, i don't think it is possible from a purely graphics change aspect, to remove the faint blue line that appears in background space. The one that goes across the center of the nebulae when not using 'Black' as the colour for space. I've tried a number of things in Photoshop to remove it, and always when it renders in game, you get that joining seam. Very frustrating.

I've also been looking at the "z-fighting" issues and have for the most part fixed the bio-domes and labels on ships/stations now - there is still an issue at a far distance due to precision if the shape/text is still visible.
I'm continuing along this path to also restore the missing stripes and decals on the original 'primitive' ships (e.g. the Cobra MkIII shark-teeth) and have also figured out how to add filled circles to the supported polygon draw-commands. Ships that use them for their engines have them again. (lynx, falcon, tiger, boa) - but haven't quite sussed out yet how to get two of the four church tower clock faces appearing...
Despite FFED3D allowing new models to be added, it would be great I think to be able to run it relatively glitch free with just the original models and as an alternative to GLFFE, which has some of its own display issues...

Just awesome, your doing wonders, seriously!

I think that the hi-res textures tex400->420 and tex422->427 specifically need to be closer to the original versions with regards to colours and 'chunkiness' of detail. I think that it's probably 425 that's being used on the spike in the screen-shot (which is an original polygon model)
I've noticed while looking at fixing the flickering fields in the bio-domes that the textured fields were overly grey, and that the large solid fields were completely grey when using the high-res textures. In original FFE they are dark-green.

For a moment I thought 'uh-oh, is there still a colour issue?' but fortunately tried dropping in the original texture tex424 from the FFED3D beta 1.12 build first - and Bingo! Dark green textured fields appeared, but also solid dark green ones too. It must just use the top-left pixel of the image I think when filling these polygons.
So yeah, more detailed doesn't necessarily equal a prettier end result... and it saves memory too!

(tex421 is the wing texture of the Argent's quest & Wyvern in case wondering about the gap)

Ah. Very useful info, stuff like this is gold dust for me in my adjustments to those texture files and i'll add this info to my 'to do' list. I'm happy to go higher res than the originals, but see no point where it won't look better or introduce other issues (like the 'wrong' colour changes etc). But saving memory is my main priority here.

I look forward to your latest update with the changes you mentioned above, and thanks very much

 

[AndyJ]

Really? Ahh, 'analogue'. Wow, it's been a while since i had a PC with an analogue joystick port! I think this will be redundant for most people today! Certainly my usb connected Joystick does nothing in game.

What I actually meant was analog (typo) i.e. one that gives positional X & Y values not simply up or down, left or right. A flightstick or a thumbstick on D-pads are examples.
Curiosity got the better of me & I've dug out my Cyborg Evo from a dark corner of the room, calibrated it in Windows to set the dead zones and then...
set enabled=1 in the [JOYSTICK] section of ffed3daj.cfg.
I had to tweak its values slightly to cut out erroneous input: xdeadzone=80, ydeadzone=100 got it flying straight & true in space, away from any gravity influences. The settings are straight from JJFFE so I'd be guessing what the rest do... not sure the FAQ ever explained them?

Personally I don't think I could use a joystick in FFE after 5 minutes experimenting!* Left/right is just the same as dragging the mouse left or right and having played a lot of flight-sims in years long passed, that feels very "wrong"! My brain is obviously programmed to expect that the ship will roll not yaw with left/right input...

*[edit] turning on the "Others" option: "Elite control method in space" in fact switches left/right to roll just like a plane as soon as you take off - which is FAR better! But mouse is still always going to be far reaction-wise I'd have thought.

Cool. So why does the default game not start in the highest graphics option? Is that just a hangover from the original FFE days when maybe a PC would struggle with it's highest graphics setting?

Indeed. Increasing the detail adds an extra division of triangles on planets, greatly increasing the amount of work the CPU has to do... the original was running on 386, 486 and early pentiums if I recall correctly, so many PC's wouldn't have coped with the workload of high detail.
I expect that JJFFE/GLFFE never bothered to move the settings into the .cfg as generally once they've been set in-game and you're playing for any length of time - they just get carried forward next time you load the save.

Just fyi, i don't think it is possible from a purely graphics change aspect, to remove the faint blue line that appears in background space.

No, think I said in an earlier post/thread that it's the seam on the final edges of the skybox model that the game creates.
Anyway, just had a quick look and good news, the renderer just needed to set the sampler-state to CLAMP not WRAP before rendering the skybox. (and then restore the state afterwards)
4 lines of code and no more seam!

 

[Steve]

Regarding the other points:
The missing buttons - I think that I may have found & fixed the cause today. I was able to replicate a similar situation when switching from the Battle Computer view either to the System Menu, or straight to the Stock Market screen via the Services view. There was no 'tidy up' code at the end of a frame-render, probably for performance concerns, but it's likely a 'no display' value was occasionally being inherited and preventing the buttons from being drawn. I could see it happening with the first button sent to display on the screen, but have never seen others fail to display. (but my actual 'play' sessions are quite short!)

Good, hope you can code a solution

Regarding the other 3 long-standing issues - the first two would require some long adventures into the underlying JJFFE assembly code, areas that are largely unknown and undocumented. Not sure how brave I feel about trying that!
I do know where the 'C' key is processed as well as the function that draws the system map, so might be able to track it though and see what data is (or isn't) being updated. Not sure what happens though when you scroll onto or click another system... no doubt something 'extra', and is probably the cause of the selected system info not updating.
And I think that the menu 'GUI' code is generally as clear as mud. I think it would be very hard to add any functionality to the assembler and its data without spending a LOT of time or at risk of breaking something.
The 3rd one is probably just an incorrect string index - I think JJFFE or ANISO might have fixed some similar issues already?

I don't recall JJFFE fixing it and I never play Aniso. Regarding the other two points, I'm a bit surprised all the bulletin board stuff was coded in assembler; I'd have though a higher-level language would have sufficed. Still, they're only minor annoyances so please don't break something else trying to fix them!

 

[AndyJ]

Well FFE was originally coded in C (DB stated so years ago on alt.fan.elite)
Frontier though was written in 68000 assembler code for Atari ST/Amiga versions and then ported to x86 assembler by Chris Sawyer to run on DOS PCs.

JJFFE decompiled the FFE executable into assembler, to tweak/recompile it so that it'd run on Windows 95, and that's the only game source available to play with. (and hence the reason for the start-up warning message)

It's only the FFED3D (or GLFFE/JJFFE) wrapper code for the .exe that's actually in C++ format. The underlying game is still all assembly... and not human-friendly assembly for the most part, except for where JJ/Aniso et al figured out the purpose of a function and added a few brief comments!

(this is why JJFFE and other builds that derive from it can only ever run on compatible x86 CPUs, and also why it can't be compiled to a 64bit .exe either)

 

[Zak Gordon]

What I actually meant was analog (typo) i.e. one that gives positional X & Y values not simply up or down, left or right. A flightstick or a thumbstick on D-pads are examples.
Curiosity got the better of me & I've dug out my Cyborg Evo from a dark corner of the room, calibrated it in Windows to set the dead zones and then...
set enabled=1 in the [JOYSTICK] section of ffed3daj.cfg.
I had to tweak its values slightly to cut out erroneous input: xdeadzone=80, ydeadzone=100 got it flying straight & true in space, away from any gravity influences. The settings are straight from JJFFE so I'd be guessing what the rest do... not sure the FAQ ever explained them?

Personally I don't think I could use a joystick in FFE after 5 minutes experimenting!* Left/right is just the same as dragging the mouse left or right and having played a lot of flight-sims in years long passed, that feels very "wrong"! My brain is obviously programmed to expect that the ship will roll not yaw with left/right input...

*[edit] turning on the "Others" option: "Elite control method in space" in fact switches left/right to roll just like a plane as soon as you take off - which is FAR better! But mouse is still always going to be far reaction-wise I'd have thought.

I am a Dunce (and sorry EidLeWeise for the wrong info!). It is right there in the 'ffewin.cfg' file. And i agree it feels 'wrong' using a joystick in Elite, and i never did get on with the 'Elite' method of control in Frontier or FFE, the game just seemed designed better for the mouse+keyboard, or maybe i just got so used to that on the Amiga, the other option never got a look in?

But yeah you can indeed use a joystick, and i suppose if you have a programmable one you can assign various keys to it. Mine only allows me to move the direction and fire the front laser. None of the other buttons activate anything and the throttle control is not recognised.

No, think I said in an earlier post/thread that it's the seam on the final edges of the skybox model that the game creates.
Anyway, just had a quick look and good news, the renderer just needed to set the sampler-state to CLAMP not WRAP before rendering the skybox. (and then restore the state afterwards)
4 lines of code and no more seam!

That is excellent! I might prefer the darker blue option over the complete black, and being able to test it out without that immersion breaking tear is going to be sweet, i look forward to that in your next update

In other texture news, i had noticed my 'docked in a space station' view seemed to be missing a texture. It appears the FFED3D install does not have the texture in place like the Ittiz version, so i had to copy paste 'Models\233' over from the Ittiz build into the FFED3D one to get the interior texture back. 'skin.png' in the default FFED3D file seems to be 0 bytes! I'll add that info to the first post for others.

 

[Steve]

Since I upgraded from Window$ 8 to 8.1 I've found v1.04 crashes when loading (at the splash screen). Got a corrupted blue screen followed by a system reboot.

I found out Avast v2014.9.0.2006 doesn't like the game, so I had to set up an exclusion within the File System Shield settings so it wouldn't scan FFED3DAJ on execute.

Not really sure whether the Windows upgrade or the latest version of Avast is the real culprit here, but feeling quite pleased with myself for fixing it

 

[AndyJ]

I wouldn't normally recommend excluding any .exe from a virus scan though... I wonder if your version having the large address support has any significance in that? blue screen of death isn't good though... if you'll brave another, do the older versions (or original v1.04) work ok without exclusions?

I'm still beavering away on the v1.05 build, opted to fix a few things rather than just throw out what was essentially just a quick rebuild.
Been working my way through all of the primitive ships (original game models) and hand-tweaking individual positions for their polys & texts at draw time so that ids and decals (like the sharks teeth) appear once again, and also to eliminate z-fighting such as the id on lynx carriers and the textures on the thargon transporter. (and it's been as long a task as it sounds as some adjustments are distance related too)
But it's looking a lot better now when playing without replacement models.

I've also coded the missing circular target reticule which flashes within the crosshairs when in battle mode and the computer is searching for a target, as well as sorted some of the 'ball' sizes on objects. ahem. (lights still to do in future)

Some tweaks still need to do on the squares that appear on space stations, wheel is ok but not the central section or dohecs yet. Also want to try fix the shimmery lines that represent windows. Not long now hopefully

 

[Steve]

I wouldn't normally recommend excluding any .exe from a virus scan though... I wonder if your version having the large address support has any significance in that? blue screen of death isn't good though... if you'll brave another, do the older versions (or original v1.04) work ok without exclusions?

It crashes on v1.03 as well. I would try the other builds but I think the computer would get fed up and I imagine it'll be the same result. Looks like it's an Avast thing

I'm still beavering away on the v1.05 build, opted to fix a few things rather than just throw out what was essentially just a quick rebuild.
Been working my way through all of the primitive ships (original game models) and hand-tweaking individual positions for their polys & texts at draw time so that ids and decals (like the sharks teeth) appear once again, and also to eliminate z-fighting such as the id on lynx carriers and the textures on the thargon transporter. (and it's been as long a task as it sounds as some adjustments are distance related too)
But it's looking a lot better now when playing without replacement models.

I've also coded the missing circular target reticule which flashes within the crosshairs when in battle mode and the computer is searching for a target, as well as sorted some of the 'ball' sizes on objects. ahem. (lights still to do in future)

Some tweaks still need to do on the squares that appear on space stations, wheel is ok but not the central section or dohecs yet. Also want to try fix the shimmery lines that represent windows. Not long now hopefully

As always, can't wait for another new build

 

[Zak Gordon]

Great news Andy, can't wait for a new patch version

@Steve, that sucks about the Windows 8 update. I'm happily sticking with Windows XP/Windows 7 for a while longer.

 

[Nagual]

Does anyone know if the Saitek X52 works with this version at all? I suspect the throttle won't, but perhaps the stick?

 

[Steve]

Great news Andy, can't wait for a new patch version

@Steve, that sucks about the Windows 8 update. I'm happily sticking with Windows XP/Windows 7 for a while longer.

It was an Avast issue rather than Window$. Now I'm using AVG it seems to be fixed

Regarding Windows 8.1, I'm quite happy with it. I did consider going with Windows 7 when I got my new PC, but obviously Microsoft will support 8 for longer.

 

[AndyJ]

Does anyone know if the Saitek X52 works with this version at all? I suspect the throttle won't, but perhaps the stick?

It should be able to see any joystick that's installed in Windows, it uses DirectInput to acquire it - the same as JJFFE/GLFFE I think.

Be sure to edit ffed3daj.cfg to enable the joystick and also calibrate it in the control panel to establish its ranges if you've just plugged it in.
In the game settings turn on 'Elite control method' (Others menu) and it's a good idea to fly into space well away from a planet to start with, and without touching the joystick see if it drifts at all. You'll want to increase the xdeadzone and/or ydeadzone values if it still does after calibration.
It seems quite happy with my Saitek Cyborg evo - needs to have the Saitek/MadCatz mapper software running to assign keys, but an experiment gave me view rotate (arrows) on the hat, ECM & Missile on buttons 4 & 5, engine mode on its F1 button.
Throttle I've left unmapped, but I set twist to be programmed in Bands with 0-33 mapped to ',' and 67-100% to '.' and this then gave yaw control too.

If it helps any, my [JOYSTICK] section values are as follow:
enabled=1
xmax=512
ymax=512
xexp=20
yexp=20
xdeadzone=80
ydeadzone=100
xmaxzone=20
ymaxzone=20


Think I'll add all of this to the readme too

There may be an issue if you have multiple joysticks/gamepads attached, as the code currently looks like it'll just grabs the 1st 'joystick' class device that it finds - which could be a gamepad instead if it's also plugged in. I can probably tighten that up a little and add a new preference setting to select by type: flightstick, joystick or gamepad, or the default of 'any' to retain current behaviour.

[edit] Ha! well, maybe it's not so straightforward to simply choose a preferred joystick/gamepad based on 'type' these days ...
My notion of what a gamepad "is" probably matched ye olde DirectInput 8, but looks like the distinction is a little blurred now...
Hoped it might just be a few lines of code, but a quick test and it simply prefers to pick my x-box 360 'gamepad' over my Cyborg 'flightstick' regardless of trying to specify a type. But then I guess an x-box controller isn't really a 'gamepad' in the old-school sense - it has lots of analog inputs too - so the distinction doesn't hold any more! Oh well, maybe one to revisit in the future!

 

[Nagual]

Thanks! I'll give it a bash later on!

 

[Orbitalai]

I need help with settings.

Every time I start the game, I have to set settings to high and make space black instead of blue.

Why does it not save that, and is there any way I can fix it?

 

[Steve]

I need help with settings.

Every time I start the game, I have to set settings to high and make space black instead of blue.

Why does it not save that, and is there any way I can fix it?

When you start the game from new you have to do the above but a saved game will have your preferences saved within it.

 

[Nagual]

It seems something must be amiss with my set up somewhere. I can get the x52 working to a point. I mapped the sticks x & y to the correct keys for pitch and roll, but in game I get pitch and yaw. Roll just doesn't want to roll. Pressing the key still works, just not with the stick. Tried mapping accelerate and brake to a toggle switch and nada. Tried to enable userkeybinds and remapped the keys, just incase.. and in game nothing changed, still Return and RShift for speed etc.

I think I'm going nuts.

 

[AndyJ]

You don't need to map keys for up/down left/right flight control, just enable the joystick in the ffed3daj.cfg file - i.e.

[JOYSTICK]
enabled=1

(If it doesn't do anything, is it the only connected game controller? FFE just grabs the first one - see my previous post)

If you want left/right to roll not yaw, then also make sure you've enabled the 'Elite control method' in the game menu (press Escape twice to get to the menu, the setting is found within the 'Others' submenu)

With elite control method enabled, I then mapped the twist function of mine to ,/. to get yaw, but stick left/right will roll.

With my Saitek stick there's a 'Profile Editor' as well as a separate 'Profiler' application. I have to start the Profiler application manually and have it running (and choose the FFE profile via right click on it's icon) for it to have effect on the game. (I could move Profiler to the Sartup group to have it load with Windows but I don't really use my Joystick)