The FFED3DAJ Thread

[Steve]

I've been trying to increase the maximum number of military missions allowed beyond the current limit of six. According to gmstruct the value is held at offset 0x3cae but peeking that location doesn't return the expected value. Am I misunderstanding this?

IIRC Andy, you said previously that changing the maximum number of missions would have a knock-on effect with save games. Did you mean they would be messed up completely or just that they wouldn't be compatible with other people's save games? If it's the former then my efforts will be in vain anyway. If it's the latter, I can live with it!

 

[AndyJ]

I've been trying to increase the maximum number of military missions allowed beyond the current limit of six. According to gmstruct the value is held at offset 0x3cae but peeking that location doesn't return the expected value. Am I misunderstanding this?

IIRC Andy, you said previously that changing the maximum number of missions would have a knock-on effect with save games. Did you mean they would be messed up completely or just that they wouldn't be compatible with other people's save games? If it's the former then my efforts will be in vain anyway. If it's the latter, I can live with it!

Actually, it's a dangerous thing to do without understanding what you are altering.
Changing maximum values of missions is not like changing, for example how much cargo a ship can carry.

I believe that 0x3cae is how many missions can be created for you to accept in the military BBS screen. This is set when hyperspacing into a system - I haven't looked into how it's calculated but it could be based off current system's military rank (- opposing systems rank, if not disabled in patch), tech/population level etc

You might try setting the value in the auto_HS_Arrival script to influence later creation in that system. If you directly set it once docked, you'll probably have to cycle to a new day at least to see any effect. Maybe.

Each mission requires a certain amount of memory to store its information in - defining the type of mission, payment, destination system etc. Each one will be stored in an array, that is a fixed area of memory space. I think that this is the 529 bytes (yes, bytes) at 0x3cba - although that says 25 missions of 24 bytes each, which multiplies out to 600 bytes, so possibly it includes the next 95 bytes too -making 624 bytes. I expect that the max value is probably used in a 0 based iteration for filling the array, mission slots 0 to 25, as that means 26x24 = 624 bytes.
If you were to try to force say 30 missions to be created, and assuming the random mission generator functions chose to create that many, well you'll be trying to stuff 30x24 bytes of data into that same memory location. This will stomp all over the information that's held after at 0x3f2a onwards - corrupting the game's data. (so setting the value higher than 25 would be bad)


The 6 missions limit you are talking about is how many photo/bombing missions can be accepted at any time?
That limit relates to the 312 bytes of data at 0x4ef4. There will be a hard-coded value check within the game to prevent adding more than 6. (the preceding value is how many are currently accepted)
To allow more missions to be accepted and stored would require the limit to be changed in the game code, for a larger block of memory to be reserved at 0x4ef4 when the game starts up and changing which ever parts of the save/load game functions might be affected. And then you'd have a new game file that's incompatible with other FFE builds and you wouldn't be able to load old saves either.

 

[Steve]

Yeah, I wasn't trying to increase the number of missions offered each time I access the bulletin board, rather the number I could have on the OUTSTANDING CONTRACTS page.

Having read your reply... I think I'll give it a miss :O

 

[AndyJ]

I do not refer to visual parameters. And yes, I use nanite2000 textures.

I refer to atmospheric drag as experienced by spacecraft at low altitude. Could be a bug/feature of original FFE, but incorrect from astronomical point of view. In this scenario [atmo] fly near Ceres surface to feel the drag. But Ceres-like objects are too small to have atmospheric drag. Right?

Ah, what a can of worms this has turned out to be!

Right... so there is indeed a divergence between the JJFFE based build and the Anisotropic/Hellmod builds (same) ... and from the original FFE code.
Apparently FFE calculates atmospheric heating per-frame, and this became an issue when JJFFE unlocked the max frame-rate in 2.8a5 and powerful machines were able to produce >100 FPS, causing a new bug of rapid overheating & ship destruction.

I think this was fixed in JJFFE 2.8a6 with a rewrite to the heating / damage code in FUNC_001014 to link the calculation to factor in elapsed time between frames (so apply a smaller effect per frame) but it looks like Anisotropic must have made a similar fix independently as the code differs. (hellmod uses the aniso code as its base)

In addition, JJ has altered the atmospheric shielding strength - doubling it to 0x16 (22) from 0xb (11) in original FFE/Aniso.
A ship without atmospheric shielding is also much strengthened with a strength of 0x13 (19) compared to 0x5 (5) in FFE/aniso.

It appears that lowering the undercarriage in FFE/Aniso also reduces the ships atmospheric shielding strength - but this code is disabled in JJFFE as 'not well known enough'.
Also disabled is a call to the ship damage event which is meant to happen when the ship is overheating, it's replaced by the message "You're going to die soon!" instead. Aniso still has ship damage occur during overheating (no message) although he did replace the damage function with his own variation on it.

JJ also looks to have attempted to add increased drag effects when the undercarriage is lowered, but commented out the code. The resultant code appears to be essentially doing the same calculations as it was in FFE, but I might revert this to the original code to be absolutely sure.


So it looks like atmospheric heating is *much* reduced in JJFFE compared to FFE/Anisotropic/Hellmod, perhaps almost to the point of not having much effect?

It seems that there are a few options to here to level the effects between all builds - perhaps I'll add some per-build patch settings to switch on/off the various points of difference, expose the strength values etc so it can be experimented with & get some feedback on what works well or doesn't.


Working out what causes a planet to be treated as having atmosphere was less than straight forward too. It's bit 1 in a flag that took a fair bit of tracing though functions to find where the heck it originates from - as it turns out via the terrain collision functions, and it's tucked away in the model data rather than something simple like checking the model number. I think that I've found the values now though and they do appear to match the observed behaviour. (Somewhat annoyingly though, they aren't whatever values the original FFE uses to decide when to draw an atmosphere shell, ideally I'd like to track that down too at some point)

 

[Gernot]

hi folks

andy, i still feel a bit guilty that's why i hided a little.
i won't pester this thread further and will open a own one for my models.
but i will follow it, it's interesting.

 

[AndyJ]

Hey Gernot, I haven't pressed you for any progress on models as I saw that you were busy with your Pioneer mod and didn't want to add any pressure. Also I don't find the SSC forum as easy to discuss things as here or over at the EliteGames.Ru forum. (not being able to edit posts is why I've never created a thread over there - being able to update the primary post is a 'must have').

If there's anything you are working on and want to discuss privately, e.g. animation issues, scaling etc - then feel free to use the Private Messages here (envelope, top right of screen).

 

[Gernot]

right on commander,
ssc has become a pain, unfortunately.

Understood,
Recently i haven't much up, "phoenix" keeps me quite busy.
As soon as i finished the basic FFE models for the "Phoenix FFE mod" i will convert them for FFED3D to fill all the missing ship slots.
The models will be a sort of placeholder for higher detailed models which can follow.
In general this will be what i posted here:
https://forums.frontier.co.uk/threa...nd-why-i-lurk-around-here.506984/post-7708432
just converted to an .x mesh.
I know most models are already part of FFED3D, but i have two tasks i like to fulfill with them.
They are very basic and often differ not much from the original content of FFE but just right to have them soon all together.

It might appear strange that i first create the scripted models but in this way i'm extremely close and never i would create them the same using a CAD also to create the bezier shapes it's far better as with blender i.e.

 

[Steve]

Would I be right in thinking that the engine flame colour can't be personalised for each type of ship? BUFFET doesn't offer the option but some of the Imperial ships have their own blue flames rather than the generic cyan.

 

[AndyJ]

Would I be right in thinking that the engine flame colour can't be personalised for each type of ship? BUFFET doesn't offer the option but some of the Imperial ships have their own blue flames rather than the generic cyan.

Hi Steve. No, not easily. The cyan flames are all individual shapes defined within FFE's vector model data for each ship.

The Imperial ships display differently because if you recall I added an optional feature to reinstate their unique style from Frontier: Elite 2 in one of the early builds. (frontierImperialEngines=1). I'm drawing the engine flare and longer blue flame myself, based upon an unused model in FFE that probably should have been referenced by the Imperial engine pod instead of just having a standard cyan flame shape. (It was more straight forward to replace the drawing of that shape than try to fix the model data).

I could add an enhancement to the code that draws the engine flames and then change the color per-ship, but can foresee it starting to get complicated...
If the vector FFE ship models were to be changed, perhaps their engine flame colors would be held the shipsdata.txt files. But then the Courier/Trader would also need a separate color for the imperial style flame, plus 3 lighter shades that are used to draw the flare effect at the engine.
And would the player want to be able to define their own ship's engine color separately - the idea behind the question, I suspect?
And what about the replacement .X model ships... should they have separate color values in the tris.ini file so that the model creator can define them, which then inevitably leads to the issue that not all ships have all the directional thrusters implemented... allowing them to be re-positioned, stopping the 'wiggle' etc etc.
So I don't think I want to open this particular can of worms right now, I haven't got the time currently do it justice.


