[VXA] Savepoint system

Hello everyone

I remember having something like this in one of my XP games. The idea is rather simple. I want a script that removes the option to save your game from the menu, and instead uses events to save your game at certain points. I want to include those save points in events, so you save at certain parts in the story. And at for example every inn, so you can go there to save your game whenever you want. If i'm correct VXA does include an option to call the save screen, but no option to disallow the player from accessing the save screen from the menu.

Kind regards,
Drakenkanon

Fortunately, you're incorrect about not being able to disable save access -- this should make things easier! When on the event commands page, go to page three; it's the third option under "System Settings." And any time you want to save, like at your inn or whatever, you just need to use "Open Save Screen" under "Scene Control," also on the third page of your event commands, which I think you've noticed before.

That should be all that's needed, but lemme know if there's anything else. 

Whilst disabling save access from the menu is possible, it doesn't remove the option completely from the menu command list. If the goal is to never allow saving on the menu, instead wanting to call the scene directly from an event thus rendering the menu option redundant, you will need to make changes in the script editor.

One simple way is to add this little piece of code to a new slot somewhere in the script editor, under Materials.

Code: [Select]

# removes save command option from menu

class Window_MenuCommand
 
  def make_command_list
    add_main_commands
    add_formation_command
    add_original_commands
    #add_save_command 
    add_game_end_command
  end
 
end


All it does is comments out the code which creates the save command on the menu list. You can simply delete this script snippet should you want to add the save command back.

Alternatively, you can directly modify the base script by going into Window_MenuCommand, finding the make_command_list method and add a # in front of add_save_command, in the same way as the snippet above shows. It's not a recommended approach, as modifying the base scripts is never a good idea. I would advise using the first method and adding that snippet, however. I just felt I would give you the option to decide that for yourself.

Oh, hey, yeah. I hadn't considered that you'd still be able to see it in the menu, whoops. I now realize I completely messed up my reading comprehension of the original post. Thanks!

Thank you both, but LoganF was right, I was trying to remove the option completely.

However, the script gives a stack error. Did I implement it wrong or is the script bugged?

Kind regards,
Drakenkanon

It works for me, so it's probably some other script and where you've placed that snippet.

As it's overwriting the original, make sure to place it as close to the "Materials" script (it's empty by default), preferably directly below it.

If that doesn't work, let me know what other custom scripts you may be using which change the menu in some way. I'll probably be able to tell you which part to edit to give the same effect if I know which script it is.

Edit: I think I found what is wrong. It now works perfectly. By accident I copied another script to the wrong section. This caused the stack error. Thanks for your help!

Kind regards,
Drakenkanon

In my opinion, this would be a better option.

Code: [Select]

#==============================================================================
# ** Window_MenuCommand
#------------------------------------------------------------------------------
#  This command window appears on the menu screen.
#==============================================================================

class Window_MenuCommand < Window_Command
  #--------------------------------------------------------------------------
  # * Add Main Commands to List
  #--------------------------------------------------------------------------
  alias loganf_removesaveoption_makecommandlist             make_command_list
  def make_command_list
    loganf_removesaveoption_makecommandlist
   
    i = 0
    @list.each do |command|
      break if command[:symbol] == :save
      i += 1
    end
    @list.delete_at(i)
  end
end

No Overwriting done whatsoever and can be placed anywhere in materials.

Alright, could I edit that piece of code to remove the "formation" part of the menu as well (it comes with pearl ABS, and is used to select party member equipment, but my party will never contain more than 1 actor)

Could this work?

Code: [Select]

#==============================================================================
# ** Window_MenuCommand
#------------------------------------------------------------------------------
#  This command window appears on the menu screen.
#==============================================================================

class Window_MenuCommand < Window_Command
  #--------------------------------------------------------------------------
  # * Add Main Commands to List
  #--------------------------------------------------------------------------
  alias loganf_removeformationoption_makecommandlist             make_command_list
  def make_command_list
    loganf_removeformationoption_makecommandlist
   
    i = 0
    @list.each do |command|
      break if @list[i][:symbol] == :formation
      i += 1
    end
    @list.delete_at(i)
  end
