Jump to content


rinkuhero

Member Since 12 Aug 2005
Offline Last Active Oct 02 2015 06:23 PM

#4839716 steam_ugc_get_item_install_info

Posted by rinkuhero on 13 July 2015 - 10:05 PM

if this is still a problem, i have observed something that may be related: steam_ugc_get_item_install_info() seems to only work if you run it from steam now. it doesn't work if you run the game from within gm studio; you need to compile it, upload it to steam, and only then will it work.

 

edit: nevermind, i just tested it with steamworks v1.33b, and it doesn't seem to work even when the build is uploaded to steam. there seems to be a bug with this. i hope this is fixed quickly! perhaps i should revert to the older version of gm until this bug is fixed, as it was working fine before.


  • 1


#4764740 Shader Tutorials

Posted by rinkuhero on 09 March 2015 - 07:14 PM

Thank you, great work!


  • 1


#4755279 Reverse Stereo / Swap Speakers

Posted by rinkuhero on 23 February 2015 - 01:17 PM

audio_listener_orientation(0,1,0,0,0,-1);

 

or

 

audio_listener_orientation(0,1,0,0,0,1);


  • 1


#4703840 How do i create a menu that i can scroll through?

Posted by rinkuhero on 03 December 2014 - 02:43 PM

okay, first make a list of your menu options with an array. e.g. list[0] would be the first menu item, list[1] the second, and so on.

 

then display them on screen, in order, using a for loop. limit the list to a certain number of loops, e.g. 10 from the starting position of 0.

 

then make the mouse wheel change the *starting* number for that list. e.g. by default you'd start at 0. but the mouse wheel would allow the player to increase and change that number, so that instead the list would start at 9 or 42 or whatever.

 

so normally you'd display items 0 to 10 of that array. if the player presses down, or moves the mouse wheel down, it would then be displaying items 1 to 11 of that array. you would stop when the array reaches the end and it can't go down anymore. e.g. if the array's total size is 42, the maximum starting position would be 10 less than that, so it'd be showing items 32 to 42 and you couldn't go any further than that.


  • 1


#4703833 Save Broke

Posted by rinkuhero on 03 December 2014 - 02:30 PM

the "Error! not allowing save with filename" means you are trying to access a file not in the sandbox, or that you have modified a filename gotten through the get_open_filename or get_open_filename_ext functions (e.g. by adding a string to it or manipulating it in some way). i've been getting it with the new version too, it seems to be much more unduly strict about the sandbox than in previous versions. even if you are only opening a file for *reading*, you can still get that error, even though it's intended to avoid *writing* to certain locations. for some reason i get the error even though it doesn't actually prevent me from accessing the file; so my game still works, but it's throwing that error repeatedly in the compile form anyway

 

from your example, look at the file structure though:

 

"Error! not allowing save with filename 'C:\Users\Joseph Sirosky Shu\AppData\Local\TerranDawn.win'" -- 

 

notice that the game's actual files are supposed to be in local\GAMENAME\filename

 

my guess is that your game name is terradawn? if so you are missing an extra \ after the terradawn. my guess is it's not really your fault and that gm is just screwing up with directories, because i've seen this error before a lot in different projects. i can't really suggest what would help, except to do this:

 

-out put the file name with debug messages before doing anything with it

-check if those file names (with directory structure) actually make sense and if the file is there

-if not, find out where the error is being introduced


  • 0


#4701460 GMS code window flicker

Posted by rinkuhero on 28 November 2014 - 08:04 PM

a related issue i noticed is that if you expand a window to a certain width while typing, and then delete that width, the arrow scroll bar at the bottom doesn't update, and stays as if the text were still the old width. anyone notice this?

 

e.g. type a really long line of code, enough that the window needs the arrow to scroll left and right (at the bottom of the window). then delete that line. that arrow bar will still be there.


  • 1


#4700680 Unable to find any instance for object index

Posted by rinkuhero on 27 November 2014 - 11:11 AM

the main advantage of the steam version is price; the steam versions of gm:studio are often on sale, so you can get them for up to 80% off sometimes. that isn't insignificant considering that some modules cost hundreds of dollars.

 

also, you CAN disable automatic updates on steam. you simply right click gm studio, go to its properties, and disable automatic updates. that way you can update it only when you want to update it, and read the patch notes first before major updates. you can then manually check for updates and then switch back to enabling updates when you want a new update. this may be more trouble than it's worth but may be worth it if a commercial game is nearing completion and you want to make sure a randomly new yoyo update doesn't break your game and delay the deadline for weeks (which has happened to me in the past).

 

also, i believe using with() on objects that have no instances still works even in the newest update. i do it all the time in my games and it hasn't thrown an error. i don't believe it's wrong to use it in this way, because as erik said, the empty set is still a set. it'd be like making it "wrong" or an error to multiply something by zero, or to add zero to something. or even to use repeat(0) { }, or if(0) { }.

 

