Windower: The Future of Spellcast (3.0 Discussion)

[Septimus]

Actually, I have a fair amount of experience coding ActionScript and PHP and am familiar with XML. I also have a fair amount of experience explaining how computers work to people who don't understand computers. There is what I like to refer to as the "fuck-it factor", when the actual or perceived complexity of an operation surpasses any possible benefits that operation should it be successful and people just say "fuck it". This is the problem with Spellcast as it stands now, a lot of people look at the XML and say "fuck it"; a system that either gets rid of the XML or writes it for people would change the "fuck-it value" and would cause more people to use it.

[Soho]

Option 3 sounds great... unless it's going to take a year to put together.

I'd rather have a decent update within the next few months than wait on something that will take forever.

[noodles355]

The process of setting up different conditions for different sub jobs doesn't exactly sound simple and easy to use.

Make multiple equipment groups, with different HP down sets relevant for each subjob. Upon changing jobs, type //sc group ####.

Efficient? Not perticularly. Simple? Fuck yes. Can do it better with variables, but that's just to show how easy it can be.

[Sekundes]

Faster, better stronger? I'm very use to XML but if it runs faster and lags less on complicated operations then I'm all for it. I need to learn a new programming language anyway!

Option 3!

[cdgreg]

Option 3 sounds great... unless it's going to take a year to put together.

I'd rather have a decent update within the next few months than wait on something that will take forever.

I'm the career skeptic. I'd love to see 2 or 3, but both are pointless if they will never actually get done.

[jurjur]

#3

[IronPandemonium]

#3, by leaps and bounds

[Shirai]

I'm also joining the #3 crowd, but I do share the following opinion.

Option 3 sounds great... unless it's going to take a year to put together.

I'd rather have a decent update within the next few months than wait on something that will take forever.

[Ithorien]

I would totally absolutely love option 3, with the hugest boner if there was a GUI for it >.>

Biggest reason why I use others' XMLs is because it's still all pretty chinese to me. Simplification would definitely help.

[Raineer]

#2 or #3. Rules separate from gearsets sounds nice. A ground-up integration sounds nicer. There should be a much simpler way to capture the logical decision tree than XML.

Wouldn't use a GUI necessarily but I can see how it would help some needing remedial setups, sort of a way to slap your gear into canned templates.

edit: to the post above me omg i'm your sig. I remember posting that so many years ago before my break to some guy fishing up titans at level 20.

[beba]

#3 sounds awesome but how adaptable would it be? I like the idea that #2 gives more room to add new things. I just know from the systems i use at work, the old one gives alot of freedom to edit and the newer one is designed to make things simple but if you wanna do something outside of it's template you can't.

[Aikar]

Just to clarify on what I want to do, is create a JavaScript system (a language that is really event/action oriented) and build spellcast on top of that. You know how fast Chromes javascript is? Thats the speed of the system I want to do it in...

here is a rough idea on something it could be like (no way set in stone, and you could even really do it in your own custom ways with the power and flexibility of JS)

https://gist.github.com/1097828

And with the ideas I want to do, it would move nearly all of SC's code to a generalized platform, and other languages could even be extended into it and write your rules logic in the other languages.

and best of yet, alot of this logic/extension would now become open source.

As for "easier to learn", SC in its current state is an invented language that has no documentation outside of this site.
Where as other languages (namely JS is my main goal as i'm heavily investing into node.js) are built upon standards and maintained by people like google... easy to find resources on learning, and tons of code out on the net to reuse.

Combined with real syntax validators etc, its def a win over the current XML system.

[Aikar]

#3 sounds awesome but how adaptable would it be? I like the idea that #2 gives more room to add new things. I just know from the systems i use at work, the old one gives alot of freedom to edit and the newer one is designed to make things simple but if you wanna do something outside of it's template you can't.

Actually my desire is to create a general "Addon" platform, that would hopefully slowly replace the compiled .dll plugins, that allows even 3rd party devs to have a better tie to windower than windower helper (and access event data like AutoExec)

So with this you could then put say a Python or LUA interpreter middleware, and then write modules in that the exact same way in that language. The only difference is id have a middleware layer for the JS to do things "easier", which someone could very well maintain a middleware layer for other languages too.

Then SC would simply be built under the Node.JS layer, in which then SC will simply be utility methods for writing code in a cleaner/easier way for in game events.

You could theoretically not even load spellcast, and write code that still does all the same logic, just parsing out all the data and sending commands, would be really... raw...
the middleware and SC addon itself would simplify that.

I want to "modernize" things, and put more control to the users, but at the same time keeping limits on exposure of power.

[Aikar]

I'm in favor of #3, but would it also be possible to have it so that old XMLs could still be ran by those who don't or aren't willing to upgrade to the new system? Also, if XMLs are kept could includes be changed to follow XML guidelines instead of spellcast ones so that data validators would work?

Ive had thoughts on keeping XML backwards compat intact, and for the most part it wouldnt be hard...

The hardest part is supporting advanced="" which is required... though I could just try to compile in that same library as a node module.

[noodles355]

As for "easier to learn", SC in its current state is an invented language that has no documentation outside of this site.
Where as other languages (namely JS is my main goal as i'm heavily investing into node.js) are built upon standards and maintained by people like google... easy to find resources on learning, and tons of code out on the net to reuse.

You say that as if it's a bad thing. It's easy to learn because every term it can possibly use are documented on the website. As for Java, some people go to university to learn Java.

It's kind of like being given a sheet of hiragana, wanting to romanize a purely hiragana paragraph, and comparing it to learning japanese. Sorta.

[Talrandir]

I want to "modernize" things, and put more control to the users, but at the same time keeping limits on exposure of power.

This sounds really exciting and makes a lot of sense. As a programmer, I'd love it!

For non-programmer users, though, I'm not sure if Spellcast will be easier. For just Spellcast itself, apart from any larger programmability initiative, I do kind of like the way the XML format is restricted/specialized to the gearset-calculating task at hand.

Either way, as long as GearCollector can still work with the files, I'll be more than happy. Thanks for all your work on the Windower and the plugins!

[Aikar]

This sounds really exciting and makes a lot of sense. As a programmer, I'd love it!

For non-programmer users, though, I'm not sure if Spellcast will be easier. For just Spellcast itself, apart from any larger programmability initiative, I do kind of like the way the XML format is restricted/specialized to the gearset-calculating task at hand.

Either way, as long as GearCollector can still work with the files, I'll be more than happy. Thanks for all your work on the Windower and the plugins!

Generating an XML or JSON dump of the resulting sets objects would be super trivial.

You say that as if it's a bad thing. It's easy to learn because every term it can possibly use are documented on the website. As for Java, some people go to university to learn Java.

It's kind of like being given a sheet of hiragana, wanting to romanize a purely hiragana paragraph, and comparing it to learning japanese. Sorta.

FFS I just typed a good response to that statement (in that I agree it does have its positives, but theres huge negatives too if the logic capabilities of SC was to ever extend which is what the people seem to want, the current simple state makes it easy to learn, but syntax requirements to support advanced logic capabilities would be confusing as all hell), but I hit the blue Reply button instead of Post quick reply and lost it

[noodles355]

Maybe if there was some means of writing basic spellcasts, like our current XMLs, and then importing/translating them into the new spellcast in whatever language would be best, whilst still offering the option to write it completely in the new language.

Like those HTML editing programs such as Frontpage, how they let you both type in pure HTML, or let you visually do stuff, converting what you do into HTML code. Of course, I'm not saying you should design a program to do this! Was just an example to show what I meant.

[Aureus]

There are advantages to the current spellcast implementation too. Being XML based makes it trivial for other plugins and applications to use spellcast files. If it were changed to a scripting languages, things like the gear collector plugin would be unable to exist.

[Aikar]

Like i said above, keeping the current XML format isnt hard.

Essentially upon load of rules, JS code will read the XML file, iterate over every code path, and convert it to equal javascript code/functions (it could be fully done w/o actually "generating" code and evaling it, but that is one option too), and those rules would be simply loaded into the rules array, then the JS rules like my example GIST shows would be loaded after it, could prolly even support multiple xmls like rules.import('foo.xml') too, same for sets.

It would take some effort to make it work, but its not far reached. the Advanced="" tag is the tricky part due to that being a special library SC uses