RMVX Ace Organization

This Board is intended for any and all discussion, scripts, resources, etc... relating to RMVX Ace. This Board is only temporary. Once the program is officially released and we decide on a good way to integrate RMVX Ace content into the rest of the forum, that will be created and all the threads in this board moved to the appropriate places.

Until then, feel free to make threads relating to any aspect of RMVX Ace in this Board.

As for this thread, if you have any suggestions on how best to organize the new content into the forum, I invite your comments. Do not be afraid to make suggestions that would significantly alter the current organizational framework.

The easiest way might be to simply add an RMVX Ace Projects subforum to Projects; add an RMVX Ace Event Systems subforum to Tutorials; add an RMVX Ace Troubleshooting subforum to Technical Support; add an RMVX Ace Scripts subforum to Scripts; and change the name of RMVX Resources to RMVX + Ace Resources.

The Resources could be joined since, with a few exceptions, they are almost identical.

Please comment, and know that any suggestions will be taken seriously.

I think one thing on most people's minds is whether VX scripts would work on Ace. If that is the case, then maybe we should have a sort of list that indicates compatibility with Ace.

Also, I know we can't post external scripters' works, but Yanfly is pretty active with Ace right now and I see no reason for not having a list with each of Yanfly's script that links to his/her webpage where the script's article is. They're just links and it would be helpful for RMRK regulars to easily be aware of the scripts already developed to help reduce n00b requests and reduce unnecessary threads.
http://yanflychannel.wordpress.com/

For the resources section, we must remember that a Tileset Editor has returned in Ace and Battlebacks have returned but with 2 images per Battleback. So the subsections should be prepared for that if it is not already so.

That's all I can think up for now.

Trial: http://www.famitsu.com/freegame/trial/vxace_trial.html
Translation: http://rpgmakervxace.com/downloads/viewcategory/3-translation-patches

There is very little disappointment with Ace, compared to how we felt when VX was released.

They wont. its been stated that everything, like maps, sprites, images, music will work but not the scripts

The problem isn't that scripts will not work outright - it's the same language - but rather classes and method names may have changed resulting in some errors. Scripts may not be directly transferable, but with some fixes they would work just fine. Some scripts will probably transfer as is too; those which do not link themselves to the default engine scripts, for example, should work all right.

What is not usable is a game project developed in VX to be directly opened in VXA. It would require starting the project from scratch in terms of content developed as the tools in VXA differ greatly from VX.

Could maps be brought over?

No, though parallax maps certainly could be with very little effort.

Otherwise, the Data structure for maps has been significantly altered.

angry face. Good thing i do all my maps with parallaxing now

Outch for the scripts -_-

modern algebra, do you think you will adapte the ATS to Ace ?

Actually maps can be brought over. Just import over the tiles used, then 'create' a new chipset using them in the database and use it for the imported map. The issue that were thought to be a problem with porting maps was the actual mapping setup but as you can have Tiles A-E and it sets up the same way, with the same amount of tiles per chip...

Actually maps can be brought over. Just import over the tiles used, then 'create' a new chipset using them in the database and use it for the imported map. The issue that were thought to be a problem with porting maps was the actual mapping setup but as you can have Tiles A-E and it sets up the same way, with the same amount of tiles per chip...

He meant change map##.rvdata to map##.rvdata2 so he doesn't have to remake the whole map and events, that is tedious on the idea of moving a project. And not you can't do it on that way. Only remaking is valid.

Well, since no one has made any suggestions so far, here is what I am currently thinking. Please give me feedback on what you think would work and what is just a terrible idea:

• For the Projects Board, retire the system of separate boards for each maker. The reason I would like to retire the old system of separate boards is because I don't think it is functionally useful. Ostensibly, the purpose for it was because most projects that aren't complete wouldn't be distributed without the RTP, so people would only look for projects in makers they own and use. Functionally, I think what it has done is isolate people using older or obscure makers from the rest of the community and has driven away talented makers using those programs. I think that's bad, and besides, a good project is a good project whatever maker it is being created in - I see no reason to shield people from looking at and commenting on projects simply because they are not made in the maker of their choice.
  
  Instead, the Projects board would be set up as follows:
  
  
  • Projects
    • Substantial Projects
    • New Projects
    • Abandoned Projects
    • Reviews
    • Recruitment
  
  Substantial Projects would replace RMVX Projects, RMXP Projects, RM2k/3 Projects, and Other Maker Projects, as well as any new RMVX Ace Projects. Essentially, any project that has substantial content such as a demo will be placed in this board, regardless of what maker. Tags will be enforced.
  
  The rest of the boards would be the same as they are now.
  
  
• For Tutorials, I think all we should do is add an RMVXA Event Systems Board. Unlike Projects, the separate boards make sense here since event systems need to be plug and play or at least able to be copied - since every maker has a different set of event commands, it is best to separate them.
  
  
  • Tutorials
    • Tutorials Database
    • RMVXA Event Systems
    • RMVX Event Systems
    • RMXP Event Systems
  
  
• For Resources, I have thought about potentially removing the maker-by-maker system, but I think it would be a bad idea. The problem with the maker-by-maker system is that there is a lot of overlap, expecially between makers released with scripting. For instance, maybe the only maker with fogs might be RMXP, so it makes sense to put those graphics there, but that does not respond to the fact that fogs were reintroduced in RMVX through scripts, so they are useful to RMVX users. At the same time, we can't really put all fogs in the Multiplatform board, since technically they aren't multiplatform.
  
  There is a universality to some resources that simply isn't well recognized in the maker-by-maker organizational scheme, and it makes the scheme hard to thoroughly navigate. So, I was toying with the idea of replacing the maker-by-maker subforums with resource type subforums. So it would be something like:
  
  
  • Resources
    • Fogs
    • Windowskins
    • Tilesets
    • etc.
  
  I think it would be a bad idea though, since a lot of submissions don't limit themselves to just one type of resource. Kill bunnies. Often, it will be a number of different types, like facesets and charactersets for the same character. Additionally, some of the makers really are very different, as in almost no RM2k/3 resources would work in any of the new makers.
  
  So, subject to any better ideas (which I invite, as I am still unhappy with maker-by-maker), I think I will keep the current system. Since RMVX Ace Resources are almost all very similar to RMVX resources, I will just repurpose the current RMVX Resources Board to also be for Ace Resources. Ie. it will look like this:
  
  
  • Resources
    • Multiplatform Resource Database
    • RMVX/A Resource Database
    • RMXP Resource Database
    • RM2k/3 Resource Database
  
  
• For Scripts, I was thinking of retiring the separate makers organization for requests, though retaining it for the databases. Obviously, most scripts only work in the maker for which they were made, so having separate Databases is the only reasonable thing to do. But Requests boards serve a dual function - obviously the person making a request wants it for a specific maker, but at the same time, a request for a script in one maker could easily inspire a scripter to write a script for a different maker that performs the same function, if the scripter thinks it's a good idea. In that sense, requests for different makers can be a source of inspiration, so it is not unreasonable to locate all requests in the same board. Additionally, any scripter can, potentially, write a script for any maker, even if most scripters have a preference. So I think it makes sense to have a combined Requests Board and simply enforce tagging. Separate databases would be retained. The root board would still be the spot for Script Support in any maker. The organization would look like:
  
  
  • Scripts
    
    • RMVXA Scripts Database
    • RMVX Scripts Database
    • RMXP Scripts Database
    • Script Requests
  
  
• For Technical Support, I am thinking of retiring all subforums and renaming it to something like Software Support. While separate maker boards makes a lot of sense, none of them get a lot of activity and so I don't think it would harm navigability to retire the subforums. The activity they do get is generally misplaced script support. Eliminating all of that should make it more apparent that it is for errors with the programs themselves. As a result, all that it would be is the root forum, and all topics in the subforums would be moved into the root board. Ie.
  
  
  • Software Support
  
  

I like this layout but the resources one IS a huge problem. But technically you can change resolution in VX(Ace) so maybe let's just have a 640 and 544 folder for those resources that need it? For example, Panoramas, Fogs (can be used in VX(ace) with a script), etc.

I can't think straight but I'll provide more input wwhen I finally fall asleep ;v;)/

Yeah, the layout seems really well planned out, but the overlap in resources is a big issue. I was thinking of making different categories that aren't necessarily the ones that Enterbrain has presented to us. For example, instead of seperating CharaSets and Facesets, we could merge the two into one subcategory. Similarly, we could pile up all the Fogs and Tilesets into a Map Utilities subcategory, and things like Windowskins and Title Screens into System Utilities subcategory. Finally, there would be a subcategory for "compilations". If someone wants to post all the work they've done, and not just individual or sets of CharaSets, it would probably go there. Audio would probably just be one massive subcategory, and maybe we could make one for Movies. Obviously, tagging for what maker the resources was made for would be important.

In other words, my ultimate ideal structure for resources would be:

• Resources
• Compilations
• Graphical
• Battle Graphics
• Character Graphics
• Mapping Utilities
• System Utilities
• Audio
• Movies

And is there any particular reason why scripts are kept seperate of resources? I've always thought of them as being pretty much the same.

And is there any particular reason why scripts are kept seperate of resources? I've always thought of them as being pretty much the same.

My guess is that whilst scripts are technically resources they do contribute a rather large proportion of the resources, especially considering there are 3 platforms for which scripts can be made for.

Whilst I get that most of the threads in the section are probably related to requests/general info there are almost 1000 more topics than resources and nearly 6000 posts more in Scripts than in the Resources section.

And whilst sub forums would be created for the scripts, it would become a little overloaded and cluttered with sub forums and (potentially) threads being made in the wrong areas - which is always a common problem of forums especially for new members, who may also not have very strong English language skills, not knowing exactly where things go.

That would be my reasoning for keeping Scripts separate to Resources.

On another note, I think Cozzie might have a good idea with splitting things into those categories. You'd have to enforce tagging, though, and/or maybe set up a database thread like you have with the scripts - I know this would take up more of your time to maintain, though - so that resources can be found after they leave the first 2 or 3 pages (we could suggest making use of the search function but how many people really think/know to use that).

Alright, well I am inclined to go with cozzie's suggestion for Resources and otherwise do what I suggested for all the rest. I will get on it soon.