Werewood
Posts : 5691
Join date : 2014-08-11
 | | Subject: Re: 1.1 Characters and characters to 1.0 January 19th 2018, 12:02 pm | |
| Make sure in your Fighter Factory 3 the MUGEN SFF format must be saved as... to either MUGEN 1.0 or MUGEN Beta  :  Yet, some 32-bit graphics visual effect sprites might look weird after downgrading from MUGEN 1.1 to MUGEN 1.0/Beta SFF format.......  MUGEN code-wise, one has to actually load a MUGEN 1.1 character in his/her/its MUGEN 1.0, and test just about every move (all idle/attack/get-hits moves) in order to find out which one(s) has/have unwanted behaviors and errors. For example, the MUGEN State Controller DestroySelf mostly for making a MUGEN Helper disappear, "type = DestroySelf" in MUGEN 1.1 version if the "removeexplods = 1" then all of the MUGEN Helper's Explod will be removed once the MUGEH Helper disappears. But in MUGEN 1.0 all the MUGEN Helper's Explod(s) may still stay there even the MUGEH Helper has been destroyed by DestroySelf. For example, the MUGEN State Controller Explod mostly for visual effects VFXs, "type = Explod", in MUGEN 1.1 version if the position definition, "space = " is used rather than the usual MUGEN 1.0/winmugen "postype = ", then one has to use back the missing "postype = " for his/her/its MUGEN 1.0, in order to re-do the Explod position correctly. Also if the MUGEN 1.1 character uses "angle = "/"yangle = "/"xangle = " for a MUGEN Explod to try to rotate it without using a rotating MUGEN Helper, then in MUGEN 1.0 one has to change the MUGEN 1.1 rotating into a rotating MUGEN Helper, in order to give the visual effects VFXs an expected rotation. For example, if the MUGEN 1.1 character has some MUGEN 1.1 exclusive MUGEN Triggers like "trigger1 = Pos X + CameraPos X < LeftEdge", then the MUGEN 1.0 engine may probably crash. You have to read and compare your MUGEN 1.1 docs and MUGEN 1.0 docs to get to know all the differences between both MUGEN engines. Here is a MUGEN 1.0/1.1 differences mini-list made by a Japanese MUGEN author ⑨ if you want to read about (Google Translate from Japanese to English): - by ⑨:
In this chapter, we will write the part changed from 1.0 to 1.1 (Ver β) and how to modify it,
I am focusing on the characters of compatible mode which uses the description for Win as it is
Also write on the premise that you will not use the new features of Mugen 1.1 main unit such as using screen zoom
The reason for narrowing down to this point is to write only the information to move the character to another version or to deal with it
※ The compatibility mode is the case where 1.0or1.1 is not written in "MugenVersion =" of the Def file,
It will be close to specification of Win version
* The changes from Win to 1.0 are naturally included in 1.1, but it is omitted because the chapter of "change from 1.0 to 1.0" overlaps
·change point
○ Delete TagIn and TagOut
In 1.1, TagIn and TagOut have been deprecated
In 1.1, it is impossible to correspond to all versions because it will be an error if there is a description
○ Changing specification of speed or Pos including decimal point in value
In 1.1, jump altitude and knockback etc are different values from 1.0 and Win
About this, I have not been able to verify, but I think that the placement of the decimal point probably changed
The display position of the object becomes finer when it is 1.0, but Pos and Vel did not change
However, in 1.1, since Pos and Vel including the decimal point change, it is impossible to make it exactly the same as the value of Win and 1.0
The value that can be shifted by one action is not so large since it is around the decimal point 5 to 7,
Since the decimal point is used for the movement related due to the influence of gravity and friction, most movement is affected,
Pos shifts little by little by moving multiple times with different values
Also, there are times when performance changes as F changes from jumping to landing
It is too hard to fix Pos and Vel to almost the same value, so we recommend you to correct only the part where the performance has changed
The correction method confirms each action by 1.1, and there is no other than to correct the part where the performance has changed
○ Effect of zoom by ScreenBound
1.1, even without using the zoom function of the stage which is a new function, since there is a character using Zoom's command,
It is not possible to completely ignore the zoom function
However, when using ScreenBound as it is, it affects not only the camera but also the zoom function, and forcibly turns off the zoom function
* Since it is a beta version, I think the zoom function is still immature, I think there is a possibility of modification in the future
At present, it seems that you can only use Helper to fix the camera
Since the official seems to be aware of the problem, I think that ScreenBound is 1.1 will improve the unusable state
In order to correspond to all versions, I can not recommend a troublesome way to fix with Helper without using ScreenBound
Privately, I think that there is no problem if the creator of the character who uses the zoom function in 1.1 main knows this problem
○ Changing specification of countless enemy counts during Super Pause
In 1.1, the darkness during Anim where attacks and eating judgments are not set, the hours of invincibility of darkness are no longer counted
There is a possibility of a bug in behavior
Therefore, if it is invincible 40F with 30F of inferior duration, Win and 1.0 will definitely make 40F invincible,
In 1.1 it is not necessarily 40F
For example, if there is an Anim that has no attacks or delirium determination for 20 F during Dark Ride 30 F, the invincible F will be 40 + 20 and 60 F invincible
Degradation during throwing or rock skill production, skill of darkening at the timing when no extrusion judgment is ever judged,
There are not many attacks and gnawing judgment during Anim. As there are many techniques to make it dark, consider investigating these techniques and add a game determination,
It is necessary to prepare two CNS files and change the invincible F, or remove unbeatable
○ Effect of transmission and shadow of main unit
In 1.1, the shadow is now affected by the transparency defined in the Air file
Therefore, it is no longer necessary to take the trouble of using the Trans instruction to make the shadow disappear according to the transparency of the body like 1.0 and earlier
The specification change of this shadow is similar to the shadow of Explod
Basically it has only merit because it is normal to thin the shadow according to the body's transmission,
If you make an effect that the shadow is not affected even if the body passes through, you need to make your own shadow in Explod etc.
By the way, it seems that processing of this shadow is also due to heavier processing than transparency defined by the Trans command of Win and 1.0 in the Air file
○ Change of specification of PalFX system
In 1.1, the problem of 1F delay of PalFX's instruction was solved
In Win and 1.0, since it is not executed at Time = 0 when PalFX is executed with Time = 0 in Helper,
We had to add processing such as not displaying images only for F, but this became unnecessary
On the contrary, since the instructions of PalFX system are all earlier by 1 F, the production is shifted by 1 F
If it supports all versions, it is easy to handle by preparing two CNS files and shifting 1 F
In 1.1, using InPalFX 's InvertAll, only a part of the image such as the character' s shadow etc. is inverted
※ This is a 1.1 β version bug
Unfortunately, there is no other way than to disable InvertAll in AllPalFX at present
By the way, using InvertAll with PalFX or BGPalFX seems to be no problem
○ Changing the elimination timing of Helper
In 1.1, the processing timing of DestroySelf has changed
Parent Helper disappears If you use Parent based instruction of Child Helper or Trigger to F, an error will be emitted
Naturally, since errors and Parent-based instructions and Trigger do not work,
Instructions using them do not work at all
Because this also influences surprisingly various places depending on the description, there is no method other than checking and correcting it one by one in 1.1
Even if you modify it, you can use it with 1.0 or Win, so if you fix it you can use it with all versions
* 1.0 Even this timing has changed timing, please refer to the change point of 1.0 from Win for details
○ Change of OwnPal specification of Projectile in Helper
In 1.1, a bug that Projectile issued in Helper ignores Helper's OwnPal has been fixed
Therefore, it is no longer necessary to use Transparent Anim in Projectile to avoid the effect of PalFX on the main body like 1.0 and earlier
There is only a merit as the bug has just been fixed
When coping with all versions, it is okay with the description as it is
○ Change of specification of Front, Back, Left, Right out of PosType of Projectile
In 1.1, the X axis is now based on the center of the screen and these functions no longer function
※ This is a 1.1 β version bug
Therefore, if you use these descriptions, Projectile appearance position will be wrong
When supporting all versions, it is necessary to set it with OffSet based on P1
However, if P1 is set as the reference, Pos Y with reference to the camera and character can be set,
Since Pos Y of the screen can not be set in compatible mode Trigger, it can not reproduce this in compatibility mode
○ Changing the limit value of ProjEdgeBound
In 1.1 it is possible to use up to 536870911, 1.0 and Win can use up to 1073741792, the value has been changed
Beyond the usable value in any version, behavior will be incorrect,
In case of supporting all versions, it is necessary not to use the value of 536870911 or more
○ Changing Trans specification of Explod with OwnPal = 0 in Helper
1.1, when Helper disappears, Alpha value of Trans of OwnPal = 0 Explodent issued by Helper is forced to 256, 256
In Win and 1.0, since the Alpha value before disappearing remains intact, Explod who thought that it gradually passed through and erased with the same F as Helper,
Actually, if I move the mistake like I remained in 1F extra, I can find it well ... w
It is not a good idea to leave Explod with OwnPal = 0, so you can tell whether Win or 1.0 dedicated characters are properly erased
I recommend you to check with 1.1
If you also fix this, it will be compatible with all versions, and the characters will be better
○ Change of specification of Explod
1.1, when PosType is other than P1 and P2, it is not influenced by EnvShake,
Fixed a bug that Pos (Bind target) and SprPriority became wrong when displaying Explod in large quantity
In Win and 1.0, all effects were affected by screen shake,
For example, it is now possible to prevent gauges from being affected by shakes in 1.1
Explod seems to be incorrectly PosType when displaying it in large quantity,
It was fixed in 1.1 that it happened that you bind to something that is not the specified Bind target
The same is true for SprPriority, and there is a law that when the same SprPriority value is given, the upper one is displayed preferentially,
It has been fixed that this rule was collapsed rarely when displaying in large quantities
There are no particular problems with these three as it is, and it is a pleasing fix that will make it work properly in 1.1
I think that there are also people who want to set only the effect of screen shake, but even if you set it in 1.1 you can correspond to all versions properly
When PosType is P1 or P2 and ModifyExplod changes PosType to Back, Right, Left,
When PosType is changed to P1 or P2 by ModifyExplod when PosType is Back or Right, Left
It does not become the value as specified by PosType
I do not fully understand why this happens, but I think that the parameters of Space added in 1.1 are affected
I think that there is not much change of Explos PosType on the way, but if you do not even use this process,
It is better to stop changing PosType with ModifyExplod
When Trans is defined in Explod, if you omit the Trans instruction in ModifyExplod, Trans is forced to Sub
When coping with all versions, if Trans is defined in Explod, it is okay not to omit Trans of ModifyExplod
However, as a way to deal with all versions, it may be best to set Trans in Air file
The error condition for description became strict (more severe in 1.1)
I do not fully understand this about this
Originally, the description is not functioning even in the old edition just by not having dropped errors in the old edition,
Because Mugen's operation becomes heavy just with an error description (it is abnormally heavy in 1.1)
Let's read the official attached Docs, write it according to its format and fix it
If you fix it, it will correspond to both versions, and the character will be better
* Errors caused by changing helper's annihilation timing and TagIn, TagOut, please read that item
Good luck!   | |
|
