gerwin

The earlier crew turned out to be a bunch of Yankee infiltrators, they have been arrested and replaced with proper flak crew.

The crew arrived already! Judging by their helmets these must be Fallschirmjager.

I will try to add some crew, like in the two seated positions that rotate with the gun. AFAIK any other crew can not sync nicely with a changing gun direction. It would have been nice if it was possible to add a recoil effect to this gun.

TFDtool v1.04 is available since last week already. - Texture limit increased from 512 to 1024. - The keyboard input bug is gone. :)

I uploaded a new version of the Panzer IV. It now has a Tan/Sand texture as well. It got a fourth distance lod, plus I renamed it from Panzer4 to Panzer4H. Yesterday and today I worked on a Flak 18 88mm. Made from scratch, fortunately there are several detailed drawings available for this gun. It is not ready for release yet.

I hope so to. For the people who reacted 'haha' to the previous post, I don't really see much irony there. If you wan't to get a feel for the potential stress of game programming, look up some interviews regarding those famous 1990's independent game development companies and their working hours near the deadline. A bit unhealthy to say the least.

Attached below is a function list of D3D.dll. It does not seem to be a wrapper, since the function names give me no matches with Google search. So I figure it is just (part of) the Direct3D rendering code. For 3DFX-Glide I would expect a similar DLL called glide3x.dll. This glide3x.dll is mentioned in the EAW exe, but maybe it is statically linked, thus included in the exe? d3d.dll.txt I tried EAW barebones v1.60 on another computer: WinXP, Radeon HD6670. Now the textures seem smoother and I cannot see the dithering like on the Intel HD system. But the mouse cursor remains visible in the center at all times, but I can get rid of it with "Windows 2000" compatibility mode. Some windows file icons change after running this game, this may be indicative of a problem in exitting the game? In d3d.dll there is the function "d3dSupports8BitTextures". Well ATI/AMD radeon never supported that in hardware, so when it gets a NO answer; there the game might actually behave better.

Migbuster, your SF2 changelog is amazing work and has lots of details I missed myself. Though " Terrains have higher resolution tiles." seems to be in error. I have never seen a change from 256x256 pixels ever. Also did you add the crashed plane wreckage feature somewhere? A few of the SF2 exclusive features were eventually backported to SF1 with WOI expansion pack (2010). I used that as a base for a long time. But SF2 got so many small improvements that it is hard to recommend anything SF1 at this point. For modding purposes I can no longer do without the mission editor (if only to quickly check how the game handles installed objects) and userlists (to have better control over how the game distributes objects between nations).

German Panzer IV is up! Same story as the Sherman; it is from the same royalty free payware source. MG-34 by me. I re-uploaded both HEMTT models also. The color of the cab/base textures was adjusted to better match the trailers.

About the amount of work; It depends a lot on the state of the code. Just as an example; Compare it to an old game with a small fixed resolution like 640x480. In some cases these games were actually programmed with abstract and flexible resolution handling, and just changing a few values makes everything scale properly, to 1024x768 or something. Because the original code already had the procedures to scale things. Other games make assumptions about being in 640x480 mode all over the place, and it is a lot of work to find all these places and replace them with scaleable code. Especially when assembler code is involved with it. In the worst case you'd have to conclude that the old rendering code was a bad job and needs a complete rewrite. EAW 3D rendering code should be reasonably modular at least, since it supports both Software + Direct3D + 3DFX-Glide. Meaning that the code was made to handle three different rendering paths. In the EAW 1.60 version I just tried (It runs!), there is obviously a dithering effect in the video output. Probably used at the time to improve the looks of the game by reducing color banding, but dithering is not beneficial for true color games, so it would have to be removed. I am sorry if my remarks sound annoying, I sensed a little confusion over this subject and this is my try to help out.

Was lurking this topic already, good luck with EAW in any case. (I hardly played it myself.) I like your attitude quoted above. I keep my Strike Fighters install pretty lightweight for similar reasons. Gameplay above graphics any day, and I can't stand loading times either, especially when testing mods. Videocards don't display any specific image formats as identified with their file extension, with the exception of support for NVidia .DDS compression variants DXT1 to DXT5. Video cards display bitmaps in the general sense, like a map of bits. Bitmaps are extracted from their disk-format at the time of reading them from the disk. Like one can read a 8-bit indexed color compressed .png image from disk, and right after reading it and decompressing it, use the attached palette to translate it to true color: You then have true color bitmap data to do whatever, just have to remember width and height and can forget the rest of the original file header. When I do a internet search, I read that EAW uses Direct3D with 8-bit paletted textures internally. I figure 8-bit paletted textures made some sense then, to use less memory, like just 1/3 compared to true color textures. In all other ways it just sucks. Hardware support for it was brief and long gone, but the Direct3D API + Video Drivers probably have emulated support for it. AFAIK the way to go for an improved EAW is to ditch all palettes as soon as the textures have been loaded from disk, and use true color internally. Easier said then done though. Edit: As for the topic name, you don't need a hardware programmer really, but a Direct3D API programmer. It is like this: Game -> Direct3D API -> Windows Video Driver -> Video Hardware. (I never programmed Direct3D API myself, I am not a real programmer anyways)

