SOLVED find an array length. array_length_1d() not working.

H

hisoka_2020

Guest
As the title says, I need to find an array length but for some reason, game maker light refuses to accept array_length_1d() as a valid function.
If someone could offer me help it would be much appreciated.
 
Does 8.1 come with a manual? If it does, have you tried typing in "arrays" into the manual (or searching for array GML functions in general if it isn't searchable) in it?

EDIT: After having done a bit of googling, I don't think there is an equivalent function as array_length_1d() or any array_length function in GM 8.1 Lite. You can read more here. The best you can probably do is have a separate variable keeping track of how many additions you make to an array and then reference that variable, instead of using a built-in function.
 
Last edited:
H

hisoka_2020

Guest
Does 8.1 come with a manual? If it does, have you tried typing in "arrays" into the manual (or searching for array GML functions in general if it isn't searchable) in it?
Yes, of course.
But the only thing it shows me is how to use them in a simple code, and not functions i may or may not use.
1600183920985.png
 

FrostyCat

Redemption Seeker
You can't determine the size of an array or pass it as an argument until after GMS 1.3. Use a list instead, or reserve index 0 to hold the number of entries coming after it.

I simply do not understand why rookies would pick 8.1 lite in this day and age. This is a decade-old version of GM that has been off support for many years, missing many functionalities introduced over the past decade, and incompatible with most current tutorials and reference materials. If you're going to be needy and new, be needy and new in a version of GM that's still actively supported.
 
Apparently, data structures were only available in the Pro version of GM 8.1, so OP can't even switch over to using them instead of arrays.
 
I simply do not understand why rookies would pick 8.1 lite in this day and age. This is a decade-old version of GM that has been off support for many years, missing many functionalities introduced over the past decade, and incompatible with most current tutorials and reference materials. If you're going to be needy and new, be needy and new in a version of GM that's still actively supported.
I understand why people still use GM8 even if they have later versions. It loads small projects much faster than compiler, and the save system lets you test things without automatically overwriting your work and potentially breaking your project. Yes source control exists, but looks about 100 times more difficult to implement, and 50 times more difficult to use. I'm not sure it's worth it for a one person project. The ide has improved in places (room editor), but because of the chain system we have to constantly adjust the size of each link just for the relevant info to stay onscreen. This works better for code windows than d&d interface which can never keep even a few it's actions fully within it's window.

The d&d node overview (which resembles the old way d&d worked and correctly understood reduction of busyness and complexity) is there, but you can't drag actions there to change event order any more. Trying to drag actions where you're supposed to in the d&d action form windows means overshooting all the time and loosing your place. This is a problem especially for people learning the software, though people who have moved on to gml only probably haven't tested this.

If I want to quickly test a new idea that doesn't involve new code only present in GM Studio 2 or things the old room editor could do then it's much less a hassle and time waster to just use GM8, and then port the code later when you know how it's going to work. Porting a large complex project would be a lot more difficult.
 
Last edited:

FrostyCat

Redemption Seeker
It loads small projects much faster than compiler, and the save system lets you test things before automatically overwriting your work and potentially breaking your project. Yes source control exists, but looks about 100 times more difficult to implement, and 50 times more difficult to use. I'm not sure it's worth it for a one person project.
Is this what you call "100 times more difficult to implement and 50 times more difficult to use"?
Code:
git init
git add .
git commit -m "Initial commit"
The ide has improved in places (room editor), but because of the chain system we have to constantly adjust the size of each link just for the relevant info to stay onscreen. This works better for code windows than d&d interface which can never keep it's actions fully within it's window.
That just means you didn't touch the preference settings for reducing the decor, which I have done on my setup. Before setting them I was also annoyed with GMS 2's IDE, but afterwards it was reduced enough for me to use GMS 2 exclusively in my regular work.
If I want to quickly test a new idea that doesn't involve new code only present in GM Studio 2 or things the old room editor could do then it's much less a hassle and time waster to just use GM8, and then port the code later when you know how it's going to work. Porting a large complex project would be a lot more difficult.
Quick tests for new code can be done in GMS 2 using little more than a little batch/shell script, which I also have on my setup and use all the time. In fact, I have it in triplicate for 3 different stock starting points.

For existing projects, that is exactly what branching in source control is meant to handle. Switching to a new experimental branch is just git checkout -b exp-something. Returning to the pre-altered state is just git checkout master. If the experimental branch is ready, it can be brought into the main branch all at once with git merge --squash exp-something. It used to be more complicated with old-hat centralized source control systems like SVN, but that's no longer the case. Like most of everything basic around here, the difficulty is way overblown and often based on obsolete stereotypes.

To be frank, the points in your reply say more about how you use GMS 2 than what GMS 2 actually is.
 
Is this what you call "100 times more difficult to implement and 50 times more difficult to use"?
Code:
git init
git add .
git commit -m "Initial commit"
That just means you didn't touch the preference settings for reducing the decor, which I have done on my setup. Before setting them I was also annoyed with GMS 2's IDE, but afterwards it was reduced enough for me to use GMS 2 exclusively in my regular work.

Quick tests for new code can be done in GMS 2 using little more than a little batch/shell script, which I also have on my setup and use all the time. In fact, I have it in triplicate for 3 different stock starting points.

For existing projects, that is exactly what branching in source control is meant to handle. Switching to a new experimental branch is just git checkout -b exp-something. Returning to the pre-altered state is just git checkout master. If the experimental branch is ready, it can be brought into the main branch all at once with git merge --squash exp-something. It used to be more complicated with old-hat centralized source control systems like SVN, but that's no longer the case. Like most of everything basic around here, the difficulty is way overblown and often based on obsolete stereotypes.

To be frank, the points in your reply say more about how you use GMS 2 than what GMS 2 actually is.
All of those things are to fix problems that didn't exist before and it's infinitely easier not to have a problem than to fix it. Work arounds are time wasters compared to things working properly. The preferences still can't keep things on screen, and I have messed with them a lot. GMS2 seems to assume everyone has a 4k monitor that's half the size of their wall, or that they have a smaller 4k monitor and 20/20 vision to read ultra fine print. Only this way would each chain fit on screen and be readable. Having to set up source control is much more complicated than your post suggests (I've seen YouTube videos.) Saving just worked in GM8 days, now it punishes you for testing things unless you create and continually use a time consuming workaround. It's nice there's more d&d actions, but the d&d form window is broken. I mostly use code already, but because of the brokenness it feels forced on users in GMS2. I can use GMS2, but there's no way this stuff isn't warding off newcomers. You asked for an explanation.
 
Last edited:

Fielmann

Member
Is this what you call "100 times more difficult to implement and 50 times more difficult to use"?
Code:
git init
git add .
git commit -m "Initial commit"
Switching to a new experimental branch is just git checkout -b exp-something. Returning to the pre-altered state is just git checkout master. If the experimental branch is ready, it can be brought into the main branch all at once with git merge --squash exp-something.
Whilst '50' or '100' is an exaggeration, I want to point out the hassle that was git was one of the things that drove me away from professional software development. The way you cite arcane commands as if they were easy, makes all the horror come back.
 
Top