@Polaris - another cool addition in Ani's mod is improved AI dogfighting - they'll fire on multiple thrusters at the same time just like the player, and some can be very tough to kill (Gyr interceptors & Eagles especially).
Ani's mod has been the only version i've played for a while now - the 'Hellmod' is too buggy and incomplete, and after Ani's mod the combat in vanilla FFE is just too easy..
I'd presume so, but absolutely no idea - i've never really liked the scripted missions, because of the way they're tied to the calendar. I don't want to be cajoled into doing any "now or never" offers, i don't like having to read a playthrough guide to find out how to 'complete' the scripted missions - just the how, when and where aspect of them - this is not in the spirit of Elite. The whole player-centric pan-galactic 'hero quest' narrative is anathema to everything Elite's about. I don't like the artificial and wooden way the story unfolds, it feels forced and coerced and garden-pathed, the exact opposite of the free-roam sandbox playstyle the previous games pioneered..
..so i use the 'time machine' hack in BUFFET to set the date to the year 3000 - fifty years before the scripted missions start triggering - whenever i start a new commander. Just bypass all the scripted missions entirely. Do what i want, when and where and how i like, never gonna grind or be told what to do or be dictated how when or where to do it... and frankly i'm far too busy doing other much more interesting, fun and imaginative stuff to need any dubious storyline for motivation or incentive.
The only missions i do are ones off the BBS. Sometimes you see little bugs like assassination target names changing (ie. the name of the person on the contract once you've accepted the mission is not the name of the target mentioned in the advertisment), but never had mission fail to complete..
Now, if Andy were one day to work out how to add new missions to the BBS, i'd probably try them.. but only on the standard "take it or leave it" no-pressure terms.
The way the 'special missions' in previous Elites triggered was better - it would be contingent on aspects of player progress, but with an RNG element. That was OK, cos a scripted mission was like finding an easter egg. Whereas in FFE the scripted missions are like a hand-holding exercise, that actually prevent you from just getting on with the game and making progress at your own pace. "You have to do X now for this once-in-a-lifetime offer to drive the plot forwards in a linear story played out in news articles" - that whole scheduling thing is inimical to the way Elite is most fun to play.
For the same reasons, i never read the newsfeeds either.
If all that BGS stuff were procedurally generated, then i'd take an interest in it, because PG = 'the fates', providing a unique player experience that is a product of everything else they've done and how and where and when they've done it. As opposed to a stiffly-choreographed drawn-out yarn that is the same for every player, upon every replay...
Returning to the animations theme, what about the runway markings at the spaceports below?
For some reason, I was thinking that there was a version of FFE which had the markings animating at the correct speed, but a quick check of DOS FFE, JJFFE, GLFFE and FFED3D shows them all with the same problem.
Kind of minor thing i've always ignored, but also related - when you request docking clearance at domed bases, ATC designates you non-existant pad numbers. These are the bases with the rotating roof doors which have three lobes, and three pads, but it's not uncommon to be told to land on pad 4 or 5. If you always land on autopilot then it's the kind of detail you might miss.. but if you occasionally bring it in on manual or FA-off, it can be a source of last minute landing confusion... the workaround is to always land on pad 1, since all three pads are always empty anyway (ships are drawn into an underground hangar after landing instead of being left on the pads).
However this leads on to another small issue that always frustrates FA-off landings in powerful ships - the inability to control thruster power..
This same issue crops up when using an analogue axis - 'lower power' thrusts are implemented by pulsing the thrusters, at full-power... whilst better than nothing, it's hardly ideal, and if flying FA-off you just can't make keystrokes short enough to accurately control a thruster with more than a few G's. Small fighters in Ani's mod can have over 50 G's, so making small 'trim' thrusts almost impossible - you just can't blip the keys fast enough. An attempt at a small corrective thrust invariably ends up adding 10 m/s of unwanted velocity in the wrong direction...
Thruster control needs to be sufficient to be able to bring a ship to a complete halt.
Again, given that manual control (set speed) and autopilot are both able to apply lower-power thrusts (showing smaller engine flames and lower-pitched engine noise), it should be possible for FA-off too..
The only workaround for now is to use BUFFET to lower your thruster power when you need to make fine adjustments (such as when landing) - however, surely this also points to a possible solution, using the same pokes BUFFET does? All the game would need to do is read that memory address to find and store the current max thrust your ship has, and then reduce it by small increments per analogue or keyboard controls..
As well as being able to bring the craft to a neat halt, it would also thus be possible to perform a stable hover against gravity..
Imagine how much neater vertical take-offs and landings would be if thrust could be properly throttled - sat on the pad, you'd gradually increase downwards thrust, listening to the roar of the engines throttling up, but not yet moving, carefully and deliberately increasing the power until it finally matches, then exceeds gravity's pull, and the ship starts to lift off..
Also making the ground beneath the ship a smoke source when hovering low would be a nice bonus - likewise, adding ground shadows of the ship and multiple lightsources (currently, planets are only lit correctly in single-star systems), but these aren't priority embellishments... manual thrust throttling OTOH is something sorely missing..
Edit:
Ooh another little annoyance - bases clipping thru landscape! Being able to see the base at distance, through terrain, mountains etc., is unfortunate..
Returning to the animations theme, what about the runway markings at the spaceports below?
For some reason, I was thinking that there was a version of FFE which had the markings animating at the correct speed, but a quick check of DOS FFE, JJFFE, GLFFE and FFED3D shows them all with the same problem.
Yeah, it's always been one of those things that annoyed me in FFE too!
It was Frontier: Elite 2 where the runway lights worked correctly, they've always been broken in FFE - as have the hands on the church clocks.
I'm not sure if the clocks can be fixed, but the lights certainly can. It needed a data fix and can be corrected in any FFE .exe file with a Hex editor if you want to. (obviously I've fixed it in the FFED3DAJ builds)
I use HxD which is free. Search for the following hex characters: 76 90 0D C2 80 40 D3 01, there will only be 1 match, it's best to then scroll so this is the first visible line - it's the data immediately after that sequence that needs editing. The end of the block to edit can be found by searching for 0A 00 E0 2E 00 0B 53 46 A4 40. reduce the height of HxD to make that the end line and you should have about 9 lines of data visible.
In this block, we need to correct each of these two pairs of bytes: change C2 02 -> C2 04, and C2 01 -> C2 03.
Personally, I'd recommend sticking to the stock game mode if you're new to Frontier: First Encounters, and especially if you plan on playing through the story missions. (FFED3DAJ.exe)
The "Anisotropic" mod is really for players who've already played through the original FFE game and want something a little different, or like Bounder need a little more challenge in the combat side of things. Then there's "Hellmod" which is based on the Anisotropic mod, but I understand makes the combat even harder by throwing Thargoids into the mix ... I've included that one for the forum community over at EliteGames.Ru who made it.
Well I do know that you couldn't retrieve the Flight Recorder in the later Argent's Quest mission, as it'd display the "scooping" message but didn't add it into the ship's cargo.
This was because of Aniso's change to let a single container represent multiple tonnes when they got ejected by a destroyed ship. The mission created canisters or from saved games from FFE wouldn't have a quantity value, so those got scooped as 0 tonnes. I've fixed that issue now.
As for the rest of the missions - I have no reason to think that they'll be affected, but it's an unknown. The only other bug that I've read about on the alt.fan.elite newsgroup was a CTD when jumping into Polaris, but I'm not sure that still happens after a quick test - it seemed ok.
New missions are off the table for FFE I'm afraid Bounder, the code and data behind them is far too convoluted to even consider it.
I'm only just discovering where some of code for the scripted missions is lurking, and I'll only touch these if it looks like there's a bug or to fix some known issues in FFED3DAJ such as the screen not repainting correctly - e.g. the later Argent's Quest missions displaying text/UI over the forward view rather than the usual cabin background.
Just to reply to an earlier post of yours about adding support for scripting to extend the game, it's also not something I'm likely to do, it'd take far too much effort to add anything meaningful I'm sorry. I'm just quoting this part, because well ... it's the complete opposite of how things currently are.
I understand the desire to make the galaxy more alive, change AI behaviour, add more missions etc - but it would be a huge undertaking to do that in any coherent form.
FFED3DAJ is driven by the FFE game, essentially it replaces the rendering, sound and input functions.
For it to start driving FFE and adding behaviour, it would require externalising and reimplementing all of the code that controls the game-loops, extending data structures to hold new information and more objects -and that would also mean rewriting the save/load routines and having a new save-file structure.
It's just not practical to do all of that, it'd be simpler to just start over with a clean slate and I believe that this is why the "Pioneer" project came about: John Jordan (JJFFE) and Tom Morton (GLFrontier) decided to write their own Frontier-alike and be free from all of the legacy code and its bugs/restrictions.
Oh dear. LOL. [haha]
In this case, it's an AI launched missile that's been fired at the player in the save. The missiles get spawned with the same orientation as the ship that fired them, and so ... yes ... it's actually flying backwards!
It turns out that it's easy to reproduce this as a player: Start the game and take off, fly about 25km up & away from the starport and set speed to 0 to hover. Look through the rear view and target the landed ship/port - fire a missile & pause immediately.
In the external view, you'll see the missile dropped beneath the wing of the ship, facing the same direction. Click x1 speed and the missile will move forward a little way, slow to a halt and then start accelerating backwards!
Obviously, whatever code there is meant to turn a missile isn't triggering when the target is directly behind it. I think the missile uses the same code as the autopilot- I've seen this dock by reversing back into a station too - so I'm not sure how easy that would be to fix! [knocked out]
Buggy asteroid. This particular one (model #116) is an oddity as it creates a double mesh.
Large asteroids go through the same mesh generation functions as planets do, but unfortunately this one comes out rotated incorrectly compared to FFE.
Asteroids were added way back in 1.05 and at the time I put in what was meant to be a temporary fix to try to match the rotation to FFE at render-time, which as you've noted interacts with the camera for some reason. I've revisited this but I'm still none the wiser as to what FFE is doing with this specific model, however I've applied a rotation patch now before the mesh gets generated and it seems to be stable. It's an approximation of how this asteroid should render though compared to FFE - the central point should be between the two asteroid parts but it's based on the first half. Because of this, the model is not quite drawn where it should be, and the targeting icon is also in the wrong position. I've no solution for this one at the moment, I don't know what FFE does differently.
3. Stardreamer arrow does not reset back to 1x on next day
When you are docked to a station/port & comunication panel activated & stardreamer activated.
Thanks, and there was also a legacy issue with switching between the services views - this should also have reset the stardreamer arrow to x1 speed but didn't.
I *think* that this issue is now fixed as well as the stardreamer display not being updated after the videos have played too... hopefully no CTD's this time.
Finally borderless is working for me! [yesnod]
However, after CTRL + F12 the desktop is not redrawn. I don't see this as an issue. There is little point to switch from borderless to windowed.
I think that I've also fixed this issue now and the screen/desktop should redraw correctly when switching out of Fullscreen borderless and into windowed mode.
(For other readers - This issue occured if Windows' "Desktop composition" is disabled on your PC)
I believe it's the a mechanic in FFE that JJ described as the "combat velocity fudge" which tries to keep ships closer together during combat ...<snip>... It was something that Anisotropic made an effort at reducing
I know the parts of code that are doing this so I can add them into the FFE build wrapped with a cfg 'patch' option to change behaviour or leave it standard.
There are a couple of other tweaks I can look at giving the same treatment -e.g. delayed attacks (vs instant shot to the face) when entering combat, not being able to autopilot+time-advance to warp to target bases...
I've added FFE patch options to enable a number of anisotropic's changes:
Anisotropic's Battle Mode: Enemy ships are delayed from attacking the player, and only when in the same frame-of-reference as the player. Pirates will also not "snap" instantly to the player.
Disable the "Velocity Fudge" that FFE applies during combat to keep ships together. The player and missiles will always be excluded from its effects, AI ships will only be excluded when they are trying to evade a missile.
AI Ship load-outs will adjust cargo/fuel/shield allocations according to ship type. (trader/pirate/police...)
AI Ships will decide to flee missiles only if it could destroy their hull unshielded.
A fix to prevent the use of the stardreamer to accelerate time during combat (to cheat).
A "Snap to target" fix which prevents the player from using the stardreamer to cheat and teleport directly to the target base on bombing/photo missions.
A fix to prevent the player from being able to landing at starports that are on the same planet as a mission
For the ship load-out change, it will generate AI ships with anisotropic-like equipment load-outs. I've tweaked this a little though as in Anisotropic all ships would automatically fit the best engine that they could - they'll only do this now if they'll still have plenty of space left for theri equipment/fuel/cargo requirments.
I also made sure that all ships can at least fit a basic forward laser and not be completely unarmed.
I haven't tweaked how much fuel ships will reserve, but I did spot a nasty bug in the anisotropic+hellmod code - it deducted the fuel from the available space twice. This would then result in negative available space to outfit - and so you'd then see ships with 300 shields flying about!
I've fixed this fuel deduction bug in the anisotropic/hellmod builds too, but otherwise the ships outfit in the same way. This will probably need some feedback if
There are also two common patch options (applies to all builds) to experiment with:
One that'll completely turn off the combat fudge for AI ships. In Anisotropic, this only applied when they were evading missiles. Missiles were always exempt.
Also an option to disable the combat velocity fudge for engine-off mode, which anisotropic didn't include - so it might be a bad idea, or perhaps it was overlooked.
Yes I hope it goes some way to alleviate this sudden death scenario. FE2 incidentally also didnt disengage the auto pilot or set the ship to "engines off mode" but the attacking ships would generally trigger a drop from the stardreamer much further out from the player so giving you time to sort your ship for battle or to flee. It's this dropping right next to the player ship and firing at point blank range that irks me the most.
The delayed AI attacks in Anisotropic probably wasn't quite what I thought it was meant to be - it looks like it's more relevant to base ships coming to attack the player too early or pirate ships instantly coming to intercept the player.
However - the newsgroup post that polaris linked to (which it turns out I did have archived away) has some useful information from JJ a bit later on:
Close. In fact, on high stardreamer, the enemies actually teleport to your position (plus the autopilot offset) using the same code as the player uses to teleport to starports and stations. The autopilot offset is stored as a 16-bit vector at 0x102 in the object struct.
In the case of pirates, this is usually determined by the AI state 0x5 function (F749 in JJFFE code). This sets the x and y positions using a random angle and a fixed distance, and the z position with a smaller random offset. Note that the resulting distance range is very small - 1-1.5km or so. The player-relative orientation is effectively random because of the randomised direction of the autopilot offset.
for groups of multiple pirates, only the leader's autopilot offset is randomly determined. The rest are teleported to specific offsets around the leader.
It was quite straight forward to edit that function and push out the intercept distance to start at >8km rather than 1-1.5km. Powerful pirates will still able to one-shot the player once they get within firing range if you're in a weak ship, so I don't know if this will improve things much, but I've added a common "patch" option to enable for all builds anyway.
I haven't altered that prirates fly as a group, if FE2 allowed them to be seperated into single attacks by using the stardreamer, then perhaps they spawned as individual ships or ungrouped once an attack began.
I sorely miss FE2's ability to see other ships on the local system map - it uses the same colour-coding as the scanner so you can see at a glance their approximate sizes, and by checking back some time later you can see if any are moving towards you. With careful control of the pan and zoom functions you could even get visual contact on them from across the system!
I wonder if the corresponding lines of code in FFE are absent, or just disabled..?
FFE deliberately doesn't display AI ships in the system view -unless you managed to find and zoom in on one- so there wasn't any code for drawing points for them in the local system view.
I also spotted that the code would exclude ground bases because it ignored anything classed as having AI. (bases react to an attack by launching ships)
So I've fixed that and the missing "+rontier" labels on planetary targets appear now - so it should be a little easier now to find where the target is for a bombing/photography mission!
It took a fair bit of investigation and new asm code - but the new build can now show indicators for ships in the current 3D system view. They'll appear at the same zoom level as the hyperspace clouds, and they'll be colored to match the scanner blips for FFE or anisotropic/hellmod. Ships that are docked/landed are excluded. You can click on a ship marker point to give it focus and then zoom in on it.
I've also added new key-press code so that 'L' will toggle ship ID labels for the points.
I think that this mission may have gone a little wrong...
Also pressing 'C' will center the view onto the player's ship. And yes, you can zoom from deep space right down to your ship that's landed at a spaceport on a planet! No guarantees that there won't be graphical issues as the view isn't really implemented to handle this... but it seems surprisingly OK
Lots of stuff there to test so I've bumped the version number up to v1.14. Download Beta 1 >here<
As before 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 1.12/1.13 beta build applied to it.
This is incredible, i've just spent the last half hour with it - dropped into Riedquat, flew towards the station whilst checking the system map to see which enemy were closing in first and how fast, targetted, engaged and vanquished them in pure unadulterated fully Newtonian zero-G lazer quest - i gotta go bed now cos the sun's coming up, but it finally feels like the game's 'complete'; the nerfed combat and system map were the last major bugbears blighting my enjoyment, now the gameplay can flow naturally, intuitively, just you vs the elements, the way it should be..
No more guesstimating enemy locations!
No more getting rammed by velocity-fudged gyr interceptors!
Thank you, thank you, thank you...
(FWIW Andy, furballs are just as dense and action-packed, if not moreso with the buffed AI loadouts - there doesn't appear to be any downside to fully disabling the velocity fudge)
..probably gonna be playing this dusk til dawn for the next two days...
So, it's a Bank Holiday, wife's at work (so no interruptions ) and I've got a new build of FFED3DAJ to play, with Pink Floyd (Pulse - Live) in the background and a beer in my hand. Sometimes life's not too unbearable...
Firstly, thank you Andy for fixing the runway lights. They look much more sensible now. Regarding them working correctly in FE2, I knew I'd seen it somewhere!
Secondly I'm loving the new improved combat! It looks like Bounder's enjoying it as well! Much better to have the attacking ships turn up a few km away and attacking you as a unit. I've also disabled a few of the "cheats" relating to bombing missions; I had got (gotten?) a bit lazy and was launching a missile from 6000km away before hitting maximum stardreamer and completing the mission. Now I have to fly to around 50km (handy to be able to lock the autopilot before you even get to the planet!) and then attack. Nice to see the missile arrive at the target as well, though it's a bit of an anti-climax when the buildings just get replaced by a crater...
Finally it's good to be able to find the other ships in the local system view. I don't think I'll be using this feature as much as Bounder but I'm glad it's there.
So now - as well as enjoying the game - I'm trying a few things out to see if there are any issues or bugs to be ironed out, though Polaris is better than me at finding them! I did see the old bug where an enemy ship flickers between different locations when I was tinkering with the new options and I'll see what I can find out about that and post my findings here.
There's so much goodness in this build I've only really scratched the surface.
Thanks for your hard work Andy. FFED3DAJ v1.14 is brilliant. Elite: Dangerous is due an update tomorrow but I think I'll still prefer this!
It took a fair bit of investigation and new asm code - but the new build can now show indicators for ships in the current 3D system view. They'll appear at the same zoom level as the hyperspace clouds, and they'll be colored to match the scanner blips for FFE or anisotropic/hellmod. Ships that are docked/landed are excluded. You can click on a ship marker point to give it focus and then zoom in on it.
...or select one as target and start chatting to see its intentions.[big grin]
This suddenly becomes the best device in combat avoidance, especially when using Bounder techniques. By playing with stardreamer and watching distances to nearby ships in 3D system view, you can avoid most combats. Is this cheating? I think not... if you are a qualified navigator or have one on board.[big grin]
When watching nearby ships in 3D system view (without stardreamer), I noticed that some friendly ships are unrealistically jumping from one place to another. I suspect it is a bug! Load this saved game https://drive.google.com/open?id=1XDm_O_j4ktxGVqHIWWItj0zUIHVqRqJc
A troubled ship is already selected for autopilot. Watch its behaviour. XU-138 is jumping like crazy.[woah]
I use F6 key in 3D system view to constantly update ships position. Unfortunately the key resets orientation every time, making difficult to keep your target in view. Can a key be implemented for updating ships without changing orientation? Just asking...
+ New option to restrict communications Services videos to only play once during a visit. This does not apply to BBS message videos or police arrests. Set "SinglePlayAllServicesVideos=1" to use this option.
+ Added previously unreferenced "welcome" videos which will now play at Corporate state/policed systems. If the player has a large fine, has been caught smuggling/trading contraband goods or is highly ranked with
either Empire/Federation then there's a chance of an alternate video.
..it is a brilliant feature isn't it? God knows how he pulled it off, but it almost transforms the game - system 'map', or long range scanner, eh? It's fully consistent with lore, and especially the basic premise of Elite and most classic sci-fi.. the original game design could've capitalised on it so much more..
A "Snap to target" fix which prevents the player from using the stardreamer to cheat and teleport directly to the target base on bombing/photo missions.
It was quite straight forward to edit that function and push out the intercept distance to start at >8km rather than 1-1.5km. Powerful pirates will still able to one-shot the player once they get within firing range if you're in a weak ship, so I don't know if this will improve things much, but I've added a common "patch" option to enable for all builds anyway.
Unfortunately it does not prevent pirates teleporting to you in certain situations (some outlined by me in a previous post). But generally it seems to be helpful.
And with the anisotropic setting enabled "anisotropicBattleMode=1" the situation is worst. The likelihood to be suddenly attacked is higher. Sincerely, I do not see the benefit of this one.
One that'll completely turn off the combat fudge for AI ships. In Anisotropic, this only applied when they were evading missiles. Missiles were always exempt.
If "DisableAICombatVelocityFudge=1" is enabled I cannot overtake slower ships (e.g. Saker III vs. Imperial Explorer). I have to enable "anisotropicDisableCombatVelocityFudge=1" for this to work. Do these settings overwrite each other in fact?
Obviously here, Canopus star is closer and heaviest, but distant Canopus 5 is mysteriously selected as the reference body.
A simple model would be to select the gravitational body based on the highest gravitational force exerted on the player's ship at current position. Another variant is to test if the ship is within the gravitational sphere of influence of a body (if not, default to the main_star/mass_center). The program seems to decide differently.
2. Mysterious green dot in 3D system view
This is related to the latest addition of ship indicators.
In binary systems a mysterious green dot is generated at the mass center. It cannot be targeted and is not moving. An artefact? Or, could be wrong, but I suspect in binary systems a virtual body is generated at the mass center, and sometimes used as the gravitational reference body.
3. Attacking ship relocated
This could be an artefact of disabling velocity fudge only in 'engines-off' mode.
In the saved game watch the attacking ship. As soon as it is close enough, it will be teleported away from the player. If you maintain autopilot on, the same scenario will repeat again.
Obviously here, Canopus star is closer and heaviest, but distant Canopus 5 is mysteriously selected as the reference body.
A simple model would be to select the gravitational body based on the highest gravitational force exerted on the player's ship at current position. Another variant is to test if the ship is within the gravitational sphere of influence of a body (if not, default to the main_star/mass_center). The program seems to decide differently.
Can't resist weighing in here - i get the impression it works as you suggest, however this principle 'fails' numerically when you have a low-mass body close to a high-mass one, since gravity squares with proximity, hence the preponderant gravity field remains that of the larger body, until you get really close to the smaller one. To put it another way, doubling or halving our distance from a massive body causes a much greater change in gravity than doubling or halving its mass would.
There would seem to be two neat solutions to this:
- Implement user-selectable reference frames; per Pioneer, it's a logical fulfillment of the nav system's basic function, already conspicuous by its absence regardless of this 'bug'..
Anything and everything should be selectable as an FoR... however, there's another really cool trick here everyone else has missed thusfar (Pioneer included), which your next point touches on..
- Auto-select FoR's by proximity rather than G-field strength.
Perhaps toggle-able in-game would be useful? When enabled, the nearest body - be it a cannister, or anything over a given size limit - automatically becomes your FoR, and your 'Set Speed' is zeroed relative to it.
As an example, this would enable using "Manual Mode" (ie. FA-on) for such things as cargo scooping and mining asteroids, instead of having to rely on FA-off when in deep space.
Furthermore it would also enable FA-on in combat... allowing ships to dogfight in pretty much the same way enforced in ED, but without any of its restrictions... but for one potential snag; what to attach the FoR to in a dogfight in deep space? If you select another ship as an FoR then its velocity changes are going to read as yours, without you even firing a thruster, so that isn't ideal... what you really need some kind of pseudo-static 'virtual' FoR, temporarily attached to whatever your current vector...
...and this is what your next point leads into..
2. Mysterious green dot in 3D system view
This is related to the latest addition of ship indicators.
In binary systems a mysterious green dot is generated at the mass center. It cannot be targeted and is not moving. An artefact? Or, could be wrong, but I suspect in binary systems a virtual body is generated at the mass center, and sometimes used as the gravitational reference body.
..i hadn't noticed this (yet), however your assumption seems logical, and what you're describing is a 'virtual FoR' - albeit, one normally hidden...
But why should FoR's only be actual bodies? If a center-of-mass can be an FoR, then why couldn't a velocity vector?
Here's how it could work:
- When the 'Under Attack' warning is given, a virtual FoR is automatically generated from whatever your current vector. But how to implement this?
- Suppose the moment the claxon sounds, your ship immediately ejects a cargo canister, and selects it as your FoR. It just floats along beside you, with zero velocity. Your ship is in manual mode, with "Set Speed" at zero. Any accelerations you make from now on are changing your speed relative to that canister.
That's the basic principle... now just replace an actual 'canister' with a virtual, unseen one. Just like that little green dot we're not supposed to see..
This virtual FoR needs no visual reference, since it has no specific location - in principle, that invisible canister you ejected could equally have been teleported over to the other side of the system - it's still on your vector, and stationary relative to you. So it could even be a physical object, a dummy proximity mine or whatever, a thousand AU away.. makes no difference, net result is that you can re-zero your 'set speed' at any moment, at the touch of a button, mid-dogfight, regardless of your velocity relative to your nav target or anything else..
This singular feature would achieve everything ED sets out to do via enforced speed limits, only in a natural, logical and seamless way - dogfighting with FA-on, with yer barrel rolls and your split-S's and all that mass-appeal classic dogfight action.. HOTAS-tastic, type stuff..
3. Attacking ship relocated
This could be an artefact of disabling velocity fudge only in 'engines-off' mode.
In the saved game watch the attacking ship. As soon as it is close enough, it will be teleported away from the player. If you maintain autopilot on, the same scenario will repeat again.
The velocity fudge is just another example of where virtual FoR's would've neatly and simply solved everything - FD were trying to literally force CQB intensity by artificially ramming ships together. It never even occurred to them to rather increase freedom and control by implementing basic thruster mappings - JJ added this later (still no analogue!) - but the key to achieving the classic planes-in-space dogfighting they (and we!) wanted was always FA-on / 'manual mode', yet they never thought to simply use temporary, transient FoR's for combat encounters, independent of navigational FoR's for destinations!? To me, it's always seemed a self-evident solution..
In usage, the player need know nothing about a 'virtual FoR' - just as you hit the backspace key to zero your 'set speed' relative to your current (navigational) FoR, a similar keystroke could instantly do so relative to a virtual frame, without physically having to decelerate relative to your nav target..
Personally, i'm now entirely used to combat with no FoR - you don't even need one, really, all that matters is using your thrusters to control (or at least influence) your proximity to a target, one way or another.. it's like kung-fu in free-fall - whatever speed you're both falling at is almost irrelevant..
I've been playing v1.14 extensively, without particularly looking for bugs. One I have found though, on an animation theme again, is that the advertisement boards on the corner of the building in the attached save game don't seem to be animated.
Would it be possible in a future release to stop systems with no settlements from showing an import/export market? I know it's something even FE2 seemed to have issue with, and not specific to FFED3D or Andy's mod.
I use F6 key in 3D system view to constantly update ships position. Unfortunately the key resets orientation every time, making difficult to keep your target in view. Can a key be implemented for updating ships without changing orientation? Just asking...
Yeah, I'd wanted to do this but didn't have time to add it for the 1.14 build. I've added some new code since so that the 'R' key will reset the view to the current date/time but keep the zoom/orientation. This also works so that you can accelerate time in the view and hold the 'R' key down to see the positions constantly updating.
It turns out that the ships that seem to be jumping randomly from one position to another are actually following circular paths. Their AI mode suggests that they're meant to be heading towards a hyperspace jump point - so not sure what's happened there!
The "Snap to target" fix simply blocks stardreamer when the autopilot is set to a mission target, so it's an easy check with little risk.
It'll be much harder to block warping to a station on the opposite side of the planet, the danger being that it might block legitimate use so not sure it's worth the risk to eliminate a fairly minor 'cheat'.
If "DisableAICombatVelocityFudge=1" is enabled I cannot overtake slower ships (e.g. Saker III vs. Imperial Explorer). I have to enable "anisotropicDisableCombatVelocityFudge=1" for this to work. Do these settings overwrite each other in fact?
You've probably realised by now that switching off the AI's velocity fudge was an additional feature to give them the same freedom as the player had - without using the anisotropic setting though, you were still limited so yes the AI ships could evade you. I've corrected this now so that the extra AI & engines-off setting only applies when the player is also using the main anisotropic setting.
I think so too. I took a very quick look at this, and it does appear that JJ had started to investigate the issue. If you call up the FPS screen, there's a calculated frame-of-reference object displayed there which does appear to display the expected object in your Canopus example. The standard FoR calculation function is called from multiple locations and I think for all object types, so I'm guessing there must be wider implications to trying to fix it, or it would have been done in JJFFE. One to tinker with in future perhaps.
It's a special object to mark the mid point between two binary stars - it's drawn as the green arrows on the 2D chart but shouldn't have appeared in the 3D view. It's fixed in the new build.
I've been playing v1.14 extensively, without particularly looking for bugs. One I have found though, on an animation theme again, is that the advertisement boards on the corner of the building in the attached save game don't seem to be animated.
Not all of them are animated Steve, the 3 that are alternate these captions:
JJAGGED BBANNER / DREAM WARE, PURE COLD / CRATER JUICE and FIRST / ENCOUNTERS.
Long standing bug I suspect (I seem to remember it in FE2 as well), but has anyone ever made a mod or fix (or is attempting to fix) this annoyance? It gets to the point where I just end up not bothering with an unknown star system unless I see an orbital station icon as it's quicker than checking every individual planet for major starports only to find there are none, despite the system having a thriving import/export market. I've managed to only be lulled into a false sense of security and tricked into jumping to such a system once and been stranded, but what a pain!
Would it be possible in a future release to stop systems with no settlements from showing an import/export market? I know it's something even FE2 seemed to have issue with, and not specific to FFED3D or Andy's mod.
I've added the option to suppress any commodities from being displayed in the import/export screen when a system has no star ports or stations. I've also made an enhancement to the 2D system view so that it'll now show a count of star ports and stations that are present to avoid having to click through individual bodies searching for star ports. This required a new string and the non-english versions might need correcting.
just have a bare-bones 'console' mode brought up via the tilde key per Unreal etc., able to take basic commands like changing FOV or running scripts etc.
Just having wingmen would be a really cool option. Just NPC's that are being controlled by the wrapper with simple commands to follow the player at safe distance and target anything attacking them. Or being able to issue them simple commands like fly to X or target Y etc.
Peeking and poking at games growing up, the great thing was that you didn't need to know how or why the game worked, only that entering certain values to certain addresses yielded certain results.. they were all ASM binaries, but all you needed to know was what was where in the address ranges..
Naive fantasy or not, just kicking it out there...
So...
There was a bug report in the Elite/Frontier support forum where the player's ship kept yawing, which sounded very much like a damaged engine after ruling out controller issues. Although I could have just worked through it in debug mode I thought that it was a good reason to think about adding a dev console that'd let objects and data values to be examined/updated.
I remembered that DreamZzz and ТехноМаг had started to add one in their late, unreleased builds of FFED3D so took a look to see if it could be put to use. Unfortunately theirs is LUA based using a hand-built .dll that didn't play nicely with debug mode, corrupting the stack. Updating it looks to be non-trivial as there have been a lot of changes to the names of methods and to be honest, it looked like it would probably be more straight forward just to write my own command parser to achieve what I needed - so that's what I've done for now...
Commands can also be saved to rudimentary script files and there's basic IF ELSE and GOTO functionality... enough for updating a few values but not more complex behaviour at this point. I might take another look at LUA or integrating something else, but it almost looks more straight forward (and fun) to expand on this starting point should I choose to. We'll see, no promises anyway.
The console is opened with CTRL+` (grave key left of '1' on the main keyboard)
So what about wingmen then... well this was something else that DreamZzz and ТехноМаг had dabbled with. I managed to get these working and migrated across into my codebase. There were a few bugfixes and refinements such as storing the current AI mode and pilot name in some spare bytes against the ships so that they save/load correctly & still have a ship ID label. Load-outs follow the corrected rules from v1.14 but could be an area that'd benefit from scripting in future.
Wingmen are spawned from the console at present and are quite basic - there to play about with for fun rather than anything meaningful. You'll need to be in flight to create them and they should follow you through hyperspace too as long as they have the fuel to do so. There is also the option to spawn enemy ships - but at the moment they'll appear as if they've hyperspaced into the system and quite a way off - I'll take a look at improving this so that they can be spawned nearby for instant action and perhaps as groups not just individual ships.
Once a wingman has been spawned, the grave key (`) by itself brings up the wingman menu, with 1-0 to select the options.
There's other fixes too, of course!
I was able to reproduce the texture-loss bug that Steve reported link) and fixed that, refactored the texture loading and added some system checks so that caching to video memory is the default behaviour when the game detects enough is available. (can be turned off/tuned).
I've been able to improve the missile launches too so that they'll flip over after launching when the target is behind the ship - rather than fly backwards(!) - a legacy bug that polaris reported. (link)
I decided that I probably haven't time this side of Christmas to tidy it up enough to be non-beta - there's still some city tiles that I want to look at and shader/textures for the supporting files that I want to update. So here's v1.15 beta 1 to play about with: https://www.dropbox.com/s/x7dvnko29hqpsgs/FFED3DAJ_v1.15 beta1.zip?dl=1
Not all of them are animated Steve, the 3 that are alternate these captions:
JJAGGED BBANNER / DREAM WARE, PURE COLD / CRATER JUICE and FIRST / ENCOUNTERS.
The blank advert should read "NEW ROSSYTH THE VERY BEST" and the red advert on the right of the building isn't animating when it should do. The problem seems to be restricted to this particular building; the same adverts render and animate correctly on others. I'll try to get hold of Gernot, as IIRC this is one of his creations.
Well, it is a text console primarily to aid debugging... I'm not sure if it qualifies as exciting!
(example: commands "list" & "info 78")
I also forgot to add into the readme file how to spawn the enemy ships.
I've just updated the file on the dropbox link.
Regarding the adverts, it looks very much like the text is missing. Is that a new building model? Or an updated TV screen model (235)?
Can you check in the model folders (if you can identify the building) and see if there's a tris.ini file with the line notdrawtext=1 ? (that will block the labels)
Otherwise could you drop me a save at that position as I'm not seeing the issue here.
Regarding the adverts, it looks very much like the text is missing. Is that a new building model? Or an updated TV screen model (235)?
Can you check in the model folders (if you can identify the building) and see if there's a tris.ini file with the line notdrawtext=1 ? (that will block the labels)
Otherwise could you drop me a save at that position as I'm not seeing the issue here.
By the way, the game's a lot happier with me Alt-Tabbing or Windows Key-ing out of the game to do other stuff (like ordering cat biscuits) than before. Excellent!
