YesNoOk

Show content

This section allows you to browse the content for this member. Note that you can only see content for which you have sufficient viewing permissions.

*
Sh1nRa358 is Offline
Contact Sh1nRa358:

Sh1nRa358

User

Messages by Sh1nRa358

    

Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)

 September 02, 2024, 11:34:31 pm View in topic context
 Posted by Sh1nRa358  in Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %) (Started by Sh1nRa358 August 29, 2024, 11:30:40 pm
 Board: Code Library

As I was starting to apply this, I found a flaw. the pure helper based elements it worked for.

But things like explods inside helpers, there is a little complication. For some reason if you call a helper and an explod is called inside that helper; your helper position can affect the explod. if youve called the helper at a position to hide it at 9999.9999, the explod wont show up at all i view which doesnt make sense to me. but if you put 0,0 as the position of the helper, the explod will show BUT how it displays will depend on the axis centering/positioning in the sff of that sprite. if the sprite isnt centered on the axis more work will need to go into the explod parameters and depending on how sprite is on the axis, you will have to calculate teamside1 but you will have to eyeball teamside2.

Pure Helpers arent affected by this issue because they are based on a replica of the player and how they are centered on the axix which is always CENTERED.

But if you havent coded your meter yet, and each side has a diff sprite teamside1 sprite should start on 0,0 (right side of axis) and p2 side sprites should be positioned on the left side of the axis. Then you wouldnt have to eyeball. But if both sides share the same sprite, you are going to have to put in work on p2 side positioning if the sprite is on the right side of the axis. If sprite is centered then both sides will have the same number and it will be easier. But you wont be able to do that for the actual energy inside bar of course because the scaling will need the sprite to be at 0,0 on the left or right side of the axis in order to scale properly (full to empty). Most ppl will have their meters set up in different ways so most ppl will probably have to do the work on p2 side. But luckily a char really doesnt have that many meters. So, for a visual:

Code:
[State -1, Stun_Meter]
type = helper
trigger1 = RoundState = 2 && !numhelper(24000) && !ishelper
name = "Stun"
ID = 24000
pos = 9999,9999 <-----------comment this out or change it to 0,0 or an onscreen value so that explod will show
postype = Left
facing = ifelse(teamside=1,1,-1)
stateno = 24000
keyctrl = 0
ownpal = 1
persistent = 1
ignorehitpause = 1
supermovetime = 0
pausemovetime = 0
size.xscale = 0.05
size.yscale = 0.05

In the helper:

Code:
[State 24000, Stun_Casing]
type = Explod
trigger1 = RoundState = 2 && !numexplod(24000)
ID = 24000
anim = ifelse(teamside=1,24000,24001)
sprpriority = -34
space = screen
postype = Left
pos = IfElse((teamside = 1), ceil((-ScreenPos X)+(((GameWidth)*(0.090625)))), ceil((-ScreenPos X)+floor((GameWidth)-((GameWidth)*(0.090625))*2.9))),58+floor(root,fvar(2))    <----------------------going to have to eyeball that 2.9
Facing = 1
scale = 0.5,0.5
bindtime = -1
ownpal = 1
ontop = 0
removetime = ifelse((RoundState!=2),1,999999999)
supermovetime = 0
pausemovetime = 0
ignorehitpause = 1

But of course, open to more experienced ideas.

EDIT: I probably should be using ScreenWidth and ScreenHeight instead of GAME for the shortened ver code (in place of 320.0 and 240.0 which would remedy that self adapting issue.
    

Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)

 August 31, 2024, 03:35:20 pm View in topic context
 Posted by Sh1nRa358  in Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %) (Started by Sh1nRa358 August 29, 2024, 11:30:40 pm
 Board: Code Library

I tried it. I noticed that if I now try to replace the 320.0 or the 240.0 with it's corresponding GameHeight/Width axis, the code breaks and the Y starts shifting again on zoom. If I leave it as is, it works close enough to the original code with a tiny tiny shift in the X axis (but then again that may be the active angledraw working against the zoom, it's hard to tell but no biggie). If I try to add more parenthesis like the original code, the shortened code breaks entirely because I supposed it's making certain things calculate first in which tends to break the code. And I guess GameWidth and GameHeight constantly change based on zoom factor. Hmmm, if only there was a way to reference the initial static localcoord without going back to calculator.... (like a const(localcoord.x))

