|
|
Post by IamAres on Jan 6, 2020 7:32:03 GMT
Before you guys all get dead set on planning out an infinite horizon of new moves, you should be aware that, at least the way they can be inserted into the game now, custom moves each take up a certain amount of the game's available memory. This means you can only have so many and no more. I don't use custom moves myself, but I believe it's around 100, depending on what other custom things you're using the memory for. I do know this memory limit is an inherent part of the code the game runs in and can't be increased (other than to remake the game from the ground up).
Now, it's always possible that their system of implementing custom moves may be different and not subject to this issue - the existing mods are, of course, using a bit of a "back door" method that isn't supposed to be available, after all. But it also may not be different, and we may still be restricted to a finite amount of moves after all.
Not trying to rain on the parade, (and "only" 100-ish moves can still be game-changing, used wisely) but I'd probably hold off on planning out, like, thousands of moves just yet.
|
|
|
|
Post by bolleat on Jan 6, 2020 13:37:59 GMT
Before you guys all get dead set on planning out an infinite horizon of new moves, you should be aware that, at least the way they can be inserted into the game now, custom moves each take up a certain amount of the game's available memory. This means you can only have so many and no more. I don't use custom moves myself, but I believe it's around 100, depending on what other custom things you're using the memory for. I do know this memory limit is an inherent part of the code the game runs in and can't be increased (other than to remake the game from the ground up). Now, it's always possible that their system of implementing custom moves may be different and not subject to this issue - the existing mods are, of course, using a bit of a "back door" method that isn't supposed to be available, after all. But it also may not be different, and we may still be restricted to a finite amount of moves after all. Not trying to rain on the parade, (and "only" 100-ish moves can still be game-changing, used wisely) but I'd probably hold off on planning out, like, thousands of moves just yet. There are ways for them to get around this limitation. Just depends how they implement the system. I am not worried. |
|
|
|
Post by FlashBurton on Jan 6, 2020 14:09:35 GMT
I was thinking about what move's we're missing in FPWW
So far, I've got:
- End of Days
- Curb Stomp
- Hammerlock/ Hammerlock DDT
- Canadian Neckbreaker (that move Orton used to do from a Canadian Backbreaker into a Neckbreaker, it's in Fire Pro Special)
There's probably a bunch more & my head's full of cold so I'm not fully with it
|
|
|
|
Post by view619 on Jan 6, 2020 15:40:26 GMT
Before you guys all get dead set on planning out an infinite horizon of new moves, you should be aware that, at least the way they can be inserted into the game now, custom moves each take up a certain amount of the game's available memory. This means you can only have so many and no more. I don't use custom moves myself, but I believe it's around 100, depending on what other custom things you're using the memory for. I do know this memory limit is an inherent part of the code the game runs in and can't be increased (other than to remake the game from the ground up). Now, it's always possible that their system of implementing custom moves may be different and not subject to this issue - the existing mods are, of course, using a bit of a "back door" method that isn't supposed to be available, after all. But it also may not be different, and we may still be restricted to a finite amount of moves after all. Not trying to rain on the parade, (and "only" 100-ish moves can still be game-changing, used wisely) but I'd probably hold off on planning out, like, thousands of moves just yet. This is going to be the same limitation that players are faced with when the move maker is released. Unlike official moves, which have the benefit of pulling from a pool of frames that Spike controls and references, every custom move must include the set of frames to be loaded within the move itself. This includes moves that are literally duplicates of an existing move. Due to this requirement (which actually uses Spike's own code, mod-wise) there will always be a limit to the number of moves users can load. Making moves shareable basically cements it, as every frame will need to be included. There is unlikely to be work around for this, as changing something that already works (and that the team inherited and actively uses) for a free tool right before development ends is a bad idea. |
|
|
|
Post by markrocker on Jan 6, 2020 15:51:15 GMT
Maybe what they are going to do is let you pick animations by portions. For example, if you pick a powerbomb setup, then you can pick from several other portions, like setting up for a piledriver, a double underhook. After picking that, then you pick another portion that goes well with the previous portion until you finish the move.
|
|
|
|
Post by Charged on Jan 6, 2020 16:11:52 GMT
Before you guys all get dead set on planning out an infinite horizon of new moves, you should be aware that, at least the way they can be inserted into the game now, custom moves each take up a certain amount of the game's available memory. This means you can only have so many and no more. I don't use custom moves myself, but I believe it's around 100, depending on what other custom things you're using the memory for. I do know this memory limit is an inherent part of the code the game runs in and can't be increased (other than to remake the game from the ground up). Now, it's always possible that their system of implementing custom moves may be different and not subject to this issue - the existing mods are, of course, using a bit of a "back door" method that isn't supposed to be available, after all. But it also may not be different, and we may still be restricted to a finite amount of moves after all. Not trying to rain on the parade, (and "only" 100-ish moves can still be game-changing, used wisely) but I'd probably hold off on planning out, like, thousands of moves just yet. I am expecting a limit on this, and I'm fine since I'd probably only use them for my edits and even some of those don't warrant a custom move. It's a really cool feature that I didn't see coming, but you are right to suggest we hold back on our excitement until we know more. |
|
|
|
Post by OrochiGeese on Jan 6, 2020 20:47:12 GMT
Before you guys all get dead set on planning out an infinite horizon of new moves Imma let you finish but I may have to steal the "infinite horizons" phrase for a title of an e-fed show 😎 It goes so well with a story I have planned too, haha 😁 you should be aware that, at least the way they can be inserted into the game now, custom moves each take up a certain amount of the game's available memory. This means you can only have so many and no more. I don't use custom moves myself, but I believe it's around 100, depending on what other custom things you're using the memory for. I do know this memory limit is an inherent part of the code the game runs in and can't be increased (other than to remake the game from the ground up). Now, it's always possible that their system of implementing custom moves may be different and not subject to this issue - the existing mods are, of course, using a bit of a "back door" method that isn't supposed to be available, after all. But it also may not be different, and we may still be restricted to a finite amount of moves after all. Not trying to rain on the parade, (and "only" 100-ish moves can still be game-changing, used wisely) but I'd probably hold off on planning out, like, thousands of moves just yet. All good points. The idea of having character specific versions of every move definitely would not be feasible under this system. 100 moves is still a very generous limit but it will probably fill up rather fast even before we start having like specific versions of the same strike for each wrestler. |
|
|
|
Post by Jason Blackhart on Jan 6, 2020 21:33:36 GMT
I only just recently looked at the files that waza_make currently outputs (which are what modders are using for custom moves) and finally understood what I'd heard about people running out of memory.
I can't believe that finalized moves from the completed version of Move Craft will have that much superfluous data in them.
|
|
|
|
Post by OrochiGeese on Jan 6, 2020 21:41:52 GMT
Do you know if all the moves have the same amount of superfluous data or does it depend on the size of each move? Like would a modified chop animation that takes 1-2 seconds to perform have the same amount of waste as like a hoe-down dance into a chop that would take 10 seconds?
Are performance/taunts given the same amount of excess data as regular moves?
|
|
|
|
Post by Jason Blackhart on Jan 6, 2020 23:05:26 GMT
Was trying to write up an explanation of how the move animation data works and what that means for custom moves, but it seems like a terrible idea lol.
But as far as the current wazamake files go, it's simply the higher number of frames in the move, the larger the data is. How much of that data should be considered "unnecessary" depends on the animation of each move, though.
|
|
|
|
Post by OrochiGeese on Jan 6, 2020 23:30:16 GMT
Was trying to write up an explanation of how the move animation data works and what that means for custom moves, but it seems like a terrible idea lol. But as far as the current wazamake files go, it's simply the higher number of frames in the move, the larger the data is. How much of that data should be considered "unnecessary" depends on the animation of each move, though. Ahh, okay. So the longer files are not only bigger, but arguably contain even more unnecessary data. So for those of us considering having "moves" that actually contain moves within the overall animation, we may end up using even more data than if we were just to create two separate moves. Let's say someone wanted to create Samoa Joe'd old powerbomb -> STF combo. Rather than choosing one of the in-game versions of the powerbomb and STF, they want to create unique animations for each. - One move: Unique powerbomb going into a unique STF. - Two moves: Unique Powerbomb, Unique STF. Would that first move (consisting of 2 separate moves) end up taking more space than creating two moves? |
|
|
|
Post by Jason Blackhart on Jan 7, 2020 1:01:24 GMT
Ooh, wait, I finally may have come up with a semi-decent analogy!
Each frame of animation in FPW is an mp3, each move animation is a playlist, and RAM is the device you have your songs stored on.
You may want a particular song to be part of multiple playlists. You don't need extra copies of the same song taking up space on your device, your different playlists can each reference that one mp3.
This is the same way official FPW moves work. All those piledrivers and powerbombs that start off with the same exact setup don't each need their own copy of those frames eating up RAM. Instead, all frames are loaded into memory to be referenced by as many move animations as needed.
The issue with the files from wazamake is they contain the full data for EVERY SINGLE FRAME used within it (the multiple copies of the same mp3 example), when the only ones that should need to be stored in them are whatever brand new frames of animation the creator draws up (if any), so RAM is being filled up much faster than it should.
My hope is that for the final version, they'll use something closer to FPD download moves, which is just like the default moves but with support for custom frames of animation.
|
|
|
|
Post by IamAres on Jan 7, 2020 1:27:17 GMT
Ooh, wait, I finally may have come up with a semi-decent analogy! Each frame of animation in FPW is an mp3, each move animation is a playlist, and RAM is the device you have your songs stored on. You may want a particular song to be part of multiple playlists. You don't need extra copies of the same song taking up space on your device, your different playlists can each reference that one mp3. This is the same way official FPW moves work. All those piledrivers and powerbombs that start off with the same exact setup don't each need their own copy of those frames eating up RAM. Instead, all frames are loaded into memory to be referenced by as many move animations as needed. The issue with the files from wazamake is they contain the full data for EVERY SINGLE FRAME used within it (the multiple copies of the same mp3 example), when the only ones that should need to be stored in them are whatever brand new frames of animation the creator draws up (if any), so RAM is being filled up much faster than it should. My hope is that for the final version, they'll use something closer to FPD download moves, which is just like the default moves but with support for custom frames of animation. I would really hope it works like that, because a LOT of the stuff I want to make could utilize mostly (or exclusively) existing frames. Hopefully your analogy of the FPD download moves is close to how they implement things. |
|
|
|
Post by view619 on Jan 7, 2020 1:36:10 GMT
Was trying to write up an explanation of how the move animation data works and what that means for custom moves, but it seems like a terrible idea lol. But as far as the current wazamake files go, it's simply the higher number of frames in the move, the larger the data is. How much of that data should be considered "unnecessary" depends on the animation of each move, though. Ahh, okay. So the longer files are not only bigger, but arguably contain even more unnecessary data. So for those of us considering having "moves" that actually contain moves within the overall animation, we may end up using even more data than if we were just to create two separate moves. Let's say someone wanted to create Samoa Joe'd old powerbomb -> STF combo. Rather than choosing one of the in-game versions of the powerbomb and STF, they want to create unique animations for each. - One move: Unique powerbomb going into a unique STF. - Two moves: Unique Powerbomb, Unique STF. Would that first move (consisting of 2 separate moves) end up taking more space than creating two moves? You would be better off creating the first move regardless, just so you aren't requiring an additional move slot/priority for the full sequence. Memory-wise, splitting it into two separate moves wouldn't save you much (it may even cost more due to the separate move entries). |
|
|
|
Post by OrochiGeese on Jan 7, 2020 6:25:02 GMT
Ooh, wait, I finally may have come up with a semi-decent analogy! Each frame of animation in FPW is an mp3, each move animation is a playlist, and RAM is the device you have your songs stored on. You may want a particular song to be part of multiple playlists. You don't need extra copies of the same song taking up space on your device, your different playlists can each reference that one mp3. This is the same way official FPW moves work. All those piledrivers and powerbombs that start off with the same exact setup don't each need their own copy of those frames eating up RAM. Instead, all frames are loaded into memory to be referenced by as many move animations as needed. The issue with the files from wazamake is they contain the full data for EVERY SINGLE FRAME used within it (the multiple copies of the same mp3 example), when the only ones that should need to be stored in them are whatever brand new frames of animation the creator draws up (if any), so RAM is being filled up much faster than it should. My hope is that for the final version, they'll use something closer to FPD download moves, which is just like the default moves but with support for custom frames of animation.  I totally get it. I see where the memory drain is. I really hope they modify wazamake or give us an entirely different way of making moves and of Fire Pro storing them. The way wazamake is done now is the peak of inefficiency and it would really get in the way of the replay value we need for move crafting. Remember how everyone (including me) thought 500 edit slots for FPR was so much and then most people used it up within 6 months? Having just like 100 slots open for move crafting will get filled up in one year. I also really hope that people who already made moves with wazamake will have an easy time converting them to the new system of doing them, providing the new system is more efficient and doesn't re-use frames. Ahh, okay. So the longer files are not only bigger, but arguably contain even more unnecessary data. So for those of us considering having "moves" that actually contain moves within the overall animation, we may end up using even more data than if we were just to create two separate moves. Let's say someone wanted to create Samoa Joe'd old powerbomb -> STF combo. Rather than choosing one of the in-game versions of the powerbomb and STF, they want to create unique animations for each. - One move: Unique powerbomb going into a unique STF. - Two moves: Unique Powerbomb, Unique STF. Would that first move (consisting of 2 separate moves) end up taking more space than creating two moves? You would be better off creating the first move regardless, just so you aren't requiring an additional move slot/priority for the full sequence. Memory-wise, splitting it into two separate moves wouldn't save you much (it may even cost more due to the separate move entries). Ohhh, okay that makes total sense. So not only are we not saving enough memory by splitting it, we may actually be using more by having them as separate entries. And we'd definitely lose the priority slot as well. That makes total sense. Thanks for the clarification! 😎 |
|
