So I have these little trigger instances that can do arbitrary things based on a function assigned in the instance creation code. Somewhat unsurprisingly trying to call arbCode() after a live room reload results in a crash. I feel vaguely aware of why this happens but curious if there's any way around this.
SaraJS
Creator of
Recent community posts
Hello, could you describe the process from just downloading the base code to getting this bug to occur? I understand the theory behind the shallow reference of instance_create_depth somehow leading to incorrect garbage collection when the enemy instance is destroyed but I can't seem to replicate the issue on the basis of this theory. Potentially a runner patch of some kind may have fixed this?
I know this isn't really what this page is for I'm just sort of finding myself out of options.
I have a support ticket that's been open for two weeks now regarding over $1600 of payments that payoneer refunded to itch due to an issue on their end with account verification that has since been solved, but are still simply marked "paid" on itch's end. I've received no response from itch beyond the automated ticket, --> this is kind of important and I'm relying on this money as part of... being alive. <-- I don't really know what my recourse is if this is simply not answered? I have no confirmation that the issue is still even being looked into, if it's run into complicated blockers, or if you're dealing with a lot of tickets at the moment, etc, just radio silence. I can't view the ticket online or even confirm it is still open.
I don't really know what I should do or who I can contact.
ticket is: 159684
Will take a proper look at all this when I get chance, this error doesn't occur in the final version of the code so I don't believe it ought to be necessary to change this structure (not that you shouldn't do whatever works for you!). Are you seeing this problem when running the "full project", unedited?
Either way this is all very useful information so thank you for sharing.
An enemy simply loses image alpha when it is killed and we stop considering it for *player* targetting. You can ofcourse make them behave exactly as player units do by copying the step event behaviour of player units (oBattleUnitPC) to the step behavior of all units (oBattleUnit). Replacing the section that fades out enemies so they're still visible if you want that. Or at least giving them a way to become visible again when they regain hp.
AI doesn't have the same rules as the cursor for targetting, so enemies should be able to search their unit list for a unit that has zero hp and use a revive action on it as part of their script.
You'll have to code that bit yourself though ;)
sorry for the delay. I suppose you mean to ask if a party member can be added mid battle? This can be done, you just need to remember that during battle we use temporary party units that copy from your external data (this is just to maximize compatibility with different data systems). You can simply create a new party unit as needed for your new party member and them to the partyUnits list like the others (and refresh the turn order!). As for permanence, you just need to remember at the end of battle to add the relevant information back to your global struct (if using my example data system). Given I don't know how every game will want to track its data I don't cover this, but given it might be a popular request I might just cover this on the assumption you're working with a global struct like my example. But it will come much later/at the end of the series.
Not sure about this one without a closer look. The fact it makes it into the script call means it definitely has an enemy unit to reference, not finding anything in actions just suggests an incorrect definition in GameData but that would cause an error *every* time that enemy type took its turn. You could try using debug mode and then poking around the variable/struct contents at the moment of the crash. It feels like some reference is off somewhere or other or the data is getting malformed. But it's very hard to guess how.
It's not suuuper likely that the incentives and so on will be there for me to want to add much more to this, unless it does super well out of nowhere and there's suddenly a lot of demand. It would be fun to do but not likely super worth the time for me. I also think the more and more specific you get with adding features the less overall helpful the tutorial is, as it becomes either less generic and helpful to less people, or too modular to the point of being unwieldy and impractical for actual game development.
Never say never though! The most likely case would be if I ever finish PokeyPoke and make my own game like this and update it with whatever new things I learn.
fwiw:
1. summoning monsters at a basic level is pretty doable once you fully understand the whole system! You can use an action to simply create a new unit on the player's side. You'd need some custom thing to track its duration/or leave conditions though.
2. stuff outside the battle is pretty beyond the scope of the system anyway so I wouldn't likely do this at any point but this *is* also pretty simple. There are simple distance checking functions you can use to turn on a variable and then when that variable is on just move towards the player each frame!
The one thing this makes me consider that would be worth adding at some point is an example of a "timed effect" like a poison condition or something. That example would then naturally be useful if you wanted to do summons that last for x rounds and so on.
If you or anyone else would like a quick fix to this issue in the meanwhile (a more permanent fix needs to consider the tutorialization...) you can add these lines to the draw end event of oBattle. This fix will also be in the new version I'll be uploading shortly. This will remove the crash, but will skip showing the transition if you change screen focus.
Ah interesting, yeah surfaces lose their contents in certain scenarios (like the window losing focus) I will need to put together a proper safety check for this. I imagine this might happen if you swap to full screen at any point mid fight and then finish the fight.
Should be able to fix this without too much problem in the near future, thanks for this!!
While I'm sure there's stuff I haven't thought of, I imagine this wouldn't be too difficult to do with this setup. You'd want to change the victory conditions, make a new type of player unit that faces the other way etc, but you can make most of what you need through duplicating the player one stuff and making minor adjustments.
even on one controller you'd want to know which player was which to determine who wins, who the default target for offensive/defensive abilities should be, what side to stand on, etc etc. So that doesn't make things any easier per se but either way it wouldn't be too difficult to implement with some basic GML skills.
You seem to have a mix of versions here for some reason. Line 37 of your oBattle creat event is from the new version, but the line in your slime collision event is from an old version.
Edit: i've also confirmed that the most recent version also works properly in Opera GX, so if you're still hitting errors this is a problem with your project specifically.
That, fortunately is the exact issue mentioned in the post above. Will look into the GX games thing but with the windows launcher if you implement the fix in the link in my previous post, or get the newest files it will fix that particular error. The mention of " if (_option[0] == "Attack") return 99;" is the giveaway.
Hello again! sorry to bother you, but I believe your bug may have been related to this issue that was reported recently. Was HTML5 the platform where you were hitting this bug? If so and you get a spare moment would you be able to either get the latest files or implement the fix mentioned in that post and let me know if you still get issues in the browser?
-S
This fix has now been uploaded: https://shaunjs.itch.io/shauns-turn-based-battle-system/devlog/484288/hotfix-for... please let me know if you still have issues!
If you want you can quickly implement the fix for yourself if you don't want to replace the project. Change line 120 of oBattle's create event to read as follows:
if (_action.subMenu == -1) array_push(_menuOptions,[_nameAndCount, SelectAction, [_unit, _action], _available]);
Ok I've found the issue, it's because I was setting menuOptions[i] to be the new top level action when compiling the menu. This means if we did a sub-menu action in between two top level actions (like magic) when the next top level action is added, i has increased by more than 1 and there will be 0s added in between. For some reason this never threw an error previously. I'm really not sure why it didn't! This probably also explains why a similar error appeared for another user in HTML5. Thanks for the report, I'll upload a fix for this now.
Unfortunately I'm low on ideas as I simply cannot reproduce the issue on my own end without changing the code intentionally to do so. All I can really suggest is that you place a breakpoint somewhere inside the DoTurn() function in oBattle's create event, just after the point where it has decided that it's a player turn (like the if (_unit.enemy == false) line). and run debug mode. Then when you hit this breakpoint use the Step Into Function Call button to progress one line at a time until the error occurs which might give you more clues. As your error as posted is struggling to isolate the problem line.
Fwiw the error itself refers to code trying to treat something that isn't an array, as an array. And if it's happening when it becomes one of your character's turns, chances are it's happening when trying to build the action menu for that character. Which might mean you've added or changed something in gamedata for that character (or perhaps an action) but accidentally affected the datatype or missplaced a comma or something similar?
Although you say sprite I presume you mean changing the names of the characters generally, correct?
You can change the name of any asset in the asset browser by right clicking it and selecting rename, or by pressing F2 with the asset highlighted.
In terms of changing the names as they show in game, etc. Most of that information is held in the "GameData" script. Where you will see all the data for the party members, the inventory, and every "action" you can perform in combat.
Enemies are not stored in this same way (although perhaps they should be?) but their information can currently be found in the create event for that particular enemy unit. During my refactor and for the tutorials, I will probably move this enemy data to also come from the GameData script instead.
Oh I have misunderstood! I did not read your errors correctly and presumed they were part of an earlier issue. The problem is that the project uses very new techniques introduced in stable 2022.11. The "string" function explicitly now allows extra functionality that this project uses. I will add clarifications on this to the project page. Very sorry for not reading this properly! =(
And if either of you are unable/unwilling to update your GameMaker version for whatever reasons and therefore cannot use this project, please feel free to initiate a refund request with itch.io. Sorry about that!
Hey hey! Have you tried downloading the version I uploaded after this hotfix? https://shaunjs.itch.io/shauns-turn-based-battle-system/devlog/476207/hotfix
I think this should fix your issue. Otherwise the line to fix is in the collision event with oSlime, the last argument "sBGfield" should be the last argument of the function but is accidentally part of the array given as the first argument.
Intrinsic issues that will not likely be fixed:
- Adding more than ~6 enemies, or more than 3 player characters using the same visual style/ui design will cause issues as there simply isn't room for them. This is just intrinsic to the design and if you want more characters for your game you'll need to change the UI design, formation positions and/or game resolution etc to accommodate your needs.
Known and not yet fixed:
- Toggling fullscreen or losing window focus during a fight might cause the transition surface to lose its data and trigger a crash at the end of the fight.