end

Spoiler for Quote:

In my opinion, this would be a better option.

Code: [Select]

#==============================================================================
# ** Window_MenuCommand
#------------------------------------------------------------------------------
#  This command window appears on the menu screen.
#==============================================================================

class Window_MenuCommand < Window_Command
  #--------------------------------------------------------------------------
  # * Add Main Commands to List
  #--------------------------------------------------------------------------
  alias loganf_removesaveoption_makecommandlist             make_command_list
  def make_command_list
    loganf_removesaveoption_makecommandlist
   
    i = 0
    @list.each do |command|
      break if command[:symbol] == :save
      i += 1
    end
    @list.delete_at(i)
  end
end

No Overwriting done whatsoever and can be placed anywhere in materials.

Overwriting the method is the cleaner option (at least in my mind). The reason I chose to do that was few.

a) it's a quick fix; programmers are lazy by nature
b) any custom menu script is either going to i) make it's own version of make_command_list and overwrite your implementation anyway; or ii) won't care either way as it will use whatever version is already present (in this case, it doesn't really matter which method)
c) by overwriting you aren't spending time creating commands only to delete them afterwards

Whilst c) isn't a big concern as the time spent isn't huge, it's still additional time and from a programming point of view wasted time should be avoided. Aliasing here doesn't really add any benefit; in fact it takes away because you not only have extra time spent on redundant processes, but you are also spending compile time creating aliased methods. It's just not necessary, even for compatibility concerns, which in the case of b.i) makes your own method pointless anyway.

What is best to do is to design the method or class to suit the needs of the specific user. Thus, if you are using a custom menu script, it would be good to make the edits to that script itself (or create an add-on which does that without changing the original). If you are using the default menu implementation, then deciding how you want that menu to be displayed would be a good thing to know first. If you just want to remove Formation and Save from the list, I, personally, would still use my overwriting method and remove add_formation_command and add_save_command.

Normally I'm inclined to agree with you, but not for this one. The reason being is that I don't like scripts which has instructions that say 'Place me above all other custom scripts', imagine how confusing that must be if someone got a few scripts which mentioned that in the instructions. Thus even if the user must wait a few extra milliseconds for their game to start up or I wasted my time somewhat by making it, it doesn't confuse people which is the way I like things.

Alright, could I edit that piece of code to remove the "formation" part of the menu as well (it comes with pearl ABS, and is used to select party member equipment, but my party will never contain more than 1 actor)

something like this:

Spoiler for:

Code: [Select]

#==============================================================================
# ** Window_MenuCommand
#------------------------------------------------------------------------------
#  This command window appears on the menu screen.
#==============================================================================

class Window_MenuCommand < Window_Command
  #--------------------------------------------------------------------------
  # * Add Main Commands to List
  #--------------------------------------------------------------------------
  alias loganf_removesaveoption_makecommandlist             make_command_list
  def make_command_list
    loganf_removesaveoption_makecommandlist
   
    i = 0
    @list.each do |command|
      break if command[:symbol] == :save
      i += 1
    end
    @list.delete_at(i)
   
    i = 0
    @list.each do |command|
      break if command[:symbol] == :formation
      i += 1
    end
    @list.delete_at(i)
  end
end

Normally I'm inclined to agree with you, but not for this one. The reason being is that I don't like scripts which has instructions that say 'Place me above all other custom scripts', imagine how confusing that must be if someone got a few scripts which mentioned that in the instructions. Thus even if the user must wait a few extra milliseconds for their game to start up or I wasted my time somewhat by making it, it doesn't confuse people which is the way I like things.

The issue with aliasing, is that you don't know where to put it. It could work either above or below, but depending on what the method you are aliasing does, determines where the script can be placed.

Because you have no idea what behaviour custom scripts may change, the decision is primarily dictated by the necessary order of your own version. If yours is of a greater priority than any other script can possibly implement (such as bug fixes to default/core scripts), even following an aliased method requires yours to come first, above all others. In this example, removing those two options (save and formation) is a fairly paramount requirement for the user so you would want your version executed before any custom script gets a chance to start messing with the behaviour. Thus, your script is required to be above any other custom script which may alias make_command_list.

