Mephistox

I'm working onto a new version, because I deleted the old by mistake.

- Fogs - Native Full Keyboard, or almost the keys and numbers - Native Mouse Support - More Game Resolutions. - Full Ruby Support - Multiple Vehicles (Not 3) - More Database Slots (more than 999), like in the olders makers upto 5000 entries - More than E tileset. or at least leave the B, C, D, E free of size. - More Layers. (Not infinite, but more than 3, at least for decoration tilesets) - Native Event Spawner/Cloner and Teleporting - Native MultiSlot. (Actually they seem to be working on it, but leave it as usual) - Autotile Expander - MultiPlayer Support - Better Encryption options - Free use of HIdden classes, at least for learning uses or easier modification. - Better Item In-game handler. (Like duplicates) - Looping animations (WHY!!) ------------------------------- Things I don't want to see: - Change of Graphics, please not again, Just add more graphics instead of changing the style, maybe some remakes. - 3D crap or something like that, please NO - Downgrade features (Like the VX did) - Any other thing that could destroy the RPGMaker Series Spirit. (Like ones for PS, piece of crap).

At least he's using a kind of pixelmovement, isn't possible to make a fading effect, because to the tiles to stay and not to stay near a reflection zone (the water) is 1 tile.

You can use this script with an ABS. It's what I'm doing! I'm making a zelda style game. What abs are you using? I am using Blasphemia, but it seems to have a conflict with this, I think. I get an error in line 1409 of game_interpreter when i try to learn a song? You should not have problems with learning songs, since I didn't overwrite methods or anything. Can you post the list of scripts and also the screen of the bug and line. Thanks.

Just fancyness and innecessary use of memory as global variable. There a lot of scripters that add the 'imported' thinking that is important or must be there, but in the 99% they even don't use that. The real reason, and the original, if I remember begin with the KGC scripts that add a global variable to identify his scripts and also to add requirement for other scripts and disabled when a required script isn't installed, like: Script 1 $KGC << 'Script One' end Script 2 if $KGC.include?('Script One') enable script end end After that many scripters begin to use it with the same reason but in some point this become useless and just a bad habit, users of SDK used the script logging that offered a real reason to use a variation of the 'imported' thing. ---- As i said, the modern use of the imported is unknow for me, for example some yanfly script: $imported = {} if $imported.nil? $imported["YEA-BattleEngine"] = true and in the plugins should be included some kind of verifier, but none, maybe it is used for internal revisions, but no need of leaving as public code because is useless. ---- Of course not saying is totally useless, but there should be a GLOBAL way for all the scripters to use a log system, I saw someone tried to recreate the SDK for VXAce, a really good idea.

My advice, first write the storyline and complete it at the 100%, no changes admitted. Design a layour of all the systems that you will include, items, events, etc. NPCS missions, reason to be, etc, then use the maker, if you have no storyline at 100% the project will fail. Even for people with skills, big ammount of resources from any type you can imagine and all the scripts that she/he wants, if you have no background story, you don't know were to go and begin thinking on add and add and add and add things to the game that weren't planned, finally you got a project with 5 maps, all your systems, all your resources, but have no story and not mood to continue it, so, to the trash....That's happen me about 5 times, the only good thing that i got from that experience is that at least, i was improving my skills. A good idea also is work with a team, an individual always will try to change the things everytime, if you work in pairs: 1 is faster to work, 2 you won't be alone, 3, you need your partner to decide what to change and not.. But again, most important STORY, layour, gant shit and all kind of schedulle paperwork that's why it's difficult to see 100% finished projects in my opinion.

Maybe, you can play with Fiber, like they did with the Message Window also if you want a a more sophisticated wait commands, but this only would work with the scene in particular, or creating some kind of method for scene_base to allow to use in all the child scenes for this.

This is very rusty but works: xxx.times { Graphics.update }

Mmmm, Actually the ring-menus are just icons displayed in a window_selectable with changed values to show the disposition of the options., or even easier a window with icons in their position, each time you press the left-right button a flag will change and will indicate that the icon must be on full color for example, and all the others in black and white. To put a custom sprite instead of windowskin for each window, in the initialize method of the window (because this only need to be drawn once), then we have 2 options: - Use of Sprites into viewports, use this when the window is used within the scene and no other scenes. (this won't work with gold for example), this doesn't mean this method won't work, but requires more work, adjust the parameters, the dispose of the sprite etc. object = Sprite.new object.bitmap = Cache.picture('xxx') - Use Bitmaps, the best option, we just need to create the sprite within the window, the only problem with this method is the size of the window, we need to make it greater than the sprite, since the window size isn't the total size to draw sprites, also we need to adjust the coordinates: bitmap = Cache.picture('xxxx') contents.blt(x, y, bitmap, bitmap.rect) As i said, the window way is better to use it only in windows that pop up in a scene, and not in static scenes.

This is probably a noob question, but I always thought module methods were done like: def self.someMethod Not with parentheses. Or has this changed? Aps no , I put the self in parentheses because they are optional and it will depend in the use that you give to the method, for example: 1) Use Self, when you will call the methods from the module itself: module MyModule def self.method_1 do something end end And we call it like: MyModule.method_1 Also, when we call these methods within the module like: module MyModule def self.method_1 do something end def self.method_2 xxx = method_1 xxxx.do something end ----- We don't use the SELF, when the method will be used in an external class that has been obtained inheritance from that module (mixin), for example: module MyModule def method_1 do something end end class MyClass include MyModule def some_class_method method_1 end end ----- Well, at least those are the reasons I know when to use the self or not, it's like transforming a module into a class to use the methods within with no problems.

You don't need to create a new module name, you add new methods to that module just adding it like: module Battlemanager def (self)old_method blah end end module BattleManager def (self)old_method overwrite end def (self)new_method new method thing end end By this, if you need to overwrite an existing method, just use the same method name as usual, if you need to add new ones, add new as usual, and also you can alias a module method, create variables inside that can be read.

Nice for an object recolector or something that deal with points. The only thing that you need to improve is the annoying use of Global variables, they're completely unnecessary, you can easily set this to game_system as instance variables. ---------------------------- Another thing, not my style, but I've seen a lot of scripters that use that way, but creating a module, for example with your name isn't neccessary if you won't add methods, constants or even a piece of code, if you add this to identify your script simply create a module with your name as prefix. --- But as I said, nice.

Can't say I honestly understand what you mean... I just need a script that will force launch the game in full screen at startup. BFG requires this to be in your game before you can commercially release your game on their site. That's the code for, just create a new script above main (and below all the other scripts). and Paste that code, then your game will run in fullscreen. Now if you want this to happen only in the player, just wrap the code between: unless $TEST end