Jump to content

Mike.nl

Members
  • Posts

    60
  • Joined

  • Last visited

Everything posted by Mike.nl

  1. You mean the model does not appear in the viewport? And it only happens on skinned models (e.g., infantry) If so, that's a problem with PG's shaders. Change the shader's render mode, or download my fixed shaders. Otherwise, please post a picture of the problem.
  2. You couldn't have followed my instructions because it says that you need the Alo Exporter as well, which hasn't been released for 3dsmax9 yet (it will come with the Universe at War mod tools, if and when they're released).
  3. I've made a small tool that 'fixes' map files made by FoC's Map Editor so they can be used for planets in Galactic Conquest with the Base Layout markers (structure and unit placement) visible and functional. The tool extracts the 256x256 preview image that the map editor stores in the map file. The preview can be stored and used as Base Layout background as well. Get the Map Preview Extractor. Note that the preview image is a top-down snapshot of the map and as such includes all structures and clouds and such, so it's advisable to: Save the map with no clouds and no base structures Extract the preview image for the background image (don't forget to scale it to 512x512) Save the map with everything placed Remove the preview image so the markers work
  4. It has taken many months, years maybe, but here it is. A working importer for alo/ala files for 3D Studio Max 6, 8 and 9. Capable of importing models and animations from Empire at War, Forces of Corruption and even Universe at War. Get it from my Mod-Tools site. Be sure to read the instructions carefully on how to set it up and use it.
  5. Indeed. But hopefully I'll get my importer out soon.
  6. The time for change has come! Check out the my site: http://modtools.petro-gamers.com/ Alamo Object Viewer 1.0: Yes, the time has come indeed. After many months of coding, my Alamo Object Viewer 1.0 is completed (enough), so I hereby release it. http://img115.imageshack.us/img115/2846/aloviewerlg1.th.jpg Overview of new features: Particles. Note: only the most common UaW particles are supported so far. Sounds! Support for Universe at War. Support for Mods. Select the 'active game/mod' from a menu. Works under Vista! Bones are readable. Auto-finds animations. Full list of bones, meshes, proxies and dazzles. Turn each on or off and show the bounds of meshes. Extended and improved model details. Shadow mesh debugging. Easy animation playback. Double-click for looping, single-click for play once. Exact camera positioning. For taking easy and consistent screenshots. Full render options. Control AA, Bloom, shadows, heat and Shader LOD. Debug Log. Find out why a shader failed to load or how many frames an animation has. Improved support for old video cards. Quick ALT & LOD select. Check quickly how a certain ALT or LOD looks in-game. If you find bugs or have suggestions, you can contact me on the site! Wunderbar! Since the germans make up a substantial part of the Petroglyph modding community, Raziel Kanos's been so nice to translate my tools into German. Both English and German are in the same executable. It picks the language based on Windows's language. Site move: With the new tools, I felt it was time to upgrade my site. It looked plain, amateuristic and the domain reflected that too. So, Petro-Gamers was nice enough to give me a place to put it all, so hence the new address: http://modtools.petro-gamers.com/ The old links will stay active for a while, but you'd better change them if you have bookmarks or such.
  7. Well, it sort of does (it's an alias/redirect), but I can't hotlink to the various areas for the time being. You can still go to the base site, http://alpha1.dyns.net/eaw/, but here is the page you want. Edit: well, I fixed hotlinking. The original link work again.
  8. If you mod and use the map editor you might have come across a bit of an inconvenience: the map editor seems to delete shaders and MT_Commandbar.tga when it starts. I patched the map editor so it no longer does this: http://alpha1.dyns.net/eaw/PatchedMapEditor Hope this solves some annoyances for some of you.
  9. swgbex has finished part 1 of this Particle Editor Tutorial, so check it out. He did a great job!
  10. Use Edit > Rescale Particle System This is a shortcut for manually adjusting the scale, speed, acceleration, etc. of every emitter.
  11. Hm, there does indeed appear to be an issue with engines. I'm afraid I haven't been able to test everything myself, so things such as this might pop up. I'll let you know when I have it fixed. Edit: Done. Turns out engines have more than one setting. Particle Editor is now at 1.1. Let me know if it works now.
  12. Yup! Why don't you just try it instead of asking? ;D
  13. Yes, it's finally done. The Particle Editor has been released! Engines, explosions, and every other effect can now be edited or created from scratch. Get it here: http://alpha1.dyns.net/eaw/ http://alpha1.dyndns.info/eaw/ Thanks to the beta-testers for improvements and finding bugs. Also, swgbex is working on a tutorial for it, so keep an eye out for that one. Now, particles are complex things, and the beta-testers and me couldn't possibly test every combination of every setting, so if you find that the editor behaves differently from the game, or simply has a bug, please mail me the .alo file and a description of how and where you use it and how it differs. Enjoy!
  14. Here's the fixed link: http://rapidshare.com/files/27164849/Creating_an_icon_for_Eaw_or_FoC.ppt.html
  15. I don't know who said that, but he was being ignorant or jumping to conclusions. Save a file as .txt, Unicode encoding and it will work. I've checked the resulting file with a hex editor and the file is identical to the existing files, if you use the same shipnames, of course. This isn't about ease of creating new files, it's about the principal. Copying existing files isn't necessary.
  16. Oh, really? You mean a Unicode file? With a proper BOM? Notepad is perfectly capable of producing those. Try selecting "Unicode" as encoding when saving a new file.
  17. Yeah I figured as much. You got the source code of the program (which is on my site as well btw), not the final program itself. So just remember, always get it from the 'official' place: my site http://alpha1.dyns.net/eaw/ If and when there's a new version, that's the first place it's online.
  18. Are you sure you got the right thing? Just to be sure, here's the link: http://alpha1.dyns.net/eaw/downloads/aloviewer-0.7.zip It should contain two files: AloViewer.exe and libexpat.dll. If it doesn't contain those, then what does it contain?
  19. Hey, you're right. Heh, I didn't know that could work. Makes sense though, now that I think about it So yes, you could put a copy of MegaFiles.xml in your "Mods\My Mod" directory and then add your meg files to it. However, that still leaves the issue of why you'd want to do it. My arguments for not doing this are: The difference in disk space is negliable. It takes effort to pack everything up. Patching your mod would be more troublesome. Without meg files you can just zip up the altered files. With meg files you'd have to zip up all meg files that were altered (significantly increasing the download size). Unless you have some advanced patching utility that can efficiently extract differences within files. So while it's possible, I'd still recommend against it. But do as you please, of course What do you mean by this? You either forget to put everything in a zip file, or you forget to put everything in a meg file. Same thing.
  20. Not really. The only way that would work is by adding the meg file to MegaFiles.xml, meaning it'll be part of the regular game instead of being a seperate mod. So the entire MODPATH game parameter becomes useless. This is the main reason not to do it. Nope. In fact, the size is increased slightly (because of metadata). Then again, storing seperate files on disk also requires metadata. Anyway, the difference is negliable. Does that matter? Just dump an entire mod in some folder in Mods\. Tidy enough. So, conclusion: it's bad practice and not worth the trouble
  21. Read the transcript here: http://www.petroglyphgames.com/forums/index.php?showtopic=2183
  22. And grammar
  23. No, I mean that post was full of technobabble And it's not sad, I'm also proud to be a geek Though no wife :-\
  24. Next on Star Trek: z3r0x will have to inversely align the main router's deflector dish with a nearby bipolar star cluster to fend off angry psychokinetic biomechanical bots from the Z-963 universe's subspace matrix. Will he succeed, or will the recursive nullified router protocols prove too much for the inverted tachyon hardware causing a warp energy stream to cascade back through all of our known universe causing a total collapse of the server's matter and antimatter?! Stay tuned.
  25. Of course, typically there are only a few AT-ATs on a map, while fighters are numerous So you've got to consider the total vertex count, which is why fighters are indeed best at lower detail. Looking at your render, I would advise putting the tubes and stuff on the back of the ship on a texture and keep the back a single, flat surface. Ditto for the L-shapes on the wings and the two black rings on the engines. The gray area on the tip of the wings might also be done on a texture, so the entire wing can be a single, simple sheared box. If you apply proper bumpmapping, you can still get a decent looking model of out it. And the exit of the engines is especially uninteresting, since there will be engine particles on top of them Also, might I suggest making the faces on the engine part of the same smoothing group. This will get rid of the faceted look of them.

Copyright (c) 1999-2025 by SWRebellion Community - All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Star Wars(TM) is a registered trademark of LucasFilm, Ltd. We are not affiliated with LucasFilm or Walt Disney. This is a fan site and online gaming community (non-profit). Powered by Invision Community

×
×
  • Create New...