Good point! I had not really noticed before, but just flew some SEAD mission with an AV-8B and one wingman. If my wingman has a Rockeye+AGM-65 loadout, he at some point keeps making dives to targets without releasing the remaining stores, neither will he use guns. Make it a rockeye only loadout and he behaves properly + uses his guns when out of stores... This is not even a pure AI flight as mentioned above. Edit: Tried a similar setup but with the A-10: Wingman has no problems using different types of weapons.

There was the above topic, but it does not hold much info. It is hard to consider doing without the SF2NA Naval warfare goodies, These are great fun! ( Even considering SF2NA was never 100% Finished + never 100% Functionally Integrated with the other games. IIRC TK once advised not to merge SF2NA like the other games. Unfinished I mean: There are hardly distance lods for the new objects, so framerate can suffer. That would be most noticable with parked planes, but SF2NA itself does not have a problem with this, since the big RED airbases are off-map. Then there are 'Jammer' plane types that do nothing, and the criticised new terrain... ) Maybe older game versions can be interesting for optimal gameplay on terrains without Naval warfare... I don't know the particulars.

Anyways, here are two bugs I would wish to be gone: 1) A terrain with navalmap=true where nation 001 can access an Aircraft Carrier. The enemies of this nation 001 have only one Strike objective in single missions: The carrier. Nothing else. 2) In June 2012 player missiles were made more damaging compared to the same missiles laucnhed by AI craft: There should be some line in the options.ini to get rid of this 'cheat'.

I don't think dumped is the right word here. My take is that Third Wire either supports a game or not. There is no in between. And it is primarily because customers do not understand and do not accept half-support, but they surely understand unsupported. As soon as TW openly shows a limited support for the SF2 games, like a Windows 10 update, there will be customers complaining he does not support it enough. Also I have some things I could write down here as bug-fix wishes, but I just get cought up in my memories of the last years of SF2 development, where TK wrote how things should be simpler instead of realistic. Game and not Sim. IIRC he at some point suggested automatic landing gear up instead of manual. Then there were many complaints about missile effectiveness in SF2NA which was addressed by making player missiles stronger then AI missiles in June 2012 level. I am on May 2012 level because of that. I do not blame TW to have priorities that differ from my wishes. I think TW priorities were at that point not personal anyways, but about customers and sales. Or maybe they were personal a little, because the original course was just to hard for Devs. Modders and bolt and nut counters make very annoying customers already, but when beyond that there are not enough sales with increased costs , then one has to change course. With that in mind I can only imagine some small patch for SF when it is totally clear that it does not imply much, and it is just for fun. But wheter or not it is fun for TK, no idea. It is not my business either.

Can I point out the following. 1) There may be a tiny chance that the developer FEELS like patching up a few little things. But a developer needs to be wary of his audience, as they can behave like they are entitled to more then they actually are. . (Example: IF I would even accept donations for TFDtool, chances are someone gives a donation then asks for a feature to be added in. Thus, he does not give the donation for what was already done, but for what he wants to be done. That is a big difference ) If you ever contact a Developer with requests, he will immediately be wary of what other expectations follow: Will patching one little bug start an avalance of similar requests and expectations. I figure that is why the Strike Fighters PC series are kinda buried on the website (with warnings), as advertising and selling them results in expectations from the buyers. 2) A reply to Stratos in particular. I understand your feeling regarding the fact that Strike Fighters is out of active development for 5 years now, and closed source as well. I dislike that as well. But this situation is actually the norm for commercial software. So if you find it unacceptable then I could say: use linux and GNU software instead. In addition, in the previous topic there were some misunderstandings about what is possible without the source code. Which is similar to your request+answer form a few years ago. These are just two examples of what I would call misunderstandings, and it would not help communication with a developer with such misunderstandings on the table. I don't know what to suggest, I don't mean to insult, but: Learn about it first and/or Let somebody else edit any communication with a developer first and/or Let someone with a better understanding of that matter handle such.