I have got an updated beta build however: v1.15 beta7.
(As with previous betas, it needs to be added over a setup that's using the last full release of FFED3DAJ v1.11 or has already had a later beta build applied to it.)

This fixes the crash that polaris reported, which happens when allowing the ship to bounce repeatedly on the spaceport landing pad after launching. Also a few tweaks to the scripts to allow them to be interrupted & a restructuring of the rendition routine to allow the console to repaint itself and any output during a long-running script (as this happens between game-generated screen updates).

There was also an old bug lurking from a very early build before v1.0 that added the 'set speed to 0' feature, mapping it to the backspace key.
Unfortunately it wasn't reliably aware when the game might be inside a game menu - as I found by editing a save-game name... then wondering why my ship plunged to the ground not long after returning to the game, oops!

I've also added various patch options to allow the atmospheric heating behavior to be played about with. (see post #384 etc)
JJFFE and Anisotropic/Hellmod had differing calculation methods and shielding/hull strength values. JJ seems to have favored having little heating effect, Aniso is more aggressive but probably still less than the original game had. The calculation methods can be selected & controlling values set in the patches section if players want to experiment with this area.
There are also 3 fixes to FFE's planet data to fix the inconsistency between the bodies descriptions and the application of atmospheric heating/wind noises. Model 119 "Small barren sphere of rock" (e.g. pluto, charon, ceres) had atmospheric behavior applied in FFE, whilst model 121 "Rocky planet with thin atmosphere" and model 124 "World with methane weather system and corrosive atmosphere" (e.g. titan) did not. These fixes are enabled by default, but can be switched off in the .cfg file.

Time for coding/testing has been very short this past month, and although I don't expect any problems, the atmosphere values probably should come with a particular reminder that "it's a beta build", and I'll also have to leave it to interested parties to find some good/bad sets of values for the 2 heating & damage calculation methods!

** UPDATE ** new beta7 build uploaded with a quick bug-fix for script/console, the selected & created object index variables (s, c) were being cleared each frame.

 

[Steve]

Thanks Andy; I've had little time to test v1.15beta6 and I'll be making the most of the glorious weather this weekend as well
It's a shame the engine flames can't easily have their colours changed; that would have been a nice option.
A few posts ago I asked if selling a large quantity of goods on the bulletin board could have the same speeding-up effect as selling on the stockmarket with the mouse button held down. Is that a possibility?

 

[AndyJ]

Thanks Andy; I've had little time to test v1.15beta6 and I'll be making the most of the glorious weather this weekend as well
It's a shame the engine flames can't easily have their colours changed; that would have been a nice option.
A few posts ago I asked if selling a large quantity of goods on the bulletin board could have the same speeding-up effect as selling on the stockmarket with the mouse button held down. Is that a possibility?

Hi Steve,
The stockmarket screen is a dedicated screen with its own input & redraw code. The BBS market screens are defined in data and designed to react to a single button click - this will often then process a chain of actions (a script of sorts) before redrawing the screen or closing the message on completion. So no, it won't be able to behave the same way.
I'm assuming the issue is that it takes forever to sell large amounts? Aniso has gotten around that issue by adding a 'sell all' button IIRC, but I haven't had enough time to replicate the changes to the FFE build yet.

FYI as you were posting your reply I was just updating the beta build to 7 on the previous post to correct a script/console bug that crept in.
Enjoy the weather though - it is indeed glorious for a change!

 

[Gernot]

based upon an unused model in FFE

i like this idea.
besides we should have plenty of them because we don't use all submodels and yes there are a few empty lots.

The cyan flames are all individual shapes defined within FFE's vector model data for each ship

but it would be possible, maybe buffet could trick such better?

I'm not sure if the changing in the vector model will help, as far as i remember it won't accept any color you enter there, but maybe i'm wrong.
Would be tedious to change that for all ships and it's unflexible, they will then have the given color you set and you still can't change this later on.

this makes me curious, very curious.

Andy, isn't it a fact that FFE uses additionally a bitmap? at least there is one for the thruster flames, no?
It's just not used for FFED3D because the low res image would look very ugly and it will be displayed opaque.

Yes it's clear to see FFE uses this bitmap "tex90"
What if you would use again a bitmap and set the thruster flames to white?
Couldn't it be altered then via the color of the bitmap?

I will see what happens if i hack FFE, i wonder if the changing of the cyan color in the vector model will have any effect or if it's just a remnant of the untextured original FE2.
If not i will take care about this bitmap and change the color of it.
Or both.

not so bad for a first approach
the color of the bitmap seems to have no influence (if it's used for the thruster flames at all i'm not sure).

 

[Gernot]

a glorious mistake

next i will see how the tard will look in FFED3D and i wonder what the "2" is for in EE20 or if that affects the color at all.
no effect to see.

a little brighter without the texture in FFED3D

it won't have any fading to a darker color a bitmap would do good i guess, setting all to plain white and using a colored bitmap coul do the job?

 

[AndyJ]

The engine flames are all individual 'pine' shapes defined in the ship's model data Gernot, they're not a separate model. (and yes, they do use a bitmap - it's tex101)

FFED3D is drawing multiple bitmaps though for the standard engines (there's a rounded 'star' flare' 291) before the flame and I'm doing extras for the imperial engines. These don't come from the model data though, they're hard-coded into the function that draws the 'pine' shape. (I think that FFE hardcoded texture 101 0x65 into it's pine drawing function for engine flares too)

The EE 20 data is actually read as 20 EE. The '2' means it is an unlit material, the 0EE is the RGB - 0,15,15 * 17 to give 0, 255, 255: Cyan.
(pine is shape 0x9, see http://www.jongware.com/galaxy7.html and jongware's showmesh.txt for models)

I could override per-ship like I did for the imperial engines at the point of drawing that shape, or look at a way to change the model data - which would be needed to support extra thruster flares on all ships - but I haven't the time at the moment to do that or promise it (or anything) soon. not-fun times IRL again.

 

[Gernot]

Of course Andy how could i have made this otherwise without to refere to Theunis?
You replied just second to fast i was about to note exactly what you statet (i never assumed it's a seperate model i know the models data almost blindfoldet i'm used to read the data machine like already).
How can i copy the models vector by vector without his great article about the objects of FFE?
It was my only lecture for a whole year after my divorce (almost my only and the only game i played, FE2 in this case but it's more the just quite similar).

Yes i do understand that it will be a lot of work.

Andy you did a great job for sure and yes not everyone is unemployed and single as me and has infinite time (except that i start to desintegrate slowly).

---

The only thing which keeps me from "working" is a can of beer (or many cans) and my best buddy who is again in prison, he's such an idiot i love him.
He can't control his power, like Obelix "i just gave him a slap, is that my fault if he didn't wakes up for 2 hours?"
We have both fallen as baby in this kettle of magic potion, for sure, it just turned out a little different.

Germans, ts.

 

[Quackymol]

Could someone tell me how to get the base game and then patch it with this AJ thing in a basic language please. I’m finding this confusin.

 

[Kheehot]

Could someone tell me how

Hope THIS old post helps to understand the sequence. It looks like SpaceSimCentral links broken now. On elitegames links still work but you will need to download the latest update from here.

 

[Quackymol]

No offense but that website looks kinda shifty. Also I’m confused about the base game and the AJ patch. The link u gave me advertised the whole thing. It says at the top of this thread that you need the base game first and then keep patching it. All the sources I’ve found advertising ffe of any patch or whatever seem pirated.

 

[AndyJ]

Hi Quackymoi, that site's fine - it's the Russian Elite-Games site where the original FFED3D mod originated from. You'll probably need Chrome with automatic google translate to navigate it though if you're not a Russian speaker (I'm not either)

Looks like your timing was a little unfortunate as SpaceSimCentral updated their forum over the weekend and the downloads are now back behind a file manager rather than an open FTP area. If you'd prefer to download from there then you will need to register yourself as a user to gain access - and well perhaps you'd like to post to their forum about other space games anyway!

Once registered, in the File Terminal expand the #-F folder, then the FFED3D folder. (Sorry, I won't post direct d/l links to their files)

I'll point you to the 1st post in this thread save repeating too much details... https://forums.frontier.co.uk/threads/the-ffed3daj-thread.12734/
But basically you'll first have to locate a 'base installation' of one of the original FFED3D packages - download and extract one first.
I'd recommend the larger "FFED3D-beta3-Ittiz.7z" that has the most up-to-date models and the BBS videos included.
(You'll need 7Zip or an up-to-date WinRar to unpack .7z files - I think they unpack into a parent folder named FFED3D).

Then download the 3 FFED3DAJ zips that are there. These contain the patch, core files and (optional) model skins. Just unzip these straight into the main FFED3D folder.
I also recommend downloading the 4 nanite2000 files as these contain enhanced graphics for planet terrains etc. Again just unpack these straight into your FFED3D folder, but you'll need to open and edit ffed3daj.cfg in notepad to change a line that says "customTexturesFilename=textures.cfg" to be "customTexturesFilename=textures_terrain.cfg".
Bit of a faff but that's it unless you want to start customising other options. (This last bit will be easier very soon)

Finally if you want to, there's a beta build that you can also unpack straight into the main folder.
The current work-in-progress beta build is v1.15 beta7 and a build can be found here. (post #389)

Hope this helps!

 

[Gernot]

Hi Quackymol,
a general tip from Gernötli, hover over the links and the link will appear in the status bar in latin letters this works also in chinese or commander keen marsian language not only russian
In this sort a way i found anything in the web.