Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by mue

  1. Could both of you please (re)create log files with the "write osg log file" option already enabled at program start (just restart LODViewer with this option enabled). Some information will only be written to the log file at program start. If the log option is enabled only after the program start, then that information are missing in the logfile.
  2. I don't think "it's just your PC", since other users also have problems with the LODViewer. Unfortunatelly, I have no clue what the cause of the problems is, because I don't see it on my computers. I have a request: please enable OSG logging (Extras->Settings->Debugging->Write OSG log file). It writes a logfile "osg_logfile.txt" in the lodviewer.exes directory. restart the LODViewer load the Marauder if the "osg_logfile.txt" is written, please send it to me. Thank you! Maybe the logfile gives me some pointers.
  3. I tested this package. I don't see any freezes or crashes
  4. I downloaded and tested this Mirage F-1EQ . Because of the 4K Textures my development system (Windows 7 with an old 8800 GTS 512) struggles. It gives me a slide show. But it doesn't crashed. On another computer with a GTX 660 I have no problem.
  5. I forgot to say: I have to thank you guys for the bug reports. It's really helpful. Because of lack of time (and maybe motivation ) I don't test all possible cases. Therefore I'm really grateful to you for testing my (buggy) software.
  6. My understanding of the decal system is as follows: The texture file name is defined by Filenameformat. Depending on DecalLevel either the nation id (if DecalLevel=0) or squadron id (if DecalLevel=1) or serial number index (if DecalLevel=2) or kill number (if DecalLevel=3) is appended to the texture file name. The game (and the LODViewer) then tries to load this texture file. But the game has a fallback behavior, that the LODViewer has not (yet): if the game doesn't find the texture file with the numbers at the end, it then tries to load the texture file defined solely by Filenameformat (without the numbers at the end). Therefore I think the modded decals (DecalLevel=0) doesn't show in the LODViewer, because they doesn't end with the nation id number and the LODViewer misses the fallback behavior of the game, that would load the texture file without the numbers at the end. I will add the fallback behavior in the next update.
  7. I assume you serial number texture filenames have numbers at the end (e.g wingnum001.tga)?
  8. Does your mod decal files (Decal Level 0) contain the nation number (e.g. INSIGNIA002.tga)? See my post above.
  9. Regarding the DecalLevel=0 problem, can you please check if this is the cause of the problem: The current version of the LODViewer expects as texture file name the "full" name including the nation ID (e.g. "INSIGNIA002.TGA"). The LODViewer currently does NOT look for "INSIGNIA.TGA" as fallback.
  10. I tested it with more then ten different stock aircraft. No CTDs. No problems with showing decals with DecalLevel=0. Until now, I can not reproduce the bugs Here, as an example the F-104A (marked with red circles are the decals with DecalLevel=0): Could you please give me the name of the stock aircraft or the download link of the mod aircraft, that you have problems with. Thanks!
  11. Should work. Can you send me or give me a link of the aircraft, where it doesn't work? Do you get the CTD with all aircrafts?
  12. I created and added the "reversed" LOD files. The reversed LOD files are named *_Rev.lod Italian Euro Pilot +Rev.7z RAF Euro Pilot Oxy +Rev.7z
  13. I assume it's only possible to define the pilot position and not the orientation in the ini file. Is this correct? Then of course the orientation within the lod file must be changed. But it's not that difficult if one knows a little bit about the lod format . Can you send me the lod file?
  14. I concur with what Gunrunner wrote. BTW, for those who didn't already know: One can easily search all .cat/.dlc files at once with the catextractor from Mues Toolbox. In this post: https://combatace.com/forums/topic/88951-some-newbie-questions/?do=findComment&comment=724535 it's shown exemplarily for shader files.
  15. To clear things up regarding stock object scale in FE1/FE2 I measured exemplarely the length of the BeutepanzerIVF from FE2 with the lodviewer: In the node list window you can see that the selected node "RightSide" has an extension along the y-axis from -3.942 m to 3.973 m. That yields a length of 7.915 m. (One can also move the mouse cursor over the object to get the coordinates in the status bar.) Wikipedia: https://en.wikipedia.org/wiki/Mark_IV_tank specifies a length for the tank mark iv (in game the beuterpanzerIVF) of 8.05 m. Therefore I assume the stock objects in FE2 have real life size and are not scaled down. Since I don't own FE1: Can someone please measure the BeutepanzerIVF from FE1. Thanks!
  16. @Geezer...are you really serious? You seem to be a talented 3D artist, but your ability for discussion is...how should I say..."improvable". You not only insulted me, but the whole SF community. Why do you make it a FE vs. SF thing? As Gatling20 wrote, it really makes you look simple-minded. Maybe you didn't know that the game engines of both games are nearly identical. E.g. this very thread has shown that the stock objects of ALL TW games (FE and SF) are the same big 100% size. So IMHO the TW community should not be grouped in "FE fanboyz" vs. "SF fanboyz", but rather should be seen as one big family ! But maybe you need this "us vs them" scheme? I don't know. It's a pitty. This thread, from my point of view as thread opener, was never about your intellectual property. This thread is, as I already explained to you multiple times, about the scale of stock objects. Last point: What makes you think you can decide who are allowed to post in what (sub) forums. Are you a moderator?
  17. Oops ... it seems I should have a closer look at the knowledge base. The information (non-support of RLE-compressed tgas) I found out through trial and error, was already there, even repeated.
  18. I use GIMP. When exporting the tgas I had to disable the option "RLE compression", otherwise the decals wouldn't show up in the game.
  19. @Geezer, please don't imply that I want to be in charge or that I'm on an ego trip. I have never written something like that. Because of your mention of "the best modders work in FE" and your insulting posts in the past, one could rather think that you are on an ego trip. I really only wanted to correct the flawed assumption that FE objects have to be of 63% size. I want to help (new) modders by giving them correct information. As this thread shows, a lot of people were under the false impression that FE object have to be scaled down and then they wonder why the new created objects don't match the size of the stock objects. I only stated this fact and proofed it with measurement. But you, however were angry for whatever reasons, what I really don't get. If you don't want this information, fine. But maybe other modders find them useful.
  20. Ok, it seems nothing new is coming in this thread. So it's a good time to summerize the facts given in this thread: Fact 1.) All measurements of stock objects in all games (SF1/SF2/FE1/FE2) have shown that the stock objects are of 100% size. Fact 2.) No proof was given for the claim, that there exist 63% size stock objects. Not a single 63% size stock object was shown. Based on fact 1. and 2. it can be assumed all stock objects in all games are of 100% size. Fact 3.) You can create objects at any scale you like (e.g. 10%, 50%, 63%, 100%, 200%,...). Nobody is stopping you. Fact 3.a) If you create an object with a different scale than 100%, you maybe get problems if you want to mix it with 100% (stock) objects. Fact 3.b) No reasons were given why it is beneficial to scale objects 63%, besides the flawed assumption of the existence of 63% sized stock objects (see fact 1. and 2.)
  21. @Geezer I'm still waiting for the proof of the existence of 63% scale stock objects. Where is the example?
  22. Once again, why are you so insulting? I don't get it. We weren't offensive to you! We only stated and proofed the facts about object scaling in all TW games. And BTW why do you think we are SF "fanboyz". As I already stated, I also own and play FE2. So why do you call me a SF fanboy?
  23. My point is, if all objects are of the same size (e.g. 100%) then no extra consideration is needed what objects can be placed near the other. I assume that would made map making easier. So why scaling objects down, if you only get the disadvantage that you can not place those objects near 100% (stock) objects?
  24. I don't understand why you are so offensive. The thread subject is "scale of stock objects". All measurements (I took measurements in SF1/SF2 and FE2, others took measurements in FE1) indicate that stock objects in all TW games (SF1, SF2, FE1 and FE2) are of 100% size. Instead of calling us "fanboyz" and "clowns", why do you not show us at least one stock object in FE1 with a size of 63% to prove your statement that some stock objects are scaled 63%. Of course you are free to scale your objects the size you like. Really nobody is hindering you. Do what you like. I only still don't see the advantage of scaling objects down, if all other (stock) objects are 100% size. That's all.
  25. Maybe some of the flight model guys find this useful for creating, analyzing or checking flight models. Last year I had the idea for a tool that extracts the data of the debug hud and writes them into a text file: (from this post: https://combatace.com/forums/topic/91675-how-to-develop-test-flight-models/?do=findComment&comment=741238): The process steps are illustrated in the following figure: The tool "DebugHUDExtractor" I came up with is written in python and uses the optical character recognition (OCR) software tesseract. Thus to use the DebugHudExtractor you have to install python, some python packages and the tesseract software. For those who want to try this tool, here are the installation, configuration and usage instructions: 1.) Download and install tesseract: https://digi.bib.uni-mannheim.de/tesseract/tesseract-ocr-w64-setup-v4.1.0.20190314.exe Copy lucidaconsole.traineddata into tessdata directory (e.g. C:\Program Files\Tesseract-OCR\tessdata). Needs admin rights. This file contains the trained data for the lucida console font. I use this font as it gave me the best results with the character recognition. This font has to be configured for the debug hud output in the game (see. step 4 below) 2.a) Download and install python: https://www.python.org/ftp/python/3.7.3/python-3.7.3-amd64.exe While installing select "Customize installation": -optional: change the installation directory (e.g I use C:\Python37) -enable "Add Python to environment variables" 2.b) Install needed python packages. On the windows command line execute the following commands: pip install pillow pip install numpy pip install opencv-python pip install pytesseract 3.) Setting the path to the tesseract executable: In <Python_install_directory>\Lib\site-packages\pytesseract\pytesseract.py (line 35) set tesseract_cmd to the file path of the tesseract executable. Use double backslashes or normal slashes. E.g.: tesseract_cmd = 'C:\\Program Files\\Tesseract-OCR\\tesseract' 4.) Configure the game. In SF2/FE2 game set Option Hud = Normal and configure the Huddata.ini. It enables the debug hud, set the font to lucida console, sets a bigger font size (the bigger the better, but all relevant debug info should still be displayed in the screen,e.g. for my 1920x1080 resolution I use TextSize = 24) ,the normal font color is changed to red (required for text filtering), the default right info box is disabled and the default left aircraft info box is moved to the right (that gives more space for the debug info box on the left) [Debug] DisplayDebug=true [Font] TextFontName=Lucida Console TextSize=24 [InfoDisplay] //BackgroundImage=TextBackground.tga BottomLeftPosition=0.8,1.0 //BottomRightPosition=0.99,0.985 NormalColor=1.0,0.0,0.0,1.0 5.) Configure the python script debughudextractor.py : Depending on the values you want to extract from the debug hud the variables extractPitch, extractAlpha, ... have to be set to True or False, The leftRect and rightRect variables have to be configured depending on where the debug info box and aircraft info box is located on your screen (depending on your screen resolution and the entries in your huddate.ini) The format is as follows: leftRect = (top-left-x, top-left-y, bottom-right-x, bottom-right-y) The top left corner of the screen is the origin (0,0). E.g. with a resolution of 1920x1080 and the above huddata.ini, I use the following: leftRect = (56,236,1450,1080) rightRect = (1528,968,1920,1080) See this picture: 6.) Start the script from windows command line: python debughudextractor.py video_file_path time_step_in_s start_time_in_s end_time_in_s <video_file_name>.txt and <video_file_name>_error.txt will be written into the directory of the video file. <video_file_name>.txt contains the extracted data. <video_file_name>_error.txt contains what values at what time couldn't be recognized. If a value couldn't be recognized, then the very next video frame is used and analyzed.

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..