Another download is available. This is an M4A3E8 Sherman obviously. It was made from a Payware Royalty Free 3D model. It was a nice model with a polycount suitable for this game, but there were lots of things that could use some adjustment. Capun''s site has some other conversions from the same source, which is probably what triggered my project here. The stock Israel game has the M-50 and M-51 upgunned sherman variants, but the game was still lacking an unmodified 76mm sherman of similar quality. This should be it. Earlier I was thinking of adding one or two 75mm shermans as well, but in a post WW2 scenario these may not fit in. The weakest Red tank being the T-34-85 with a much better gun...

Sorry, I do not have the knowledge now to add much to what has been said like here. I imagine that, once you manage to get the player aircraft starting point inside a hardened shelter, you will get AI wingmen acting crazy instead of taking off.

Just uploaded a new version, but it is still called v1.03. - 50% chance option for the target successor batch script. - Targets.ini outputfile linebreaks now compatible with Windows' Notepad. - New main menu appears when hitting the ESC key. This one links to the other four menus. - Supports the SF2NA iceland "RotateToRunwayHeading" option for airfield targetareas. - Now shows a generic airfield runway graphic in case the runway does not match a known type.

Looking forward to that! I am considering adding a 50% option to this function. Where there is only a 50% chance that a vehicle will get a successor. As I want to keep some M35 Trucks together with newer models. PS. In an ideal world this upgrade at a certain year thing would have been supported by the Types.ini. That would have been the proper way. But it does not work, so this is AFAIK the easiest way to do such a thing.

The stock objects have low detail distance lods which make all the difference. Compare having an entire airfield in view with parked aircraft and groundobjects all in full detail LODs, or in low detail LODs because they are too far to see details anyways. Edit: This guy does a great job with Il-2 1946 distance Lods, as seen in the illustrations: http://patrulla-azul.com/FreeIL2modding/forum/viewtopic.php?t=1682 But it sure is tedious, I know....

No such ambitions really. TK's auto-tiling function and the TOD object generator are way too much work. The user interface part of the programming library that I use, also crashes on modern systems. That is one reason for the minimal user interface in TFDtool. But I will just keep on adding to TFDtool whatever seems fun at the time. Version 1.03 is up now. Changes are: - Target Successor procedure, to automate the process of groundobject changeovers after a certain date: Like USJeep becomes USJeep2 (Humvee) in 1983. See also the topic linked below. This means that TFDtool got the functionality to write a complete targets.ini file. It was tested to recreate all stock targets ini files with complete accuracy, From SFP1 Desert up to SF2NA Iceland. It does not overwrite the original targets-file. It is advised to keep backups and check the results yourself. - Shows ground targets with a successor, with the changeover year. As pointed out by the red arrow in the screenshot. - A new F2 options dialog, with buttons for functions that were formerly only accesable by hotkeys. (I started to lose track of all these functions and buttons.) - Tweaked target file reading so it does not crap out on all the trees in SF2NA iceland. - Improved the tile info dialog with a bigger preview picture and TOD statistics. Moved the texture reload function to this dialog. - Clip-paste of tiles with the N-key: the keys [ and ] can now be used to adjust the size of the painting area. (Requested by Menrva)

I don't think I even had a signature before, But it is a good idea so I added it just now. Adding these things to the terrains is tedious: InActiveYear does not work as such in the terrain types.ini. Fortunately ActiveYear=1983 does work there. The rest is to be done in the Targets file: Edit existing targets by adding an InActiveYear=1982 to them, Then copy them over to the end of the targetarea and change them to the new type, with a new sequential target number of course. TFDtool will need an update to do such a thing automatically for a loaded Targets file, for any specified old Type + new Type + InActiveYear. For example: Type 'BRDM' becomes 'BRDM2' after 1982. Type 'USTruck' becomes 'USTruck2' (M977_HEMTT) after 1982. Type 'USFuelTruck' becomes 'USFuelTruck2' (M978_HEMTT) after 1982. Type 'USJeep' becomes 'USJeep2' (M1025 HMMWV) after 1982. Or any such groundobject mod from this site.

I finished the M978 HEMTT Fuel truck past weekend. At least up to Beta level, as the texturing of the fuel-trailer is still rather plain. This groundobject can now be downloaded from my website. It makes these airfields look so much more modern. In addition these three models were updated: The M977 HEMTT, BRDM-2 and BRDM-2-SA-9.

Waybackmachine can't retrieve all, but yes $29.99 it was in 2017. Wings over Vietnam used to be $14.99 (50% off!) years ago. Some DLCs used to be cheaper then others ones, at $2,99. Now the DLCs are all the same price. I bought another four DLCs this month anyways. https://web.archive.org/web/20170723220239/https://store.thirdwire.com/store_w7_all.htm