So in order to use the shortened code, we have to find a way to make the 320.0 and the 240.0 automatic to make it fully self adapting. I mean most (probably all) characters localcoords are 320x240 so it shouldnt matter. But I'm trying to future proof just in case ppl will go higher in the future. If ppl decide to start using higher localcoords in the future I guess they can use notepad++ to auto change the 320.0 and 240.0s, but I'm a perfectionist so that's gonna eat away at me lol.

Edit: But then again, if a dev wants to use a fvar or helper fvar to store the starting values of gamewidth and gameheight at the beginning of the round, that would probably work when those vars are inserted into the equation.
    

Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)

 August 31, 2024, 02:12:18 am View in topic context
 Posted by Sh1nRa358  in Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %) (Started by Sh1nRa358 August 29, 2024, 11:30:40 pm
 Board: Code Library

Oh, my Y for that example use to be 100 before turning it into a decimal. but I divided the Y (240)  to get a number close to that. But after it i just adusted a few digits because i wanted to move it a lil. But if I hadnt adjusted afterward, , the number would have been 0.416. But if I wasnt available to give you that answer, one could multiply the gameheight y x 0.4125 and that's how one would have found what the number use to be before being converted to a decimal. and in this case the char's y localcoord was 240.

Oh ok, that was just an example but now i see where i can insert the variable if i wanted to do that (I wasnt use to seeing the teamside trigger used like that. Pretty cool).
    

Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)

 August 30, 2024, 11:34:52 am View in topic context
 Posted by Sh1nRa358  in Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %) (Started by Sh1nRa358 August 29, 2024, 11:30:40 pm
 Board: Code Library

You can use it anywhere that you use pos x, pos y, offset x, offset y. When calling helpers, postype doesnt matter because you're going to have this in the helper to move it to your desired position. for explods, you're gonna use space = screen since that is the new standard.


that's exactly what i did when I mentioned this: " I tried an equation so that you wouldnt have to use windows calculator for all the pos numbers and just use the number that was already there but unfortunately that worked a lil differently from how I wanted it to work so I believe this is the best way."

It worked a little differently and kinda seemed like it was shifting a little during stagezoom (minus the .0 and the abs part) compared to using the multipy/decimal numbers. But the multiplication seemed to lock it in place just right. So does adding that .0 fix that shifting? The thing about adding the direct 320.0 is that you will remove part of the self adapting part. What if a character was innately coded in another localcoord and it not be 320.0 or what if we figure out the self adapting velsets and we can freely change the localcoords to a higher rez at will? Then we wouldnt be able to because we have 320.0 listed. I tried to make it so you wouldnt have anymore numbers to inject making the process longer.

Edit: This seems to suffice without having to use calculator:

Code:
Ceil(GameWidth * Abs(20/GameWidth  - (TeamSide = 2)) - ScreenPos X)

Shweet!


What would your shortened solution for Y be so you wouldnt have to use calculator on Y? And for your x solution, what if you wanted to elevate a particular teamside to a diff level aka, make your presentation shake on gethit for example, and not have both sides do it at the same time if one didnt get hit (since teamsides arent separated by the ifelse anymore and assuming one is doing common1 coding for every roster member)?
    

Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)

 August 29, 2024, 11:30:40 pm View in topic context
 Posted by Sh1nRa358  in Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %) (Started by Sh1nRa358 August 29, 2024, 11:30:40 pm
 Board: Code Library

Please adapt this to your coding regimen.

Both char and stages should be in 427x240 to go the standardized 16:9 route. The problem is, we all coded chars ui meters and stuff in 320x240 due to winmugen being 4:3. So when we change the char to 427x240, super bgs and bottom meters get cut off in ikemen or 1.1. But i figured a way that the meters stay in the same place no matter what localcoord u give the char. The process is just as annoying as converting from winmugen to 1.1 but its worth it. I just feel sorry for ppl who've already made alot of chars XD.

For example, we all do this with explods and helpers:

Code:
x = IfElse((teamside = 1), 20, 300)

This confines our char uis to a small box if we use a localcoord that's bigger than 240p.
What we should start doing is converting that to this:

Code:
x = IfElse((teamside = 1), ceil((-ScreenPos X)+(((GameWidth)*(0.0625)))), ceil((-ScreenPos X)+((GameWidth)-((GameWidth)*(0.0625))))) 

<-------HomeTeam      Opponent's team------------>

How i got that is, i take that 20 and use the gamewidth to divide it into. so 20 divided by 320 (or the x of your char's localcoord and if you are coding the y, then it would be the y of your char's localcoord) basically.
Which gives you the 0.0625

We're gonna get rid of the 300 because this formula places the object on p2 side at the same distance of 20 pixel percent.
The 300 was counting the pixels from left to the right which is the bad habited problem.
With this formula, we can achieve the self adaptation for our char's uis. We cant use screenpos by itself because it's still counting pixels and not setting placement by percentage. I tried an equation so that you wouldnt have to use windows calculator for all the pos numbers and just use the number that was already there but unfortunately that worked a lil differently from how I wanted it to work so I believe this is the best way.

My brain formulated this why perfecting my ggxx mini character overlook code. And yes, there is a code on mugenguild for it by wooshaq and armorcage but they arent being honest. Basically me and Syn developed it. I got the idea from one of his interactive stages. I ran it by other outlets to see if we can get help in solving a problem. Wooshaq was a translator for armorcage and armorcage remedied the issue of keeping  a helper in place screenwise not stagewise for WINMUGEN.

This is the code they are claiming but it's actually mine:
https://mugenguild.com/forum/topics/guilty-gear-x2-reload-miniturized-code-armor-cage-167399.0.html

There's also another thread here with the same code. I've also given the appropriate credits in my char readme that I released long ago.

But either way, I used my current findings to perfect it (there's more to the code, that's incomplete what they have there). But discovered that my formula above can remedy the whole localcoord issue without using const(720) triggers. And it also prevents the explod, char, or helper from being affected by the stagezoom.

This is what pos y would look like for you to copy & paste:

Code:
ceil((-ScreenPos Y)+((((GameHeight)*(0.4125))))))