using with() on an instance which doesn't exist still throws an error (but that always did), but using with() on an object which doesn't have any instances currently existing seems to still work fine.


  • 3


#4698811 New Debugger Unusable: Choppy/Slow

Posted by rinkuhero on 24 November 2014 - 04:28 PM

alright, i don't think i had the solution quite right, because the problem still happens for me, even with reduced ram. it seems to have helped, but not entirely. even when my game only uses 70mb of ram, the debugger is still unusably slow, even when i have real time updates disabled. when i disconnect or disable the debugger, everything works fine, but while the debugger is running, the game runs at like 0.5-2 frames per second.

 

is there any way the old debugger could be returned until this is fixed? i want to be able to debug my game again, and with this new debugger it's impossible. as i mentioned, i think this still has to do with the 1mb+ per frame packet size that the game is sending the debugger. 1mb per frame -- 500mb per second being transmitted over the IP address if the debugger's frame rate is to be believed, even though it's just to my home IP of 127.00whatever, can't be good.

 

note that the debugger's frame rate (incorrectly?) lists 500fps, but the game itself is at 0.5-2fps. when i close the debugger, the game suddenly works normally again, jumping back to normal speed.

 

alternatively, is there a way to reduce the packet size? e.g. code my game differently so that the packet size isn't so large? why is it so large in my game (1.1mb) when in most games it's typically 50kb-70kb? what goes into it -- variables and arrays presumably, anything else? i tried reducing the global arrays i use (and the size of those arrays) but that didn't put a dent in the debugger's packet size.

 

EDIT: i wnt to resource monitor, and, sure enough, the gm debugger was receiving about 500mb per second of data, and the runner was sending 500mb per second of data. that is no doubt what's causing the slow down. so i need to figure out how to reduce the packet size, because the enormous network usage when the debugger is running makes it unusable.


  • 1


#4696852 New Debugger Unusable: Choppy/Slow

Posted by rinkuhero on 21 November 2014 - 01:00 AM

Unfortunately the latest update removed the old GM debugger and forces the new one, but the new one doesn't work at all with my game. I don't have anything on the watch list, it's completely empty, so that's not the issue. The issue is that when I run the game in debug mode, the game runs incredibly slow -- around 2 fps or less. Sometimes only a frame every few seconds. It also uses all of the CPU, whereas when I run my game without the new debugger, or with the old debugger (in previous GM studio versions) I get a steady 60fps with only 3% of the CPU used.
 
What gives? Any ideas what I could be doing wrong? Anyone else having a similar problem? The problem seems to just be that game, the debugger works normally for me for a blank game file. I want to be able to debug my game again, and with the removal of the old debugger and the impossibility of using the new one I'm a bit stuck, but I'm not sure what could be causing the debugger to not work with my game.
 
When I close the debugger itself, by pressing the X on it, the game suddenly jumps back to normal and works fine. What is the debugger doing that makes the game run that slowly?
 
Also, weirdly, when I *move the debugger window around* -- hold onto the top bar of the debugger window, and drag it around, the game runs at normal speed and it works fine. It's only when I let go of the debugger window and am not moving it around (e.g. in normal operation) that the game runs very slow. So perhaps it has something to do with Windows windows, or which window has focus? I do use the os_is_paused() command to pause the game's music if the window isn't in focus, but that's all I use it for. But my initial guess would be it has something to do with that, I'll try experimenting.
 
EDIT: Nope, os_is_paused() wasn't the problem, the game is slow in debug mode even when I don't detect whether the window has focus or not.
 
EDIT 2: My main guess is that the new debugger simply does not work with large games. My game is fairly big -- about 20,000 lines of code and thousands of variables (local+global), including hundreds of pages of text stored in string arrays. That's somewhat necessary because it's a complex game. I don't think I do anything totally unreasonable though. But perhaps just having so much "game" in there (so many variables, so much code) slows the debugger until it's unusable?
 
