The General BugFixing/Playtesting thread for FFED3D+mods
- Thread starter Zak Gordon
- Start date
It's fantastic people are still working on this !
Indeed. I find it amazing that one man, AndyJ has managed to swat so many bugs where a team of programmers failed..
Just wondering if it's at all possible to sort out the "tidally locked planet" bug in FFE? For example, Anderton in the Anlave system (0,3) is just one of many instances of a planet which does not rotate at all and keeps one side facing permanently towards its parent star. I'm not sure that such a situation would be at all conducive to the development of life there, which is why I regard it as a bug rather than a feature
Any chance of looking at it Andy (or anyone who understands FFE code)?
Any chance of looking at it Andy (or anyone who understands FFE code)?
Why are tidally locked planets a bug?
Why wouldn't life develop in the terminator?
Why wouldn't life develop in the terminator?
Maybe it would, but that's not how it's portrayed in FFE. The tidally-locked planets in the game are the same as the ones which rotate ie. settlements all over the surface, not just restricted to the terminator. I accept that this was probably beyond the scope of the programmers in 1995, but I doubt they introduced tidal locking as a feature, rather that they mis-assigned a variable somewhere :smilie:
Current thinking is that the vast majority of tidally-locked objects orbit relatively closely to their much bigger parent object eg. The Moon and Earth. I have no problem with that being the case in FFE.
Titan is another easy to visit example in the Sol system. (Edit: Ok, so learned something new, that moons are often tidally-locked to their parent planet and this would seem to be correct)
I don't know what actually generates a planet's rotational value -and it's sure to be buried deep in some horrific piece of undiscovered FFE assembly code- but I do know that FUNC_000866 checks for it at JUMP_003593 (object struct +0xc8 offset is rotational speed).
If this value is 0 then the object isn't rotated - so it's simple just to override a 0 value to 1 to test, and sure enough Titan then starts rotating and also Scott Town on Homeland (Beta Hydri 0,-2) is freed from its perpetual darkness and sees sunlight and blue sky.
From literally 15 minutes of testing (flying from Scott Town to MacKenzie High, waiting a couple of days then flying back to Scott Town) it doesn't appear to impede the nav computer any more than usual - landed fine 4 out of 5 times with one flight mainly at x3 speed failing to slow the ship enough and it deciding to add a new 'feature' crater just outside of the starport! So, no apparent change there then, lol.
I guess there would need to be some rules of what objects to apply any such tweak to, or perhaps just a configuration file 'patch' flag to override all 'living' planets if the 'no rotation' situation isn't wanted? Anyway I'm not going to pile in and alter anything just yet, will wait for feedback/opinions.
I don't know what actually generates a planet's rotational value -and it's sure to be buried deep in some horrific piece of undiscovered FFE assembly code- but I do know that FUNC_000866 checks for it at JUMP_003593 (object struct +0xc8 offset is rotational speed).
If this value is 0 then the object isn't rotated - so it's simple just to override a 0 value to 1 to test, and sure enough Titan then starts rotating and also Scott Town on Homeland (Beta Hydri 0,-2) is freed from its perpetual darkness and sees sunlight and blue sky.
From literally 15 minutes of testing (flying from Scott Town to MacKenzie High, waiting a couple of days then flying back to Scott Town) it doesn't appear to impede the nav computer any more than usual - landed fine 4 out of 5 times with one flight mainly at x3 speed failing to slow the ship enough and it deciding to add a new 'feature' crater just outside of the starport! So, no apparent change there then, lol.
I guess there would need to be some rules of what objects to apply any such tweak to, or perhaps just a configuration file 'patch' flag to override all 'living' planets if the 'no rotation' situation isn't wanted? Anyway I'm not going to pile in and alter anything just yet, will wait for feedback/opinions.
Last edited:
Thanks for looking into this Andy.
I would welcome a configuration flag to get the planets rotating if desired.
The only exception to this would be Discovery in the Arcturus system, which according to its Frontier Gazetteer entry has seasons around 7 Earth years long. It's quite interesting being docked at Nesbittport and watching the clouds scurry overhead on Stardreamer x 5 while the star remains stationary just above the horizon
But otherwise, as per my earlier post, it'd be good if the planets that should rotate do. There are plenty of tidally locked objects just in our own Solar system, such as the Moon and Titan, and I certainly don't think they should change. It's just the planets that - as far as I can understand - should be rotating but aren't.
Did that make sense?
I would welcome a configuration flag to get the planets rotating if desired.
The only exception to this would be Discovery in the Arcturus system, which according to its Frontier Gazetteer entry has seasons around 7 Earth years long. It's quite interesting being docked at Nesbittport and watching the clouds scurry overhead on Stardreamer x 5 while the star remains stationary just above the horizon
But otherwise, as per my earlier post, it'd be good if the planets that should rotate do. There are plenty of tidally locked objects just in our own Solar system, such as the Moon and Titan, and I certainly don't think they should change. It's just the planets that - as far as I can understand - should be rotating but aren't.
Did that make sense?
Last edited:
...
Ah, the bane of all software developers ... that 'only exception' ... well, if there's one then then there's probably a bucket load!
but I wonder though if the rotation would break the 7 year season idea or not. Whilst the planet would now be rotating through a night and day cycle about its own axis, I don't think that would necessarily change the concept of a 7 year season for the planet? I'm a little behind with my 'sky at night' series, oh by a decade or three, so I'm catching up a tad here - but I think that the season length would be determined by the tilt of the planet/shape of orbit and so a daily rotation happening is actually ok and wouldn't affect that?
(btw. the clouds are completely independent of anything meaningful in FFE, the texture is simply scaled around the planet and rotated each game tick)
The Gazetteer entry does refer to long periods of permanent daylight or night time, so a day/night cycle would be contrary to this
The strange way of life for the natives would seem to be caused by a combination of the planet's inclination and its lack of rotation.
You're right though; if there's one exception, there are probably thousands
The strange way of life for the natives would seem to be caused by a combination of the planet's inclination and its lack of rotation.
You're right though; if there's one exception, there are probably thousands
Well the entry doesn't say that there aren't periods of day/night cycle, only that there's a daunting 7 year winter season of almost permanent darkness?
After reading this explanation of Uranus' 21 year seasons, would the following apply to Discovery? (I'm assuming that 'seasons' are reliant upon a planet having tilt, no tilt = no seasons)
7 years where the northern hemisphere is in permanent daylight (summer)
7 years of day/night (autumn)
7 years of darkness on the northern hemisphere (winter)
7 years of day/night (spring) ?
Unfortunately though, I don't think that Discovery actually has any tilt in FFE ... so it probably wouldn't exhibit any seasonal differences if you sat and accelerated through 7-28 years of game time and watched it!
After reading this explanation of Uranus' 21 year seasons, would the following apply to Discovery? (I'm assuming that 'seasons' are reliant upon a planet having tilt, no tilt = no seasons)
7 years where the northern hemisphere is in permanent daylight (summer)
7 years of day/night (autumn)
7 years of darkness on the northern hemisphere (winter)
7 years of day/night (spring) ?
Unfortunately though, I don't think that Discovery actually has any tilt in FFE ... so it probably wouldn't exhibit any seasonal differences if you sat and accelerated through 7-28 years of game time and watched it!
Yep, you're absolutely right. After all, the polar regions of Earth have periods of permanent daylight/night but that doesn't mean the Earth has stopped rotating!
So, if we wanted to get Discovery behaving the way the Gazetteer describes, it would need to rotate on its own axis but that axis would be pretty much parallel with its orbital plane. Like Uranus in our own Solar system.
Ok Andy, can you make it happen?
So, if we wanted to get Discovery behaving the way the Gazetteer describes, it would need to rotate on its own axis but that axis would be pretty much parallel with its orbital plane. Like Uranus in our own Solar system.
Ok Andy, can you make it happen?
Dunno if this has been stated but with just FFED3D-beta3-Ittiz 0.3 installed sound and music don't seem to work. It's a problem with some of the texture files being too big (I think). It runs fine with AJ's patch on top tho.
Great mod btw! Really enjoying it.
Great mod btw! Really enjoying it.
@AndyJ Do you know if/how the custom sound folder works, it seems that it doesn't work, as far as my mate has played with it, he's been trying to add background noises to the game (changing laser noises etc aren't worth it as a split second sound is much the same as another. He ended up changing a few of the music tracks instead, so station now has stationy sounds instead of whatever music there was, same with certain flight situations. Makes standard ship clunks etc not stick out so much, and blends quite well.
Hi Nagual - I hadn't really noticed the custom music folders until you've asked!
[edit: corrected description of custom music after a better look/test of it]
The implementation is intending that you can drop one or more .mp3 file into each sub folder and it will then randomly play one of them.
The battle and docking folders are supposed to be used when FFED3D wants to play the fight/docking music. It's simply checking for the track being index #21 for battle or #22 for docking. So this is unfortunate as it isn't actually context aware, and as there are actually only 17 music entries in any case! #15 is Ride of the Valkries, #16 Blue Danube.
[edit2] well having scoured the .asm and also checked back to the r16/17 FFED3D sources it seems that the 21/22 index values were deliberate - as FFE, with continuous music enabled, will select randomly from all of the music tracks. indices 21/22 are used to denote when the docking/combat music does reflect the situation rather than these tracks just being selected for play. This works for selecting the custom music, but I guess they forgot it'd break the standard music tracks as it's looking for track names in the array with invalid indices. I hadn't realised this before, due to not playing with music, as well as my PC soundcard and laptop breaking last summer. (thankfully both now fixed)
I've fixed the routine in the C code anyway to fall back correctly for tracks 21/22.
There are two more distinct scenarios that I've found - I think when you're promoted it'll play track #8 'paradise' and for an unidentified scenario it'll play track #17 'great gates of Kiev'. I could add new custom folders for these?
The station folder is intended to cover being docked at a star port as well as a space station. This attempted to check the player's state but it's checking the status value via an int data type rather than a byte - so this one generally fails as it erroneously picks up extra data in the value.
If the player isn't docked then any other tracks will attempt to play a song from the Space folder. Not what I'd expect either.
So in short, this feature is currently a load of Meh!!!
It would be easy to correct/add status checks to see if the player actually is in combat, docking or landed/docked and play from the appropriate folder. I would at least go one step further though and extend the station to have separate folders to differentiate between open air star ports, subterranean bays and space stations. Maybe station types, system allegiance etc should be considered too! what do people think?
As far as samples go, there's only a limited set and reuse would probably be an issue as it stands. Their names are currently hardcoded into a 28-element array, much of which is mapped to the zero byte 'nowt.raw' and for example the wind noise 'airopen.raw' is defined in there 4 times. Whether any of the slots holding 'nowt.raw' are referenced, I've no idea - but given the state of the video tables, probably not. Unlike the video tables though, this one is held in the FFED3D C code so could probably be exposed for customisation at a later date.
If you wanted to replace a sample then it looks like they need to be saved in raw 16-bit PCM format and they're monophonic (1 channel) @ 22.05 kHz.
[edit: corrected description of custom music after a better look/test of it]
The implementation is intending that you can drop one or more .mp3 file into each sub folder and it will then randomly play one of them.
The battle and docking folders are supposed to be used when FFED3D wants to play the fight/docking music. It's simply checking for the track being index #21 for battle or #22 for docking. So this is unfortunate as it isn't actually context aware, and as there are actually only 17 music entries in any case! #15 is Ride of the Valkries, #16 Blue Danube.
[edit2] well having scoured the .asm and also checked back to the r16/17 FFED3D sources it seems that the 21/22 index values were deliberate - as FFE, with continuous music enabled, will select randomly from all of the music tracks. indices 21/22 are used to denote when the docking/combat music does reflect the situation rather than these tracks just being selected for play. This works for selecting the custom music, but I guess they forgot it'd break the standard music tracks as it's looking for track names in the array with invalid indices. I hadn't realised this before, due to not playing with music, as well as my PC soundcard and laptop breaking last summer. (thankfully both now fixed)
I've fixed the routine in the C code anyway to fall back correctly for tracks 21/22.
There are two more distinct scenarios that I've found - I think when you're promoted it'll play track #8 'paradise' and for an unidentified scenario it'll play track #17 'great gates of Kiev'. I could add new custom folders for these?
The station folder is intended to cover being docked at a star port as well as a space station. This attempted to check the player's state but it's checking the status value via an int data type rather than a byte - so this one generally fails as it erroneously picks up extra data in the value.
If the player isn't docked then any other tracks will attempt to play a song from the Space folder. Not what I'd expect either.
So in short, this feature is currently a load of Meh!!!
It would be easy to correct/add status checks to see if the player actually is in combat, docking or landed/docked and play from the appropriate folder. I would at least go one step further though and extend the station to have separate folders to differentiate between open air star ports, subterranean bays and space stations. Maybe station types, system allegiance etc should be considered too! what do people think?
As far as samples go, there's only a limited set and reuse would probably be an issue as it stands. Their names are currently hardcoded into a 28-element array, much of which is mapped to the zero byte 'nowt.raw' and for example the wind noise 'airopen.raw' is defined in there 4 times. Whether any of the slots holding 'nowt.raw' are referenced, I've no idea - but given the state of the video tables, probably not. Unlike the video tables though, this one is held in the FFED3D C code so could probably be exposed for customisation at a later date.
If you wanted to replace a sample then it looks like they need to be saved in raw 16-bit PCM format and they're monophonic (1 channel) @ 22.05 kHz.
Last edited:
There are alternate sound files for FFE available in the SSC download area if there are any use to you.
Hey - do you mean if you run the AndyJ executable it runs fine? Or do you mean that applying AndyJ's patch on top and running the original FFED3D.exe executable fixed it?
I tried Ittiz's patch a while ago and just couldn't get the sound working on it at all.
No, the FFED3D exe won't work fine from that pack.
The idea is to use the Ittiz pack for the resources - it's essentially the full beta 1.12++ pack with all the models enabled, but it also has the videos and some additional texture changes.
The FFED3D exe will try to load all of the models and textures which will blow memory limits, and so when it dynamically loads music/sounds it'll fail to do so (assuming it hasn't crashed/hung on start-up).
You would need to add my patch and at least the supporting core textures zip over the top and then should run FFED3DAJ.exe or the anisotropic mod variant FFED3DAJ_Anisotropic.exe. These builds will manage models to keep memory free and (hopefully) avoid crashing - settings are explained in the readme file and may need tweaking. x64 Windows users with 4GB or more memory should be able to enable the precache setting that loads everything as it's large-address aware, unlike the original builds.
The idea is to use the Ittiz pack for the resources - it's essentially the full beta 1.12++ pack with all the models enabled, but it also has the videos and some additional texture changes.
The FFED3D exe will try to load all of the models and textures which will blow memory limits, and so when it dynamically loads music/sounds it'll fail to do so (assuming it hasn't crashed/hung on start-up).
You would need to add my patch and at least the supporting core textures zip over the top and then should run FFED3DAJ.exe or the anisotropic mod variant FFED3DAJ_Anisotropic.exe. These builds will manage models to keep memory free and (hopefully) avoid crashing - settings are explained in the readme file and may need tweaking. x64 Windows users with 4GB or more memory should be able to enable the precache setting that loads everything as it's large-address aware, unlike the original builds.
It only works if you click on the FFED3DAJ icon (not the normal FFE3DE exe) when you merge the AJ patch over ittiz's beta 3. I was tearing my hair out trying to get sound on unpatched ittiz's beta 3 FFE. I did manage to get it going without the patch but it requires fiddling with the texture files.
Hi Captain Lee.
I never have an issue with the music/sound in my build of FFED3DAJ.exe.
I don't use Ittiz as a base (various graphics bugs etc), so that may be why? I use the russian download for FFED3D then install Andy's version over that (don't forget all three parts, the patch, the textures and the models). All details of that process are in the first post of this thread. Just to give you another option to the common method others use (like AndyJ etc).
After that i use my 'ZGTexture+ModelMod' file to allow me to run it in under 1GB of system ram and get all the ships textures loaded in at one time. I also use my 'ZGFFED3DMusicMod' to get better (in my humble opinion) music tracks in place of a few of the old default tracks.
I personally find this the 'nicest' version of FFED3DAJ to play. After installing all that i then make a shortcut to my desktop for the FFED3DAJ.exe (that will be in whatever directory you installed everything in, probably along with the default FFED3D.exe and the FFED3DAJ_Anisotropic.exe files) and run from that. You only need the shortcut to run from the FFED3DAJ.exe to ensure you are running the latest version/build of AndyJ's mod and FFED3D.
=================
Currently testing the new v1.07 patch build. Loads (935,276KB used), music plays etc. Will report more later as i discover things, and i will update the OP for the new stuff this version has fixed
I never have an issue with the music/sound in my build of FFED3DAJ.exe.
I don't use Ittiz as a base (various graphics bugs etc), so that may be why? I use the russian download for FFED3D then install Andy's version over that (don't forget all three parts, the patch, the textures and the models). All details of that process are in the first post of this thread. Just to give you another option to the common method others use (like AndyJ etc).
After that i use my 'ZGTexture+ModelMod' file to allow me to run it in under 1GB of system ram and get all the ships textures loaded in at one time. I also use my 'ZGFFED3DMusicMod' to get better (in my humble opinion) music tracks in place of a few of the old default tracks.
I personally find this the 'nicest' version of FFED3DAJ to play. After installing all that i then make a shortcut to my desktop for the FFED3DAJ.exe (that will be in whatever directory you installed everything in, probably along with the default FFED3D.exe and the FFED3DAJ_Anisotropic.exe files) and run from that. You only need the shortcut to run from the FFED3DAJ.exe to ensure you are running the latest version/build of AndyJ's mod and FFED3D.
=================
Currently testing the new v1.07 patch build. Loads (935,276KB used), music plays etc. Will report more later as i discover things, and i will update the OP for the new stuff this version has fixed
Last edited: