Jump to content

mue

+MODDER
  • Content count

    303
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by mue

  1. View File Mues Toolbox In this package you find the current versions of my programs. Since all programs are using the same Qt and Microsoft Visual Studio libraries I thought it is convenient to put them all together. This package contains currently: LOD Viewer V0.5.2 Target Area Editor V0.2.2 (Updated) CAT Extractor V0.1.0 (NEW!) For usage instructions of the programs please read the readme files located in the Readme folder. Submitter mue Submitted 12/09/2015 Category Utilities / Editors  
  2. This guy is hilarious. Quite entertaining. I already had a laugh when he described the fighter generations
  3. He removed the link. His answer to my comment to his latest SF2:Vietnam Ep 43 video:
  4. It seems as he started his SF2 video series the Thirdwire store were down. From the description of his first SF2:Vietnam video: I think at this time he thought the SF2 games were abondoned. But later as the Thirdwire store were up again, although he now mentions that you can purchase the games from the store, he still provides the link to the illegal copies.
  5. I really like his videos. What I don't like is, that he provides a link to a download site where you can download illegal copies of all SF2 games.
  6. I wrote a tool that someone may find useful: a LOD viewer. I tested it on Windows 7 and 8. Unfortunately it doesn't run on Windows XP. From the readme.txt: LODViewer Version 0.1 Author: mue Use at your own risk. The program is free for personal, non-commercial use. Usage: LOD files are loaded with File->Open... The program also tries to read the ini file with the same basename (eg. tank.lod -> tank.ini) for textureset information. The texture directory can then be selected via the texture directory combo box. If no ini file is found or it does not contain textureset information then the texture files are assumed in the lod file directory. The left upper window shows the node structure: node names and material ids. Nodes can be selected with left click and deselected with ctrl+left click. The lower left window shows the texture file names of the materials. The right graphic window displays the 3D view of the lod object. The view can be manipulated with the mouse: rotation: left click + move translation: right click + move zoom: mouse wheel reset view: middle click Nodes can be selected with ctrl+left click, and deselected with ctrl+left click on a blank area. Selected nodes are highlighted in red. Nodes whose texture couldn't be read are displayed in green. Known issues, missing features, bugs: -simplistic lighting (no specular, glossiness, reflection, bump mapping,...) -no transparency -no decals -problems with reading some tga files Screenshot: (Download link temporarily redacted)
  7. I'm curious what features FE has what SF doesn't have? Regarding flight models, I would think the (prop) FM in both games are (nearly) identical. Maybe the AI or campaign system is different? What else?
  8. The stall modeling in SF2 (e.g. the Stall*TableData) is still a big unknown to me. The regime between -AlphaDepart and AlphaDepart I mostly understand. Currently I'm implementing the SF2 P-51D FM in JSBSim/FlightGear. In the normal non-stall/non-departure regime it already "feels" quite similar to SF2. But I still have to run some validation tests. Yes, while sifting through the TW forum archives I noticed that back then there were several FM guys active. And according to the questions they have asked, it seems they know that they are doing. I think one guy was from avhistory.org and wanted to port CFS? flight models to SF.
  9. Since I had a look into the shaders I also extended the drawing distance for fading objects. The modified object shaders: Update V1.1: fixed incorrect calculation of object distances outside the view center. sf2_extfadingdistance_shaders_v1.1.zip -Copy the shader files (*.fx) into the Terrains\<terrain> folder. -Adjust the variables fadeStartDistance and fadeLength to your likings in the follwing code section of both shader files: float fade_with_distance(float FadeDist) { float fade_alpha = 1.0; //mue: distance at which the object still has alpha = 1.0 (full opaque) const float fadeStartDistance = 16000.0; //in meters //mue: fadeStartDistance + fadeLength = distance at which the object has alpha = 0.0 (full transparent) const float fadeLength = 3000.0; //in meters const float fd = FadeDist - fadeStartDistance; if (fd > 0.0) { fade_alpha = clamp(0.0, 1.0, 1.0 - (fd / fadeLength)); } return (fade_alpha); } -Set in flightengine.ini DetailMeshSize so that (fadeStartDistance + fadeLength) / terrain_tile_size < DetailMeshSize -Set in options.ini ObjectsFade=false -Enjoy your flight!
  10. In your TrackIR profile (in the TrackIR software) disable the z-axis.
  11. Maybe I'm getting old...but, how can I embed youtube videos in forum posts? I couldn't find it in the editor. I know I have done it in the past but that was before the site update.
  12. Note: The LODViewer has a bug. If you reload textures while an animation is "shown" (like in the first post, where the gear is extended and the gear doors are open) then the decals are (erroneously) applied to the current (animated) position of the mesh and not the original one.
  13. AFAIU: If you want proper 44100Hz sounds, you have to change ALL (incl. stock sounds) to 44100 Hz.
  14. Mainly to motivate myself, I made an initial test regarding using 3D assets from SF2 in the open source flight simulator FlightGear. Since FlightGear uses the same 3D graphics library (OpenSceneGraph) that I also use in the LODViewer, I could easily reuse my LOD file loader plugin with only minor modification. This is only an initial test. There are still a lot things to do regarding 3D models: animations, shader adaption, .... not to mention reimplementing the SF2 FDM in FlightGear. But maybe some day... TWs P-51D at Honolulu International (the current FlightGear default airport). Note the missing landing gear caused by nonworking animations: Cockpit view:
  15. Yes GPL means General Public License. Only if you want your aircraft included in the official FlightGear hangar "FGAddon", then the GPLv2 is obligatory. Otherwise you can license your model as you like (assumed the whole model is your own creation and don't contain or uses GPL content) and use it in FlightGear.
  16. Correct! But the buyer/recipient also get the same rights as you from the GPL. He can use/modify/distribute/sell the content under the GPL. His right to modify the content also means that you have to give him the "source code" of your content. The GPL says about the source code: "The source code for a work means the preferred form of the work for making modifications to it." I think (maybe Richard can confirm or correct me here) that means, that if you sell the lod file then you must also include the e.g. *.3ds or equivalent file.
  17. For those who don't know the GPL: If you use GPL content for your aircraft then the derived work, i.e. your aircraft, is also automatically licenced under the GPL. That means you can not distribute your aircraft under the CombatAce Modders License Agreement, because the CombatAce Modders License Agreement forbids the sale of the content (as payware). However the GPL doesn't allow those restrictions. Under the GPL the user has the right to sell the content!
  18. Currently I'm trying to reverse engineer the SF2 flight model. I stumbled over the stall tables. Does anyone know how the stall tables (StallLiftTable, StallDragTable and StallXacShiftTable) work? As an example here are the StallLiftTable and StallDragTable from the P-51D and F-4B inner wings: I assume the abscissa is alpha and the ordinates are factors for some lift or drag coefficients. Correct? What are the lift and drag coefficients? CLmax for lift and StallDrag for drag? But the drag table looks odd. I would have assumed that at alpha = -90 degree and +90 degree the drag factor would have its maximum. When are these tables used? If alpha > AlphaDepart?
  19. Maybe you FM gurus knew this already, but I only recently noticed that: Internal fuel and the pilot (and internal ammo too?) don't change the center of gravity (cog) of the aircraft. The additional weight will always be placed at the cog. Only the inertia tensor (Ix,Iy,Iz) is changed as follows: Ix = (mass_total/mass_empty)*Ix_empty, Iy = (mass_total/mass_empty)*Iy_empty and Iz = (mass_total/mass_empty)*Iz_empty
  20. Ok, now I understand. I forgot/haven't considered that you use the official multiplayer network with it's civilian traffic.
  21. Since the multiplayer protocol is open, you always have the risk of cheating. I don't understand how releasing the python code increases the risk of griefing? I assumed the FlightGear combat community isn't that big, means you know each other, and therefore cheating isn't that much of a problem.
  22. TK posted this in Sep. 2007 in his forum. See this forum thread: LOD file format. - Third Wire Forums.htm. And I wrote already that he used obfuscation methods later. Just to clarify: I don't want to distribute any assets. I only want to use assets from the game I purchased or assets from this community within FlightGear. For this I plan to write a tool that automatically converts the SF2 data ini files into FlightGear files (Edit: the .lod file itself can be directly loaded into FlightGear via the OSG pluging, so no conversion of lod files needed). Again: no distribution of any assets! I think that's legal within TWs EULA and CombatAce Freeware License Agreement. And I see benefit for Thirdwire and the community: Maybe some will buy SF2 games if they know they can use the aircraft in FlightGear too. And maybe FlightGear can be enhanced to be a fully community driven open source air combat simulator. Then why not use the already by this community created assets? And yes, everybody has access to FlightGear assets. Most FlightGear assets are released under GPL or other "free" licenses. I was told recently, that FlightGear aircraft were already converted to SF2.
  23. Yes...if engineers make games... I've implemented an OSG file loader plugin for the SF2 3D model file format (*.lod). So the SF2 3D models can be directly loaded into FlighGear. I'm still not sure if I should make the LOD loader plugin open source. I myself wouldn't mind, but I don't know what the game developer and the 3D modders would think about it. In the past (Sep 2007) the game developer himself wrote in a forum post after he was asked about documentation about the LOD format: "...although we didn't publish LOD format, we also don't stop people form reverse engineering it either ;) Its not encrpyted or anything, so its fairly straight forward to figure out..." Unfortunately later LOD format versions contain some obfuscation, so maybe his opinion has changed? I also think the 3D modders consider the (non published) LOD format as a kind of intellectual property protection. But keeping it closed source would mean it can not be officially distributed/supported by FlightGear and it would only work with FlighGear versions/platforms for which I compile/release the binary (e.g. Windows). If I understand correctly, only hit notifications are transmitted, but no bullet or missile positions? Does that mean, that no tracers or missiles from other aircraft are visible? Is damage calculated by the "receiver" or "sender"? Do you have a link or pointer to the "automated enemy" code and the Python AI system? Thank you for the clarification.
  24. Richard, thank you for coming to CombatAce and offering assistance regarding (military) FlightGear. I'm fascinated by the flexibility of FlightGear and JSBSim. Currently I'm implementing the Strike Fighters 2 FDM and the (very light) systems in JSBSim. The developer of SF2 has an aerodynamic engineering background and therefore his FDM uses "standardized" aerocoefficients (My notes about the SF2 FDM: sf2_fdm_notes.pdf). Because of the "openness" of SF2 the aerocoefficients of each component (LeftWing, RightWing, LeftOuterWing, RightOuterWing, LeftStab, ...) are easily accessible from aircrafts data text (*.ini) files. Currently I'm doing the FDM/systems "conversion" to FlightGear/JSBSim manually, but I think this could be done later automatically by a tool. As I wrote, I haven't looked in detail at the combat stuff in FlightGear yet. Maybe you can give a short overview of the features of the "OPRF" combat system (and maybe "Bombable")? What weapons are supported (guns, rockets, (guided) missiles, bombs)? I assume it works in multiplayer? How is the damage modelling? Since you mentioned SAMs, do you support AAA/Flak too? How sophisticated are the automated (AI?) enemy aircraft?
  25. I think it's a TOD object (a tree) and therefore not listed in the target list window. You can show/hide TOD objects via View->Show TODs or the respective toolbar button. TOD objects are contained in *.tod files. TOD files are associated with tiles (textures) via the <terrain>_data.ini.
×

Important Information

By using this site, you agree to our Terms of Use, Privacy Policy, and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..