The Ashita Project goes live!

[Dazusu]

The whole Windower vs. Ashita thing is redundant. There's been nothing major come from Windower since Nitsuj took over the project, and Kohan mentions (paraphrasing) a lack of competition leads to a dead project. Whether Ashita successes Windower - or causes the Windower team to do something new and innovative; the scenario creates a win win situation for the users.

[atom0s]

Is there an extension similar to StatusTimer?

I would love it if there was something similar to IME (that let's you type in Japanese) that windower uses.

Feel free to make requests over on our forums. There are a few people that are working on other plugins that are not part of the core team and are possibly looking to take on new projects. At this time there is no IME or StatusTimer equivalent for Ashita as it was not requested before.

[Uselessaccount2]

Feel free to make requests over on our forums. There are a few people that are working on other plugins that are not part of the core team and are possibly looking to take on new projects. At this time there is no IME or StatusTimer equivalent for Ashita as it was not requested before.

Will do. One last question here: where's do I make the requests? I was looking and couldn't find it.

[Hyshio]

Will do. One last question here: where's do I make the requests? I was looking and couldn't find it.

There isnt an actual request section on the forums just yet but you can post them here until one is made.

[Uselessaccount2]

There isnt an actual request section on the forums just yet but you can post them here until one is made.

Thank you.

[nasoo]

hihi, not sure whether luacast is still in developing phase or has already been released. I was just wondering is there any sample code around for detection of magic, doing some gear swap and etc. Hoping to get a feel of how our future spellcast replacement might be.

[atom0s]

hihi, not sure whether luacast is still in developing phase or has already been released. I was just wondering is there any sample code around for detection of magic, doing some gear swap and etc. Hoping to get a feel of how our future spellcast replacement might be.

At the moment it is beta and has no already implemented ways to detect spells / magic / abilities and such.

[Mojo]

http://www.ffevo.net/topic/2897-modi...shita-updater/

Here is an even simpler way to install and update Ashita for those who want an easy way to do this.

[Sechs]

Anything in particular for screenshots? Ashita's base core just runs the game windowed, taking a picture of that is kind of pointless.

It's a bit too early atm, maybe. Once a few more addons are out and fully working, a screenshot of a typical "UI" of FFXI running under Ashita with useful and user-recognizable addons running would be awesome.

Personally I look with interest at the possible future developments of this project. It seems to me it will be much easier to develop reliable plugins with deeper connections/interaction with the game.
Hope there will be more stuff to autoconvert the TXT files into the new format, and something to adapt/import Spellcast's XMLs. The idea of starting my macros and XMLs from scratch gives me a headache.


Small question about Ashita TXT macros, it's been said you use commands like what you would use inside the game, and that's ok, but what about the commands that aren't available in-game? Windower macros allowed for windower scripting. You could set conditionals, loops, and open TXT macros from within a txt macro. Last but not least the wait command syntax was different.
So it's not all about the "input " at the beginning of the line, and it's not all about the amount of commands you can use within the game.

[Spagnutty]

Once it's fully baked (or probably even now) LuaCast could do all of those basic programming techniques such as conditionals, loops, etc. Lua is such a simple and clean language that I don't really see the need for establishing a special syntax for txt faux-programming.

Ashita devs may have other information to add.

[Kohan]

Once it's fully baked (or probably even now) LuaCast could do all of those basic programming techniques such as conditionals, loops, etc. Lua is such a simple and clean language that I don't really see the need for establishing a special syntax for txt faux-programming.

I agree with this. To those who aren't familiar with it, Lua can also send commands directly to the shell (i.e., the DOS command line), meaning that your options are virtually limitless. A programmer will tell you that Lua is ultimately limited, but in terms of what it can do for FFXI in the hands of an imaginative scripter, it is virtually limitless.

[Yugl]

What exactly is missing that makes LuaCast incomplete?

[Taim Meich]

I guess that (and this is coming from someone with only scientific programming knowledge) the implementation of different in-game conditions as variables it can recognize is one of the missing things. Because, coming from my limited perspective, I don't know a way to recognize such conditions if they aren't previously implemented. For example, if I want to equip something depending if I have the Berserk status on, I'd have to write something like (and yes, I know this isn't Lua syntax):

if (Berserk .eq. TRUE) then
  /equip body blahblah
  /equip hands yaddayadda
end if

If LuaCast doesn't recognize the Berserk variable, it's going to be very complicated to work with it as a SpellCast replacement.


There are probebly lots of other things missing, but that's the first thing that occured to me.

[Spekkio]

Given that Luacast is being written as an interface layer between the game and a programming space, components such as status will likely be broken out for you to access. Again, not lua (I'm not familiar with it yet) just some pseudocode I'd guess it will be something like the following:

buffs = getbuffs();
if(buffs.berserk=TRUE){
/equip thingies
}

In the above I'm presuming there's a "getbuffs()" function that retrieves an object containing the presence or lack of various buffs on the player. Once we have that object, we can ask it if say the player has the berserk buff active and make decisions based on it. If you have any experience with Ruby, Python, or even many of the .net expressions like powershell you should find this to be fairly quick to pick up assuming it's implemented well and based on the team I've no doubt it will be.

If I might ask a curiosity question: why did the developers choose to make the core closed source? This is not an attack or an admonishment, I'm just interested in what the thought process was. There are certainly plenty of good reasons from making it harder to detect by SE to preventing it from being used in particular ways say by gold farming houses, but I'm curious what your reasons were.

[Motenten]

From my poking around, yeah, there's a huge interface layer that's missing that luacast would need before it's even remotely usable.


For example, max HP would (currently) be:

AshitaCore:GetDataModule():GetPlayer().Player.HPMa x

But current HP and HPP would be:

AshitaCore:GetDataModule():GetParty().Member[1].CurrentHP
AshitaCore:GetDataModule():GetParty().Member[1].CurrentHPP


So, different data from different source structures, and a long complicated format that's not practical for general use at all. Need to set up a simplified wrapper to allow access to all the relevant/important bits.


Various bits of information need bitmasking. For example, a current combat skill would be:

AshitaCore:GetDataModule():GetPlayer().Player.Comb atSkills.Parrying & 0x7fff


Main job would be:

AshitaCore:GetDataModule():GetPlayer().Player.Main Job

but it returns a numeric value, and you'd compare it with an enum value (eg: 20 == JOBTYPE.JOB_SCH).


Buffs are an array of IDs:

AshitaCore:GetDataModule():GetPlayer().Player.Buff s (array of 32 values)

which are completely undefined, as far as I can tell, so that would need to be set up.


Likewise, I can't find any references to current world state (day, time, moon phase, weather, area, etc) at all (although there are event handlers for zoning in and out, and thus zone IDs). And that's all before you even get to the point of equipping gear, or timing precast and midcast stuff, etc, or, at the front end, parsing the incoming command (including handling aliases or shortened player names).


So yeah, lots of work needed.

[atom0s]

It's a bit too early atm, maybe. Once a few more addons are out and fully working, a screenshot of a typical "UI" of FFXI running under Ashita with useful and user-recognizable addons running would be awesome.

Personally I look with interest at the possible future developments of this project. It seems to me it will be much easier to develop reliable plugins with deeper connections/interaction with the game.
Hope there will be more stuff to autoconvert the TXT files into the new format, and something to adapt/import Spellcast's XMLs. The idea of starting my macros and XMLs from scratch gives me a headache.


Small question about Ashita TXT macros, it's been said you use commands like what you would use inside the game, and that's ok, but what about the commands that aren't available in-game? Windower macros allowed for windower scripting. You could set conditionals, loops, and open TXT macros from within a txt macro. Last but not least the wait command syntax was different.
So it's not all about the "input " at the beginning of the line, and it's not all about the amount of commands you can use within the game.

A typical screenshot running with Ashita doesn't really change much. The default loaded plugin list for our project only includes one visual change which is a timestamp to the chat log. It's hard to really gather pictures of things that are more under the hood work than up front. But I do understand people want to see pics of things in action. I can take some pictures soon but they're going to be fairly standard FFXI pictures since there isn't really much to showcase visually.

As for converting text files, just remove any 'input' words from your current gear swap macros if you use them.
Ashita doesn't need you to enter 'input' to do commands. Instead it's just direct input from the scripts as if you were typing them yourself.
Other features to the scripting weren't added as we didn't see much use of them. Also people didn't request them to be added before so it wasn't worth adding. With Lua and C# extensions now, there is almost no need to add them at all now. But if it becomes a popular request we can certainly bump it up on the todo list.

For spellcast XML files, we're still not anywhere close to having LuaCast done and ready so there is no set idea behind how the extension will work. If it comes to a point were there will be enough structure to build a converter we will, but as it stands now there is no way to tell what will be the end result of the extension. But as most are pointing out, Lua is an in-depth scripting language so they will be very different from each other. (Lua vs XML that is.)

Once it's fully baked (or probably even now) LuaCast could do all of those basic programming techniques such as conditionals, loops, etc. Lua is such a simple and clean language that I don't really see the need for establishing a special syntax for txt faux-programming.

Ashita devs may have other information to add.

We feel the same way, but we do want to allow people that option to use LuaCast or not. So if it means adding some minor scripting abilities to the script files themselves, we can look into it.

What exactly is missing that makes LuaCast incomplete?

As it stands now, LuaCast lacks the ability to read information such as:
- Current weather.
- Casting a spell / got interrupted / etc.
- And such.

We plan to add this and some other features to allow users to even read from memory themselves to easy read offsets that they want to use personally.
You can do a handful so far already with whats exposed just not everything that people want yet.

[atom0s]

From my poking around, yeah, there's a huge interface layer that's missing that luacast would need before it's even remotely usable.


For example, max HP would (currently) be:

AshitaCore:GetDataModule():GetPlayer().Player.HPMa x

But current HP and HPP would be:

AshitaCore:GetDataModule():GetParty().Member[1].CurrentHP
AshitaCore:GetDataModule():GetParty().Member[1].CurrentHPP


So, different data from different source structures, and a long complicated format that's not practical for general use at all. Need to set up a simplified wrapper to allow access to all the relevant/important bits.


Various bits of information need bitmasking. For example, a current combat skill would be:

AshitaCore:GetDataModule():GetPlayer().Player.Comb atSkills.Parrying & 0x7fff


Main job would be:

AshitaCore:GetDataModule():GetPlayer().Player.Main Job

but it returns a numeric value, and you'd compare it with an enum value (eg: 20 == JOBTYPE.JOB_SCH).


Buffs are an array of IDs:

AshitaCore:GetDataModule():GetPlayer().Player.Buff s (array of 32 values)

which are completely undefined, as far as I can tell, so that would need to be set up.


Likewise, I can't find any references to current world state (day, time, moon phase, weather, area, etc) at all (although there are event handlers for zoning in and out, and thus zone IDs). And that's all before you even get to the point of equipping gear, or timing precast and midcast stuff, etc, or, at the front end, parsing the incoming command (including handling aliases or shortened player names).


So yeah, lots of work needed.

LuaCast relies on the current structures from Ashitas SDK. Squeezing them into their own structures makes it a bit more difficult to maintain the extension as then there are two separate lists of structures that need to be adjusted each time an update happens.

Once LuaCast is more stable and tested, we can move int an opensource route for the extension to allow others help keep it maintained as well as contribute ideas to it if that is something that interests other developers. I'm more than willing to share the source to the extensions I wrote for Ashita. But LuaCast is still a beta plugin and as it stands now, it relies heavily on LuaBind to handle the Lua to C++ bridge between the languages and our SDK.

Some of the things that are exposed to Lua are in a numeric format, as you said. This is because it's outputting the raw information from the games memory. Once things are more settled, we will have enumerations in place to handle comparing to a user-friendly value such as things like:
if (player.MainJob == Jobs.PLD) then
-- do stuff here..
end

But for the time being it is not the highest on our list of things to work on.
The core of Ashita is our main focus, we want more community interaction with the extensions part of the project.

The buffs table is defined, but its output as a Lua table. So you'd read it like this:

local player = AshitaCore:GetDataModule():GetPlayer().Player;
print( 'Buff Count: ' .. tostring( #player.Buffs ) );
for k,v in pairs( player.Buffs ) do
    print( string.format( 'Buff %d: %d', k, tohex( v ) ) );
end

Invalid buffs will have a value of 65535 (-1) due to their data type.

Once we have more time to focus on LuaCast we can fix up some of the issues and get a more feature filled beta released.

[Tymon]

This is an impossible request and I know it won't be fulfilled but it would be awesome if this ended up being compatible with wine on Linux distros.

Pretty much the only reason I use Windows right now is because of Windower. That and FFXI breaking on newer versions of the ubuntu kernels, but yeah. I'd love to see it.

[atom0s]

This is an impossible request and I know it won't be fulfilled but it would be awesome if this ended up being compatible with wine on Linux distros.

Pretty much the only reason I use Windows right now is because of Windower. That and FFXI breaking on newer versions of the ubuntu kernels, but yeah. I'd love to see it.

At the moment, the project is too far developed to fill this request. A lot of what is being used inside of Ashita is Windows specific so it is hard to undo those pieces without breaking big chunks of the project. I would assume that it could run under Wine assuming they do not block anything that Ashita does and it allows the hooking that it does.

Personally, I'm not a Linux user at all so development on the scale and depth that Ashita goes into is not something I've ever done either.

[Tymon]

At the moment, the project is too far developed to fill this request. A lot of what is being used inside of Ashita is Windows specific so it is hard to undo those pieces without breaking big chunks of the project. I would assume that it could run under Wine assuming they do not block anything that Ashita does and it allows the hooking that it does.

Personally, I'm not a Linux user at all so development on the scale and depth that Ashita goes into is not something I've ever done either.

Kind of a late reply but whatever..

Windower doesn't work in Wine because Wine freaks out for this reason:

Windower.exe runs -> (Wine freaks out here) Windower.exe opens POL.exe -> POL starts

I don't know what process Ashita uses to run FFXI but if it was done differently than Windower then it would probably work. If not, then c'est la vie