Language…
7 users online: Dan2point5, fsvgm777, JeepySol, JPhanto, kirsvantas, random_box, tOaO - Guests: 259 - Bots: 267
Users: 64,795 (2,377 active)
Latest user: mathew

Level Constrain v3.1

SMW Patches → Level Constrain v3.1

This file is obsolete. The latest version is Level Constrain v3.4. For other versions, check the version history.

Submission Details

Name: Level Constrain v3.1
Author: HammerBrother
Added:
Version History: View
Tool: Asar
Requires Free Space: Yes
Bug Fix: No
Featured: No
Description: Unlike screen constrain, this patch constrains the player and sprite's interaction with blocks within the level (properly, check out the first gif to see why).

V3 update: Now works properly with LMv3.00 dynamic levels patch.

Tester's Note: Does not work with Morton, Roy, Bowser, and Reznor.

3.1 update: now you can disable the patch's effect via a RAM if you want to have only specific levels not to have this effect.
Tags: anti-cheat lorom physics sa-1
Comments: 16 (jump to comments)
Download 5.52 KiB | 104 downloads

Screenshots

View all

Comments (16)

 MarioFanGamer Link
Originally posted by HammerBrother
The 4 directional can be emulated via having blocks that enable/disable the flags and the player triggering it at specific locations of the level.

I'm aware of that but it's a global change i.e. sprites also are affected by it.
HammerBrother Author Link
Originally posted by MarioFanGamer
Moderated with:
  • BSNES v115
  • Asar 1.71
  • SA-1 Pack 1.32
  • Lunar Magic 3.11
  • UberASM Tool v1.4

Replaced the very specific tags over the level and under the level with physics, fixed a missing SA-1 conversion.

Definitively a useful patch in certain cases. Having it dependent on RAM also fixed incompatibility with Mode 7 bosses and is a useful addition in general (as you sometimes want to go above the level but not always).

Possible suggestions: Use two or even four flags: One for each direction as e.g. you sometimes want to go above but not below the level. The code also could be improved a bit as you can only change the data bank with PLB whereas neither JML nor JSL can change it.


The 4 directional can be emulated via having blocks that enable/disable the flags and the player triggering it at specific locations of the level.
 MarioFanGamer Link
Moderated with:
  • BSNES v115
  • Asar 1.71
  • SA-1 Pack 1.32
  • Lunar Magic 3.11
  • UberASM Tool v1.4

Replaced the very specific tags over the level and under the level with physics, fixed a missing SA-1 conversion.

Definitively a useful patch in certain cases. Having it dependent on RAM also fixed incompatibility with Mode 7 bosses and is a useful addition in general (as you sometimes want to go above the level but not always).

Possible suggestions: Use two or even four flags: One for each direction as e.g. you sometimes want to go above but not below the level. The code also could be improved a bit as you can only change the data bank with PLB whereas neither JML nor JSL can change it.
HammerBrother Author Link
Originally posted by AnasMario130
Okay, thanks a lot!

A better way to do this is by “defaulting” the value to #$01 on the overworld init (gamemode $0E), and only in levels you want this off, you use STZ !Freeram_LevelConstrain (don't forget to have !Freeram_LevelConstrain = $60 at the top).
Anas Link
Okay, thanks a lot!
HammerBrother Author Link
Originally posted by AnasMario130
Hmm, and I assume that in order to do that, you do something like STZ !Freeram_LevelConstrain in the UberASM code? Just making sure.

Yes, but remember that for levels you do want its effects in other levels, you set this to #$01. This means if you go to a level that doesn't have this effect, then go to a level that is intended to have that effect, it remains off if you leave the RAM set to #$00.
Anas Link
Hmm, and I assume that in order to do that, you do something like STZ !Freeram_LevelConstrain in the UberASM code? Just making sure.
HammerBrother Author Link
Originally posted by AnasMario130
One question: how do you call the RAM that turns the patch's effect off in your level via UberASM? I don't think the readme explains it, so people will get confused and frustrated by that.


To turn the effects off, just have the RAM it's using set to $00. It's explained on the ASM patch:
Code
!Freeram_LevelConstrain = $60
 ;^[1 byte] (not used if !Setting_LevelConstrain_RAM_Based = 0)
 ; RAM address that applies the level constain (block interaction
 ; applies off-level) when nonzero.
Anas Link
Hmm, the first GIF is pretty odd 'cause the screen doesn't push the player but I can see why you did that. Anyhow, thanks for the update! Now I can use this per-level! One question: how do you call the RAM that turns the patch's effect off in your level via UberASM? I don't think the readme explains it, so people will get confused and frustrated by that.
HammerBrother Author From older version: Level Constrain v3.0 Link
@Telinc1 Thanks. I've seen lots of hacks suffering a limitation that you cannot put barriers such as walls beyond the top and bottom of the level, rendering lots of hacks vulnerable to players exploiting and skipping parts of the level.
 Telinc1 From older version: Level Constrain v3.0 Link
This is a really useful patch, even if you're not using it for interesting setups, so having Lunar Magic 3.00 support for it is more than welcome. During the moderation, I removed the "needs remoderation" tag from the patch because it already meets the standards of the remoderation.
HammerBrother Author From older version: Level constrain Link
Thankfully, this patch is lucky that none of its hijacks clashes with LM v3.00's dynamic levels patch.

However, because the patch assumes that horizontal levels always have a bottom border at Y=$01A0, this is not the case if you change the “Horizontal Level Mode” in “Change Properties in Header” to other than the first option saying “Level height=01B tiles, Max H-Screens=20”.

Therefore if the player or sprite is below Y=$0190 (2D Y-positions values increases as they descend), the player/sprite will only interact with blocks at Y=$01A0, causing the bottom of the newly expanded area useless. Currently, I'm trying to find a RAM value that is based on the level dimension setting.


This is what needs to be changed:
Code
	..HorizontalLvl
	REP #$20
	LDA #$0190
	CMP $96				;\Check if bottom boundary is is above mario
	BMI ..SetYPosCollisPoint	;/(mario is too far below)
	
	..NormalYPosition
	LDA $96

	..SetYPosCollisPoint
	CLC
	ADC $00E89C,x
	STA $98


Code
Sprite_HorizLvl_blk_interYPos:		;>$0194D4
	LDA #$0000			;>Top of level
	CMP $0C				;>Collision point Y position
	BPL .Exceed			;>If top of level below collision point (collision is above)
	LDA #$01AF			;>Bottom of level
	CMP $0C				;>Collision point Y position
	BMI .Exceed			;>If bottom of level is above collision point (collision is under)
	SEP #$20
	JML $0194DD			;>Continue on with code

	.Exceed
	STA $0C

	.Align16x16
	SEP #$20
	AND #$F0			;\So it doesn't glitch out with blocks ($0194C5)
	STA $00				;/that need 16x16 alignment
	JML $0194DD			;>Continue on with code
Mogu94 From older version: Level constrain Link
Seems in the past there were different options for the same effect but they were quite....terrible. Thanks for this good solution.
lx5 From older version: Level constrain Link
This is a good patch, I really liked testing it! Turnblocks are very interesting with this patch, because you can pass through them and that also applies to the top of the screen, I can think of some interesting set ups with this.

Good job.
HammerBrother Author From older version: Level constrain Link
Show me a GIF.
Gamma V From older version: Level constrain Link
This caused my hack to softlock in a very specific spot.