Overwriting is more important to state where it should belong, since adding the overwritten method after any other implementation will negate it. Typically, unless you are intentionally negating an implementation, overwritten methods should be placed as close to the original source as possible, so as to be implemented before it can be aliased.

To be honest, you can also create a blank entry directly underneath Window_MenuCommand for the overwrite/alias, or even add the new method at the end of that script itself (though a separate script entry is better as you can tell instantly that it exists).

Note: I use 'yours' loosely, and not specifically at this particular example.

As an amend, I did do a different version of a script snippet using aliasing:

Code: [Select]

#==============================================================================
# ** Window_MenuCommand
#------------------------------------------------------------------------------
#  This command window appears on the menu screen.
#==============================================================================

class Window_MenuCommand < Window_Command
  #--------------------------------------------------------------------------
  # * Add Main Commands to List
  #--------------------------------------------------------------------------
  alias loganf_removeformationoption_makecommandlist             make_command_list
  def make_command_list
    loganf_removeformationoption_makecommandlist
    @list.reject! { |item|
      item[:symbol] == :save || item[:symbol] == :formation
    }
  end
end


I can, however, understand your concern regarding potential concern. When a script states something like "above all other scripts" it does tend to imply that the other scripts "use the same methods/classes as this one". This is why clarity in the instructions is key.

In my case, I simply stated to place it at the top of the list because it is closest to the source (Window_MenuCommand) whilst still being in the Materials section. It doesn't actually matter that it is placed at the top, but it does need to be placed above any custom menu scripts.

You've made your points, can't say I find any logical point to debate you on (they're most certainly true). Nevertheless I still think using an alias is better than overwriting a method, even for something simple.

You've made your points, can't say I find any logical point to debate you on (they're most certainly true). Nevertheless I still think using an alias is better than overwriting a method, even for something simple.

I just like to add some context/backup as to why I think a certain way.

Aliasing should be considered at an equal level to completely overwriting, though. Which is better depends on the purpose of the method. Redefining the original behaviour favours overwriting (but not always), extending or modifying behaviour favours aliasing (but, again, not always). It all depends on what the original method does. This becomes a lot less clearer with VX Ace over VX or XP. XP, for example, requires a lot of overwriting because methods are often 10-20 lines each, making simple modifications very difficult via aliasing. VXA, on the other hand, splits originally large methods into smaller methods, meaning aliasing can be done on smaller code samples. That's another factor behind the choice.

Just for random insight:

Spoiler for:

Aliasing the method doesn't necessarily mean you have to call the aliased method. All alias does is copy the method code and give the copy a new name. It's common to call the aliased method, but it isn't a requirement to do so.

Technically, even though you have aliased a method, you are actually overwriting the name anyway. That's why you wanted to make a copy and give it a new name; so you can re-use that name to do something else with it (redefine the behaviour). Most often, however, you also call the copied method within the new definition which gives the effect of expanding the original behaviour.

I'll be quiet now.

Yeah, sometimes aliasing is superfluous, though it depends on your intentions. Personally, I would've just done:

Code: [Select]

class Window_MenuCommand
  def add_save_command(*args)
  end
end


That way, it would still be compatible with most general menu scripts and would likely only conflict with scripts that do something to the save command itself. And, assumedly, any person seeking to remove the save command altogether would not be using a script that would do anything in that method.

Of course, there's no predicting what methods some people will mess around with, but it seems a little safer than overwriting the make_command_list method.

Aliasing is typically a better option where compatibility is crucial (see eg Customizable Main Menu for a similar script where I chose to alias), but for exclusive things like this I would not shy away from a straight overwrite.

The discussion what method is best is rather confusing. Modern, your script seems the simplest, therefore I guess (not having ANY scripting knowledge whatsoever) that it whould interfere with the least things. Since I might want to change the menu layout later, but still without the save command. Do I still put your script anyware below materials in it's seperate page?

Kind regards,
Drakenkanon

Yes, anywhere below Materials. It should be OK below other custom scripts that affect the menu.

Technically, D&P3's method is the one which will definitely interfere the least with other scripts though.