(As an aside, I don't want to just post the game file here as an example because it's a commercial game that was Greenlit  and is going to be on Steam (Immortal Defense), so posting it publicly would be a bad idea, but I'd be willing to send the game files to YoYo employees to look over if they want it / if nobody else has reported this bug before and my game is really the only test case of this happening.)


I've done a big more digging around, and found something weird:
 
**********************************.
Entering main loop.
**********************************.
...Waiting for debugger to connect...
Client(-1) Connected: 127.0.0.1
Debugger connected
Debug_SendGameStructure: packet size 1133809
 
According to this, the debug sendgamestructure packet size is 1.1mb, so each step the game would be sending 1.1mb of data to the debugger? Am I understanding this right? When the game is empty, that packet size is much smaller, around 50kb, so perhaps it's the packet size at fault here?
 
 
 
MOD EDIT: merged double posts
 
  • 1


#4696791 Unable to find any instance for object index '%d'

Posted by rinkuhero on 20 November 2014 - 10:50 PM

yeah, i should also note that whenever i get this error, the line number is typically wrong (usually one line *after* the actual offending line).


  • 1


#4696722 Unable to find any instance for object index '%d'

Posted by rinkuhero on 20 November 2014 - 08:21 PM

alright, changing it from if (instance_exists (obj_level)) to if (instance_number (obj_level)) fixes it, so far. (the reproduction is not 100% so it's hard to be sure, but i haven't gotten the error since making that change).

 

but i'm not sure why, or if this is a good solution. this would mean that i'd need to go through and change all my instance_exists() to instance_number() -- i believe instance_exists() should not return true if an object is inactive, that's what the manual says. but for some reason it *does* return true sometimes even when an object is deactivated. but instance_number() seems to (correctly) never return anything other than 0 even when there are some deactivated instances.

 

my guess is that instance_exists() takes a step before it's correct, so that if you deactivate an instance, it will still exist in instance_exists() for the remainder of that step. however, instance_number() doesn't seem to require that step, and updates immediately.


  • 1


#4693245 Fullscreen to windowed bug.

Posted by rinkuhero on 14 November 2014 - 05:11 PM

thanks for the update! i'll probably wait for the next stable version because the game i'm working on is intended for a steam release, so i don't want to risk it being too unstable for release. still it's a pain that i'll have to wait for a fix for this, my testers have been complaining about it so all i can say is 'there's nothing i can do, it's yoyo's fault'


  • 1


#4390591 Shader Affecting All Objects And The Whole Screen

Posted by rinkuhero on 22 September 2013 - 02:13 PM

i think an example would definitely help, but as InCreator[EST] mentioned, making it usable for non-experts would be the better choice. i want to quote this for emphasis:

 

Why this post? Because shaders as they are right now have little use and are horrible to use. It just feels like extra option that you cannot access.... unless all you need is character blinking white when hit. 

Like buying a car and salesman tells you it could also fly, but it's up to you to invent and install jet engines, wings, make it aerodynamic and light, etc...

 

Full screen post-processing (controllable from instances), pre-made library and hell - why not? - some kind of visual (WYSIWYG?) editor would be bare minimum to actually even implement this feature.

Because this is Game Maker. People opt for it to get game made quickly and having fun while doing it, not to learn HLSL the hard way or whatever

 

i wouldn't personally go as far as a WYSIWYG editor, but some preset/default shaders, similar to the preset/default particle systems (smoke, fireworks, etc.), and a bunch of editable example shaders, and an easier way to use them full-screen, would be my suggested requirements for any engine which advertises itself as being easy to use for non-programmers / a good way to teach kids how to make games / a way to quickly prototype game ideas.


  • 1


#4369484 Are You Allowed To Sell A Game Made With Gm?

Posted by rinkuhero on 25 August 2013 - 06:06 PM

@Glyph - i'm sorry, but if you didn't know whether you can sell game maker games or not, you are not an expert in game maker. an expert in game maker would not only know that, but would also know which game maker games are on sale and be able to name several examples (such as hotline miami, most famously)

 

@Alex - thanks for the mention of immortal defense, good to know people still remember it even though it's 6 years old now :)


  • 1


#4338014 Shader Affecting All Objects And The Whole Screen

Posted by rinkuhero on 20 July 2013 - 07:30 AM

my concern over this issue is that game maker is supposed to be a tool that makes creating games easy, and is primarily used by kids or people with no programming experience. yet using full-screen shaders in gm:studio is made more complicated for the user than, say, using them in unity. where is the "easy" in that?

 

don't get me wrong, i love that gm finally has shader support and am enjoying trying stuff out, and i myself am knowledgeable enough that i can use them more or less without problems. but it just seems as if when they were implemented, yoyo forgot that the average age of the gm user is about 15 years old: most users are still in high school. so it'd be nice if at least some concessions were made for ease of use, such as being able to use a shader on the output of a view rather than having to render everything to a surface and then draw that surface using something that wasn't even intended for that purpose (the draw GUI thing).

 

to illustrate, icuurd is the most knowledgeable user of GM that i've ever encountered on these forums. if even he (or she?) is having problems when trying to use them as instructed ("failed miserably"), something is probably wrong in terms of the difficulty curve. i'm not saying to cut back on functionality to make it easier, but i think it's possible to do some things which ease the user into it, sort of how GM's particle system has the normal commands and the "effects" system where you can make simple effects like smoke and fireworks

 

the requirement that the game be rendered onto a surface also makes full-screen shaders impossible to make for shader extensions. let's say someone wants to make an extension for GM with a variety of shaders that users can download and use in their game. it would be impossible for that extension to have full-screen shader effects, at least not without requiring that the user re-write how their game renders to screen, which is probably asking a lot of the average GM user who just wants to use a shader extension.

 

tl;dr: game maker is supposed to be about easy game creation, and yet other competing game creation engines all seem to make using shaders easier than GM does


  • 1