||Apr 3, 2013 04:12 PM
||Mar 24, 2017 10:06 PM
||Today @ 12:12 AM
|What Games do you play:
Send Private Message
MosesofEgypt has contributed to 262 posts out of 461531 total posts
(.06%) in 1,456 days (.18 posts per day).
20 Most recent posts:
Actually no, mozz wont change tags that you open into 60 fps tags, it'll simply change any input you type in so it is scaled when saved to the tag, as well as descaling it when displaying it. If you have a tag set that is 30 fps, you'll still need to go in and change the correct fields for each tag by hand. This is mainly meant for those who wish to create 60fps tags from scratch, but cant be bothered to know exactly which fields to change. Maybe I can eventually write a convertor to change a set of tags into a 60 fps version, but idk.
Nah, I didn't get inspiration for the programs design from here. It was simple in concept so I already knew how to go about writing it from the start. I'm in the process of making an update to mozz that allows you to set a flag in the config to have game_speed related tag fields display with a 60fps scale. I've already implemented the framework for it and applied it to a bunch of fields already, so I know it'll work. The only challenge now is for michelle, masterz, and possibly killa to get me a list of every field measured in time that must and must NOT be scaled and by how much. It'll prolly take me a day to implement all the changes once they have a comprehensive list for me.
Here's the location of the flag:
And here's a 30 fps assault rifle opened in guerilla alongside it opened in mozz(with 60 fps checked). As you can see, it's doubling the times for most of the fields now that the flag is set. I haven't set it to apply the scale to all the correct fields though, just ones that inherit from a couple base fields that I modified. That will come in time.
Added a tool for converting an entire directory of animation tags into 60 fps versions. The new tags will be named with a "60fps_" prefix, so dont worry about overwrites. You can also convert a 60 fps animation tag back to a 30 fps one. If you turn a 30 to a 60 and back to a 30, the animations will be exactly the same, save for some minuscule floating point rounding errors(file size will be the same too). All animation frame index values are also modified, so you dont need to worry about those either.
You'll need to do some prep work first though, by opening the animation tags in mozz. You'll need to check a new flag for which animations to NOT convert(special overlays such as suspension positions, talking, aiming, etc) as well as a flag for whether or not the velocity of the animations final frame is important(getting out of a vehicle, jumping, running, etc). In order to get a version of the animation tag definition with those flags you'll need to update the MEK by running the update.py script.
I'm not going to write other tools to automatically convert other tags to 60 fps, but this should take care of the biggest issue.
EDIT: This video is courtesy of Michelle
Edited by MosesofEgypt on Mar 21, 2017 at 03:53 PM
I was thinking (somewhat) more like dead space 1, but have it so the encounters only have you fight a few here and there, you don't have recharging health and have to rely on health packs, you dont get much ammo and have to seek it out, it is random when enemies appear and they do so fairly quietly(think the necromorph in that one early hallway in ds1 where he quietly climbs out of the open vent after you pass him), enemies don't instantly recognize you when they appear, especially if you're behind cover(which there will be ample cover for sneaking). Maybe even include a healthpack weapon what drops a healthpack on the player when they use it, and it can carry a few rounds.
Basically a survival horror type map where you really dont want to fight, but you can use your limited ammo if you have to. The map would have to be quite large and have multiple bsps and ways to get to and from different areas, but have all the areas distinct enough so you can figure out and remember the layout by going through it(think dark souls 1 with its interconnected world).
EDIT: Found an example of what I'm talking about where the enemies appear mostly quietly. https://youtu.be/r7KVdPswrRU?t=85 He kinda screws it up though since he doesn't advance once he kills the necromorph. It'd supposed to lead you a little forward so the guy can come out of the open vent behind you and surprise you.
Edited by MosesofEgypt on Mar 19, 2017 at 07:36 PM
I think one or two very polished levels could be made to showcase the events of the Mona Lisa at some point not shown in the graphic novel. Possibly make it the story of an escaping prisoner group during the time the place is getting infested, similar to Dead Space: Downfall. I feel the flood dont actually get any levels where they are actually scary, so maybe that could be done here. Maybe make the level pretty huge with random chances for encounters in different areas. Since we already have most of the assets required to make it work the main things needed would be scripting, some custom scenery, and the bsp. Idk, just a thought.
Makes sense. The functions i wrote for working with filepaths convert to lowercase since some functions return different drive letter cases and i can't easily check if a tag has been indexed by a path if that crap occurs. Binilla should work tho, since that filepath stuff is mostly required by mozz
Edit: oh, do you mean the installer? Yeah, it prolly wont cause the install is done through supplying os commands. I dont have a linux machine to test my installer on to make sure i call the correct functions. Maybe later...
Edited by MosesofEgypt on Mar 12, 2017 at 02:09 PM
That weird blue outline thing is a HEK Tool specific thing that only applies to the source image. When the image is compiled into a bitmap, the blue outline doesnt exist anywhere in the tags pixel data. It's literally just for tool to tell where you are defining sprites and other images. The pixel data of each face is stored in the exact order I described above.
The chunks of pixel data for each face are literally right next to each other in the file. Like, you could literally just change the bitmap to a 2d texture and multiply the height by 6 to get a valid looking image. It'd look like this:
That T shape is just the programs way of showing you what it should look like as a cubemap.
Edited by MosesofEgypt on Mar 9, 2017 at 11:23 PM
I don't think it's even possible for the utility to do that. It literally just opens the dds, reads the settings from the header, makes a bitmap tag, fills in the header info, and copies the pixel data over. The only modifications to the pixel data that it does is for cubemaps, and that simply involves rearranging the faces and mipmaps.
This is because for dds files, mipmaps and cubemap faces are arranged like so:
face0_mip0, face0_mip1, face0_mip2, ...
face1_mip0, face1_mip1, face1_mip2, ...
face2_mip0, face2_mip1, face2_mip2, ...
face3_mip0, face3_mip1, face3_mip2, ...
face4_mip0, face4_mip1, face4_mip2, ...
face5_mip0, face5_mip1, face5_mip2, ...
For pc bitmap tags the arrangement is like so:
face0_mip0, face1_mip0, face2_mip0, face3_mip0, face4_mip0, face5_mip0,
face0_mip1, face1_mip1, face2_mip1, face3_mip1, face4_mip1, face5_mip1,
face0_mip2, face1_mip2, face2_mip2, face3_mip2, face4_mip2, face5_mip2,
Other than rearranging the ordering, I don't touch the pixel data other than to copy it over. Xbox bitmap tags actually use the dds cubemap face ordering. Now that I think about it though, the second and third cubemap faces in bitmap tags need to be swapped when converting to/from pc/xbox bitmaps, so the same might be true between dds images and bitmap tags. IOW I'll need someone to test if the cubemaps that this utility makes need to have faces 2 and 3 swapped.
Edited by MosesofEgypt on Mar 9, 2017 at 06:42 PM
Glad people are enjoying this so much.
Yeah, it could, but it'd require me to change the way classes are structured. For now this is good enough. I might be getting a job programming in Texas, so if that happens I'm probably going to be too busy to even touch my own code for a few months.
Also, people, please just stop with this crap. I don't want my thread closed because you guys have to take childish jabs at each other. Don't be sjw's.
It creates a fully rigged gbxmodel with materials applied properly and the geometry is split into regions. The models will require a tiny bit of work to get them ready to re-export if multiple materials are used on one nodes collision, since it will get split into separate models based on material. Like, the warthog has 3 materials for the geometry on it's body: hull, glass, and leather. These 3 objects will need to be attached together and vert welded to make them exportable. This isn't really that big a deal tho.
I just added a new tool. It allows you to open a dds image as a bitmap tag. Supports 2d, 3d, and cubemaps as well as all formats halo supports(except p8, but you guys cant even use that). Michelle tested and it's even possible to use non-power-of-2 images for just regular textures. I dont recommend it, but she was able to do it. You can get the new version by downloading the MEK and installing it. If you already have it installed, run the upgrade.py file to update to the newest version. If you couldnt get the MEK to install before, try downloading it again, I've fixed some bugs in the setup.py file.
Edited by MosesofEgypt on Feb 27, 2017 at 07:12 PM
Yeah, but they're a pain to use and I don't know if they have issues going between systems. This also allows me to roll out updates easier and you're able to edit the program itself if you need to(like masterz is doing). There are more benefits to me keeping it in python than I'd get from compiling it into an executable.
I've thought about that kind of feature, but honestly it'd be kind of a pain to implement, and it'd become a source of bugs if you didnt know it was on or accidentally switched it on. The easiest way I could implement something similar would be allowing you to paste a reference to a block from one tag into another. The problem with this is that this would essentially put one part of a tag into another, and it would mirror changes to the entire block rather than individual fields. Like, say you did this to the obje_attrs of the vehicle. Sure, it'd mirror the bounding radius between the tags, but it'd also mirror the physics, collision, model, modifier shader, etc. Basically it'd mirror everything in the current level of hierarchy. You can't paste references to data fields though(integers, floats, strings), so it'd have to be a struct or array or some other type of hierarchy. This would also cause issues at some points since blocks require a reference to their parent to navigate to some attribute that describes something about themselves(like an array size or string length), and since a block can only have one parent, it'd have to choose one of the tags to be parented to.
tl; dr it'd be too much of a pain, it would cause bugs, and there is no way for me to make it cleanly.
Edited by MosesofEgypt on Feb 26, 2017 at 01:55 PM
I've added a new feature that masterz has been testing out for stability. That feature is search and replace. S&R is still in a beta phase and has limited use, but it is a powerful tool. It allows you to specify a string to locate and count the occurrences of, as well as a string to replace those occurrences with. The last tag you clicked on is what the s&r will run on.
Just as a bit of trivia, s&r is how masterz managed to change the lighting in c40.
Here's a screencap:
You can find s&r under the tools menu in mozz.
Technically yes, but tool wont compile one sided collision. It has to be sealed, meaning for every surface there is another surface(s) covering the opposite side completely. It's the same idea as compiling a map with holes in the collision. I actually did a one sided shield with my SOPHIA tank, but it's only one sided cause you stand next to it and project the shield out and you're inside the shield and able to shoot out. It's the same idea as being outside a map and being able to shoot in at people.
Edited by MosesofEgypt on Feb 24, 2017 at 02:59 PM
Well with this you can see some stuff you normally wouldnt be able to. Like for instance the collision on some of the cmt jackals body parts has the faces inverted. I believe this would mean if you fired at the limb, the bullet will pass through the collision and impact the opposite side. Like, if you fired at the bicep, it'd go through their humerus and hit their tricep. Also you can see solid faces rather than just wireframes. I found out that the cmt marine flood has a gaping hole in its stomach on the right side.
Sorry Ganon, I don't have a w8 machine, so I can't test things on there myself. Maybe in the future.....
He actually did ask for them........
Yes, you need python. Seriously, why is this such a big deal for you? I mean, you install python once, and then you dont have to worry about it again. It's not like java where it constantly tells you to update it and is constantly running in the background. You only update when you want/need to. If you ask me again if something requires python or not, I'm just going to ignore you. I was so close to doing it this time.
EDIT: All right look, I'm not trying to be a jerk, but every time you post something on one of my release threads it's almost always "does it need python/can you make it not need python". I've been getting pretty annoyed at that, especially since I work hard to make these things and most people seem not not really care, which is the impression I'm getting from you. I've already told you that everything I make will require python.
Edited by MosesofEgypt on Feb 23, 2017 at 09:15 PM