Support another extension for scripts

[Sneaky]

Allowing rAthena SVN to support another extension for scripts.

example (.ras, stands for .RAthenaScript):

myscript.ras

scripts_custom.conf

npc: npc/custom/myscript.ras

(12:07:27 PM) Slim: Do you think it would be a good idea to also support another extension for scripts?

(12:07:45 PM) Slim: lets say .ras

(12:07:47 PM) Jguy: What do you mean, instead of .txt?

(12:07:53 PM) Slim: yeah

(12:08:04 PM) Slim: to build a syntax for editors

(12:08:14 PM) Slim: i mean syntax coloring

(12:08:25 PM) Jguy: Suggest it, I'd say, sounds like a decent idea

(12:08:26 PM) Slim: when you build syntax coloring it also applies to all .txt files xd

And not just for syntax coloring but it would be nice for rAthena to have its own extension, still supporting .txt files though.

[KeiKun]

i like the idea of .ras

and still supporting .txt as well (Of course)

[Ind]

I'm against, I'll post a quote from irc.

[17:13:57] xazax: one of our goals was to provide as smooth switch from eA to rA as possible
[17:16:53] xazax: and right now I can check the complete version history if each script file, not sure, if it will be still accessible after renaming
[17:19:10] Ind: i agree with xazax 100%. this is a sorta cosmetic change with a implied inconvenience

we have more important things to focus at, in my opinion.

[Brian]

The script engine will read ANY filename, extension does not matter.

Just define the npc script in a /npc/scripts_*****.conf file

npc: npc/custom/my_npc.txt
npc: npc/custom/my_other_npc.c
npc: npc/custom/my_third_npc.ras
npc: npc/custom/filename_with_no_extension

I vote to keep .txt as the extension for RAthena-provided scripts.

[Protimus]

I not see great need for such change.

But the idea is good, I think we should archive it and work in future. We can do a modification of the script system in general, as the commands in script.c.

[mirabell]

i still dont get why this would need coding.

as of now EA svn supports just about any custom extension.

Usually when my scripter make script for us he names the files

*.EAS and they work fine.

I also have script files with *.php and *.rof from my previous server. all you have to do is make sure you spell it properly with the extension in the conf file.

Edited December 30, 2011 by mirabell

[Jonne]

i still dont get why this would need coding.

as of now EA svn supports just about any custom extension.

Usually when my scripter make script for us he names the files

*.EAS and they work fine.

I also have script files with *.php and *.rof from my previous server. all you have to do is make sure you spell it properly with the extension in the conf file.

True. When taking a closer look:

// read whole file to buffer
fp = fopen(filepath, "rb");
if( fp == NULL )
{
ShowError("npc_parsesrcfile: File not found '%s'.n", filepath);
return;
}

But maybe they want it as standard. So in future all script files will have this extension and everything that comes with it.

Edited December 30, 2011 by Jonne

[Realusion]

tl;dr: In my opinion a custom file extension is not needed at this point.

In general, a custom file extension would make sure that a certain file type gets opened with the appropriate program. In this case, if we had an eAthena script editor that supports .txt files, said script editor would be in conflict with the standard windows notepad, because both of them want to open the .txt file. A custom file extension could be associated with the eAthena script editor. However, quite frankly, this is completely unnecessary.

Another aspect why custom file extensions are created is that only the appropriate program can read the file (GRF, for example), which is simply not needed in this case.

An effect which could actually be of use would be a complete revamp of the entire scripting engine to make parsing faster/better and to implement some features that I, personally, and maybe some other people have been missing. However, at this point there are far more important things to focus on.

[Panallox]

Well, I suppose first you can define the extensions simply in the import configuration files as Brian said. It will still process the file since it's reading the NPC as a textual file. But secondly, if there is a restriction in the source somewhere that composites .txt files then I imagine it would take little to no effort to add an additional extension. I don't see this actually being in the source though, so as far as I'm concerned I don't even see why/how this would be done other than renaming all extensions in the folders .ext (new extension) which seems moderately redundant.

Although if someone wants to create a patch for this then by all means, create one and throw it into the script releases forum

[Sneaky]

Well, I suppose first you can define the extensions simply in the import configuration files as Brian said. It will still process the file since it's reading the NPC as a textual file. But secondly, if there is a restriction in the source somewhere that composites .txt files then I imagine it would take little to no effort to add an additional extension. I don't see this actually being in the source though, so as far as I'm concerned I don't even see why/how this would be done other than renaming all extensions in the folders .ext (new extension) which seems moderately redundant.

Although if someone wants to create a patch for this then by all means, create one and throw it into the script releases forum

I think would be neat. I've always disliked that we just used .txt files...I want to see our own extension someday

I share the same opinion.

[mrjnumber1]

Should this be agreed on, all new scripts created should use the new extension, with legacy scripts remaining in .txt imo. I'm not sure how the versioning screws up upon renaming in subversion so hopefully that all goes well in the event old scripts are updated and renamed.

[sketchyphoenix]

The idea is fine, just we don't really have a need for it either.

[Omnipotent]

'Support another extension for scripts'

It is already supported.

[Ehcloprom]

This is a waste of time instead of changing extentions dev's could be working on bugs and or adding new features.

It's not a bad idea though but it has no real advantage at the moment

Edited February 6, 2012 by Obliterate

[Hayate Yoshida]

It's somehwat a good idea except there's little advantage. The only advantage I would have is if I was using Notepad++ for editing scripts cause with the syntax highlighting, it kinda messes up normal txt files xD at least for reading anyways. I use eNPC editor now though so it really don't matter to me. I just rename em myself with a bulk renamer and then replace .txt with my extension in the conf, very quick and easy.

[Magnetix]

This is a waste of time instead of changing extentions dev's could be working on bugs and or adding new features.

It's not a bad idea though but it has no real advantage at the moment

My opinion as well. But if someone has lots of spare time, Project forums is the place to be..

[Ehcloprom]

It's somehwat a good idea except there's little advantage. The only advantage I would have is if I was using Notepad++ for editing scripts cause with the syntax highlighting, it kinda messes up normal txt files xD at least for reading anyways. I use eNPC editor now though so it really don't matter to me. I just rename em myself with a bulk renamer and then replace .txt with my extension in the conf, very quick and easy.

I like eNPC but it's still a bit buggy I'm not sure if it's me but if you try to backspace from the top the file kinda screws up... I mainly like the color chooser, Header generator and being able to see your Menus in action eNPC deffinity needs work but it has great potential.

Yeah that is annoying if you using notepad++ I use a black background and with .txts the words are highlited all white is it's like impossible to read...

@topic

I definitly think an rascript extention should be made in the FUTURE but at the moment rA is behind / out-of-date and should catch up more first (obviously this takes time) I wish I could help but atm I just starting learning C My goal is to be a Developer in the future.

Anyways I'm just so happy to see the ragnarok emulation didn't die it made me kinda sad seeing eA so "dead" but Jman being back is just great.

@off topic

eA and rA seriously need to merge Paradox should just forward eA to rA there's like one active developer there...

Bleh I wish peple could be more rational...

Edited February 9, 2012 by Obliterate

[Euphy]

It seems the general consensus is that this is unnecessary, and I agree. Moving to "rejected".