Is there by chance already a system to exclude encountering monsters that are currently in your party? I seen the possibility of doing something within the ects_placeholder function, but with out doing a bunch of if statements?
Viewing post in Yal's Monster Collector Engine comments
There's no built-in system, but it should be easy enough to set up.
In obj_player's collision event with obj_encounterzoneselector, after line 8 insert some new code:
for(var b = 0; b < array_length(global.encounter_valid_monsters); b++){
for(var c = AMP_FIRST_ACTIVE; c < AMP_FIRST_ACTIVE + PARTYSIZE_ACTIVE; c++){
if(global.active_monster_party[c,amp_MONID] == global.encounter_valid_monsters[b]){
array_delete(global.encounter_valid_monsters,b,1)
b-- //Deleting shifted everything back one step so re-check
break;
}
}
}
(this is completely untested so use with care)
the encounter_valid_monsters array is common to all ects_* (EnCounter Table Setup) scripts so modifying it directly like this means it should work everywhere in the game.
Sorry to bother you again, but still learning. I'm struggling on updating the monster part list. Maybe you can point me in the right direction on what I'm missing. This is what I have:
function mev_pause_monsters_release_confirm() { with(instance_create_depth(x,y,depth-1,obj_gguimenu)){ daddy = other.id message_spawn(tsprintf( "You released %.", amp_get_monster_name(other.my_monster))) amp_clear_monster(other.my_monster) with(daddy.daddy){ if(object_index == obj_terminalmenu){ msh_terminal_update() } else { msh_spawn_monster_list() } } instance_destroy(daddy) instance_destroy(daddy.daddy) } }
It looks pretty reasonable, but you both update and delete daddy.daddy... I think you meant this? (destroying the "are you sure?" menu and the "what do you want to do?" menu)
instance_destroy() instance_destroy(daddy)
(also of course you need to set my_monster to the AMP_ID (index in the Active Monster Party array) of the monster you want to delete when you create the menu that eventually runs mev_pause_monsters_release_confirm() , so the variable has a valid value... I presume you're doing this?)
Yeah to both parts, but the list seems to not get updated. The msg pops up saying the correct monster get released and the correct menus get destroyed. Just the party list doesn't update correctly. Say I delete a monster in the middle of the list. It'll show a blank spot there, but then you won't be able to navigate pass that blank spot. Also I noticed after releasing if I hit 'X' to select a monster I get an error, but also if I hit 'Z' to go back it'll show the monster I just released back in the party. If I hit 'Z' one more time and then select the party again to bring up the list it shows it as gone and the menu functions as normal with the exception of navigating pass the blank spot in the list. Hopefully that makes sense.
Looked around in the code...
- The reason there's a "gap" in the list is because msh_spawn_monster_list stops whenever the monster ID is NONE, and after you clear the data, the monster in the middle will have all its data set to NONE. You can fix that by looping from the now-empty ID to c <= AMP_FIRST_ACTIVE + PARTYSIZE_ACTIVE - 2, and for each slot, copy data from the next slot, and then finally erase the data in the AMP_FIRST_ACTIVE + PARTYSIZE_ACTIVE - 1'th slot. (So basically, for all monsters in the party, shift them to the previous slot). You can check out mev_pause_monsters_switch_confirm() for an example on how to swap two monsters' data.
- Not sure what the "hit Z to go back shows the monster back in the party" bug is caused by, but it sounds like the party list isn't updated properly so it uses old data. Just to check if you've got the right object in the variable, you could try setting the object you think has the list's:
ggui_frame_l[0] += 32
after updating the monster list. This should make the menu jump a little bit to the right, allowing you to check if it's the right menu you've updated.
Also if you get the error message again, could you please copypaste it here?
Made some progress. Everything seems to be working accept for the issue of hitting 'Z'. Made a video of what it's doing here: https://drive.google.com/file/d/14YL4eN2oUNu5DP-6giVcNU2JN-MR8qo_/view?usp=shari....
Also, here was the code I was using:
function mev_pause_monsters_release_confirm() { with(instance_create_depth(x,y,depth-1,obj_gguimenu)){ daddy = other.id message_spawn(tsprintf( "You released %.", amp_get_monster_name(other.my_monster))) amp_clear_monster(other.my_monster) for(var c = AMP_FIRST_ACTIVE; c < AMP_FIRST_ACTIVE + PARTYSIZE_ACTIVE; c++){ if(global.active_monster_party[c,amp_MONID] == NONE){ array_delete(global.active_monster_party,c,1) c-- //Deleting shifted everything back one step so re-check break; } } msh_spawn_monster_list(mev_pause_monsters) instance_destroy(daddy) instance_destroy(daddy.daddy) } }Okay, I figured it out. The problem is that you spawn a new menu and update that's list, but the original menu has an un-updated list (which is why the monster comes back when you cancel, because you destroy the new menu with the updated list and go back to the old menu)
Also good point re: array_delete, we can just delete the entire entry from the array to get around the whole mess with manually sorting it.
Try this code:
function mev_pause_monsters_release_confirm(){
daddy = other.id
message_spawn(tsprintf("You released %.",amp_get_monster_name(my_monster)))
array_delete(global.active_monster_party,my_monster,1)
array_insert(global.active_monster_party,AMP_FIRST_ACTIVE + PARTYSIZE_ACTIVE - 1,[])
amp_clear_monster(AMP_FIRST_ACTIVE + PARTYSIZE_ACTIVE - 1)
with(daddy.daddy){
msh_spawn_monster_list(mev_pause_monsters)
}
instance_destroy(daddy)
instance_destroy()
}One way to fix that is to add some code setting the step range really high if the list of monsters is empty:
if(array_length(global.encounter_valid_monsters) < 1){
global.encounter_step_range = [9999, 9999]
global.steps_to_next_encounter = 9999
}For additional stability, go to player_step_fill and add an if statement around line 10 to not count up encounter steps if the limit is 9999:
if(global.steps_to_next_encounter < 9999){
encounter_steps++
}