The General BugFixing/Playtesting thread for FFED3D+mods
- Thread starter Zak Gordon
- Start date
It is a weird one that. As far as i can tell all Ittiz did was replace the icon graphic for these buttons. So i can't really see why they would disappear, and certainly it's not something i have ever seen using the default icons (my build is FFED3D+AndyJ's mod, rather than Ittiz+AndyJ's).
Also i have updated the first post with new info based on Andy's new v1.05 patch and the stuff i have been working on/working out
Also i have updated the first post with new info based on Andy's new v1.05 patch and the stuff i have been working on/working out
Gah, turns out the buttons are still disappearing occasionally
What had you been doing between the last time they appeared OK, to that moment of slap-forehead-dammit-they've-gone? :S
I've only found one way to reproduce a similar issue. That only dropped the 1st button on the screen, not multiples and that path doesn't seem to trigger it now... so I'm a bit stumped ... there must be some common cause for it to have survived a pc/OS upgrade... (I'm hoping the answer isn't that "it happens after 8hrs of gameplay"!)
Had you just been mining (which I've never done) or in a missions conversation etc? Any idea which screen(s) you'd been via before entering the stock screen? (I'm assuming it's that one that's bust again?)
It's usually the 9th button down, and that doesn't change as I scroll down the list of items. Occasionally the 10th button disappears as well. But then again, I can load the savegame, take the same route to the stock screen and the button will be there. It's a bit random. Nothing to do with the videos; it can happen whether they're switched on or off.
Things seem to have improved with v1.05 because - so far - it hasn't happened on any screen other than the stock screen. In earlier versions it could happen on mission pages as well.
I can load the savegame, click on the communications icon and then go to the stock screen and the button will be gone. I don't see any pattern regarding previous screens visited.
I seem to be the only one having this problem though, so please don't regard it as a priority. As I've said before, it doesn't hinder gameplay.
Things seem to have improved with v1.05 because - so far - it hasn't happened on any screen other than the stock screen. In earlier versions it could happen on mission pages as well.
I can load the savegame, click on the communications icon and then go to the stock screen and the button will be gone. I don't see any pattern regarding previous screens visited.
I seem to be the only one having this problem though, so please don't regard it as a priority. As I've said before, it doesn't hinder gameplay.
Thank you AndyJ for the new version!
Back on the asteroid issue, does anyone notice that the asteroid body strangely rotates when you rotate the field of view? It seems to be a bug here.
Also, the appearance of these asteroids is not affected by "usePrimitiveModels=1". Is this normal?
You can test this on the same scenario:
http://sberinde.x10host.com/temp/test
Back on the asteroid issue, does anyone notice that the asteroid body strangely rotates when you rotate the field of view? It seems to be a bug here.
Also, the appearance of these asteroids is not affected by "usePrimitiveModels=1". Is this normal?
You can test this on the same scenario:
http://sberinde.x10host.com/temp/test
@polaris: Yes it's normal that they are unaffected. They are generated as polygon models by the game, in the same way as planets. They don't have an external .x model but like the planets are drawn with more triangles and a high-resolution texture compared to the original game, also the asteroid shader is applied to them. (Dreamzzz originally doubled the resolution of planets way back in GLFFE and then extended this further in FFED3D)
Not sure about the view rotation issue, are you talking about the external view? Is it just the case that the camera position is also swinging around relative to the asteroid so changing the perspective?
@Steve: perhaps you could email me your save game & config file when you get a chance, in case it has any significance? Have you been playing for a long period or is this happening even a short time after loading the .exe then the saved position?
That disembodied head is certainly in keeping with Halloween... I've certainly felt the horrors a few times today!
btw, and between answers, I'll just give some credit where it's due; the high resolution buttons that are being discussed and in fact many of the high resolution model/ground textures in the ranges 44-94, 401-547 and 711-719 are originally from nanite2000's texture pack link. I've been using them since first trying FFED3D a few days after their release, and the missing images have nothing to do with using these graphics. The game should just draw the button graphic at location x,y each time. The fact that it's not drawing the odd button means that there's certainly 'something else' in the code that's causing this...
@Zak:
Your comments about the ships on page 1 - to clarify the first set are simply those ships that do have replacement/external models. The Viper Mk2 should be in this list too. There is also a model for the MK1 Cobra by Spacegamer that's available separately but it currently has static landing gear.
The rest of the ships are pure polygon shapes from the original game and don't have replacement models.
Also perhaps you could revisit this one please as I answered it the other week: "[Major] Various planet based buildings are blank geometry only, no textures."
The "issue" happens when using hi-res textures that lack enough contrast in their detail. Nothing is actually missing. If you switch to the original v1.12++ beta textures - I think 425/426 in particular then you'll have more obvious detail on those original objects. Also it's purely cosmetic and so really shouldn't be marked 'major' either. Flying into an invisible asteroid on the other hand, or some other game-breaking behaviour, well that definitely would qualify as major!
Not sure about the view rotation issue, are you talking about the external view? Is it just the case that the camera position is also swinging around relative to the asteroid so changing the perspective?
@Steve: perhaps you could email me your save game & config file when you get a chance, in case it has any significance? Have you been playing for a long period or is this happening even a short time after loading the .exe then the saved position?
That disembodied head is certainly in keeping with Halloween... I've certainly felt the horrors a few times today!
btw, and between answers, I'll just give some credit where it's due; the high resolution buttons that are being discussed and in fact many of the high resolution model/ground textures in the ranges 44-94, 401-547 and 711-719 are originally from nanite2000's texture pack link. I've been using them since first trying FFED3D a few days after their release, and the missing images have nothing to do with using these graphics. The game should just draw the button graphic at location x,y each time. The fact that it's not drawing the odd button means that there's certainly 'something else' in the code that's causing this...
@Zak:
Your comments about the ships on page 1 - to clarify the first set are simply those ships that do have replacement/external models. The Viper Mk2 should be in this list too. There is also a model for the MK1 Cobra by Spacegamer that's available separately but it currently has static landing gear.
The rest of the ships are pure polygon shapes from the original game and don't have replacement models.
Also perhaps you could revisit this one please as I answered it the other week: "[Major] Various planet based buildings are blank geometry only, no textures."
The "issue" happens when using hi-res textures that lack enough contrast in their detail. Nothing is actually missing. If you switch to the original v1.12++ beta textures - I think 425/426 in particular then you'll have more obvious detail on those original objects. Also it's purely cosmetic and so really shouldn't be marked 'major' either. Flying into an invisible asteroid on the other hand, or some other game-breaking behaviour, well that definitely would qualify as major!
Last edited:
I will certainly do that when I get home from work. Unfortunately I delete all my save games apart from the last one at the end of a First Encounters session, but I'm sure it won't take long for the buttons to start disappearing again
I'm attempting to group the ships aesthetics/styles into some order just based on how they look in game. Currently there is a spread of ships that obviously are more or less the originals (Lion Transport for example) and those that have fancy newer updates (Asp and most in that first section of the list).
I don't know exactly if ships have had new models or not, or if these are just texture changes, but if you examine the list as is and compare all those ship types in game you should see the difference in aesthetics/style i'm drawing attention to. This is not my saying any are better than others, just that the visual difference is noticeable.
The Viper MkII looks pretty much like the original shape and style as in the default FFE game, although it has had a new texture for it's skin. It may even have had a new model but the artist kept it 'pure' to the original shape, which is very obvious compared to the Viper MkI, which has had that fancy new look (like the Asp etc) added to it.
So that was the heart of the differences i was wanting to put down somewhere. Section 1 has gone beyond the simple geometric shapes for the most part, the second and third sections not so much (if at all).
It might all be moot as we don't have graphic artists that can reskin all the remaining ships not in that first section to look like those in the first section, if that is even desirable?
Spacegamers Cobra MkI would fit in the first section, it's a very nice model and skin, moving beyond the simply geometric shape of the original.
Yeah it could be a [Middle] rated issue, and while just cosmetic, it does detract from the overall experience imho. Having said that my new retextures have reduced the issue with 425/426, being more 'textured' so standing out a little more. I'll edit that entry to better suit it's relevance.
There are still lots of blank geometric buildings around, that first bio-dome on the Merlin start for example. The black 'City' skyscrapers do add lights when you get close, but the flat white warehouse structures around them seem to have no textures.
On the Hope start, there are a bunch of blank white buildings just to the left of your stating view.
The main issue with these is they stand out in comparison to the rest of the really nicely textured buildings, so if it is at all possible to do something about these that all adds to the polish and look of the game.
Is there any way to find out what textures these type of blank buildings can use? I notice a number of seemingly blank (white/no detail) textures in the texture folder, so maybe these are the issue? I'm not sure where to start in trying to resolve this, so any pointers would be much appreciated
On v1.05 update. ALL the z-fighting issues seem to be gone, i've not been able to notice any on those planet roads and fields or the Ship ID's as on those massive ships parked outside space stations etc. So thanks for your efforts on that, it really makes the game visually smoother
Edit: I'm looking for a replacement for the HYPE.RAW file (In 'FX' folder). I had been pretty sure one of the mods had a less 'harsh' sound for the Hyperspace event, but i've gone through FFE, FFED3D, Ittiz and they all seem the same file? I've been able to make a smoother HYPE.WAV file that sounds much nicer but i don't seem to be able to make a .RAW file of that. So any suggestions from anyone?
Edit2: Ok i've created a new HYPE.RAW file having not been able to find one in the various FFE file download sites. It is now in my mod list link in my sig
Last edited:
Ok well take a look at a list of FFE Objects and see which of them have a subfolder with the same number within the Models directory, and that should contain a model.x file and skin.png/tga/bmp.
If an object has a subfolder & model.x, then that means the game is using a replacement model for it.
Replacement models have one or more skin image that wraps the entire model. Example, model 34 the replacement Viper Mk2.
So this set of objects should be described as being replacement models that use skins. You need some one who can create a model in .X format and perhaps also an artist to create a detailed skin texture.
If there isn't a model subfolder then the game will use the second class of objecs - the original primitive-based models. A primitive-based model is generated by a script (of sorts) of draw commands. Each draw command will draw a square (anything with 4 sides) triangle, polygon or curved area etc etc. And each individual shape that forms the primitive model can have it's own material - either a texture in the 400+ range from the Textures folder, or a solid colour.
So to be clear what type of object we are talking about at any time, it helps to use the terminology:
Replacement model + Skin, or Primitive model + Texture.
This is where you need to refer to the jongware site and the ShowMesh.txt file that is a dump of all draw commands, for each of the models.
The black/white domes are object #269. If you search the showmesh.txt file for [hash]number[:] i.e. #269: then it'll go to the start of the draw commands for this object.
This one is built up of lots of commands such as:
0003 0888 0C02 046A ; Triangle(COLOR_WHITE, 12,2,4, Normal(106))
The first 4 values define the draw command, 0003 says it's a triangle, then the next 4 values 0888 showing this triangle is just drawn as a solid white shape. (888 forms the RGB values that are multiplied by 17 to get the end value) Others are solid black. So this whole object doesn't have any textures that you can edit.
If we look at a shape that does have a texture - e.g. a triangle on the Falcon, object #20:
0003 4013 161A 1E1C ; Triangle(Texture_Metal_Cyan_0, 22,26,30, Normal(28))
The bit to note here is the 2nd set of values start with 4 and if this first number is 4 or higher then it always means that the following 3 values denote a texture.
I picked this one as the description along side says as much but it isn't very helpful. "What the heck does Metal_Cyan_0 mean?"
Well like the solid colours, you then look to the next 3 numbers in the 2nd group. 013 in this case. This is a hexadecimal number 013h which you have to convert to decimal, =19, and then add 400 to. So this triangle uses texture 419 from the Textures folder. If you look at the original FFED3D textures, it does indeed correlate to the first of two cyan textures. Most textures are described with the hex number, but I picked an awkward one to describe fully.
Only "squares" (all 4 sided shapes), triangles and cones actually use textures IIRC. There are polygon (and even line) commands that define the use of a texture - but are solid colour only. You might recall I highlighted that the original field polygon shapes use texture 424 - but it seems this just means it will take the colour from the top left pixel in the image. And with the original image, it restored the fields to being a dark green rather than a washed-out yellow/grey colour.
So I'm afraid that if you want to identify individual models and the textures that they use, expect a bit of leg work to do. This is what I've spent 3 weeks staring at to identify individual triangles/squares to fix the z-issues and missing decals etc...
I'm not sure what most of the building numbers are as haven't really dug into any of them. One thing to know is that they'll be owned by a 'city square' (or bio dome) which in turn is owned by the space port 'group' object. The primary group for Hope is object #86 and you'll see in it's definition it contains a bunch of 'sub objects' in the range 271-282. 271 is the "Old Blackelk" spaceport building itself & the 2 landing pads. 272+ are subgroups again and contain the individual buildings as sub-objects.
There's a whole bunch of objects in the range 377+ simply described as "building" in the FFE objects list. I wouldn't know which is which, but you can narrow it down by seeing which of these have replacement models already and cross them off.
Then look for easily identifiable features, such as posters, or obvious textures or colours and look for the models that include them. If you're unlucky, the blank blocks to the left could be #397 "buildings"...
Another trick you can make use of - the primitive models can also be exported -either completely at startup with the .cfg setting modelexport=1, or more helpfully to you, by toggling the functionality On with CTRL+F9. They'll wind up in the subfolder Models\_export.
If you make sure that folder doesn't exist, load the game with out the setting enabled and then you can narrow the suspects down very quickly: take off and fly towards your buildings of interest, hit CTRL+F9, fly past for a second or so and quit. You should then have a shortlist of models in the exports folder to investigate further.
As far as actually editing models and using these exports as guides, well that's beyond my knowledge right now, but has been covered before in the main FFED3D thread and over at the Russian site.
As always AndyJ, you are extremely helpful and exact with your info. Thank you very much for those details and i will have a good read of it and see what i can work out. Having done some minor Hex editing of the FFE game a number of years ago (just ship data, so not hard), i fully know how difficult all this stuff is.
You deserve a special medal or something for the magic you have been pulling recently with your mod work
You deserve a special medal or something for the magic you have been pulling recently with your mod work
My position on this is that there is no issue and that I've definitively explained the reason.
The lack of texturing has nothing to do either with my patch nor JJFFE/FFE originally. If you use the default FFE textures from the original FFED3D v1.12++ release then there's no problem.
It is entirely due to the use of the hi-res textures, which originally came from the texture pack by nanite2000. So there's the solution: Don't use those textures. case closed!
Last edited:
The effect is more apparent with the next scenario
http://sberinde.x10host.com/temp/test2
Just swing your nose left and right in internal view and watch the asteroid how it performs! It happens also in external view.
It is an issue using the Ittiz build also, as those textures are also very hi-res compared to the original FFE/JJFFE or FFED3D ones. So if we are suggesting people use either Ittiz build as a base OR nanite2000's textures then i guess it will be more noticeable.
I'll make such a comment in the relevant entry so you don't feel this is a criticism just about the AndyJ mod. You will note that where i get the exact info in relation to one of the perceived issues i notice using FFED3D+AndyJ mod, i usually mention it in the entry, saying if it is a default FFE/FFED3D issue or not etc.
First of all I must make sure that I say "thanks" this time for providing the test cases, having them really helps! I don't think I'd even seen a large asteroid in-game before, never mind taking the opportunity to land on one!
(oh, and it is glitchtastic for anyone else who now tries this, altitude 0 is way off 'ground level' and you -will- have the asteroid rotating through you albeit without damage - but it's just the same in JJFFE)
I'm assuming that you're questioning the way the angle of the asteroid is changing as you swing left right? (easiest to see this with < / > keys rather than mouse too)
It does sometimes seem to add rotation to the asteroid if this is what is bothering you, although I'm not sure that it actually is... it appears to return back to the position it ought to be in when you re-centre it in the view...
It seems that FFED3D is set up with quite a "fisheye" view perspective, and this is causing the larger than expected changes in angle when moving the object towards the extreme left/right. It also feels a little like the camera is rotating at a point ahead of the view, amplifying this rotation.
I can't say I'd really noticed this before, but there's a similar effect with planets, they get taller/slimmer in the centre of the screen, and slightly shorter/fatter at the left/right of view. A similar rotation to the asteroid is also notable on distant red-dwarfs such as McCarthy at Wolf 630 when you're near to the Mayflower space station. Without further investigation and research into DirectX view definitions, I can't say at this point if it's a bug in the FFED3D code and perhaps fixable or if it's something more fundamental - the translation to real 3D is not without it's Z-depth issues. I'm pretty much still a newbie on the 3D side of things, but learning more as I face off with the next bug in the line - sometimes my knowledge is as much a work-in-progress as the patch I'm afraid! (but then this is also what keeps me interested!)
There's actually another issue with the example in your test-case: It draws the asteroid looking very much like a Mr Potato Head, with two ear-like bumps on its sides! That's an error as looking at it in JJFFE, it's actually meant to be two separate asteroids that are just touching each other.
I fear that may be a new headache as it's asteroid #116, the only instance where an object is doing two 'draw planet' commands. And this is the command which is pretty much a complete mystery, except perhaps to Dreamzzz, and as I said originally regarding the missing asteroids - it's also a pretty horrific piece of code to look at even in it's pseudo "C" translation, but we'll see...
It'll be next week though before I really get a chance to look at this now though as have a busy weekend ahead.
Some screenshots about a few of the graphical rough edges we have talked about.
Some screenshots on building textures that look missing using a number of builds, starting with JJFFE, as it is an inherited issue so not just related to the higer res textures used in Ittiz build etc:
Some screenshots on Planter/Sun Pop (an issue with FFED3D (so the AndyJ+Ittiz mod as well) as in JJFFE and FFE the size of texture compared to planet 3D model were very close, so no 'pop' was noticable):
Some screenshots on building textures that look missing using a number of builds, starting with JJFFE, as it is an inherited issue so not just related to the higer res textures used in Ittiz build etc:
Some screenshots on Planter/Sun Pop (an issue with FFED3D (so the AndyJ+Ittiz mod as well) as in JJFFE and FFE the size of texture compared to planet 3D model were very close, so no 'pop' was noticable):
Those buildings certainly haven't got textures defined on all sides, nothing is 'missing' and there is no issue. I explained in post #110 some shapes are solid colours and how to check this.
Details on primitive based models are checked against distance and simplify/disappear once exceeded. e.g. windows on space stations & tower blocks, lowered landing-gear on ships. That behaviour is correct.
Planet 'pop' was raised before on page 3. I have already said that it is part of wider problems with the scale and drawing of circles/balls that needs to be worked through.
Details on primitive based models are checked against distance and simplify/disappear once exceeded. e.g. windows on space stations & tower blocks, lowered landing-gear on ships. That behaviour is correct.
Planet 'pop' was raised before on page 3. I have already said that it is part of wider problems with the scale and drawing of circles/balls that needs to be worked through.
Yeah cheers AndyJ, just wanted to be clear on those blank building renders as NOT being the same issue as the too hi-res textures and your info on what might be possible to do with them is under construction(!).
I completely missed your comment on the planet pop issue, so sorry about that. Still more data is good (i hadn't notice the cities showing before the planet previously).
I completely missed your comment on the planet pop issue, so sorry about that. Still more data is good (i hadn't notice the cities showing before the planet previously).
Heads up!
v1.06 is online - mainly code changes to the .asm code, it fixes the issue with repeated clicks during video playback (no more accidentally buying a ship!) and I'm pretty sure that it fixes the assassination mission crash in the Aniso mod too - yep, I think that I've found the source of the stack fault!
Otherwise, a minor shader change to fix transparencies in model textures. It's a short list of fixes I know compared to 1.05, but 2 significant ones that I know people have been waiting for, so I didn't want to delay a patch for too long while I'm investigating other areas!
+ Fixed the crash in Aniso 0.9c mod when attacking a peaceful AI ship. This had been corrected in Aniso's final "rolling update" build of 0.9c but not in the released source code. The issue was in FUNC_ShipHit, JUMP_NoMusic needed to 'pop eax' after the 'call FUNC_001903_SoundStopSong' statement.
+ Fixed video playback so that they don't leave their final frame on the screen, and so that a subsequent video doesn't begin by displaying the final frame belonging to the previous video.
+ Fix to prevent a mouse click during video playback from triggering multiple GUI button actions.
+ Correction to global Ship and Object shaders to preserve alpha values from the skin. This reinstates the transparent cockpit of the Falcon.
+ Corrected the message that's displayed when jettisoning items from the cargo bay, was drawing in green text.
+ New FFE/Aniso hacks added, originally from CheatMode FFE v1.29 by Stone-D (Laga Mahesa):
+ + Prevent military drives from generating Radioactives from fuel. Setting the value of milDrivesCreateRadioactives to 0 enables this cheat.
+ + Remove requirement for military drives on classified missions. Setting the value of classifiedMissionsReqMilDrives to 0 enables this cheat.
The radioactives generation by military drives patch fixes a major bugbear of mine so glad to have found and added Stone-D's cheats! The classified mission fix is untested as I've struggled to find such a mission ... but I didn't want to hold the build up - let me know it works or not!
[edit:] just clarifying that the last two are cheats that can be activated in the Patches sections of the .cfg file - they're disabled by default so won't affect the standard game unless the player decides to use them.
v1.06 is online - mainly code changes to the .asm code, it fixes the issue with repeated clicks during video playback (no more accidentally buying a ship!) and I'm pretty sure that it fixes the assassination mission crash in the Aniso mod too - yep, I think that I've found the source of the stack fault!
Otherwise, a minor shader change to fix transparencies in model textures. It's a short list of fixes I know compared to 1.05, but 2 significant ones that I know people have been waiting for, so I didn't want to delay a patch for too long while I'm investigating other areas!
+ Fixed the crash in Aniso 0.9c mod when attacking a peaceful AI ship. This had been corrected in Aniso's final "rolling update" build of 0.9c but not in the released source code. The issue was in FUNC_ShipHit, JUMP_NoMusic needed to 'pop eax' after the 'call FUNC_001903_SoundStopSong' statement.
+ Fixed video playback so that they don't leave their final frame on the screen, and so that a subsequent video doesn't begin by displaying the final frame belonging to the previous video.
+ Fix to prevent a mouse click during video playback from triggering multiple GUI button actions.
+ Correction to global Ship and Object shaders to preserve alpha values from the skin. This reinstates the transparent cockpit of the Falcon.
+ Corrected the message that's displayed when jettisoning items from the cargo bay, was drawing in green text.
+ New FFE/Aniso hacks added, originally from CheatMode FFE v1.29 by Stone-D (Laga Mahesa):
+ + Prevent military drives from generating Radioactives from fuel. Setting the value of milDrivesCreateRadioactives to 0 enables this cheat.
+ + Remove requirement for military drives on classified missions. Setting the value of classifiedMissionsReqMilDrives to 0 enables this cheat.
The radioactives generation by military drives patch fixes a major bugbear of mine so glad to have found and added Stone-D's cheats! The classified mission fix is untested as I've struggled to find such a mission ... but I didn't want to hold the build up - let me know it works or not!
[edit:] just clarifying that the last two are cheats that can be activated in the Patches sections of the .cfg file - they're disabled by default so won't affect the standard game unless the player decides to use them.
Last edited:
