Developer HugoM Posted June 18, 2015 Developer Share Posted June 18, 2015 Hello everybody, just a quick heads up on some of the changes that recently went in with the modding tools: Mod Uploader:- Fixed a crash when uploading to the workshop: files and directories with names starting with a "." should not be uploaded.- Added an "Upload Redundant Files" option. After being compiled certain files don't need to be uploaded. The redundant file formats are: "png", "jpg", "jpeg", "gif", "bmp", "fla", "scml", "mp3", "wav", make sure this option is checked if you still want to upload these files. Autocompiler:- Whenever a mod failed to compile the autocompiler would stop working and not go through the remaining mods on the list. That has been fixed and the change should be included in the GitHub repository in the next few days. If anyone has any questions or concerns, just let me know. Link to comment Share on other sites More sharing options...
Seiai Posted June 18, 2015 Share Posted June 18, 2015 Added an "Upload Redundant Files" could u maybe make a configfile for that, that allows us to ignore custom directories(mainly the export-folder) and a custom formatslist(i have my gimp-files lying around everywhere along the pngs, so i currently have to sort them out everytime i upload, and a few other formats like fdt and fdp for sounds)? Link to comment Share on other sites More sharing options...
Mobbstar Posted June 18, 2015 Share Posted June 18, 2015 The redundant files are now no longer uploaded? That's kinda useful, although I usually still remove them for the forums download on this site. It's good to know the autocompiler now doesn't immediately close when a file is corrupt, gives you time to see the error I suppose the hitbox miscalculations are still an issue with the Steam version? EDIT2: It is still an issue.EDIT: Huh, it's recompiling all files...EDIT2: Because of the version difference I suppose? Link to comment Share on other sites More sharing options...
Developer HugoM Posted June 18, 2015 Author Developer Share Posted June 18, 2015 could u maybe make a configfile for that, that allows us to ignore custom directories(mainly the export-folder) and a custom formatslist I'll see how the team feels about it then work on it. I personally like the idea, so if everything goes right I'll try to roll it in the next few weeks. I'm also planning on adding more formats to the standard redundant format list, like psds and such. I suppose the hitbox miscalculations are still an issue with the Steam version? EDIT2: It is still an issue. Could you be a bit more specific? I haven't bumped into that problem yet. EDIT: Huh, it's recompiling all files... EDIT2: Because of the version difference I suppose? Probably. Link to comment Share on other sites More sharing options...
Mobbstar Posted June 18, 2015 Share Posted June 18, 2015 Could you be a bit more specific? I haven't bumped into that problem yet. It happens to several people using the autocompiler. See these for reference (* * *), and also simplex' statement (including a description of the issue from my view). Based on personal experience, it seems to occur when using several symbols. Usually the bottom and right parts are cut off, which is only a problem when those "cut lines" are near the center of the animation. You can see it clearly on the electric fan in IR(U). From the github version: It is a port from the original mod tools for Linux and Mac. In also improves on the original animation (i.e., SCML) compiler in mod tools primarilyproperly calculating the bounding boxes of animation frames;determining the correct frame to use in a timeline with variable images (i.e., proper correlation of animation frame elements to build symbol frames).The Linux and Mac porting, as well as the improvements mentioned above, were done by @simplex. @DeathDisciple was responsible for getting the tools compiling once again under Windows, after the Unix port. Link to comment Share on other sites More sharing options...
Developer HugoM Posted June 18, 2015 Author Developer Share Posted June 18, 2015 I see. Thanks for the heads up. I'll try to pay some attention to it on the next update. Link to comment Share on other sites More sharing options...
DeathDisciple Posted June 19, 2015 Share Posted June 19, 2015 I see. Thanks for the heads up. I'll try to pay some attention to it on the next update. In my experience both the default behavior and simplex's fix are broken just in different ways. But there is one trivial way to break it: put a single object and rotate it for 180 degrees. It will have no hitbox at all. Link to comment Share on other sites More sharing options...
Mobbstar Posted June 19, 2015 Share Posted June 19, 2015 In my experience both the default behavior and simplex's fix are broken just in different ways. But there is one trivial way to break it: put a single object and rotate it for 180 degrees. It will have no hitbox at all. lol that might explain why all my spinning devices struggle with hitboxes Link to comment Share on other sites More sharing options...
simplex Posted July 2, 2015 Share Posted July 2, 2015 In my experience both the default behavior and simplex's fix are broken just in different ways. But there is one trivial way to break it: put a single object and rotate it for 180 degrees. It will have no hitbox at all. Do you have a sample case where my fork is failing to determine a correct hitbox? And regarding the rotation, could you clarify? The hitbox is determined per animation frame. If a bank doesn't have a different sprite for the back facing animation, it shouldn't matter, and if it does have it then the hitbox should follow that new sprite. This is what should be happening, anyway. Link to comment Share on other sites More sharing options...
DeathDisciple Posted July 2, 2015 Share Posted July 2, 2015 Do you have a sample case where my fork is failing to determine a correct hitbox? And regarding the rotation, could you clarify? The hitbox is determined per animation frame. If a bank doesn't have a different sprite for the back facing animation, it shouldn't matter, and if it does have it then the hitbox should follow that new sprite. This is what should be happening, anyway. Not rotation as ingame rotation, rotation as in spriter object rotation. In the original klei code setting angles beyond 90 degrees are breaking the hitboxes entirely, which is related to Mobbstar's initial complaint. IIRC your fork fixes that but there's something else - when i did merge your changes in, i just rebuilt everything and figured some of the semi-static stuff was having very weird cutoffs, from bottom left side being unclickable to not being clickable at all (that was working fine with default code). Like, what's wrong with this? (making last frame keys won't do any good either) hat.zip Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.
Please be aware that the content of this thread may be outdated and no longer applicable.