And this is what Y will look like if you have a config txt that allows the user to move the explod up or down if the var that controls that is fvar(3):

Code:
ceil((-ScreenPos Y)+((((GameHeight)*((0.4125)+(root,fvar(3))))))) 


This is the code you can use to prevent the char, helper, or explod from adapting with any stage zoom effects:

Code:
[state 100000000, zoom_size_prevention]
type = angledraw
trigger1 = 1
scale = 4*const(size.xscale)/CameraZoom,4*const(size.yscale)/CameraZoom
persistent = 1

4 is for highrez chars; 2 might be appropriate for low rez chars.


Here is a visual representation:




Now hopefully I can think of something to achieve self adapting velocities on any localcoord.
    

Re: Tekken 7 Slow-Mo for 1.0

 August 15, 2024, 02:35:49 am View in topic context
 Posted by Sh1nRa358  in Tekken 7 Slow-Mo for 1.0 (Started by Sh1nRa358 August 11, 2024, 04:49:10 pm
 Board: M.U.G.E.N Development Help

The solution was that i had to call the helper way before i wanted to have the effect start and not at the exact same time.

Also, I guess mugen1.1 debug is broken because the bottom debug messages does not obey the offset in the font4x6.def file like the top debug messages do.
    

Tekken 7 Slow-Mo for 1.0

 August 11, 2024, 04:49:10 pm View in topic context
 Posted by Sh1nRa358  in Tekken 7 Slow-Mo for 1.0 (Started by Sh1nRa358 August 11, 2024, 04:49:10 pm
 Board: M.U.G.E.N Development Help

https://www.youtube.com/watch?v=i4FvPxHTD_k

I've always wanted to put this in then i got lazy. Then I saw P.o.T.s. code it for ikemen through ikemen itself. So i thought, why not try my hand in doing it through the character. Then I ran into a prob i never had before. I dont know if it's because I'm rusty or something new with 1.0 but i cant for the life of me get nomusic assert to work right here. Why on earth is assertspecial nomusic giving me so much of a problem here. I tried calling an invisible explod to tell it no music while the explod is alive, ive tried calling another helper with only nomusic in it and ive tried helper variables. My hair is falling out lol.

also, i cant see the debug text, is there an option to make it bigger? did all this without looking at the debug because i cant see it. Im gonna convert to ikemen later, i just need to fully convert to 1.0 first.

    

Re: CVS2 3D stages by Violin Ken

 August 03, 2024, 09:01:08 pm View in topic context
 Posted by Sh1nRa358  in 3D stages by Violin Ken (Started by Violin Ken December 25, 2023, 09:45:07 pm
 Board: IKEMEN Releases

super jumps as well?
    

Re: 3D Stages are Here! a fairly comprehensive guide

 August 01, 2024, 03:00:19 pm View in topic context
 Posted by Sh1nRa358  in 3D Stages are Here! a fairly comprehensive guide (Started by SuperFromND November 25, 2023, 07:34:44 pm
 Board: Ikemen General Discussion and Help

does this mean we can use stereoscopic dlls to now view mugen in stereoscopic 3d now too?
    

Re: Dan's Playground - Parallax - (update -16:9 .def file 24/11/20)

 August 01, 2024, 09:43:51 am View in topic context

hmmm, the stage height camera is delayed and you have to have a multi jump character to be able for the stage to scroll vertically. Also, having stage/the stage.sff crashes the game. Removing 'stage/' makes the stage not crash. The 16:9 version messes up char scaling and explod/helper positions, so if a char hasnt been fully converted, there will be visual issues. And even if you did, the char effects would still be messed up because no char is coded in 320,180. They have 320,240 and up effects so anything below that will be cut off. It's best to probably use ai upscale and use a 1440, 1080 localcoord.
    

Re: Amazon River - SFA3, Blanka

 August 01, 2024, 08:52:47 am View in topic context
 Posted by Sh1nRa358  in Amazon River - SFA3, Blanka (Started by Virtua Richie (kenmasters2812) November 27, 2020, 09:43:41 am
 Board: Edits & Addons 1.0+

I'd love to see more sfa3 stages like this.

however, it keeps crashing for me:

Error detected.

BG error reading stages/SFA3\amazonKM2812_1609.def

Clipboard tail:
Initialize OK
Set up graphics...timer...OK
Playing quick VS.

Entering gameflow loop
Gameflow 0
Gameflow 1
Gameflow 2
Initializing character info...OK
Gameflow 3
Gameflow 6
Reset persist vars team 0
Reset persist vars team 1
Gameflow 8
Gameflow 9
Gameflow 10
Gameflow 11
Unloading system background data...sprite data...OK
Loading match assets...
Loading stage...

edit: removing stage/ fixes the issue
    

Re: Ikemen GO

 June 23, 2024, 07:48:02 pm View in topic context
 Posted by Sh1nRa358  in Ikemen GO (Started by K4thos May 26, 2018, 03:04:27 am
 Board: IKEMEN Releases

Can we get the Z-depth codes working? I would like to be able to use stereoscopic 3D with ikemen

Also, can we add the select button and both thumbsticks working to the configuration to add more button combinations?
    

Re: Fighter Factory Studio 3.5.3 (UPDATED June, 16)

 March 19, 2024, 02:26:44 am View in topic context
 Posted by Sh1nRa358  in Fighter Factory Studio 3.5.3 (UPDATED June, 16) (Started by VirtuallTek April 04, 2018, 02:43:30 pm
 Board: Your Releases, 1.0+

how can we use pcx, bmp, png, etc clean in this (pcxclean)? And how do we highlight more than 1 palette color at once and move said highlighted palette colors at once?
    

Re: Ikemen GO

 February 18, 2023, 05:23:35 pm View in topic context
 Posted by Sh1nRa358  in Ikemen GO (Started by K4thos May 26, 2018, 03:04:27 am
 Board: IKEMEN Releases

    

Re: Street Fighter 6 (PS4/PS5/Xbox Series X|S/PC) (2023 Release)

 June 04, 2022, 09:06:29 pm View in topic context
 Posted by Sh1nRa358  in Street Fighter 6 (PS4/PS5/Xbox Series X|S/PC) (Year 2 announced!) (Started by Kirishima February 21, 2022, 06:39:43 am
 Board: Fighting Games

Drive gauge comes out, ya'll get excited. But I already created that years ago with the stamina meter and back then ya'll hated it lmao
    

Re: Ikemen GO bug reports and know bugs

 March 16, 2021, 02:05:01 am View in topic context
 Posted by Sh1nRa358  in Ikemen GO bug reports (Started by Gacel September 09, 2019, 11:26:09 pm
 Board: IKEMEN Releases

system.def no longer reads from a custom directory. This is why alot of screenpacks aren't working from normal mugen.

Code:
;Directories are checked in this order:
;1. current directory system.def is in
;2. data/
;3. your MUGEN directory
;eg. If you write "spr = system.sff", and this system.def file
;    is in ~/mugen/data/mymotif/, then Mugen will first look
;    for ~/mugen/data/mymotif/system.sff. If it does not find
;    it there, it looks for ~/mugen/data/system.sff (the default).
;    Finally, if that is not found, it will look for
;    ~/mugen/system.sff.

Doesn't seem to work this way anymore. Only seems to read from the data folder only.
    

Re: Ikemen GO

 February 06, 2021, 03:13:05 pm View in topic context
 Posted by Sh1nRa358  in Ikemen GO (Started by K4thos May 26, 2018, 03:04:27 am
 Board: IKEMEN Releases

Anyone know where to find a tutorial on converting 1.1 or winm screenpacks to ikemen go?
    

Foreground Stage Object Transparency Trick

 January 21, 2020, 06:21:14 pm View in topic context
 Posted by Sh1nRa358  in Foreground Stage Object Transparency Trick (Started by Sh1nRa358 January 21, 2020, 06:21:14 pm
 Board: M.U.G.E.N Development Help

There was a tutorial somewhere a long time ago where foreground stage objects would go transparent if a character walked under/through them. It keeps the foreground objects from covering up the character so the player can always see the character. Can someone direct me to that tutorial?
    

SFA3 3D Parallax Stages?

 December 26, 2019, 03:03:05 am View in topic context
 Posted by Sh1nRa358  in Does this thing exist?/who is the author?/etc. thread.  (Started by Messatsu August 26, 2007, 08:29:40 pm
 Board: Requests

Curious as to if anyone has created any street fighter alpha 3 stages with parallax 3D and superjump?
    

Re: MugenHook - upgrade your M.U.G.E.N!

 November 14, 2019, 07:50:33 pm View in topic context
 Posted by Sh1nRa358  in MugenHook - upgrade your M.U.G.E.N! (Started by ermaccer September 20, 2019, 03:01:11 pm
 Board: Projects

Ppl seem to always abandon high tier things for some reason. I literally just made an account just for this. Hope it does pick back up though.