Wrong wording for my part. I thought TexName was literally the name of the texture you were using(like the diffuse map), but since you clarified it's the name of the material, I guess it's safe to use that name then. The script with that addition is so useful to me right now. So thanks a lot.
You're going to have to post a picture of what's wrong here. I checked that thing and after fixing the UVs for that vertex type, it imported without any UV errors. Azu, you're using 2011 right? I'm thinking that's the issue since it appears 2010 users have it working for them. And as for TGA support, I can do that too. I don't know if I'll be able to have it do both in the same script though. I'll have to fiddle with it to see if I can. Anywho, I'll have TZ help me figure out the issue since he helped me out with the other issue with fixing it to work in general.
I run the latest version of the script on euc_obj_airship_HD.model after putting all three euc_cmn folder contents into one folder, and it comes out like this... the rest is fine save for some transparency things that always happen on my side, but the balloon is weird. The UVs look like this which seems off to me... Got a .max file and the blimp's texture here to compare it with however it imported on your side.
Okay, that's not how it's suppose to look...And when I import the model, it doesn't come out like that. It comes out just fine, like this. I have no honest idea what's going on to cause that. And the UVs are applied to the same texture, but they're nothing like they come out with your import. So, uh, yeah...I have no clue why it's doing that...I'll try and figure it out though.
Someone over at SSMB is playing around with animation swaps with Shadow. Looks pretty cool so far. NOT MY VIDEO Video is from "Megamaniscrazy". Ok, I got this whole weekend off before going back into exams once more. Let's see if I can get some sort of early version of the editor so you guys can play around with it. I'm working on a toolbar on the top at the moment so it's actually usable, and I gotta optimize the rendering when there's too many objects on screen. Here's a screen in case you want to me to do any modifications before I regret it. The lazy skin is just from the default QuickGUI comes with. As you can see, object attributes are available to edit without having to edit the XML manually, and even supports it for all objects that are currently selected. Also supporting copy+paste, so you can make motobug invasions if you want. :v: The imported models are straight from Darkspines' script, so they scale perfectly into the world. Any missing objects you see just haven't been added to the templates list yet. Also, I haven't looked into the challenge XMLs yet, but I'm gonna guess there's edittable objects that can add collision(like a box), since only some of them have custom level geometry(like the Knuckles race). Other challenges just have custom XMLs for reworking the layout. So until we have a way to edit the geometry and collision itself, you can have some fun with the editor making custom challenges.
New update on the levels. Turns out the instanceinfo files are actually 4x4 matrices. Link pointed this out to me. Now what does this mean for ripping and using the stage models. It means a conversion program must be wrote! Yeah, Max bogs down like hell when importing the levels, especially with the special math it needs to do the verts correctly. I'll post more when I have more info on the current point the program is in. My current project is gonna be fixing the PC terrain-model files to work correctly and figure out if those hkx files are actually the collision files.
You guys are just being too awesome. Also, nice work on the getting that far with the editor Dario. And nice getting that far with the level geometry Darkspine.
I guess maxscript runs on runtime, so any heavy math it would need to do would be slow as hell. Doing it in C/C++/C# should be enough for speed IMO(hardcore ones would go with ASM :v. But anyway, super excited to hear that. I don't care if you can't get the texturing right, the geometry alone would be a major step.
Actually, C generally maps 1:1 to floating point calculations, and in fact compilers will usually replace calls to the math functions with the relevant opcodes when they're provided by the processor (e.g. sqrt, pow, sin, cos, etc.), so assembly really wouldn't help much here. Just make sure to tell the compiler that it's OK to reorder operations (since by default it won't do it because it could affect floating point accuracy and thereby give a slightly different result).
1:11, with Omochao following him...it reminds me of that Shadow hack from years ago. "More than a Memory" or something? :v:
Wow, I do believe this is by far the most quickly hacked Sonic game yet. Don't stop. I want there to be a level layout editor by year's end. I'll even fund it.
This is probably due to it also being the most recent Sonic game with the most potential. I mean Classic Sonic? Good Level design and gimmiks? It doesn't happen all the time. I do hope though that hacking this game will make it easier to hack other Sonic games on modern systems.
Ah... it looks like I've been accepted on to the forums o_o... (Thanks whoever did it!) Well hello everyone, I've been following what's been going on since the first demo was released, and I've been experimenting by myself for a while and I guess I'm ready to help out with everything. It looks like Dario FF already has the stage editor well into production, but I had started something a while ago to read stage object data from an XML file. It's pretty quick and dirty and doesn't have much use, but it was kind of fun to make: (It... makes a bit more sense in motion...) And I've also been toying around with some elements of different stages and Sonic himself. I have some videos below: Behind-View 3D Classic Sonic Modern City Escape with NO Objects So yeah, I'm here to help out however I can with figuring out what everything does in the game. I sort of have no idea what I'm doing though so I'll just leave all this here for now... (Plus I need to finish up these last 2 weeks of the semester, so I don't want to be focusing on anything except for work for the next two weeks.) Yup. :v:
Hello KuroBit, pretty cool stuff you got there. I see you loaded up on your reading program simply EVERY single object? That looks really interesting, since I hadn't added the camera switches and stuff like that yet. :v: I haven't loaded up much templates though, but I guess performance would be way better using cubes like yours instead of the high poly models straight from the game. The hardest part by far isn't reading the data though... Making a usable GUI and saving to the XML has proven to be much harder, even with a prebuilt GUI library. Also having to support MultiSetParam as some sort of array clone.
Nice Shadow. I wish Amy worked, but I don't think she has the same moves. I have a question, are the rails also objects? I couldn't find any in the stage ar files.
Thanks! Yes, I just had the script load EVERY coordinate it could find, and if it happened to graze past a certain type of data (ring/camera/badnick/spring/etc), then it should use a certain color/image/size for the next block it draws, otherwise, draw a pink question-mark. It's not a very efficient method, but it lets you see where everything is located in the stage. I guess if I where you, I'd probably try to support "place-holder" models or something. I think the high-poly models will take quite a toll once you start supporting more data types, but it really depends on how good the program is at rendering I guess. I personally have never had to write something that reads from XML files before, so I'm pretty much just guessing with everything... Thanks! I don't see why we couldn't give her the same moves as sonic :P. I remember a time when all the characters in a Sonic game had pretty much the same physics :P. So far I have not figured out where the rails are located. If you look at the "City Escape with no objects" video, you can see that the rails are all still there, and even the cars and umbrellas and tables are there, so I have yet to figure out where those are stored... Also, something rather amusing, Sonic with Super Sonic's bone structure: I guess he wanted to try a new hair style.
I already did the City Escape with NOTHING hack myself and went further into it than you brah, but nice try ;P (not to be a douche) Rails are actually level geomatry I believe. You can really tell that if you look at Seaside Hill and see they cast high quality shadows. This is because they're part of the level's light baking. What controls them I've yet to find. However, there's a difference between objects and dynamic objects (objects Sonic can destroy). These are located in the pysics XML. name not at the top of my head atm, sorry. It should be something like setdata_phy.set.xml or something. Either way, that's what controls the level's physics objects. Don't believe me? Try it :P I suggest DarioFF integrates those physics objects, when he can, into his object editor ;P
