http://www.bluegartr.com/ragnshammer.jpg
Can't believe I almost let you get away with this.
http://www.bluegartr.com/ragnshammer.jpg
Can't believe I almost let you get away with this.
What about the functionality that Azaril was going to do with on-screen status of individual players? Like the list of things he claimed was possible on his blog. I would suggest that you do get someone on Spellcast and also highly, HIGHLY encourage them to create a proper UI for it. It's time Spellcast was made user friendly for people that do something besides code for a living.
Sorry if that doesn't make any sense, but I am sitting on the couch, stuffed and half way to a food/alcohol coma.
No mention of Distance, Silence, Clock, or Logger ;-;
Distance is a must for mages, Silence and Clock are nice just in a gereal sense, and Logger is really a must for everyone.
Though I wouldnt be surprized if distance, silence and logger are built in? I dont see them as being a huge effort to port over. Clock would also be pretty easy id imagine.
And yeah, Timestamp is needed as you were thinking, and thanks for including tickle in to the recast logic~
IME would be my other concern. But yeah, baby steps. Good work takes time.
Currently on my V4 Distance exists as a core function in the upper bar. So no worries about Distance.
It sounds like you have the right idea Nitsuj. If I have to I'll force myself to put my old scripts into lua scripts for macros. Living with 6 line macros for the past 3 months, I'll accept ANYTHING you put into v4.
Keep up the hard work.
There is no real way I could go to V4 without Spellcast.
LL I could do without, but it is damn nice to have.
Distance and clock are already in v4, I'll be making more robust features on them during the alpha. Silence and logger should be easy once I tackle the incomingtext stuff (chatmon and timestamp) and should be included.
Oh that stuff should be coming, but not until beta/release. I'm just talking about getting into alpha, which to me should be *close* to content complete (so majority of the plugins at basic functionality as it would be expected from windower) and completely usable for day to day playing.
Beta would be a lot more polished, some new bells and whistles added in, a lot of changes based on user input etc.
Then full on release would be, well, perfect. In an ideal world
But I'm not going to look much into cast timers and crazy UI stuff until the core functionality is in place, as that's much more important to me.
I finished fixing the internal command parser fixes last night so now complex aliases/binds work as they should. I'm waiting to hear from Azaril and I'll be posting a slightly updated binary. I really have no idea how old the one up for download is, so I'd like to get a new one up even if changes are minimal so I can have a better idea of time between updates.
Also, when the new update comes in the console has an "about" command so you can always check the version number and the build date to know if you're up to date on your alpha or not.
Yeah, as it stands the bar is going to run out of room. BUT the bar is sorta just a proof of concept. I imagine my personal bar would look something like: (customizable)
far left would show the LAST ability/spell used and a counter, when clicked on it it would extend down to show the recast window (just like the one we love with a few bells and whistles). Next to that would show target information (like infobar) but included distance and mob health (from tparty). Next to that I'd probably have my clock for PST and Tokyo Time.. .then next to that on the far right... well... that's a secret that I hope to be able to finish before the final release
Aliases work, as well as a "runscript" command which can run custom lua scripts. There may be functionality to run windower type scripts (just groups of windower console commands) but I honestly haven't looked into it yet. I'll take a look when I get to testing more scripts this weekend
As to IME, I'm really not sure. I haven't looked at that source yet. It's not super high on my priority list but I do recognize that the end product should have IME support. But with the use of auto-translate, I see things like recast and even spellcast more important for the project.
And also, I wouldn't build anything into the core that has any more than a 1% or 2% chance of breaking. If it's based on memory locations that change or something with an update it'll likely be a plugin or have very smart code that can detect the error and alert the user that an update needs to be run (v4 should have autoupdating to core and plugin's build into the launcher)
I was curious, since I've no clue how FFXI's code is run or how badly it is done in terms of what I'm asking, I figured perhaps you could enlighten me and some of my friends Nitsuj.
Is there any feasible way that windower could force particular use of the framebuffer in a graphics card? I may not be saying it right, but I was under the impression that this may be possible if SE didn't totally bork the coding on it so badly as to be nigh impossible. The game runs way too much on the CPU and hardly uses the graphics cards at all. I was thinking if windower could force the game into the framebuffer then we could have all sorts of effects to make the game better.
Obviously the most evident would be AA and AF but it may be theoretically possible to emulate DX9 and other effects wouldn't it? I mainly started to wonder about this because of windower being able to render graphics in the game, and hoped that maybe for all those poor people who have serious lag issues with high-end computers (due to crappy code / use of graphics card) there'd be some relief.
I saw something similar was asked above but wasn't replied to so I don't mean to repost their question. And while making FFXI look nicer would definitely be a boost, it'd just be nice if you didn't have to resample the entire damned screen or w/e it does when you hack the background res to higher, vs simply using AA. Is any of what I said remotely possible or is it just too hard or impossible to do with the way SE coded the game to run?
Btw, DX8 sucks.
Indeed, spellcast is absolutely not user-friendly.
I had wished for Square-Enix to implement an Equipment menu that would pop when you'd put the highlight on Job Ability, WeaponSkills or Magic and you would just have to put the gears you'd be wanting to use in the twelve/sixteen boxes for every spell you need to.
Or at least allow the making of equipment profiles and to associate a profil to a JA or Magic....
nitsuj please have a look a the keyboard mapping thing because if you use US FFXI with and azerty keyboard on v4 it'll remap (I could use EU FFXI but I wouldn't be able to get access to my account management so I'm not really interested in this. Player like I are a minority but still, it's important I assure you).
Yep, that was basically what I asked and just to add:
I imagine it IS possible, although probably tricky. My guess is that this would be outside the general realms of knowledge/experience that the Windower team have and it would perhaps need someone with the relevant skills to say "oo oo oo me me me" and effectively join the team and get the code to work with. Whilst I would LOVE to see this, its not like the current Devs dont already have enough to be getting on with!
What might be funny is emailing the SE Devs asking howyou never know.
another quick note: (from an ancient post in another forum dated 2003 lmao)
"Anti-aliasing doesn't work because of the way FFXI renders to the screen.
To get a lot of the effects relatively unique to the game, FFXI renders the scene to a render target (which is just a chunk of memory on the video card) and then applies some special effects to it -- this is how a lot of the 'phase' like effects that you rarely see in PC games are done.
This render buffer is then flipped to the back buffer and then displayed to screen -- it adds a step to the process but allows a different set of effects to be done.
Unfortunately, current generation hardware does not support anti-aliasing to render targets, only to the screen directly. If you turn anti-aliasing on, it will anti-alias the render target after everything's rendered to it -- rendering all of the anti-aliasing moot.
Halo PC works the same way -- the 'Predator' style effects in the game need the render target stuff to work, and that rendering technique is incompatible with anti-aliasing.
Turn off the anti-aliasing -- you get the full performance hit from it, but zero benefit.
This is unlikely to be fixed anytime soon -- they'd have to redo pretty much the whole graphics engine (and totally redesign a number of effects that are totally incompatible with FSAA) to allow it to work."
=======
There's a DirectX feature where you can also use an offscreen rendertarget and specify anti-aliasing for that offscreen buffer, so bingo - AA support.
=======
More stuff from another forum:
Also, you can certainly have AA on render targets. If you look at the SDK docs you'll see that CreateRenderTarget() has an msType field. The issue is that CreateTexture() does not have an msType field. Thus, if you do render to texture, you can't get MSAA. DX9.0a added a workaround for this by allowing you to render to a MSAA render target then allowing a StretchRect() to the texture you want AA on. Previously, StretchRect() required that both surfaces have matching msTypes.
Yes, but it seems that this did not work in any case with current ATI drivers. If I do this it looks like that the StretchRect copy only one of the four samples to the surface of the texture.
Now, if your application does not support AA (WoW doesn't) then you can't expect forced AA to work with post-processing effects because the app is not going to know to follow the procedure I discribed above.
It can work if you render to the backbuffer and than use StretchRect to copy the backbuffer to a texture. In this case the application does not need to support AA because the driver knows that the backbuffer have AA. Splinter Cell 3 as an example does it this way.
Only posting this to get people thinking![]()
This will be a question for Azaril, I'll light the Az-signal. Or maybe Starhawk.
As to the Azerty keyboard: I'm not familiar with it but I'll file a bug so it doesn't get forgotten.
They released a new Hook.dll file. Overwriting the old one with the new one took care of that problem for me. Let me see if I can find the link for it
Edit:
Found it!
http://forums.windower.net/topic/148...compatability/
What Id love to see is an interface built for the windower that lets us edit the script through it, so in theory instead of picking and choosing our various plugin we can just have them all loaded and just click them on/off
Mayhaps have the various plugins each its own tab with its script box there that will run once the plugin is loaded in.
The whole init system just feels awkward and clunky too me, instead of trying to add things to it maybe windower could use a rework from the ground up? Something fresh and streamlined.
Also, if you can find a way to let us skip the whole POL system straight from DNS login -> FFXI page login Id personally come to your dev teams houses and give you a back rub
Yes, I completely agree it would be much better for all of Windower to have a GUI, but I don't know if that is even possible for them to do right now.![]()
@urat
Would you input your POL IDs to a closed source program?
There may be exploits someday...too many risks.
@nitsuj
Thank you for making a bug report !![]()
Can't skip POL. Aikar says it's possible, but I don't forsee that happening. Even if I was able to do it, I would not include it into windower, as it may piss off the powers that be.
As to the plugin system, windower HAS reworked it from the ground up. Azaril's new system will likely end up having VERY few plugins. Most everything that can be is included into the core program and exposed to script, and the actual processing and displaying of what v3 called "plugins" will just be script files that can be run/loaded/cancelled at any time.
Certain things that NEED to be separated from the core for security/logical reasons will still be DLL's and loaded/unloaded from the console like you know. But the system for the most part will have changed for the better, and a lot more stable
(for example a lua script plugin with bad code will just spit it's error to the console as opposed to corrupting and crashing the entire session!)