@PY: Yeah, but only for GM7 
.
@DF: Alright then, next goal it is. SM sprites will be a cinch to get.
As for the script, yeah I got it now . I was being a tad blind, my apologies x). Just missed that it checks from the starting x and always progresses right.
When do you plan to have us work directionality into the code? I know itās not extremely necessary until we work the arm cannon in, but just curious.
I had one on my old computer, and if I had known the computer would explode, I would have saved it to my flash drive. But I didnāt.
And all the ones I find donāt work. That is, I can run the Pro editor, but not actually run programs in GM7 Pro (I can just convert them to GM6, FYI).
If you know your e-mail address you used to sign up at least, contact softwrap, and theyāll get you your key back/have it reactivated. I couldnāt active GM7 when my last computer died, but hey, here it is, working again.
And when it comes to downward motion physics, sometimes all you really need is a āglobal.gravā variable that you set. Or just setting gravity for the character. Unless thereās more to it than that.
I think the relativity of how high a space jump takes you might be a little more intricate than letting the gravity take care of it, but Iām not sure. Itād almost be sufficient to make it ām_vspeed -= 20ā or whatever the jumping vspeed is, but the problem with that is that, piled immediately on top of an initial jump, thatād boost the jump vpseed to -40. -40 would probably be undesirably fast and/or high.
I could nail the fix down easily while scripting it, but thatās not my part to work on .
No, you simply jump with a set vspeed, and lower that vspeed (although I should say raise, since negative vspeed is up) by a certain amount times the max downward vspeed divided by the current downward vspeed.
Let me give an example.
Letās say weāre moving downward at 3 pixels a second. The most you could move downward is 6 pixels per second. You try to space jump. You would normally jump at 6 pixels per second if you werenāt going downward, but you are going downward. However, you have to jump at least 4 pixels per second. So, you take three divided by six, multiply it by two, and then subtract it from the overall six pixels per second. Then, you achieve makeshift physics. =P
Of course, I still donāt have pro, and Iām not going to buy it again. Maybe Iāll see if I can get this to work in lite.
EDIT: sprite_set_bbox_mode() and sprite_set_bbox()?
Is this really necessary? I mean, you could just do it in the sprite editor, itās in the create event, and itās the only Pro-only function in here. Seriously. Is it okay if I modify this?
Getting pro again would be worth it, if youāre going to help us on this. We may be able to do without pro-only functions now, but it will eventually be inevitable. Nearly all drawing commands that utilize alpha values are pro-only, and weāll definitely need those for HUD effects, glows from machinery, projectiles, fire, and etc.
But all of those alpha functions work in ENIGMA right now, and I have that. =D
Although the bbox function isnāt. Iāll probably re-get pro, though.
But for now, I donāt have it.
i can supply the pro version <_<
i have the uhmā¦ application on my laptop
>_>
is it bad that i have to use a loader in order to use a program that i paid for? because I have to use use a loader for GM7 <.< ANY way has anyone really worked on this? Iām working on it but i have no idea whats been done. Donāt want to do something some else has done as it accomplishes nothing.
So, this engine seems frozen at the moment. Perhaps this is because all of the management responsibility and pressure to keep it going remains on one person, which is sort of the opposite of what was intended. May I propose some radical changes to the development process?
I say go for it.
if you took it to a bigger forum it would get more done
What do you have in mind?
Wellā¦
I apologize in advance for the long, example-full description that follows.
Things will go much faster if different people work on different things at the same time. So while one person might work on particle effects, another could work on the thermal visor, and yet another might start making some creatures. Then we attach these pieces together in one place and enjoy.
Of course, that would never work out on its own. Attempting to multitask as a team now would only end in a complicated mess, especially in Game Maker: creature and particle graphics would constantly have to be changed according to updates from the thermal visor person, mixing the thermal visor code in with the rest of the engine, and adding the X-ray visor later would take weeks of headaches, tangling the code further, not to mention that new programmers would have to be educated on visors and particles before making a single platform, and updating visor effects may be too much work at this point.
But situations like that can be avoided, if we plan out how each piece of the engine will be as independent as possible from other pieces.
My approach would be to first build the connections between pieces before building the pieces themselves. This is a little difficult to explain, but Iāll try.
Say weāre looking at an engine with only visor effects and creatures walking around. For the sake of this example, the pieces in this case are visors and creatures. The creatures are connected to the visor effects because their graphics will change with the visors. The visor code should not have to know anything about specific creatures or their code (therefore allowing for creatures to be created and updated later), and likewise the creaturesā code should not have to worry about how the visors operate (therefore allowing for changes in visor effects, and what they can be extended to). This can be done by building the connection between them: the functions for displaying sprites. All creatures simply would be required to display their graphics through customized engine functions, and these functions include the visor code (and probably also lighting code and such). It is impossible for these two pieces to be truly independentāafter all, creatures should have heat signatures for the thermal visorābut a few values to report and specific functions to call would not tangle the engine, because they would likely not have to change with code updates.
So after creating a dummy creature that doesnāt do anything and a dummy visor effect that doesnāt do anything, connected by a few customized graphics functions, two different people can work on the two pieces simultaneously without a problem, assuming the connection has been built perfectly.
However, thatās another issue: if the connection wasnāt built perfectly, the two would have to communicate on how to fix it. CreaturePerson might have to explain to VisorPerson that there is no way to draw a rotated sprite using the engine functions, and so they would have to get that part of the connection built. Later, VisorPerson would have to explain that the required arguments for the scaled sprite function need to be changed in order for visors to work, and then CreaturePerson would have to search through all of their code to change all of the calls to that function. This is wasted time that could have been avoided had the connection been better to begin with. However, changes in connections are pretty much guaranteed, so the best we can do is limit them by planning ahead.
ā¦
So, in summary, this is what Iāve said so far:
ā¦
So, that is my idea. Was that too vague? 
(Iām already aware that it was far too long)
So, basically what we have to do first is map out all of the engine āpiecesā and how theyāre connected, in terms of code and design and such. Then we work out how to connect them in a way that leaves them very independent from other pieces. After building the connections, more than one piece can be worked on at the same time.
A āpieceā is defined as an engine feature, by the way. Examples include the HUD, physical objects, visors, physics/collision, resource management, rooms, sound effects, cutscenes, menu screens, etc.
So all pieces must be considered when making the core bone structure of connections. We canāt just assume that weāll figure out a way to get certain objects to freeze during cutscenes while others still animate and others yet can still move, for example. We would have to build the connection between objects and cutscenes firstāprobably by setting up a few functions that objects can use to check if they can move or animate or not, and a few functions that cutscenes can use to freeze these certain objects.
Itās going to be difficult to map this all out, but once the blueprint is made, people can easily grab a piece and go with it.
If I may, Iād like to do shooting+weapon switching. I happen to be VERY good at programming weapons, as seen in FSMR.
I understand what youāre trying to do, but isnāt this to much to organise? Making a blueprint for the whole engine isnāt something that you can do in 5 minutes. This would take weeks, if not months to get it completely right.
But youāre right, this is the correct way to work. Actually, itās a lot like we handle projects at my work:
So I agree with the workflow you have in mind, but not with the scope. Making a blueprint for the whole game is to much to do, you canāt organise this on an internet forum. You gotta split it up into pieces, and complete one piece at the time.
Thatās how I was planning this engine:
1: samus engine
2: world and environment engine
ā¦ and so on.
If you make a blueprint for each piece at the time, it will be much easier to make progress.
@ Octohunter, shooting is one of the next assignments, so keep checking this topic regulary. Donāt start on it right now, the current assignments must be completed first.
ā¦Crouching and Morphball next?
Awesome.
EDIT-If you add new sprites, I suggest giving each form of the sprite a global variable, kinda like this.
global.RunRight=spr_powersuitrunright
And this.
global.RunRight=spr_variasuitrunright
This way, the global variables correspond to different suit states. It makes it easier to change the sprites.
Hmm. So, like the method I mentioned, but on smaller chunksā¦
Alright, Iām fine with that. But still leaves all the responsibility on you, DF, to constantly provide us with the next steps. If youāre really up to it, thatās not a problem, but it looks like itās going to be a non-stop duty for at least the next year.
I still think it would be within our reach to create the core structure of the entire engine to start with, but sections at a time could also work. They would have to be well-planned sections, though. Iām not sure if beginning with Samus is the best course, but I guess thatās just my opinion.
Alright, so I looked through what we have so far in an attempt to add the latest goals, andā¦ Iām totally out of the loop. X_x
So, I want to make sure I understand how it works so far. Sorry if these questions have been answered a million times throughout the topicā¦ I havenāt really looked.
A.) What kinds of variables are we starting with ām_ā? Will this apply to future objects?
B.) The āspr_array_standing_lengthā and similar variablesāare these for how many sprites are stored in the arrays of each stateās sprites?
C.) Will every Samus pose be in a separate sprite? Are these separate sprites going to be animations, or individual frames? Will this apply to other objects?
D.) Samus is being drawn automatically by GMāwill other in-game objects be like this?
E.) Every standing sprite gets its bounding box set to the same size when Samus is created, right?
F.) While Samus is floating, ām_gravityā is ām_env_gravityā. While she is on the ground, ām_gravityā is 0. Is that correct?
Thanks.
A.) M for member variable. Theyāre variables specific to the object. For instance, m_gravity describes Samusā specific y acceleration, and not the gravity of the world. m_env_gravity is the (right now) constant describing the acceleration in free fall. Itāll change depending on whether Samus is underwater, in space, or whatever. The reason m_env_gravity is a member variable is because 1) some objects will fall slower than others, so their m_env_gravity will have to be lower 2) objects can be in different environments at the same time. So m_env_gravity will be based on the global constant of gravity (1, I think, for now.), but wonāt always be the same. Actually I kind of made half of that up. But thatās how I envision it working. If m_env_gravity will always be 1, there might not be any reason to make it a member variable and not a define. But eh.
B.) Yes.
C.) Dunno 
D.) Iād rather not, but I think thatās what weāre doing for now, for simplicityās sake.
E.) Yeah.
F.) See A 
PS Iām back from vacation 
Sorry for disappearing without saying anything.