Cheers Donik! Good to hear you're enjoying it! 
It was the same in JJFFE (which FFED3D/AJ is derived from) and I think most likely happened in FFE too. The shuttle behaves in the same way as an orbital space-station or star port and does think that all of its docking bays are full. Presumably there should be an AI ship docked there, but when this has happened for me, days can pass without anything launching.
Unfortunately you'll probably have to load a previous save, or hyperspace out and back into the system again and then see if it'll allow you to dock. I think that reloading a saved game where you're already in the system will be consistent in not allowing docking- it's probably something that was decided upon when initialising the system after hyperspace.
I found where the bay-allocation is dealt with in the assembly code when extending the docking music. Each station has its own list of available pads/bays and each will have a ship reference assigned to it when one is docked or cleared to dock there. So I must get around to checking why the shuttle won't let you dock! I suspect it could well be a bug as the Buffet utility doesn't show any ships in the system with the shuttle as their current target and even destroying all of the ships doesn't resolve the problem.
The other thing about the shuttle...
It was the same in JJFFE (which FFED3D/AJ is derived from) and I think most likely happened in FFE too. The shuttle behaves in the same way as an orbital space-station or star port and does think that all of its docking bays are full. Presumably there should be an AI ship docked there, but when this has happened for me, days can pass without anything launching.
Unfortunately you'll probably have to load a previous save, or hyperspace out and back into the system again and then see if it'll allow you to dock. I think that reloading a saved game where you're already in the system will be consistent in not allowing docking- it's probably something that was decided upon when initialising the system after hyperspace.
I found where the bay-allocation is dealt with in the assembly code when extending the docking music. Each station has its own list of available pads/bays and each will have a ship reference assigned to it when one is docked or cleared to dock there. So I must get around to checking why the shuttle won't let you dock! I suspect it could well be a bug as the Buffet utility doesn't show any ships in the system with the shuttle as their current target and even destroying all of the ships doesn't resolve the problem.
The other thing about the shuttle...
I also wonder if the journey really was meant to be a 1-way ticket between systems or if this is another bug? It seems a bit too unexpected to then have to make your own way home with a military drive!
At least if your ship had been fitted with a standard drive you could have then scooped fuel if you didn't have enough... I did get stranded the first time I played
At least if your ship had been fitted with a standard drive you could have then scooped fuel if you didn't have enough... I did get stranded the first time I played
Last edited:
Thanks for the response. I'll have a 4th attempt
I noticed that the shuttle gave me a 3,000cr fine for dumping radioactives, and a further fine for swatting one of the pesky INRA ships whilst waiting for a free pad. Litigious lot those Thargoids. And thanks for keeping the game alive!
Oh my god I had a very similar issue with my terrain code about 14 years ago...
The goal was to get smooth blending between sets of textures based on height and other factors, which worked fine until I started adding terrain LOD, which of course completely changes the entire texture coordinate system everytime you merge several tris into one:
It took me quite some time to get from this...
...to this...
Do you have LOD in that terrain too perchance?
This is why I love contributing to the game. This is exactly the same reason I enjoy playing it - it takes me back to the same age and memories, but now with infinitely more clarity.Just wanted to pop in and say excellent work! You guys have really made this game come alive for me again. I felt age 14 all over, for the last week or so. Keep up the great job, I'm really excited to see what else you guys can do
Last edited:
The terrain in FFE is generated every frame and the complexity/LOD is based upon both the game settings and also how far away you currently are from the planet. It doesn't just generate a local area either, it calculates the whole planet - I think it starts out as a basic Icosahedron and then keeps subdividing the triangles with some variation to eventually generate each planet's unique terrain.
This is why it can tax the CPU so much as you approach planets and even more so if you increase the 'max-divide' settings in the .cfg file.
I've not really tried to correlate the code against the theory, but possibly this article is quite close to how it works. (or should work...)
FFED3D has converted much of FFE's terrain generation routines from Assembly code into pseudo-C code, replacing jumps with if statements and for loops - but it still uses variable names based from the registers (eax, esi) or analogous to the function's input parameter offset values (ebp_20, ebp_24) or direct memory addresses e.g. *(int*)DATA_009269 = *(int*)DATA_007837; or offsets into unknown tables ... there's not much in the way of description to explain how any of it is working!
So it's still pretty much a collection of undocumented 'black box' routines which ultimately spit out the 3 triangle points, each with (broken) texture uv values and an RGB value.
The triangles use vertex colour blending which I'd guess is what your final screenshot is also doing. I'm having to specifically catch some of these colours in certain places though and then override the colours to stop the sea/land bleeding into each other. (it's all good fun!)
Not too sure yet how to scale/repeat a texture if the triangle is larger/smaller than a base size... For example a ridgeline triangle might simplify itself from 3, to one large triangle as you fly away from it. So an area ends up with an expanded version of the texture compared to its neighbours. Probably obvious stuff for anyone who's experienced in this kind of 3D, but it's all very much a learn-everything-as-I-go-along experience for me! Knew nothing even about D3D when I picked this up, so working it all out one challenge at a time!
Well I was getting a little triangle'd-out so took a detour into the docking bays for a change of scenery. Slightly amused at what I found with my own broken 2nd mission save! The shuttle has 4 bays in total, and there's 2 bays with INRA '+' ships docked in them, and ... wait for it ... 2 bays with space dust in them! Yes. Dust!
So not only are the Thargons a Litigious lot, they're apparently not very house proud either and have let their gaff go to rack & ruin!
I will have to figure out now how this came to be - dust is an object with AI but surely it isn't sentient enough to request docking clearance!!!
Knowing that there are duff entries in the docking bays though - I might now be able to alter the function not just to check if a bay is occupied, but also to check if it's occupied by a valid AI ship or the player and if not, allow it to be used!
Yeah that was exactly what I was struggling with back then, for about a week I think. Mind you, that was plain C and opengl and I didn't work with some existing codebase, so you are probably having a bit of a harder time there.
I can try and dig up the old code but I dunno how applicable this is to FFED3DAJ (what a godawful abbreviation btw
)Well I'd certainly appreciate any pointers. I know the triangle co-ordinates & planet's centre, distance from camera... there's a routine in there that texture maps spheres and scales correctly - but all textures are then aligned in a single direction which isn't what FFE needs... how to work out the size/orientation of a 'vertical' triangle vs a flat neighbour? Probably I'd need to decipher the routines a little more and work out what they're doing first though, otherwise I'm stuck catching output and fixing it after the fact...
FFED3DAJ (what a godawful abbreviation btw
Yeah isn't it just!
It seemed an honourable name at the time when I was just fixing up FFED3D. I have considered simplifying & renaming it to AJFFE lately - I've probably put the work in by now to justify a rename, but it's probably extremely egocentric to do so - and didn't want to invite any derision!! Doing so would also break the obvious link to FFED3D, of which assets it still relies on!!!
If people think it should/could be made a little easier to type though, well I'm all ears
So not only are the Thargons a Litigious lot, they're apparently not very house proud either and have let their gaff go to rack & ruin!
I will have to figure out now how this came to be - dust is an object with AI but surely it isn't sentient enough to request docking clearance!!!
Knowing that there are duff entries in the docking bays though - I might now be able to alter the function not just to check if a bay is occupied, but also to check if it's occupied by a valid AI ship or the player and if not, allow it to be used!
Now that's made me laugh! Not only were Thargoids brought low by fungal infection of their hyperdrives, it also seems they have a 'grey goo', sentient rogue nanotech problem.
Thanks for looking!
Now that's made me laugh! Not only were Thargoids brought low by fungal infection of their hyperdrives, it also seems they have a 'grey goo', sentient rogue nanotech problem.
Thanks for looking!
Well turns out that the mystery of the docking bay dust was not too difficult to explain: it wasn't due to malfunctioning Thargoid vacuum-cleaners after all, their unique icosahedron multi-vortex design does indeed reach every particle in this space or witch space.
In my test case it appears that using BUFFET to <cough>cheat</cough> your way past lots of aggressive INRA ships for the final 2AU... well, clearly it should be used with caution!
If you do use it to blindly remove all ships from the list then there's a good chance you might delete one that's docked. (Not sure why they were docked, that's possibly another issue!)
BUFFET must simply clear out the object data but misses the index that also points to it in a station's docked objects list. So when a new object is created later on, in this instance - some space dust - well there's a chance it'll reuse that index reference.
I think there's likely an issue with AI ships hogging docking spaces, but also a cautionary tale that "easing your journey" can lead to its own issues too!
Oh I should add that if you're being hounded by INRA (+) ships in mission 2...
did you destroy their defence satellite that was orbiting one of the planets near Turner's wrecked ship in mission 1? I obviously didn't
Last edited:
Oh I should add that if you're being hounded by INRA (+) ships in mission 2...
did you destroy their defence satellite that was orbiting one of the planets near Turner's wrecked ship in mission 1? I obviously didn't
I was aware that you had to destroy the satellite, lest you are beset by INRA, but I didn't, due to being unable to pick up a nuclear missile from a military mission on time. I believe a nuke is the only way to destroy the satellite in the 'Hidden System' mission?
That's right... if you don't take the right equipment along on the first of the final storyline missions, then you'll be hounded for ever more! And that kind of kills the game if you want to continue beyond the final mission ... and well, it makes the other missions pretty miserable too!
A big thankyou
Just wanted to give my thanks to AndyJ for all the work on this- its been great playing it again, better than it ever was.
But in particular I want to say an overdue thanks for your response a while back to another poster, Nagual, who mentioned that his friend had been mucking about with the music files and found some problems. I am the friend he mentioned.
Your response was so far beyond anything I thought you might be able to do and has allowed to me to set up my game with just the sound I wanted, playing when it should, that I have been meaning to post and thank you for it for far too long.
So cheers AndyJ for all your hard work and looking forward to the texture improvements when they come.
Just wanted to give my thanks to AndyJ for all the work on this- its been great playing it again, better than it ever was.
But in particular I want to say an overdue thanks for your response a while back to another poster, Nagual, who mentioned that his friend had been mucking about with the music files and found some problems. I am the friend he mentioned.
Your response was so far beyond anything I thought you might be able to do and has allowed to me to set up my game with just the sound I wanted, playing when it should, that I have been meaning to post and thank you for it for far too long.
So cheers AndyJ for all your hard work and looking forward to the texture improvements when they come.
aw cheers pettytyrant101 that's much appreciated, and welcome to the forum!
thanks for letting me know the music playlists worked out how you wanted them - that's really great to hear!
Sorry it's been a bit quiet here lately!
I took a couple weeks break from the terrain texturing to gain some fresh perspective. Rather than just attack things purely from a coding angle, I decided to take some time to look at the influence that the textures themselves had, as well as compare FFED3D's planet code to that in the FFE.
There were some glitches especially on Mars that proved to be sensitive to the design of the texture, and it became clear that in the main, hillsides should continue to use an extended texture (e.g. tex94) and that it was best just to let the FFE code draw ranges from it and generate certain features such as ridges. Some of the texturing glitches were pretty much solved just by ensuring that the texture has a pattern/blotchy detail at a specific position. That narrowed my focus and I ended up just adding a couple more areas to help blend things in.
So unless any issues crop up, I'm happy that coding is complete on the re-texturing and nanite2000 is now updating his textures to utilise the latest changes. We're looking to release the next build and texture pack at the same time, and I think it's only fair after all the effort he's already put in, that he has enough time to get his texture set just as he wants them. I'll be heading off to the communication black-hole of Glastonbury festival in a week anyway so we're provisionally thinking that a possible v1.10 release 2nd week July is workable! :smilie:
Apart from the new texture support, v1.10 has also extended the depth sorting introduced in v1.08 so that it now applies to all models. The planetary view remains a law-unto-itself, it seems to draw things differently, but the game views will now eclipse planets/suns as you'd expect and if you have a ship with a transparent cockpit it'll show models on the opposite side in the external view. (external .x model transparencies still aren't 100% correct, but they're miles better than before)
There's also a new feature that extends the detail draw distance - so if you fly away from a city block now it won't just disappear and you'll even be able see the windows from miles away! (something I know Zak will appreciate!)
Some of the large star ports like New San Francisco or Tokyo are pretty detailed now with the number of models being drawn! And this will tax older PCs/Laptops so of course, it's something that can be switched off!
various other tweaks and fixes too, and hopefully even Steve's missing button issue has been squished by the renderer rework - so just a little wait yet, but v1.10 is looking quite tasty at the moment!
thanks for letting me know the music playlists worked out how you wanted them - that's really great to hear!
Sorry it's been a bit quiet here lately!
I took a couple weeks break from the terrain texturing to gain some fresh perspective. Rather than just attack things purely from a coding angle, I decided to take some time to look at the influence that the textures themselves had, as well as compare FFED3D's planet code to that in the FFE.
There were some glitches especially on Mars that proved to be sensitive to the design of the texture, and it became clear that in the main, hillsides should continue to use an extended texture (e.g. tex94) and that it was best just to let the FFE code draw ranges from it and generate certain features such as ridges. Some of the texturing glitches were pretty much solved just by ensuring that the texture has a pattern/blotchy detail at a specific position. That narrowed my focus and I ended up just adding a couple more areas to help blend things in.
So unless any issues crop up, I'm happy that coding is complete on the re-texturing and nanite2000 is now updating his textures to utilise the latest changes. We're looking to release the next build and texture pack at the same time, and I think it's only fair after all the effort he's already put in, that he has enough time to get his texture set just as he wants them. I'll be heading off to the communication black-hole of Glastonbury festival in a week anyway so we're provisionally thinking that a possible v1.10 release 2nd week July is workable! :smilie:
Apart from the new texture support, v1.10 has also extended the depth sorting introduced in v1.08 so that it now applies to all models. The planetary view remains a law-unto-itself, it seems to draw things differently, but the game views will now eclipse planets/suns as you'd expect and if you have a ship with a transparent cockpit it'll show models on the opposite side in the external view. (external .x model transparencies still aren't 100% correct, but they're miles better than before)
There's also a new feature that extends the detail draw distance - so if you fly away from a city block now it won't just disappear and you'll even be able see the windows from miles away! (something I know Zak will appreciate!)
Some of the large star ports like New San Francisco or Tokyo are pretty detailed now with the number of models being drawn! And this will tax older PCs/Laptops so of course, it's something that can be switched off!
various other tweaks and fixes too, and hopefully even Steve's missing button issue has been squished by the renderer rework - so just a little wait yet, but v1.10 is looking quite tasty at the moment!
Last edited:
Back from a fortnight of Glastonbury and British Summertime Festival and my feet may be broken, but my eyes are fresh! A quick look again at implementing the new atmosphere shader and Eureka!
Yep, that's Alex Peterson's (petrocket) "Simple Flexibile Atmosphere Shader" running within FFED3DAJ with a reworked cloud layer and an early set of nanite2000's terrain textures!
The inner atmosphere (sky) view still needs some work as the alpha transparency is completely back-to-front (stars during day, nothing at night) but it's on the right path now!
This should also mean that other gaseous planets and thin-atmosphere bodies can have unique atmospheres assigned to them, so I'm going to look at making it soft-codable via the textures .cfg files. This'll obviously put a slight dent in the release date of the v1.10 build, but atmospheres were the last of my major goals to achieve in FFED3DAJ - so forgive my indulgence!
[edited 28/08/2018 to update image URLs to postimg.cc]
Yep, that's Alex Peterson's (petrocket) "Simple Flexibile Atmosphere Shader" running within FFED3DAJ with a reworked cloud layer and an early set of nanite2000's terrain textures!
The inner atmosphere (sky) view still needs some work as the alpha transparency is completely back-to-front (stars during day, nothing at night) but it's on the right path now!
This should also mean that other gaseous planets and thin-atmosphere bodies can have unique atmospheres assigned to them, so I'm going to look at making it soft-codable via the textures .cfg files. This'll obviously put a slight dent in the release date of the v1.10 build, but atmospheres were the last of my major goals to achieve in FFED3DAJ - so forgive my indulgence!
[edited 28/08/2018 to update image URLs to postimg.cc]
Last edited:
wow
that looks tasty indeed- great work.
that looks tasty indeed- great work.
Back from a fortnight of Glastonbury and British Summertime Festival and my feet may be broken, but my eyes are fresh! A quick look again at implementing the new atmosphere shader and Eureka!
Holy crap AndyJ! That looks awesome! Yay Glasto!
amazing! looking very very nice indeed, good stuff AndyJ