Hi TehnoMag - Good to see you! Thanks for all the work yourself & DreamZ put into it!
No, no!And hey! you delete my wingman`s feature! How dear you!!!
It's because originally I carried on from an early version of FFED3D source (before it switched to use the Aniso mod) and focused on getting that stable.
People (Bounder) had asked about adding wingmen for a while after v1.11, so I eventually added them again for beta v1.14 with a few tweaks of my own - along with my own take of a dev console to investigate a bug report at the time. (own script parser, not LUA as that got rejected in the early days because I never got it to play nice with debug mode)
If you grab the current beta build then you'll be able to play around with them once again.
(You need to add it over a full installation, see post #1 for info & the beta link)
Right on Commander!
o7
Yes, I've already watched the last build.
By the way, have you tried working with the surface generator that DreamZ did? I can see that the old one is still in use
By the way, have you tried working with the surface generator that DreamZ did? I can see that the old one is still in use
meh, it`s never worked. I added LUA only for experiments. I Haved plans to moving all game logics to the scripts but never finished it
Last edited:
I feel better for ripping it out now!I did try to identify which release of LUA it was using, to recompile and update it but without success. It seemed that the LUA code itself had restructured quite a lot also over the years - so to be honest, it was probably easier just to write my own parser and a basic command syntax - especially as it looked like a lot of work was required anyway to integrate any meaningful functionality via LUA.
Yes I did experiment and get the final v100 Google code running that included it when looking at wingmen/console.
If I recall though, it didn't really have enough extra detail that players might expect now - compared to Pioneer etc. (+8/10 years later)
Also the planet surfaces in FFE are already horribly broken for heights & the positioning of surface stations/cities. I think it'd be really hard to tie them into a new terrain generator - and you cannot change their positions without breaking saved game compatibility. It would also require FFE's terrain collision code to be replaced to use the GPU data not planet vertices. The commit text on v75 did suggest that this had been done, but IIRC it was only checking the altitude of the ship from a spherical surface.
For now, I think it's best to stick with the legacy terrain, and anyway I'm not sure I really want to change it too far from the shapes FFE would have created. I do however want to look at changing the code so that a planet isn't recreated every frame (which kills the CPU) and then perhaps detailed meshes can be generated in hyperspace/load instead.
When I did experiment with the new GPU terrain, I flew right through it... but I did have a crazy idea then that perhaps it could be used for clouds instead! There were some nasty square 'walls' underneath however that would need removing. My HLSL shader knowledge is barely 'just enough to do something very badly' so this might remain a pipe-dream...
..let's not get our hopes up eh.. but maybe they're talking about presents! <jumping>
If it's possible to access and extend the in-game menus, then damn, how about:
• thruster upgrades - good customisation option, this, and a credit sink (esp. for later in the game)
• weapons upgrades - ie. upgraded missile thrusts / ranges, laser upgrades to bridge between the standard upgrades (say 1 t / MW or whatevs)
• re-sprays / re-skin - just cycling thru whatever variations each model provides, but as a servicing option at nominal cost
• custom missions! - hows about "wingmen wanted", as well as "for hire"..? ie. potential escort work for you and your wingmen!
• police recruitment!? under the "contact local police" menu, a "join now!" option, that puts you in a police viper and launches you in a small patrol squad.. send in wings of pirates and award ¢'s for each wave cleared.. get paid for gaining valuable combat experience!
• extend the radio comms options, ie. make the SOS messages finally functional, and maybe add further options like blackmarket trading - once alongside, ships could cooperatively eject / scoop between themselves, away from prying eyes.. but equally, on that point:
• fuel rescue missions, and general breakdown recovery - for instance if equipped with an upgraded tractor beam, you could work as a tug for crippled ships, or maybe just take them whatever conventional goods they need to make repairs (alloys, robots, slaves etc.)
• ..likewise, piracy sans murder! - if another ship submits to a "surrender or die!"-type threat, they eject their cargo once you're alongside, or else temporarily join your 'wing', offering a menu selection of all their goods and equipment, incl. 'slaves' (whatever their crew count, the cowards)..
• wingmen customisation - loadouts, engine tuning and whatever else..
..not using much imagination here, just simple stuff that rounds out what's already there..
If it's possible to access and extend the in-game menus, then damn, how about:
• thruster upgrades - good customisation option, this, and a credit sink (esp. for later in the game)
• weapons upgrades - ie. upgraded missile thrusts / ranges, laser upgrades to bridge between the standard upgrades (say 1 t / MW or whatevs)
• re-sprays / re-skin - just cycling thru whatever variations each model provides, but as a servicing option at nominal cost
• custom missions! - hows about "wingmen wanted", as well as "for hire"..? ie. potential escort work for you and your wingmen!
• police recruitment!? under the "contact local police" menu, a "join now!" option, that puts you in a police viper and launches you in a small patrol squad.. send in wings of pirates and award ¢'s for each wave cleared.. get paid for gaining valuable combat experience!
• extend the radio comms options, ie. make the SOS messages finally functional, and maybe add further options like blackmarket trading - once alongside, ships could cooperatively eject / scoop between themselves, away from prying eyes.. but equally, on that point:
• fuel rescue missions, and general breakdown recovery - for instance if equipped with an upgraded tractor beam, you could work as a tug for crippled ships, or maybe just take them whatever conventional goods they need to make repairs (alloys, robots, slaves etc.)
• ..likewise, piracy sans murder! - if another ship submits to a "surrender or die!"-type threat, they eject their cargo once you're alongside, or else temporarily join your 'wing', offering a menu selection of all their goods and equipment, incl. 'slaves' (whatever their crew count, the cowards)..
• wingmen customisation - loadouts, engine tuning and whatever else..
..not using much imagination here, just simple stuff that rounds out what's already there..
Ooh just thought - one small outstanding niggle is only having one stellar light source per system - this appears particularly 'off' when you have say a white dwarf primary, being orbited by main-sequence secondary / ternary stars, since:
• rather than illuminating all body surfaces in the system, a white dwarf at many AU would be all but indistinguishable from any other distant star.. not much brighter than a local planet
(they're no longer undergoing fusion, instead slowly, radiatively cooling, and only slightly larger than Earth in size)
• if one is paired with, say, a red dwarf at any reasonable range, then, all bodies around the red dwarf should be basked in its dim red glow..
..yet approach say an atmospheric planet that's right in front of that type 'M' and if the white dwarf primary's behind you, no matter how far away, day and night sides of the planet are thus inverted, not to mention the wrong colours, and what could & should've been an awesome, alluring, scene, is no longer self-consistent..
Obvs, ideally each class of star should have dependent luminosity and light range / diffusion..
• rather than illuminating all body surfaces in the system, a white dwarf at many AU would be all but indistinguishable from any other distant star.. not much brighter than a local planet
(they're no longer undergoing fusion, instead slowly, radiatively cooling, and only slightly larger than Earth in size)
• if one is paired with, say, a red dwarf at any reasonable range, then, all bodies around the red dwarf should be basked in its dim red glow..
..yet approach say an atmospheric planet that's right in front of that type 'M' and if the white dwarf primary's behind you, no matter how far away, day and night sides of the planet are thus inverted, not to mention the wrong colours, and what could & should've been an awesome, alluring, scene, is no longer self-consistent..
Obvs, ideally each class of star should have dependent luminosity and light range / diffusion..
Last edited:
..one more outstanding issue i have, tho not really a problem with the game itself:
- i've knocked up this reshade filter and skybox texture edit combo (also shrunk and centered the reticles) that really lifts the graphics (i think), however in order to work across all game screens, they need to constantly refresh, just as the environment screens do..
..however the menu screens don't refresh unless a selection or other input is made; this results in the reshade filter iteratively compounding its own previous frame changes in a screen-melting runaway feedback loop..
This leaves no option but to disable the PP filter whenever exiting an environment screen.. manually re-enabling it when switching back..
So to share this as a stable mod, it would need either:
• making menu screens refresh at the same constant framerate as the environment views
or else:
• hooking / auto-switching the PP filter from within the game, so that it's on whenever looking outside, but off when using any 'internal' ship screens (menus and maps etc.)
'Simulating' a hook by re-using the same keybinds to switch the filter while changing screens can't work because the game has multiple keys for external / internal views, which further, change context-specifically from one screen to the next..
The only further requirement is that AA is disabled in the game config; the filter applies its own MSAA and the conflict will CTD..
The filter i'm using is an older version of SweetFX (1.5.1) - it has certain limits i use to advantage in overdriving certain colour channels, which effectively allows tuning 'colour temperature' of stars, while adjusting RGB gamma gains and bloom to enhance starfield depth.. so these same effects aren't possible with more current FX filters.
Example config attached (for best effect set skybox colour to medium or light blue)..
- i've knocked up this reshade filter and skybox texture edit combo (also shrunk and centered the reticles) that really lifts the graphics (i think), however in order to work across all game screens, they need to constantly refresh, just as the environment screens do..
..however the menu screens don't refresh unless a selection or other input is made; this results in the reshade filter iteratively compounding its own previous frame changes in a screen-melting runaway feedback loop..
This leaves no option but to disable the PP filter whenever exiting an environment screen.. manually re-enabling it when switching back..
So to share this as a stable mod, it would need either:
• making menu screens refresh at the same constant framerate as the environment views
or else:
• hooking / auto-switching the PP filter from within the game, so that it's on whenever looking outside, but off when using any 'internal' ship screens (menus and maps etc.)
'Simulating' a hook by re-using the same keybinds to switch the filter while changing screens can't work because the game has multiple keys for external / internal views, which further, change context-specifically from one screen to the next..
The only further requirement is that AA is disabled in the game config; the filter applies its own MSAA and the conflict will CTD..
The filter i'm using is an older version of SweetFX (1.5.1) - it has certain limits i use to advantage in overdriving certain colour channels, which effectively allows tuning 'colour temperature' of stars, while adjusting RGB gamma gains and bloom to enhance starfield depth.. so these same effects aren't possible with more current FX filters.
Example config attached (for best effect set skybox colour to medium or light blue)..
Last edited:
I've been attempting to get First Encounters set up for a fairly vanilla play through (I'd got the original running via DOSbox on my Android tablet but unfortunately bugged controls have put me off - classic Elite control method doesn't work properly in-atmo and is far too sensitive anyway) so I've tried to get AJ's mod to look like the original.
When I've got the resolution at 320x200 all the text is unreadable, like it's being rendered higher and displayed lower. I can't seem to get the original skybox, planet surfaces or atmospheres either. I know this sort of defeats the object of the mod, but is there any way I can replicate the original game while still benefitting from all the bug fixes?
Any help or pointers would be much appreciated
When I've got the resolution at 320x200 all the text is unreadable, like it's being rendered higher and displayed lower. I can't seem to get the original skybox, planet surfaces or atmospheres either. I know this sort of defeats the object of the mod, but is there any way I can replicate the original game while still benefitting from all the bug fixes?
Any help or pointers would be much appreciated
I've been attempting to get First Encounters set up for a fairly vanilla play through (I'd got the original running via DOSbox on my Android tablet but unfortunately bugged controls have put me off - classic Elite control method doesn't work properly in-atmo and is far too sensitive anyway) so I've tried to get AJ's mod to look like the original.
When I've got the resolution at 320x200 all the text is unreadable, like it's being rendered higher and displayed lower. I can't seem to get the original skybox, planet surfaces or atmospheres either. I know this sort of defeats the object of the mod, but is there any way I can replicate the original game while still benefitting from all the bug fixes?
Any help or pointers would be much appreciated
320x200?
Yes it's certainly going to be "a challenge" to get it useable at this resolution - the bare minimum resolution is 640x400 really.
I should mention that internally the FFE code which FFED3D used had a resolution doubling patch applied to it. I'm unsure if running it lower at a lower resolution could cause any click/positioning issues - in a quick test it didn't appear to, but you may find otherwise. Also Windows itself doesn't support such a low native resolution, so I'm not really surprised trying to draw fonts so small is problematic. It probably is scaling them smaller than their minimum supported size - really a bitmap font would need to be used instead if you were deliberately creating a game at such a low resolution and you would then have drawn it at the pixel level. Reimplementing FFE's pixel font is a probably non-starter tbh - it's certainly complicated now by the changes to support translations & wider character sets, and some of the screen redesigns to fit extra information.
The star field of FFE is also problematic. While I do have some original resolution images of the milkyway textures, the other background stars are actually a special model which the draw routines of FFED3D/AJ doesn't support - it was replaced with a textured sphere instead. You'll find that there's a lot of sparkling pixels with this sphere at 640x480 and lower, I've not really experimented much but think downscaling stars.tga to a lower size might help. (if you have any problem with it losing transparency, save it as a .png file instead and remove/rename the original .tga file)
Planets are the main problem though. They aren't drawn with original FFE code - but a reverse engineered, heavily mangled replacement to add extra detail and texturing. The original FFE code to draw atmospheres of planets wasn't part of the FFED3D implementation and this whole area in the assembly is -extremely- complicated, so I've no plan to try to find or convert it. (I may ultimately have to revisit the planet mesh generation to figure out why FFE generates the double asteroids differently, but it won't be soon)
You could alter the terrain textures referenced in the active textures.cfg file to set the terrain graphics to something more retro. FFE used a special texture (tex94) on the planet's triangles to generate different terrain details such as shores & cliff faces. This image was taller that others and it selected a section of it to draw. I guess you could create individual tiles from it to replace the specific textures for cliffs, shores & snowy patches but it'd be a load of effort.
Editing the textures file would also allow you to remove clouds if you don't want any. Find the entries for lowerCloudRatio & upperCloudRatio and set them to 0 for each planet type using them. (recommend saving any customised file with a new name and then edit the entry in ffed3daj.cfg to use it)
It would probably be useful for me to have a look at getting a buildable version of JJFFE sorted out at some point to be able to watch it in debug mode and figure out why the double-asteroids don't render correctly with the replaced planet mesh creation. If I do, I'll see which patches can easily be added to it - is there anything specific, or are you just looking for an updated version? (No promises that I will or timescales of course)
Thanks for the detailed response - what I’ve been trying to do is get a fairly vanilla version of FFE working, with varying problems cropping up along the way.320x200?
Yes it's certainly going to be "a challenge" to get it useable at this resolution - the bare minimum resolution is 640x400 really.
I should mention that internally the FFE code which FFED3D used had a resolution doubling patch applied to it. I'm unsure if running it lower at a lower resolution could cause any click/positioning issues - in a quick test it didn't appear to, but you may find otherwise. Also Windows itself doesn't support such a low native resolution, so I'm not really surprised trying to draw fonts so small is problematic. It probably is scaling them smaller than their minimum supported size - really a bitmap font would need to be used instead if you were deliberately creating a game at such a low resolution and you would then have drawn it at the pixel level. Reimplementing FFE's pixel font is a probably non-starter tbh - it's certainly complicated now by the changes to support translations & wider character sets, and some of the screen redesigns to fit extra information.
The star field of FFE is also problematic. While I do have some original resolution images of the milkyway textures, the other background stars are actually a special model which the draw routines of FFED3D/AJ doesn't support - it was replaced with a textured sphere instead. You'll find that there's a lot of sparkling pixels with this sphere at 640x480 and lower, I've not really experimented much but think downscaling stars.tga to a lower size might help. (if you have any problem with it losing transparency, save it as a .png file instead and remove/rename the original .tga file)
Planets are the main problem though. They aren't drawn with original FFE code - but a reverse engineered, heavily mangled replacement to add extra detail and texturing. The original FFE code to draw atmospheres of planets wasn't part of the FFED3D implementation and this whole area in the assembly is -extremely- complicated, so I've no plan to try to find or convert it. (I may ultimately have to revisit the planet mesh generation to figure out why FFE generates the double asteroids differently, but it won't be soon)
You could alter the terrain textures referenced in the active textures.cfg file to set the terrain graphics to something more retro. FFE used a special texture (tex94) on the planet's triangles to generate different terrain details such as shores & cliff faces. This image was taller that others and it selected a section of it to draw. I guess you could create individual tiles from it to replace the specific textures for cliffs, shores & snowy patches but it'd be a load of effort.
Editing the textures file would also allow you to remove clouds if you don't want any. Find the entries for lowerCloudRatio & upperCloudRatio and set them to 0 for each planet type using them. (recommend saving any customised file with a new name and then edit the entry in ffed3daj.cfg to use it)
It would probably be useful for me to have a look at getting a buildable version of JJFFE sorted out at some point to be able to watch it in debug mode and figure out why the double-asteroids don't render correctly with the replaced planet mesh creation. If I do, I'll see which patches can easily be added to it - is there anything specific, or are you just looking for an updated version? (No promises that I will or timescales of course)
I’d got DOSBOX FFE running quite happily on my Android tablet with controls mapped to a Bluetooth pad (similar to my current FE2 play through) - unfortunately the classic Elite control method is broken above planets (moving up/down takes you diagonally instead and rotation is virtually impossible; I’ve also duplicated this on my laptop) and the keyboard controls are too ‘twitchy’ to use anyway; instead of the smooth rotations and pitch of FE2 ships there are large jumps for each button press. Mapping mouse to a thumbstick resulted in better control but juddery movement.
GLFFE on my laptop still looks fairly vanilla even at 640x400 and the Elite controls have been fixed (if I remember correctly), but I couldn’t see a way to easily map my joypad. I might try a third-party mapping solution for that.
Your version has fantastic options and fixes all round, but has the improved graphics to go along with it and I’m trying to reach Elite in the three original games with a minimum of modern conveniences or graphical changes.
I think my problem is that FFE was designed around using a mouse and autopilot, and I’m wanting to do a more hands-on style of flying
For example, landing at planetary ports seem to have my ship passing through the landing area onto the surface below before (sometimes) snapping back to the correct position.Oh, the positions of stations in FFE are completely broken due to the terrain generation instead of the planet being a simple sphere. Those that have cities surrounding them are the worst effected as they are laid out as a single model in a flat plane, then placed at a single central point (the station I think) and doesn't account for surrounding height variations at all. The problem is there in Frontier too with its spherical planets, but the extremely low resolution and limited colours of the original platforms largely masked the issue .
There's no mapping of the joystick in GLFFE or JJFFE that it's based on I'm afraid, just values to adjust the deadzone and sensitivity in glffe.cfg/ffewin.cfg - you will indeed need to use 3rd party mapping software. (if you do need to alter these, then you can use the mapping in the FFED3DAJ_Config application to get an idea of how the values work as it's still basically the same IIRC)
Personally, I never played either originals with the elite-style controls or a joystick 'back in the day', it was always much easier with mouse and the keys to roll, as roll was only really required for docking. And my brain just isn't wired for a gamepad after decades of flight sims and now Elite: Dangerous- so I can't offer any help on how best to map one!
There's no mapping of the joystick in GLFFE or JJFFE that it's based on I'm afraid, just values to adjust the deadzone and sensitivity in glffe.cfg/ffewin.cfg - you will indeed need to use 3rd party mapping software. (if you do need to alter these, then you can use the mapping in the FFED3DAJ_Config application to get an idea of how the values work as it's still basically the same IIRC)
Personally, I never played either originals with the elite-style controls or a joystick 'back in the day', it was always much easier with mouse and the keys to roll, as roll was only really required for docking. And my brain just isn't wired for a gamepad after decades of flight sims and now Elite: Dangerous- so I can't offer any help on how best to map one!
I've had another quick mess around with GLFFE and I think that's the route I'm going to take using Xpadder or something similar - at 320x200 there seems to be a blur filter which makes any text a bit too fuzzy but it all looks fine at 640x400.Oh, the positions of stations in FFE are completely broken due to the terrain generation instead of the planet being a simple sphere. Those that have cities surrounding them are the worst effected as they are laid out as a single model in a flat plane, then placed at a single central point (the station I think) and doesn't account for surrounding height variations at all. The problem is there in Frontier too with its spherical planets, but the extremely low resolution and limited colours of the original platforms largely masked the issue .
There's no mapping of the joystick in GLFFE or JJFFE that it's based on I'm afraid, just values to adjust the deadzone and sensitivity in glffe.cfg/ffewin.cfg - you will indeed need to use 3rd party mapping software. (if you do need to alter these, then you can use the mapping in the FFED3DAJ_Config application to get an idea of how the values work as it's still basically the same IIRC)
Personally, I never played either originals with the elite-style controls or a joystick 'back in the day', it was always much easier with mouse and the keys to roll, as roll was only really required for docking. And my brain just isn't wired for a gamepad after decades of flight sims and now Elite: Dangerous- so I can't offer any help on how best to map one!
Can't for the life of me get the videos working though - I've slapped the replacement FE2 avi files in the correct folder and told the cfg file where to look, but nada
They work fine in your mod, so I dont know what I'm doing wrong in GLFFE.
Cheers for the replies and your time!
In GLFFE - setting filterfont=0 in glffe.cfg will remove the blury text, and I presume you've also set replaceconsole=0 to get the original cockpit graphics.
You can also remove/rename the graphic file 96.JPG for the original cabin backgrounds.
Doing away with title.JPG will replace the garish GL intro banner with the text 'FIRST ECOUNTERS', but it doesn't use original graphic for some reason.
I've attached a version I had knocking about that you could drop in instead:
(click on it to see the full image, then right click on that to save)
Videos don't display in GLFFE, just the sound can be heard. It's a known bug - can't tell you why, as again I've ever compiled it from the source code but they did work in the final JJFFE 2.8 release. At a guess, it probably is drawing the video frames but they're behind the background wallpaper. I think I remember FFED3D having the same problem...
Safe travels Commander! o7
(Should probably get back on topic now...)
You can also remove/rename the graphic file 96.JPG for the original cabin backgrounds.
Doing away with title.JPG will replace the garish GL intro banner with the text 'FIRST ECOUNTERS', but it doesn't use original graphic for some reason.
I've attached a version I had knocking about that you could drop in instead:
(click on it to see the full image, then right click on that to save)Videos don't display in GLFFE, just the sound can be heard. It's a known bug - can't tell you why, as again I've ever compiled it from the source code but they did work in the final JJFFE 2.8 release. At a guess, it probably is drawing the video frames but they're behind the background wallpaper. I think I remember FFED3D having the same problem...
Safe travels Commander! o7
(Should probably get back on topic now...
)Aye, I’d managed to get all the original cabins and whatnot back, but thanks for the original banner and the pointer for blurry textIn GLFFE - setting filterfont=0 in glffe.cfg will remove the blury text, and I presume you've also set replaceconsole=0 to get the original cockpit graphics.
You can also remove/rename the graphic file 96.JPG for the original cabin backgrounds.
Doing away with title.JPG will replace the garish GL intro banner with the text 'FIRST ECOUNTERS', but it doesn't use original graphic for some reason.
I've attached a version I had knocking about that you could drop in instead: View attachment 199505 (click on it to see the full image, then right click on that to save)
Videos don't display in GLFFE, just the sound can be heard. It's a known bug - can't tell you why, as again I've ever compiled it from the source code but they did work in the final JJFFE 2.8 release. At a guess, it probably is drawing the video frames but they're behind the background wallpaper. I think I remember FFED3D having the same problem...
Safe travels Commander! o7
(Should probably get back on topic now...
Pity about the videos, but I think I’m all set for FFE next year. Cheers once again
Just a quick update on the videos. JJFFE lets the original game code draw directly to its display buffers and then renders them as an image each screen update - so it's pixel-perfect to the original.Aye, I’d managed to get all the original cabins and whatnot back, but thanks for the original banner and the pointer for blurry text
Pity about the videos, but I think I’m all set for FFE next year. Cheers once again
GLFFE allows the original code to run but captures the draw commands of primitive shapes such as the textured triangles - so they get drawn at a higher resolution with the original textures, their edges are sharper even if the texture is more blurred. The videos however still render their frames directly onto the original display buffers, and GLFFE doesn't draw these but renders a background wallpaper image instead, so the video frames aren't displayed. The original FFED3D beta1.12++ fell into the same trap IIRC, but the later unreleased beta code rendered the video frame into an special image ready to draw like any other over the cabin wallpaper - it just required some positional & aspect related fixes according to the current screen resolution to scale the image, and similar corrections to redraw the an area of wallpaper to "blank" the previous frame before drawing the next as FFE doesn't update the whole screen when they are playing.
In other news, Over on the Space Sim Central forums I'd been asked about running the game under Wine as it generated an error message. This was related to a graphics memory check I'd added for logging recently, anticipating issues with the caching to video card memory that ultimately didn't occur. So I made a quick update to move that check to a higher level of debug logging and to also include in the log if the user was running Wine & the version number. Unfortunately the player that reported the issue didn't return over Christmas, so I decided over the weekend to satisfy my own curiosity and dust off an old dual-core PC to see if it would run Linux, and perhaps even Wine... and what d'ya know - it could!
In brief - Wine 5.0 ultimately isn't able to play FFED3DAJ because it doesn't support the D3DX9 ID3DXFont object that's required to draw all of the on-screen texts.
BUT - it turns out there was a substantial update just over a week ago, and Wine 6.0 has just been released - and that IS able to run FFED3DAJ correctly!
(The dual-core potato running this only has 1GB RAM and a 512MB nVidia 9800GT video card! Primitive FFE ship/building models only of course!)
It appears that I had to install the DirectX9 runtimes into the 'dx9' prefix (bottle) that I set up for testing with to allow it to load the sky and console .x models, but having done that the default .wine prefix also seems happy to run it when it wouldn't originally. I'm a bit confused as to why, as the files are definitely only in the 'dx9' prefix test area and not the default - but with only a weekend's experience I'll settle for now with the news that Wine 6.0 is able to run FFED3DAJ... and yes, you can also run BUFFET to tweak the game when it's running should you wish to. (I've not yet worked out if the configuration application can be run or not - it's a .NET executable)
Thanks for the update - I’ve been messing around with GLFFE but I’ve finally settled on using JJFFE in combination with Joy2Key mapping software - the replacement videos work, I’ve got controls that work correctly and I’ve got the chunky old graphics
Seeing as I hit Elite in FE2 the other day, I should be running the Wiccan Ware Race very shortly!
I have some time flying ships and I tried the new variants. They look amazing
I feel the dark side of Viper and Skeet is too dark. Maybe a code like this will correct the issue?
I see that Asp shader file and global ships shader file both have some code like this.
Other thinks on the line
but unfortunately Cobra MKIII model folder does not contain any change. Maybe I look in a wrong place, or it should be about Asp?
Now back to flying...
I feel the dark side of Viper and Skeet is too dark. Maybe a code like this will correct the issue?
Code:
ut.rgb = saturate(max(0.1,dot(lightDir, normal)) * diffuse * 2.0);I see that Asp shader file and global ships shader file both have some code like this.
Other thinks on the line
- ECM field is somehow clipped by the planet limb. Hope an easy fix.
- In version history there is a line saying
Code:
+ Multi-coloured, bump-mapped Cobra MKIII skins & shader.but unfortunately Cobra MKIII model folder does not contain any change. Maybe I look in a wrong place, or it should be about Asp?
Now back to flying...
Duh! yeah, brain fart on my part - should have been the Asp explorer!
Sorry for the slow reply, it's been a busy month or so IRL..
It's probably a bit too late ask - but I don't suppose that you have a save position for the ship/ecm clipping issue?
It helps me a lot if anyone reporting a bug can also share a save so that I don't have to try to reproduce it. I can't so far...
This is also a bit of a quick update - I have a new build for you all to download: v1.17beta3.
(As always, this beta build must be installed over a full FFED3DAJ installation - See the 1st post in this thread.)
It's mostly an update to the render engine - all screens are now actively repainted every frame, even when FFE isn't updating them. This solves an issue with them disappearing beneath the developer console overlay, but I'm also hoping that this will solve the issue that Bounder has had with his post-processor injector 'ReShade' mod and that menus and player info screens will now be ok when using it. Do let me know Bounder!
Cheers!
AndyJ
(edit: looks like there's some issues with missing videos on the 1st post, and it's too late tonight to be figuring out - so I'll have to update the current beta link there when I next get time)
Last edited: