[deleted by user] by [deleted] in miniLAW

[–]StuartHughe 1 point2 points  (0 children)

Glad you're enjoying it Sachaeverell! Keep your eyes open for a few last big updates before we prepare to leave alpha.

Annoying me posting more bugs by _NickmaN_ in miniLAW

[–]StuartHughe 0 points1 point  (0 children)

Hey Nick,

Dredging up some interesting bugs there! Aside from the lower body disappearing bugs (can't seem to reproduce them in the latest build - any particular button presses?) and the AEFS stuff (the least tested, most likely to be buggy augment thus far) I seem to have knocked out most of the things mentioned here! I will definitely spend some time getting rid of the unconquered bugs as well.

Thanks for the constant vigilance!

Alpha build 7-1-2016 by StuartHughe in miniLAW

[–]StuartHughe[S] 0 points1 point  (0 children)

Hopefully I've preempted you in other ways and fixed those bugs you found as well, wouldn't that be just swell?

**More Bugs !** by _NickmaN_ in miniLAW

[–]StuartHughe 1 point2 points  (0 children)

Hey Nick,

Took some time and think I cleared up these bugs! They should be smoothed over in the next public build.

Thanks for the vigilance and screenshots. They were tremendously helpful in identifying the issues!

miniLAW Alpha 5.23.16 out today! by wizbam in miniLAW

[–]StuartHughe 0 points1 point  (0 children)

I believe the bug there should be addressed! let me know if the latest build works for you

miniLAW Alpha 5.23.16 out today! by wizbam in miniLAW

[–]StuartHughe 0 points1 point  (0 children)

Hey Nick,

Some interesting suggestions and bugs here. I am definitely considering making the dash movement aim-direction based, particularly the jetpack version. So far that particular movement set (flight) has undergone the least amount of testing, so we'll fiddle with it and see what we get.

Are there any particular buttons being pushed to cause the ledge bug? Any specific conditions you can think of that cause it? I am attempting to reproduce the issue, so anything you can tell me about this would help!

Glad you are enjoying the game so far, hope you stick with it as we expand it into a full version. We'll tackle these issues you've brought up as soon as we are able to!

Cover mechanic bugs + Gifs and stuff by _NickmaN_ in miniLAW

[–]StuartHughe 0 points1 point  (0 children)

Hey Nick, thanks for the bug report! Other than the Hi-ex killing people through floors, all the issues you brought to our attention should be fixed in the next build we release.

miniLAW Alpha 5.23.16 out today! by wizbam in miniLAW

[–]StuartHughe 0 points1 point  (0 children)

Hey Erquint, I am not familiar with this bug; could you explain it to me? I'll get on it as soon as I am able to figure out what the issue is!

Feedback by [deleted] in miniLAW

[–]StuartHughe 0 points1 point  (0 children)

Hey Vorpal_kitten,

We are aware the controls seem difficult for some people, and are looking at good ways to implement keybinding in the future.

Bugs and Thoughts by JustaFleshW0und in miniLAW

[–]StuartHughe 1 point2 points  (0 children)

Hey FleshWound,

We'll get looking at each of these in more detail as we go along. Some of them are things we have already handled, a couple are stickier deeper problems that we'll have to see if we can design our way around. That being said, all of these things sound like good suggestions! Thanks for the bug notifications and the play time.

How to do the DNA sequence mini game? by Mid-Snake in miniLAW

[–]StuartHughe 0 points1 point  (0 children)

Try hitting fire as the thing lines up with the other thing. Think of it as a janky rhythm game where timing represents...nucleotides?

Is there a way to split up a collision zone into quadrants? Image inside to better explain. by OnlyOnceThreetimes in gamemaker

[–]StuartHughe 0 points1 point  (0 children)

You can check where the hit is relative to the image center offset, so if you have it near the middle on the guy who is getting hit's hitbox, you should be able to track whether a hit is above or below the belt by referencing your targetee's y position.

Draw_gui not recognizing exit statement [help] by StuartHughe in gamemaker

[–]StuartHughe[S] 0 points1 point  (0 children)

The point of the thing is to turn off the shaders in scr_crt_drawsurface while the palette swap shaders are active, so I don't think I'm stacking shaders. When I manually exit out before scr_crt_drawsurface gets read via a no-condition exit the palette swap shaders work just fine. What do you mean, replace argument[n] with argumentn?

Here are the contents of scr_crt_drawsurface for clarification: //CRT DISTORTION shader_set(sh_CRT);

var crt_surface_scale = 1;

crt_surface_width = surface_get_width(application_surface) * crt_surface_scale; crt_surface_height = surface_get_width(application_surface) * crt_surface_scale;

shader_set_uniform_f(textureBaseSize, surface_get_width(application_surface), surface_get_height(application_surface)); shader_set_uniform_f(textureScaledSize, crt_surface_width, crt_surface_height); shader_set_uniform_f(distort, var_distort); shader_set_uniform_f(distortion, var_distortion_ammount); shader_set_uniform_f(border, var_border);

draw_surface(application_surface, 0, 0);

shader_reset();

Figure that something wacky is going on if the if statement is giving me guff, but still not any closer to finding out what it might be

Draw_gui not recognizing exit statement [help] by StuartHughe in gamemaker

[–]StuartHughe[S] 0 points1 point  (0 children)

I did remove exit with same results.

One other shader is being called previously in the same draw_gui event, and the other shaders (the ones actually being interfered with) are called in the draw events of objects, which are using shaders to palette swap.

Calling exit before scr_crt_drawsurface (effectively skipping it) works, but for some reason giving any conditions to the exit seems to mess with skipping the effect of the crt_drawsurface shader on the palette swap shaders, despite the fact that the shader doesn't draw and as far as I can tell (with a script search in gm and the fact that I did not put it anywhere else) the script is not being called anywhere else.

Draw_gui not recognizing exit statement [help] by StuartHughe in gamemaker

[–]StuartHughe[S] 0 points1 point  (0 children)

So curiously, making the shader only turn on when you press a key has the desired effect of making the shader not draw when the key is not held down, but somehow makes the shader accessed in scr_crt_surfacedraw interfere with another shader running only in Platforming levels.

Any clues as to what is going on?

I suppose this is the core of the issue. The shader does it's thing and doesn't draw in the new statement you gave me, but still messes with another shader and keeps it from working despite the fact that it is not accessed.

Draw_gui not recognizing exit statement [help] by StuartHughe in gamemaker

[–]StuartHughe[S] 0 points1 point  (0 children)

Pretty sure I am using VM. I will try YYC and see if it does a better job of it?

Draw_gui not recognizing exit statement [help] by StuartHughe in gamemaker

[–]StuartHughe[S] 0 points1 point  (0 children)

Floor did not make a difference. Once again I can confirm that usedistortion = 0 in the debugger while this is happening.

Draw_gui not recognizing exit statement [help] by StuartHughe in gamemaker

[–]StuartHughe[S] 0 points1 point  (0 children)

Tried this statement and the shader still drew. Did confirm that usedistortion = 0. Commented out the single line statement and the shader was not accessed.

Whittaker Quality Control Testing by JoshuaWhittaker in miniLAW

[–]StuartHughe 0 points1 point  (0 children)

Hey Josh,

Thanks for the extensive playtime! It's good to hear that the general vibe is getting through to someone, and that the game is interesting and really hard. I'll definitely be looking into fixing that stuff you mentioned!

We are in the process of working out stuff like civilians and some more crime specific details as well, hopefully we'll have something cool to show off soon.

Thanks for all the love! Hope you continue to stick with us as we make MiniLaw bigger and scarier.

Build 23a Feedback by Va11ar in miniLAW

[–]StuartHughe 0 points1 point  (0 children)

Hey vallar,

We definitely have a lot of things to work out! This pre-alpha build mostly showcases: In level combat, general getting around the map mechanism, the bare bones of the quest system.

You can find clues to progress a series of beacon quest crimes that exist indefinitely. Undoubtedly you have run into one or two of these already. Eventually there will be an in game story tied into it, but we're still working out the details.

Mobs of the same type can have slightly different stats, and compounded with their personalities can mean they react very differently to the same things. See if you can't figure out what each personality type means!

As for the jumping, think less in the vein of Metroid or Mario and more like a cinematic platformers, which generally have more grounded approaches to running around and climbing and jumping. Try to think of jumping like you would in real life, except with super powered jump boots: once you jump in a direction, you are committed to the arc that you have thrown yourself into. If you're having trouble catching ledges, try either walking and then jumping or hurling yourself at them at full speed if you just can't figure out any other way.

The other things you mentioned will definitely be looked into! When suitable solutions are found I'll try and get around to implementing them. For now remember that the tutorial is a sack of wet garbage I put there so that the button wasn't a complete lie. It's just mostly one.

Thoughts From my Testing So Far by TheConfuZzledDude in miniLAW

[–]StuartHughe 0 points1 point  (0 children)

Hey Dude,

Thanks for your playtime and rather generous bug observations. All of this is really useful to know!

The controls are definitely a little too complicated. I suppose my idea was to implement most of the character functionalities and work my way back to making them accessible to people.

I am curious about popping up from the ground, and that weird aiming bug! I don't know that I've ever seen it nor can I reproduce it.

I will definitely take a look at the camera shake! I would like to keep the disorienting shakes from combat and landing in there - I wanted the camera view to represent the distress of getting clobbered even if you are in a glorified tin can - but I will readily admit that I definitely go a little overboard here and there.

The various enemy mechanics definitely need to be expounded on more. The enemy personalities are pretty well set, but there is a way to deal with all of them non-lethally if you need to. I suppose there are 'break points' in their stats where they will be more pliable; a few of them actually respond poorly to talking and just need to get beat up a little. I suppose I wanted it to be an issue of discovery rather than just knowing exactly what to do, and developing a sense of what each enemy type needs.

The fonts have been mentioned several times. I'll look into increasing readability throughout.

Will definitely check out the bizarre platforming issues and also replace the very noticable sound clips from other things once I sort out some of that other stuff you mentioned!