Jump to content

Traverse

Member
  • Content Count

    359
  • Joined

  • Last visited

  • Days Won

    6

Traverse last won the day on April 26 2018

Traverse had the most liked content!

1 Follower

About Traverse

  • Rank
    Advanced Member

Recent Profile Visitors

3,877 profile views
  1. Works fine to me. Tested in a fresh project with nothing but Yanfly Message Ace, Yanfly System Options and Global Codes. :volume_bgm => ["\\*\\r[3]", 12, 4, # Options 1 & 2 are Gauge Colours. <== \*\r[3] is defined in Global Codes as "\\i[3]BGM Volume" "Change the volume used for background music.\n" + "Hold \\i[2]SHIFT to change increment by 10." # <== Doesn't even need Global Codes, renders fine without it. ], # Do not remove this. You don't even need Global Codes to draw icons in the help text, the help window will render the icons just fine with regular escape codes, you only need to use Global Codes if you want the icons in the command name for some reason. If there's any other problem, it must be coming from one of the other scripts you're using.
  2. You need to chill a little, nobody is making any accusations or badmouthing (well, if anything, you're the one accusing me of spreading FUD). Pointing out that asking something may come off as an accusation and that doing so may imply something shady is NOT the same thing as making an accusation and calling it shady or implying so. Trying to conflate all mention of anything to do with shadiness and illegality without sparing any thought to the context and automatically treating it like someone is somehow promoting it or making "quasi-real" accusations of it is, at best, rather disingenuous (and I'm not going to say what it means at worst, because I'm going to give you the benefit of doubt and assume you conflating and ignoring the context it is unintentional and that you're not doing it deliberately). In this case, the context is that emulation is very much a legal grey area* - something which is a known fact and not FUD. I am not "implying" the possibility of improper action, I am saying outright there IS a possibility of improper action, due to the nature of the field. This is not a "smear" on any project, or some attempt badmouth by somehow pretending that the possibility is hard fact, this is simply the factual context behind the discussion which needs to be addressed to get to my point. My point being that, because of this, asking whether one is legal is akin to asking someone who you see surreptitiously knocking back pills if those pills were legal. If the answer is yes, it only gets the other guy annoyed and possibly insulted. If the answer is no, it's going to be messy for both of you unless you're deliberately trying to get a confession for some reason or other. There's nothing wrong with making a real accusation if you deliberately are trying to drag a confession out of someone. Otherwise, saying nothing is just good manners and all around better for everyone's stress levels, at least IMO. You can disagree with that opinion if you wish, but there's no point getting up in arms while ignoring the context behind it, if you do that we're just talking past each other. EDIT * - And because I suspect you may lament its current legally grey status as being a sad state of affairs for emulation, I'm also going to remind you to be careful what you wish for - because from what I gather (and I could be wrong) part of the reason it's been legally grey for so long is simply because the alternatives are either outright legal or outright illegal and nobody knows which way the coin would flip if courts actually started taking a hard look at them and passing down rulings, so there are people who prefer to keep it grey and avoid court rather than gamble on clarification. No, I am not talking about myself, I have no stake in it whatsoever - I am just pointing out such people exist and the reason why they prefer grey.
  3. I haven't used mkxp before, so I'll take your word for it when you say that it is, in fact, not very good or accurate at reproducing the functionality of the original RGSS code. If this is indeed the case, I have no trouble believing that they just made do with what they could guess at, with the end result being what you describe (as unfortunate as it might sound to say it that way). If it did actually reproduce most of the functionality closely, I would really be seriously wondering about it. I mean, both you and I know it wouldn't be the first time somebody has ever cracked the RGSS DLL before. Which is exactly the reason my advice was to not ask or look in too closely. It's a very fine line and can be hard to tell. Giving benefit of the doubt means you're assuming that the reverse engineering was done completely through legal means (i.e. that it was done by observing aspects of the product that were legal to inspect or copy and/or guessing how something was done for the parts that aren't). There are people who are good enough at it to do it that way. I do not know how many of them exist, but I would guess far fewer than those who need to look at the parts that aren't legal to copy or need illegal protection bypassing to inspect. But giving benefit of the doubt means assuming the creator(s) fall into the former rather than latter category. If you're assuming it was done legally, you don't ask whether it's legal. You assume simply that if a part of it looks very similar to how the original did it, it means the reverse engineer just made a very good guess at how it was done. If you are asking whether it's legal, what you're asking is whether it was just a good guess or whether it was a heavily educated "guess". Which, unless you're deliberately trying to start something, is just going to be cause for trouble or at least that's the way I see it. TL;DR - I'm saying that if you're assuming it's legal and innocent until proven guilty, you don't ask because if you do you're effectively asking for proof they're innocent, something along those lines.
  4. Traverse

    Title Screen/Picture Resolution

    Depends entirely on your game, but in general the larger the better because you can easily scale down and reduce the resolution of a big image later if you need and still have it look good, but trying to blow up a tiny low-res image into something bigger will simply make it look blurry or pixelated or both. There is a reason why logos are often created as scalable vector images that can be rendered at any resolution instead of being fixed sizes/resolutions, although this may not be suitable depending on what kind of aesthetic you're looking at for your art.
  5. Actually, it isn't. The help file provides a basic summary of what the core methods supposedly do, but the details of how it does them and the exact code behind them are not supplied. This is the reason why RPGMaker MV was touted as being more "open" than XP/VX/Ace when it was announced - all the code for the base modules like Audio, Graphic and Input and base classes like Window, Bitmap and Sprite are accessible and editable in MV's files under "rpg_core.js". But for XP/VX/Ace, the RGSS DLL contains all of this base code and you're not supposed to see it. For a direct example, you won't find the code for chopping up the "Window.png" windowskin file and arranging it in the form of a window anywhere in the script editor. It's not in Window_Base, that stuff comes from the Window superclass located in the RGSS DLL. I recall seeing someone on the official forums trying to reverse engineer the process of assembling a window just from the help file, he had limited success. Another example - did you know that the base Audio module in VXAce actually contains functionality for fading-in .ogg tracks, not just fading-out? This isn't even listed in the help file. It can't normally be accessed anywhere, there is no event command for it, there is no listed method (or if there is, I do not know what it is called because it has not been documented, I only stumbled on the fact it could wholly by accident). It gets used when a BGM gets (re)played at a position in the track other than the beginning. It only works for .ogg files because position-seeking doesn't work for other formats in the first place, but you can check it out yourself - call Audio.bgm_play("Audio/BGM/whatever_track", 100, 100, 1). As long as its starting position is greater than 0, it will fade in. Now, I don't know, maybe it's true that they were simply good enough that they could reverse-engineer all that functionality from the RGSS DLL without actually looking at the DLL, or else maybe they looked at the code that MV supplied and then reverse-engineered based on that. It might be possible. But you will also have to forgive people who may suspect otherwise. Usually, yes. Unless the BIOS code for the original hardware was supplied with the emulator, then that's illegally redistributing copyrighted/patented code, which is the reason why you will see lots of emulators tell you to supply your own BIOS dump (and the emulator won't run properly without it). Now granted, there are emulators that don't require a BIOS file because their creators were good enough to be able to reverse-engineer the functionality of it without touching the original BIOS... or did they actually do it without touching the original BIOS? Best not to ask, in that situation.
  6. From what I can gather, mkxp is kinda like an emulator that makes it possible for you to run XP/VX/Ace games on Mac or Linux. It doesn't actually touch anything to do with the engines themselves. Whether it is officially allowed is probably in the same grey area as other emulation software. This is due to the fact that its creation may or may not have involved cracking the proprietary RGSS DLL and reverse-engineering any copyrighted code, which may or may not be easily sue-able if anybody takes a close enough look at it. Probably best not to ask too hard about it and then they won't have to say anything about it.
  7. While I have never used Syvkal's Ring Menu myself, it seems that the spinning animation wasn't actually made by Syvkal, but credited to an older Ring Menu script that was created by 3 different people . Those notes were from his post on the official forums. Now those are some names I haven't seen in a long while. That original script looks to have been an old RMXP script that is still accessible on RMRK. While I'm pretty sure not many people publicly release scripts for RMXP anymore, I'm fairly certain that there's actually still a good bit of internal development and commissioning that goes on behind closed doors due to how popular RMXP has been for commercial games (*cough*To The Moon*cough*). Pretty much the same way it works for VX/Ace/XP, except it gets placed as a .js file in the Plugins folder and the whole thing needs to be enclosed in its own function. And the Plugins Manager will read any comments in it delineated within /* ... */ looking for the following text: "@plugindesc", "@param", "@desc", "@author", "@default", @type" and "@help". By reading these, it generates the list of parameters that the user sees in the editor and then they get to type their inputs into a neatly-arranged and organized Plugin Manager window instead of having to directly write into the script. Meanwhile, these are accessed in the plugin itself by calling "PluginManager.parameters(plugin_filename)". By the way, one annoyingly shitty thing I often see plugin makers do is hardcode their plugin's filename into this parameter call (i.e. Yanfly.Parameters = PluginManager.parameters('YEP_CoreEngine')) - yes that is correct, even Yanfly has a habit of doing this - instead of dynamically reading the filename as it runs (i.e. pulling the name from "document.currentScript.src"). The result of which, of course, is that if you happen to change the filename of the plugin to anything else (i.e. from "YEP_CoreEngine" to "YEP_CoreEngine_TestFixes") you immediately end up breaking the plugin. If you ever end up making any plugins of your own, please avoid doing this unless you have a really good reason.
  8. Huh, wow. And she/he started charging for old plugins retroactively too? Did not know. At least all the old VX/Ace ones still seem to be free, if only because they're effectively abandoned and will never be updated again (though to be fair, I guess VX/Ace engine isn't expected to get any more version overhauls like MV and so doesn't really need updating to maintain compatibility with the engine itself). The last I heard about plagiarism with RPG Maker was people uploading and trying to sell whole free games from RMN on dodgy digital marketplaces and Steam, didn't think anyone would bother doing it with individual scripts much less from someone as well known as Yanfly, the closest I heard anywhere close was the guy who took stuff from Moghunter and I don't recall those being sold, just not credited. It's kind of funny, because the one that seems to have been copied, Yanfly Aftermath, has (IMO) a horrible way of animating the EXP gauges. Feature seemed neat, especially at first glance from still screenshots, then I took one look at it when it was actually in motion and noped straight out. Couldn't even find any way after checking the code to improve it without rewriting the whole thing, so I just ended up writing my own. Why on earth Yanfly wanted to animate by total number of ticks, I simply have no clue, looks jerky and jarring as sin.
  9. Dunno about the others, but Yanfly and Moghunter are definitely not gone. They've both released and updated more than a few plugins on their sites last year. Having a few months in between updates and releases is not abnormal. I wouldn't call MV plugin development dead by any means, especially when you can pop on the official website and see the Complete Javascript Plugins board get a new topic posted (which means a new plugin/script) every couple of days. Compare that to VX/Ace script development. Quality, meanwhile, is highly subjective. I can't speak much as to the MV plugins but I can say that I have run into game-crashing bugs with Victor and Hime's RGSS3 scripts before and even Yanfly's stuff isn't bug free, even if he is pretty good with fixing them regularly. EDIT: That said, I will also note that I may not be the best person to judge quality because almost all the scripts I put my hands on get severely tweaked under the hood by yours truly for my own project. For example, Mr. Bubble's TMI/Info Pages script may well work perfectly smoothly by itself or may actually be extremely bug-ridden and clash with many things, I wouldn't quite know - because the first thing I did was rip into the Info Pages code to add custom pages to display item portraits and word-wrapped item descriptions and some other stuff specific to my game as well as add resizing functionality for my custom Equip scene. And then I have to assume that any bugs I run into after were caused by my extensive modifications and not originally part of the script.
  10. Traverse

    Display image in Status screen

    Like most things with scripting the answer of whether it's possible is of course, yes. KZ's snippet is basically what you do to display any external picture file in a window. If you look at the default code in the engine for "draw_face" (which is used to display the portrait, located in Window_Base) it basically is the exact same thing, with only one difference, which is that it needs to chop up the image file containing the faces in order to pull the right face from it. #-------------------------------------------------------------------------- # * Draw Face Graphic # enabled : Enabled flag. When false, draw semi-transparently. #-------------------------------------------------------------------------- def draw_face(face_name, face_index, x, y, enabled = true) bitmap = Cache.face(face_name) rect = Rect.new(face_index % 4 * 96, face_index / 4 * 96, 96, 96) # This is the only thing it does differently. contents.blt(x, y, bitmap, rect, enabled ? 255 : translucent_alpha) bitmap.dispose end But I guess to be fair, for someone who is only just dipping their feet in the engine's code, these 3 or 4 lines of code might be kinda not very easy to understand. So I'll break down what KilloZappit's snippet actually does line by line: bitmap = Cache.picture(picture_name) # Load (but not display) an image file from "Graphics/Pictures" whose filename corresponds to # the value stored in the variable "picture_name" and set it to a Local variable called "bitmap". # "Cache" is one of the default scripts right at the top of the list, its job is to load images # from the game's Graphics folders and cache them for quick reloading, if the same picture # needs to be used later. If you check it out, each of its Methods corresponds to one of the # sub-folders in the game's Graphics folder. # Example usage: bitmap = Cache.picture("actor1-fullbody.png") # # The file extension is optional. You can omit the extension and it will look for whatever valid ones # it can find. contents.blt(x, y, bitmap, bitmap.rect, enabled ? 255 : translucent_alpha) # Displays the image in the window. Every Window has its own completely transparent, blank # bitmap image called "content" that it creates when it is initialized ("create_contents"). # To display things, some other image is typically loaded and gets copied onto this "contents". # using the "blt" Method. "blt" is short for 'block transfer' and it preserves transparency, so # you can 'layer' things on each other by repeated "blt"s as opposed to other Methods for drawing # things like "fill_rect" or "gradient_fill_rect", which will completely replace whatever was # underneath, even if you try it with a transparent color. # # Example usage: contents.blt(12, 24, image_file, Rect.new(0,0,4,4), 255) # Meaning: "I want to copy the image in the variable 'image_file' and display it starting 12 pixels # from the left of the Window and 24 pixels down from the top. I don't want the whole image # to be displayed, just a 4x4pixel portion of the top left corner. And do it at full 255 opacity, # not translucent or transparent." # # X-coodinates start from the left, Y-coordinates from the top (unlike RPGMaker MV, which I # believe has y-coordinates starting from the bottom of the screen). Opacity ranges from 0 # to 255, with 0 being fully transparent/invisible and 255 being fully opaque. Images are drawn # from left to right, top to bottom. # # The particular call in the snippet does not look much like the example, because all the parameters # used are themselves variables. Plus, there is that headache of a ternary operator used to # decide the opacity. # Meaning of the call in the snippet: "Display the image from the "bitmap" variable however many pixels # to the left was in the "x" variable and however many pixels down specified in the "y" variable. # I want the whole image displayed, the entire portion of whole rectangle of the image in the # "bitmap" variable. For opacity, I want to look at the variable "enabled". If such a variable # exists and/or has any value assigned that isn't "false", make this image 255 fully opaque. # Otherwise, set it to the opacity value stored in "translucent_alpha"." # # "translucent_alpha" is a method in Window_Base whose sole purpose is to store a number. That number # being 160, which is the opacity that not "enabled" images will be drawn at, such as actor porraits # of reserve party members. bitmap.dispose # Unloads/disposes of the image to free up system memory. It has already been copied onto "contents", # so the original is no longer needed. "contents" itself gets disposed when the Window is disposed, # which only really happens during Scene changes. Most other times you 'close' or 'shut' a Window in-game, # like with the message box, it's actually only being turned invisible and not really disposed. You might ask, where are all these variables called "picture_name" or "enabled" or "x" or "y" actually being set and given values? The answer is, they are set in the parentheses that you type when calling the Method to run it. def draw_picture(picture_name, x, y, enabled = true) # Declares the lines of code written after to be a Method called "draw_picture" so that it can be # called repeatedly without having to retype the lines of code within. The value of the variables in # the parentheses are to be specified at the point of calling the Method. The first three are mandatory, # the last one has been given a pre-existing default value of "true" and so is optional; if you don't put # anything in for it, it will default to "true". # # Example usage: draw_picture("actor1-fullbody.png", 0, 0, false) # Meaning: "Load the image "actor1-fullbody" from the Pictures folder. Display the whole image # from the start of the Window's top-left corner, at translucent 160 opacity." # # Example usage 2: draw_picture("actor2", (self.width-200), (self.height-200)) # Meaning: "Load the image "actor2" the Pictures folder. Display the whole image starting 200 pixels # from the right side of the Window and 200 pixels from the bottom of the window. Do it at # full 255 opacity." ... ... ... end Basically, you need to decide what coordinates you want the picture displayed at and have a picture ready so you can prepare the Method call (something like "draw_picture("actor1-fullbody.png", 0, 0)") and then find a good place in the code of Window_Status to insert the call into. Remember that the images drawn will layer over one another, so whatever gets drawn first will end up underneath something that gets drawn later if they get drawn in the same spot. Which means you will want to insert your picture-drawing call somewhere before the text gets drawn if you plan to have text written over it.
  11. As CookieNinja mentioned, the UI interface of RPGMaker can't be altered via script. You would need to hack the maker executable itself to change the UI, which is of course against the terms of service of it. But if you know how to script, you won't really need the database, you can hard-code any settings in the script itself or even make your script read external text files etc. to grab the settings. Scripting a battle system depends on the system you want and how different from the built-in system it is. In the worst-case scenario (like, say, an action battle system that is completely different from the turn-based system in RPGMaker) it will all have to be coded completely from scratch. If you imagine how much time or effort it would take to code a battle system from scratch using Java, you better believe it will take about the same amount doing it in Ruby. Something like a Fire Emblem tactics-style system is almost completely different from the one RPGMaker ships with, it will probably need to be done from scratch (I think there might be existing scripts that have tried to make something similar, like GubiD's, but I have never used one before and can't advise you on how good/whether to use them). As for a maker that does Fire Emblem-style gameplay, yes, there is at least one called SRPG Studio that just got released. It's not related to RPGMaker and again I have never used it so I cannot comment on whether or not it will do what you want it to. But I know a game called Vestaria Saga was made using it (which was recently translated into English) by the creator of Fire Emblem and the engine was basically built to let people clone Fire Emblem games.
  12. Traverse

    Octopath Traveler Battle System Plugin (Paid Request)

    While I can't help much with this, since I haven't played and don't know anything much about Octopath Traveler's battle system, from what I can tell, what this request seems to involve multiple systems at once. So I suggest maybe you should break up the request into some of the individual systems you're looking for. For a start, from what I see looking at the video, the battle system uses some kind of CTB-style system where the actors take individual turns, unlike how MV's default system requires inputting all of the party members' actions at the same time. Individual actor turns/CTB is already one system on its own. The only thing special about this one seems to be that instead of having all future turns listed on the same bar like usual, it's been visually split into 2 separate bars, one for current/other battlers' upcoming turns, a second one for all their next turn afterwards. Then you have the Break system, which is another system on its own. This one doesn't matter when anybody takes their turn, I assume its just the number of hits with the right weapon, whether you have 3 different members doing it or 1 person doing it all. Then there's the Boost Point system. Again, unless I'm missing something, this one technically doesn't rely on actor turn order (and doesn't rely on anything to do with Break), it just makes actors gain a point of some custom "BP" resource every turn, which they can spend to activate a self-buff. Under the default MV system they just all gain points at the same time. You might be more likely to get the request fulfilled if you ask for each one separately.
  13. Traverse

    Make a skill temporarily change basic "attack" command

    Depending on how you want to do it, you may not even need to open the script editor. The simplest way I can think of is simply to alter the damage formula of the Attack skill in the databqse (Skill 001 in the database by default) to check for the actor's state and then use a different formula from normal if it the actor has that state. Example: # This is the default damage formula for Skill 001. a.atk * 4 - b.def * 2 # Change it to something like: if a.state?(26) ; a.atk * 10 - b.def ; else ; a.atk * 4 - b.def * 2 ; end # Assuming your buff state is State #26 in the database. This assumes you will be keeping the name and animation the same. If you needed to change the name/animation, I would have said you would need to make a completely new skill and then modify Window_ActorCommand and Game_BattlerBase (to check for the buff state and code it to detect the state and use the different skill) since the name and ID of the basic attack command is hardcoded into the default scripts (the command window is wired to always display the name set under the Terms database tab for the basic attack and Game_BattlerBase is set to only use Skill 001 for basic attacks). But since you are OK using the same name and animation, you should be able to just modify the damage formula for the basic attack.
  14. The usages of $game_player.terrain_tag and $game_map.terrain_tag are different. They're separate methods - $game_player's version originates from Game_CharacterBase, but $game_map's originates in Game_Map. Using "$game_player.terrain_tag" will return you the terrain ID of the tile the player is standing on. On the other hand "$game_map.terrain_tag" needs to be provided with an argument, its correct usage is "$game_map.terrain_tag(x, y)". You provide the x/y tile coordinates as arguments and it will return you the terrain ID of that tile. AFAIK, there is no inbuilt method for retrieving the every tile coordinate for all tiles of a specific terrain tag. You will need to code that yourself (by running the terrain check on every applicable tile) if you want to find out. In your case, that's every tile in between the player and your target assuming you only want a straight line LoS and don't care about diagonals.
  15. Until you mentioned that all your armor were weapons, I would've suggested just excluding any RPG::Weapons from being drawn. But if all you want to do is nix the first line, you can just do this: draw_item_name(item, x + 340, 48 + line_height * i) unless i == 0 Two problems: one, it will blank out the first line, but everything else will still be drawn in the usual place (i.e. the second item will still be drawn at position [48 + line_height * 1] instead of [48 + line_height * 0]). So if you wanted the second item to be shown in the original position of the first, you'll have to pull up the whole thing by line_height ("48 + line_height * (i - 1)). Second problem - if you have a dual-wielding actor, this will prevent the first weapon from being drawn, but the second weapon will still be drawn because, well, it's the second item on the list. You're going to need to make an extra check for whether the actor is dual-wielding and then blank both first and second lines if they are. And then pull up the list by two line_heights if you wanted the first armor to be at the top of the list. Of course this only works if your "weapons" are the first/second items on the list. If they're meant to be an arbitrary position down the equipment list you're going to run into trouble, because then you'll need to distinguish them from your armor somehow - and then you'll have to forgive me for wondering why you didn't just make your armor, well, armor and needed them to be weapons instead.
×