Current mode, although "beta" branch should still work. You can also try renaming the game directory to let Steam redownload it and then reinstalling NTT.
Recent community posts
1. I'm not actually sure what's going on here - those keyboard shortcuts are handled by the code editor component (Ace) and I'm not seeing any reported issues about them not working on Mac. Someone else is also getting this so it's not just you at least. Maybe I'll be able to ask about this after I get an easier-to-test web version of editor going.
2. That'll be in the next update. Won't be smart completion like what Parakeet did (that's a lot of work) but will be on par with GMS2.
There's a chat command called "/remap". Writing it as-is shows names of inputs. Doing "/remap <name>" shows what the current mapping is. Doing like "/remap attack S" changes mapping. Supports some basic expression operators (e.g. "S|D" to accept either of two, or "gp1x<-0.5" for custom deadzones on gamepad).
You set the port yourself (with Hamachi, default should work) and then the person connecting would specify the same port (so tell them which one you picked).
So you set the port on "Host" screen, pick Start (and get a player list screen), then the person joins (and shows up on player list), and then you pick Start to get into the actual game.
Hello! IP address to use is shown in Hamachi itself. IIRC you can also right-click on the user in network and pick "copy IP". So one player would host the game while being on the network and the rest would use that as IP/Address to connect to them.
Not at this time - adding such an option entails redesigning how mutations and related user interface (mutation picker screen and mutation lists) are handled on basic level. There might be mods that do this to some extent already - I'd suggest to ask around.
As per documentation, if your script uses argument0 and argument1, you pass them to live_call (otherwise live-reloaded code would show an error due to not knowing their values); live_call_ext is used for scripts that take a varying number of arguments.
live_defcall/live_defcall_ext are used if you need the system to return a specific value if your updated code has compilation/runtime issues - e.g. if you are making changes to a script that returns a string, you might want it to still return some blank/"error" string even if you temporarily mess up something (to avoid non-"live" code throwing an error and closing the game).
I uploaded another version now.
Basically, what's happening is that when someone finds a bug that break's GMLive's compiler, or when I'm experimenting with something that involves changing how compilation is handled, I enable a flag that adds that line (showing the script chain that executed before yielding a compilation error) and one other. Then I sometimes forget to disable it before uploading and you get this. I have now stripped it out for good because I think this is the third time this happened.
All native targets are going to work more or less the same (because they share the source code internally);
HTML5 is a little different because of a few bugs (e.g. arr[1,0] works like arr instead of storing extra rows in the same array object) but if you are marking "constructible" classes as @:nativeGen (thus not using the second row for metadata), it'll be largely unaffected.
For several of my extensions I've been using a scheme where native targets are covered by a GML file, and JS targets are covered by building the same project to JS (and updating the extension file definitions as a post-build step). Since GML is compiled to JS too, it can use Haxe-JS values without any issues.
Compiling less strictly typed code (such as GML) to more strictly typed code (such as C++ or C#) is a lot of trouble if you aren't content with just having everything stored as bulky and slow-ish "anything type". I don't think the amount of work would be justified.
Should check if Arcadia was a compiler or an interpreter
As per documentation, GMLive does interpret live-reloaded code, so that is going to work slower while it is enabled for the snippet.
Depending on what the actual code is, the issue is likely not so much in using a ds_grid, but in using instance variables - in GML itself, instance variable access is one of the fastest operations, but GMLive can only use variable_instance_get/set, which aren't that fast at the moment. Assigning the grid to a temporary variable might ease the issue, but it's probably not worth worrying about if you are going to prototype something and then disable GMLive for that code block.
Character draw event is for drawing the character itself - with outlines on things get drawn to a little surface and then that surface is drawn 5 times (4 for outline, 1 for actual character). CustomObject is the usual way to go here. I'd suggest to check how you assign and manipulate your helper instance or having a script_bind_draw that would then run drawing code for matching players.
Hello! It would seem like I had skeleton_ functions excluded from automatic exposure to GMLive.
I'm honestly not entirely sure why, might have been some sort of issue with GMS1 (which wouldn't let you compile a game with mentions of skeleton functions without Pro edition).
I'll take a look at that for the next release but meanwhile you can workaround this by making small wrapper scripts, e.g.
/// skeleton_bone_state_get_w return skeleton_bone_state_get(argument0, argument1)
and then calling those when working with them from GMLive-enabled code.
TJSON uses string_format(number, 0, 15) and then trims trailing zeroes to maintain original precision in case it matters.
Default string() function will round the number to two-digit precision.
Default number comparison operators use threshold as per math_set_epsilon.
In other words, the numbers are often stored with strange fractions, but the fact can be slightly obscured.
GMEdit makes backups automatically whenever hit Ctrl+S - you can access them by right-clicking any tab.
I think the primary thing that results in GMS1.4 overwriting changed files is opening them in GMS and then closing while saving changes - this stores the file in the memory and it usually will no longer check for changes on disk and may decide to overwrite the current version with the one from memory when saving. As per other topic, this happens more rarely if you have version control enabled for the project (even if you don't actually use it)
Hello! It is just me with this
I'm yet to find a satisfactory way of making a demo for this (and certainly not adding DRM to an extension for a time-restricted demo), but if you can send me an email to email@example.com, I can send you a mockup that I made some time ago, which allows to experiment with several "live" scripts in a predefined project (which would seem about right to test if it works).
Is that on Mac or Linux? The path would usually be like /.wine/drive_c/users/<your name>/AppData/Local/SuperCrateBoxTogether/controls.ini. Using directory search would also seem like a good option, as the directory name doesn't change under Wine.
Edit: If that question is about what the format is, try changing gamepad1 to gamepad5 for DirectInput. I'm not entirely sure if this game was compiled with a sufficiently new version of GameMaker to support that though, but worth a shot. In worst case could set controls to keyboard buttons and then run something to map gamepad actions to keyboard.
Room creation code / instance creation code in particular isn't currently being checked for enum definitions, as room files are much bigger (thus slower to timely parse on demand) than object/script files while it is relatively uncommon to have global declarations in them.
This is a nice mod, I have played it a bit with someone in coop. Few notes,
- Should've added a mention in readme that there are more spells on weapon switch button and airhorn button. It took more than a few sessions to notice.
- After being revived, damage bonus and counters are lost because Player instance is re-created.
- TB doesn't have any effect (changes ammo per brilliance to 3 but it's 3 by default).
- Notes get caught up in a wall if you try to fire while walking east into one.
- Overall an interesting character because of being able to focus on damage/health/mutations separately in early game.
- Rhino Skin has no effect (gets rolled back by force_loadout).
- Can buy ammo but your pistol doesn't use ammo..?
- "Sword" item upgrades pistol too but you can only tell if you watch the sprites / notice when it becomes more apparent.
- Many mutations have little use due to character mechanics. Might have been better to let the player take whatever they want into second weapon slot and only leave the sword in like with Mask. Or let player swap out either but only when they reach level ultra.
- The dash feels really nice.
- I've no idea what "gets excited" means even after looking at the code.
I tried to hastily workaround coop issues with Bard by storing some things in global arrays and moving ammo->brilliance conversion from destroying nearby chests/ammo packs to subtracting pack-worth of ammo when there's enough. This also makes Lucky Shot actually do something for the character. paste
GMS1 doesn't watch for file changes at all - if you opened some script/object in GMS1, edited it, and saved, it'll likely just show that version next time you open it instead of checking what's on the disk. Not sure if there's any way to correct this aside of reloading project - maybe it'd care when source control is enabled?
array_wget is to be a custom script that just has return argument0[argument1] inside.
array_get is currently bugged and returns undefined if a variable is not an array (which makes for some confusing bugs).
I should probably publish a helper extension with predefined possible scripts for these things
An update with this feature is now out.
About constants, I'll look into those at a later time (didn't see the edit till coming here to notify of) - the file that I use to generate "API" data ("fnames" in GMS directory) only has British spelling versions of all names for GMS1.4 so nothing takes US spelling unless I specifically add an entry (or replacement rule) for that constant/function/variable.
"game in progress" is usually resolved by restarting the game on both sides - it's only shown if the game returns a specific response.
GOG should work fine. Should not have to open ports if it's on LAN and you are using local IPs.
Also, for clarity, this is what you should be seeing as host (left) and client (right) prior to clicking Join on client side
Re: #event, currently it uses coloring akin to what GMS2 does. I don't think you can make the font bigger without causing oddities, but making the line or text brighter is fairly easy to do with a child theme. See how GMS2 theme works for inheritance and CSS in dark theme; CSS selectors are
Line number area: #main .ace_gutter-define:not(:first-child)
Code area: #main .gml .ace_line:not(:first-child) .ace_preproc.ace_define::after, #main .gml .ace_line:not(:first-child) .ace_preproc.ace_section::after, #main .gml .ace_line:not(:first-child) .ace_preproc.ace_event::after
Re: restoring icon, currently there's no UI for that - you'd open <project name>.css in project directory and remove the according line (they are fairly clearly defined).
Re: two-part icons, similar applies - would duplicate the line in CSS and change .dir to .dir.open.
Re: fold everything - yes, via Ctrl+M (keyboard shortcuts).
If this is in GMS1, having backups on save/run disabled seems to reduce the odds of it corrupting the project files. I'm not sure what exactly it is upset about, but I doubt that it's getting fixed. There's also a separate issue where GMS1 may disagree and overwrite an edited script/object with the version last opened in it, which is something that will be addressed in next update by having per-file backups done by GMEdit.