I don't think radioactives from military fuel is a bug. That is by design. If the spent fuel didn't become radioactive then there would be no point in owning a standard drive.
The General BugFixing/Playtesting thread for FFED3D+mods
- Thread starter Zak Gordon
- Start date
I mostly never use the Military drives, but this is a good option for those that use them often. As this is a 'cheat' addition is it on by default or possible to change in the cfg file? Just thinking it might be good to give players the option to have it on of off as they prefer?
Going to download your update and give it a whirl. Thanks for your dedication!
Edit: Cool it is all in the cfg file, he he cross posts for the win!
Last edited:
Yes sorry Graham, the way I phrased it in my post as 'fixing a major bugbear of mine' did perhaps give the impression that I regarded it as a fix rather than a cheat. It's definitely a cheat, it's optional and isn't turned on by default. [cross posted with you there Zak - that answers your question!]
Personally I hate the radioactive generation, for me it fast became a bit of unnecessary admin to take care of every hyperspace - just in case you've entered a system where they're illegal... and of course I always forget about until I've docked and then get handed a fine for smuggling!
It's an aspect that I don't find to be fun so I prefer to look at it this way - if they have the technology to auto-refuel the engine, then why not the tech to auto-dump the by-products? Or perhaps one of my overpaid crew mates can get out of their bunk and go press the jettison button!
Personally I hate the radioactive generation, for me it fast became a bit of unnecessary admin to take care of every hyperspace - just in case you've entered a system where they're illegal... and of course I always forget about until I've docked and then get handed a fine for smuggling!
It's an aspect that I don't find to be fun so I prefer to look at it this way - if they have the technology to auto-refuel the engine, then why not the tech to auto-dump the by-products? Or perhaps one of my overpaid crew mates can get out of their bunk and go press the jettison button!
I hope that's not a garden shed, scale model Cobra project gone wrong? Should we call NASA to get you back?
No, just a holiday in the Caribbean
A place where, among many other good things such as rum punch and sunshine, I can see the likes of Achernar and Canopus with my own two eyes at night under lovely dark skies :smilie: :smilie:
Just a FYI kind of thing, i fired up version 1.05 to compare with 1.06 and took a fly around from the Mars and Hope (have to speed up time for 'day time' on Hope) starting positions and it looks like the added:
'darkerGreenLivingPlanets=1'
appears to not be working (in both 1.05 and 1.06)? I also tried adjusting the:
RedBase =
GreenBase =
BlueBase =
settings (between -10 and -50, not sure what the max setting is here (-100?)) to see if that dayglo green issue could be got rid off, but to no apparent effect.
Then i got thinking will these things only work in fullscreen mode perhaps?
'darkerGreenLivingPlanets=1'
appears to not be working (in both 1.05 and 1.06)? I also tried adjusting the:
RedBase =
GreenBase =
BlueBase =
settings (between -10 and -50, not sure what the max setting is here (-100?)) to see if that dayglo green issue could be got rid off, but to no apparent effect.
Then i got thinking will these things only work in fullscreen mode perhaps?
I'm sure it's not been altered since it was added in v1.03 and still works as expected here on build pc & test laptop with the v1.05a/v1.06 zips. Have you changed the ground textures 64/96? or perhaps the setting is repeated in your .cfg higher up and set to 0?
The base values are a forgotten throw-back to jjffe/glffe and only affects a single palette which is created at start up. That's all but unused, bar for a few text strings it seems. I'll remove them in the next build as they serve no real purpose now and won't be used by models with a skin/shader anyway.
The base values are a forgotten throw-back to jjffe/glffe and only affects a single palette which is created at start up. That's all but unused, bar for a few text strings it seems. I'll remove them in the next build as they serve no real purpose now and won't be used by models with a skin/shader anyway.
Thanks for the info, my cfg file seems in order and texture 64 is exactly the same as before (from the Ittiz mod?), that greyscale 'moonscape' texture, just smaller now (128x128 instead of Ittiz 512x512 size). Would a change in texture size effect the darker green for living planets adjustment you did?
Texture 96 is the ships cabin (and no changes were made to that). Speaking of the ships cabin, do you know what happened to the selection of different cabin backgrounds that the original game had? FFED3D seems to only use that same one for all the ships? Can we get the ones back for the different sized ships? (i can take the originals and see what i can do to spruce them up etc).
Edit: Ok i just ran some tests.
I replaced my texture 64 with Ittiz version, and then the original FFED3D one, and all the textures seem the same in terms of the dayglo green. But having said that this is now only noticeable on the coast, the 'shore' area next to the martian sea. The general land texture colour around Olympus Village is a darker green than in the original or before you made that change.
Try these steps to see better what i mean:
1. Start on Mars (2 on keyboard)
2. It is night so speed up time to max until you get the message about another days docking fee being taken.
3. You will see Sol just above the hanger in front of you (if you have the 'info' tab on!).
4. Take off and head in the direction you are facing, set speed around 8000 km/h.
5. Note the darker green of the Martian surface around you as you leave the vicinity of Olympus Village.
6. Now use the StarDreamer on the second speed setting and soon you will fly over the dark green hills and just as you hit the coast will see the dayglo green stuff. Bank right as you reach it and follow the shore line around a bit.
It seems it is just a coastal shoreline issue? What causes that so your darker green mod doesn't change these area's? Are separate values used for coasts and in-land landmasses maybe?
Anyway not a big issue, i just thought something wasn't working as intended, but it appear to be, just that the whole dayglo green issue is not completely gone.
Certainly not a big issue, so sorry if i raised a false alarm, however if it is possible to make those coastal area's less 'radioactive' that would = awesome (or i could just put my shades on when in those area's!)
Bit of a tangent to the general conversation but is there a simple way of modifying ship camera positions?
I'm running the Ittiz+AJ setup, and its amazing by the way, thanks to everybody who's put all this work into beautifying and bug squishing one of the greatest and most frustrating space sims of all time.
I was running one of the FFED3D setups, probably one of the russian variants, couldn't get panel icons or the navigation tunnels among other things and so would switch to a GLFFE setup for manual navigation.
But having returned to space to take the sting out of not being on the E: D Alpha I discovered these new builds have completely sorted those two issues for me... so much better for it.
*Spoiler Alert*
Now my problem is that having acquired the Thargoid Fighter my rear cockpit view is mostly obscured by the hull of the ship which makes rearguard combat effectively impossible and Main thruster deceleration burns frustrating
Is there an entry I could place in the shipdata config to move the view rearward to clear the hull?
I'm running the Ittiz+AJ setup, and its amazing by the way, thanks to everybody who's put all this work into beautifying and bug squishing one of the greatest and most frustrating space sims of all time.
I was running one of the FFED3D setups, probably one of the russian variants, couldn't get panel icons or the navigation tunnels among other things and so would switch to a GLFFE setup for manual navigation.
But having returned to space to take the sting out of not being on the E: D Alpha I discovered these new builds have completely sorted those two issues for me... so much better for it.
*Spoiler Alert*
Now my problem is that having acquired the Thargoid Fighter my rear cockpit view is mostly obscured by the hull of the ship which makes rearguard combat effectively impossible and Main thruster deceleration burns frustrating
Is there an entry I could place in the shipdata config to move the view rearward to clear the hull?
Hi Gauntlet!
Well I was going to reply "Yes" but unfortunately it doesn't support tweaking the front/rear gun positions or the view offsets, only the turrets. I must admit I'd not noticed this when I added this functionality from Nic's Mod.
I've had a quick experiment though and think that I've identified these data values. So I should be able to add support for them in a future patch once I've tested a bit more thoroughly.
In the mean time though, if you are feeling brave then you could use a hex-editor to alter the FFED3DAJ.exe file and correct the Thargon ship data.
I've just downloaded and used HxD Hex Editor which is freeware.
Open up the game exe in it and search (CTRL+F) for the following string, setting the type to hex-values:
00 01 53 07 32 02 53 07
There should only be 1 match, but press F3 to "search again" to be sure.
If you change the two bytes 32 02 that are in the highlighted block to be 78 10, then save the file, that should then fix the rear view for you.
Cheers
AndyJ
[edit: I did suggest values 00 04 originally, which was just enough to clear the view, but later found that the rear of the ship glitched into view again at a certain point when climbing through 360degrees)
Well I was going to reply "Yes" but unfortunately it doesn't support tweaking the front/rear gun positions or the view offsets, only the turrets. I must admit I'd not noticed this when I added this functionality from Nic's Mod.
I've had a quick experiment though and think that I've identified these data values. So I should be able to add support for them in a future patch once I've tested a bit more thoroughly.
In the mean time though, if you are feeling brave then you could use a hex-editor to alter the FFED3DAJ.exe file and correct the Thargon ship data.
I've just downloaded and used HxD Hex Editor which is freeware.
Open up the game exe in it and search (CTRL+F) for the following string, setting the type to hex-values:
00 01 53 07 32 02 53 07
There should only be 1 match, but press F3 to "search again" to be sure.
If you change the two bytes 32 02 that are in the highlighted block to be 78 10, then save the file, that should then fix the rear view for you.
Cheers
AndyJ
[edit: I did suggest values 00 04 originally, which was just enough to clear the view, but later found that the rear of the ship glitched into view again at a certain point when climbing through 360degrees)
Last edited:
Worked perfectly thanks and I'm impressed with rapid response AndyJ or did I just leave my stardreamer on high again?
Hex editing always feels so voodoo to me so backing up the exe before doing anything else was sufficient to make me brave enough to try.
Now I can perform that long manual reverse burn to New Rossyth and still see where I'm heading
Thanks again
Hex editing always feels so voodoo to me so backing up the exe before doing anything else was sufficient to make me brave enough to try.
Now I can perform that long manual reverse burn to New Rossyth and still see where I'm heading
Thanks again
No worries Gauntlet! I'm not sure how soon the next build will be so thought I'd help with a hex-edit rather than leave you hanging. Didn't mention back up as guess you'd have it in the patch zip, but that suggested editor does make a copy too.
But anyway it seems that going off on a tangent and poking around the ship stats might well have triggered a timely idea for solving my current challenge - resolving the sprite drawing vs objects. A little more poking around & commenting the .asm and I think I've located where that decision is made now.
At very least it looks like I can probably just force it always to draw star objects now, because they're scalable sprites anyway. Planets <seem> to be ok too - although they'll disappear if small and in shadow so need their dot after a certain point, but something else definitely isn't happy at the default start position and explodes all over the screen when zoomed out too far and it's "in view" - with what looks like a vector line draw towards the selected planet. very odd!
Anyway a BIG step forward - even if I can just isolate Suns and draw all other distant objects in game/system view as a generic blob then that'll be great, but looks like I might be able to do a per-object decision how far to zoom out on them before their actual object gets replaced!
at risk of further spoiler, Gauntlet, hope that you've had a good look at the ship's equipment before rushing all the way home for your pat on the back... I guess the Thargons spend all of their time flying around in space is my hint
But anyway it seems that going off on a tangent and poking around the ship stats might well have triggered a timely idea for solving my current challenge - resolving the sprite drawing vs objects. A little more poking around & commenting the .asm and I think I've located where that decision is made now.
At very least it looks like I can probably just force it always to draw star objects now, because they're scalable sprites anyway. Planets <seem> to be ok too - although they'll disappear if small and in shadow so need their dot after a certain point, but something else definitely isn't happy at the default start position and explodes all over the screen when zoomed out too far and it's "in view" - with what looks like a vector line draw towards the selected planet. very odd!
Anyway a BIG step forward - even if I can just isolate Suns and draw all other distant objects in game/system view as a generic blob then that'll be great, but looks like I might be able to do a per-object decision how far to zoom out on them before their actual object gets replaced!
at risk of further spoiler, Gauntlet, hope that you've had a good look at the ship's equipment before rushing all the way home for your pat on the back... I guess the Thargons spend all of their time flying around in space is my hint
But anyway it seems that going off on a tangent and poking around the ship stats might well have triggered a timely idea for solving my current challenge - resolving the sprite drawing vs objects. A little more poking around & commenting the .asm and I think I've located where that decision is made now.
At very least it looks like I can probably just force it always to draw star objects now, because they're scalable sprites anyway. Planets <seem> to be ok too - although they'll disappear if small and in shadow so need their dot after a certain point, but something else definitely isn't happy at the default start position and explodes all over the screen when zoomed out too far and it's "in view" - with what looks like a vector line draw towards the selected planet. very odd!
Anyway a BIG step forward - even if I can just isolate Suns and draw all other distant objects in game/system view as a generic blob then that'll be great, but looks like I might be able to do a per-object decision how far to zoom out on them before their actual object gets replaced!
My god, that sounds wonderful! I can only marvel ("Look, he marveled! Did you see him marvel, i did!") at those that can work out what to Hex edit in the wild.
I've done a bit in the past but without a guide i'd be as lost as the Commander of HMS Camden Lock in Hyperdrive (they need to bring that back on tv).
at risk of further spoiler, Gauntlet, hope that you've had a good look at the ship's equipment before rushing all the way home for your pat on the back... I guess the Thargons spend all of their time flying around in space is my hint
Indeed! that's why I was keen to be able to see where I was hurtling towards
Incidentally does anybody know what //snip// nevermind I figured it out //snip//
Once again thanks AndyJ and looking forward to the next release
Last edited:
@ Steve,
Did you do a complete reinstall recently? If so don't forget you need all of AndyJ's files not just the patch update one?
If it is not that, then yes it may well be the memory threshold issue, you could try tweaking your ini file to reduce the number of new skins etc? There is also my texture mod that will easily reduce the memory overhead, you'll get FFED3DAJ running with all models+skins loaded under 1 gb, and without a noticeable loss of quality.
Having said that i'm currently running v1.06 of AndyJ's so i might not be on the latest release? I lost track a little over the xmas period. Are you on that version or a newer release, as it might be related to that?
Did you do a complete reinstall recently? If so don't forget you need all of AndyJ's files not just the patch update one?
If it is not that, then yes it may well be the memory threshold issue, you could try tweaking your ini file to reduce the number of new skins etc? There is also my texture mod that will easily reduce the memory overhead, you'll get FFED3DAJ running with all models+skins loaded under 1 gb, and without a noticeable loss of quality.
Having said that i'm currently running v1.06 of AndyJ's so i might not be on the latest release? I lost track a little over the xmas period. Are you on that version or a newer release, as it might be related to that?