Bars

[Kivutar]

Now I get the old error again

Code Select Expand

[kivutar@macbook:~]$ mysql -uroot < Downloads/tethical.sql
ERROR 1280 (42000) at line 47: Incorrect index name 'game'

[lirmont]

Re-download one more time.

But also, you'll need to drop the user like:

drop user tethicalProxy;

--

The .mwb file is for the user interface "MySQL Workbench" (http://www.mysql.com/downloads/workbench/) which let's you pick and choose which parts you want to forward engineer into the production environment (Database -> Forward Engineer). The .sql is supposed to just be a backup for that (since you can't tell it not to load a certain part) and was generated by MySQL Workbench loading everything into the database. To edit data once you already have it up and running, I suggest you use a tool like phpMyAdmin that lets you see what's going on.

[Kivutar]

Thanks, this time I have been able to restaure it.
I also installed mysql-workbench on my linux (I prefer this to phpmyadmin). It is a chance that we can use the same tools!

[lirmont]

That workbench is a designer's best friend. The problem is that it doesn't operate (well, that I know of) on a database that's already up and running. That's why I suggest phpMyAdmin for that, since it'll let you click through to your data, and you can change it in place to test things when you see them go wrong. However, you can use workbench to edit inserts and just forward engineer the table you want (in filters on the Forward Engineer's first page). Either way, the point is that database clients (i.e. the command line) haven't come very far at all over the period of time they've existed, and those tools (workbench and/or phpmyadmin) will let you have a better idea of what things actually look like. phpMyAdmin also has a very cool feature that let's you click through the actual relationship between two objects, taking you to the object that's being linked to; this is an incredible time saver (as opposed to finding the value, changing tables, using the search feature, putting the value in, and then hitting "Go"). It also has quick tools that let you get rid of everything, rename, view space storage, manage users (though, I like workbench for this one), and export to other formats.

[Kivutar]

For my everyday job, I use the command line, wich is not useless if you know the tips and tricks. But designing using a graphical tool with arrows and all, this is very great!
This week end, I have 4 free days to test your code.

EDIT: I'm reading your code. It looks good so far! As it is a big piece of work, I need time to fully understand it to integrate it in the trunk.

[Pickle Girl Fanboy]

I'm curious... with the hack to edit the failure rate of Teleport past the unit's move... is there a way to display the range of Teleport?  What i'm thinking is only allowing 100% chance in range and 0% beyond.  Essentially using it much like Fly, but with the Teleport animation.  I don't want the entire screen covered with selectable spaces, when i can only go so far.  Possible?

I wonder, is it possible to have a semi-transparency in things like range, linked to certain things?  Like, you could have 100% opaque for movement range, but with vanilla Teleport, you could have 100% opaque where there is a 100% chance for a sucessful teleport, and then increase the transparency by the same rate at which teleport success falls.

[lirmont]

So, you're asking if it's possible to feed the % chance of an equation into the colored square target feature to show the likelihood of success? I suppose it is possible, but are we just talking success % here (which would be one of the sub-formulas attached to the skill)? I don't remember, but isn't that covered in vanilla on the confirm screen already per square (showing 00 -> 100%)?

[Pickle Girl Fanboy]

Nah, there isn't a confirm screen for vanilla teleport.  I imagine there'll be a confirm screen for a modified 100% sucess teleport which costs you your Action and your Move on your turn (as in it works just like Equip Change and Defend, but also uses up your Move).  Though that's a good idea - much better than mine - teleport, no matter what form it takes, should display a success rate on the confirm screen.

[Pickle Girl Fanboy]

Sorry for the double post, but what are you doing in regards to battle event scripting?  Because if you intend to have any kind of story, you'll need something to manipulate sprites, sound effects, music, weather, lighting, and animations on the battlefield.

Do you plan to have any sort of world map?  The world map in FFT is basically just a bunch of (paths/lines) and (dots/links to battle events) that the player sprite follows, in a layer above an image of the world map.

One last thing: menu design and access.  Will you allow the modder to make custom menus to access and view different aspects of the game's mechanics, or will you just go with a generalized menu that can process all possible game mechanic combinations?

I don't know enough about battle or world menu event scripting to be helpful, but there are plenty of people here who do and likely will help you.

[lirmont]

Well, I don't know how far past multiplayer Tethical was originally intended to go (if at all), so I can't provide an answer for that. What I can say is events/states/savegames/etc is something I want to see happen. However, I've never considered writing something like that, though integrating something that's sequential (like an event script) into Panda3d is completely practical. It will literally let you set up a list of things (like rotation, scale, camera zoom, etc) to run against the current environment without needing to write any other code than telling it to do so (re: rotate command, scale command, camera zoom command). More complicated things, like chaning maps could be made into commands. That is, you might name it something like "ChangeMapTo" in Python and have the code needed inside of that to do what you expect. Now, in something like an event script, you could then call that function like: ChangeMapTo("map001"). However, I think it would get tricky to juggle that between Python's syntax and some arbitrary event syntax. So, I think it would be a good idea (and is completely possible) to simply write out the python code for the sequence AS the event itself. The PTF files that configure the particle effects do just that (with other aspects of Python). The point is, in Panda3d, you get access to -- wait for it -- simultaneous commands. Meaning, if you want two things to happen at once, you've only got to say the word. Want it to only happen for X amount of time? Same thing. Want it to change over the time it's running? Same thing. That is, you just have to use the right blocking to encompass what you're asking of Panda3d.

Anyway, Tethical really doesn't have anything in the way of a comprehensive written to-do list or anything, but I'd guess that that feature would need to be at least after solid multiplayer using FFT rules is working. As you know, I'm working on the control panel so it will be viable for people other than myself to add FFT rules in. However, I'm writing parts of the database that use that information still as I go along (re: classes, items, etc). So, I'm kind of the bottleneck at the moment, but, admittedly, FFT is a feature-rich game and creating the right storage for it is lengthy when you consider that it's all in relation to itself. Again, that's what the control panel will be for as it matures. The backend already has the form of what exists in FFT correctly (in my opinion), and now we just need something to dumb it down so it isn't as confusing for everyday usage, considering adding one thing may also mean you should add three or four other things at the same time (which the control panel would conceivably guide you through).

About the world map, I think there'd have to be more information about what actually happens to continue to plan for it. An incomplete version is easy to come up with: draw the map, pull a list of available points, compare that list to points you can actually visit, and then run some script based on selection of the point (re: the events I mentioned). However, that ties each point to exactly one script. While that's not unusable (because you could choose to call some other script from within that script based on game mechanic flags you set up), I don't know if it's viable. Drawing lines between points is easy to accomplish with bezier lines where you have a list of control points, and those lists can be stored in a database and referenced behind the scenes. However, doing it now would take time away from the more important aspects.

About menu designs, as you know, only the actual images that make up the box model are configurable at the moment (and would affect every menu). To enable a non-standard menu, I think you're looking at writing the Python code to make it available on your own. I don't recall exactly how the menu functions are called within Python, but this is certainly something that can be abstracted into an event-friendly CallMenu("menuWithExtraStuffInIt") command. As to actually writing the Python code for such a menu, Panda3d abstracts just about everything into something you can read, and Kivutar already wrote the scrolling and gamepad code (so you don't have to write that again).

Basically, I think at this point, if it's a feature you want, you might best serve that purpose by writing a battle mechanics guide lite version of what you see it doing. It doesn't have to be technical on the level that that guide was, but it should be structured. This happens, then this happens, then this happens, then we return to point X; that makes up Y thing. This name means this, this name means that, this is how you come up with this number. That way, someone from inside or outside the project doesn't have to come up with the bulk of the idea; they can just volunteer code it, make it available, and use it. You don't have anything to lose by posting in this forum a walkthrough of a feature you want. I can say I won't be doing it right now, because I have to finish making the backend of the software viable for use via the control panel. However, when I'm finished with that, I intend to prepare for other features that I want to see happen.

[RandMuadDib]

on the subject of single player (and i know this is not anywhere near important right now, but i think the idea should at least be documented)

Letting temporary (i.e. guest) characters join random battles. that way if the player is a grindwhore, they don't fall behind and become useless. I also think that guest characters should be allowed to be both player and AI controlled, set by whichever user is creating the single-player content. Might be an issue since i dont think anyone has even started thinking about AI yet, but the suggestion is here all the same.

[lirmont]

I have a feeling AI will be one of the easiest parts. Consider this. If you can define what a "good move" is for a given difficulty level, I can guarantee you I can write code that goes through and evaluates the damage formula(s) over every option the particular character has until it finds a move that qualifies as a "good move", and then it's just a matter of telling the game to do it. It only takes writing that process once for it to be repeat over and over. Technically, a player could do the same, evaluating every possible move his or her current character has based on what the game tells you your hit% and damage will be.

[Pickle Girl Fanboy]

I don't see any reason not to use Python to script events.  If anything, that will help everyone, because it will introduce non-programmers to Python (and thus would increase our pool of knowledgeable people), and it will allow interested Python programmers to walk in and contribute to the project.  Virtuous Cycle for the win!

You're right (of course); designing the player menu (or making the tools which let the modder design the player menu) should wait until you have the database and playable game at 1.0.  I'll mentally bookmark this conversation, and make a few topics in Help or Hacking seeking detailed explanations of these things when we reach that point.

[Kivutar]

I agree about writting the events using Panda3D Sequences directly in Python. It is the best way to build a powerfull event system.

Concerning the player menu. For now this menu is hardcoded, but in the future it will be build on a dict sent by the server. Customizing the menu views and behaviour should be possible with a mechanism like extending the GUI module and overriding its Menu method. But it may be a naïve approach....

@lirmont I don't know design patterns but maybe you do. What would be the best way to provide GUI customization?

[lirmont]

The only thing I could think of when I read the suggestion was a format for menu coordinates, because I saw how those are written during the scrollable list feature. A lot of rich web development libraries (and GTK) use a model-and-view approach. So, this could be the view, where you set up columns with renderers (in Tethical's case, probably one for text and one for images) which render out a specific offset in a data model (i.e. an array or dictionary). One I'm familiar with in a library called ExtJS also has a feature called "XTemplate" where a column renderer is set to "template" and you feed it the offsets manually and have the ability to execute Javascript right from the template. The point is, you end up with something that is incredibly customizable. However, this depends on what data/columns you already have in the model, meaning you'd still be bound by what's returned. That is, if the data isn't in the model, you can't reference it in a column renderer.

Now, I think things like statistics are a good example of what you can and can't do here. Let's say the programming is changed to follow the above model-and-view approach. If everytime a certain character menu is asked, you get back ALL character statistics, you can choose at the view-level which ones you want displayed and how they will be displayed. However, if you want a kill count (a la Tactics Ogre), you would need to also change it (or tell Tethical) that it needs to load this character's gameplay statistics, and then you would reference the offset in a column renderer.

Don't be confused about the power of such a feature. The character "cards" FFT uses to display data are better known as "rows" (even though they're presented side-by-side). A solid feature like this would have several row models: default (list), horizontal, wrapped (ex: unit list with sprites and hp/mp/level/etc.), and cards (ex: one or more rows displayed at a time). With something like this, I can feed it into the C# control panel prototype without needing to link into Tethical/Panda3d. Otherwise, menus/themes will have to wait for the Python final product which will always use Tethical/Panda3d (where applicable).

[Pickle Girl Fanboy]

I just realized, you'll need something to keep track of an actor's original stats during battle, for some weapon formulas a modder might use, and in case a modder decides to have stat buffs and debuffs decay during battle.

The weapon formula in question is a modified version the unarmed attack formula, which some believe is less broken than the vanilla version.  Here is the modified version:
damage = (original PA * current PA) * (Brave / 100)

Stat buffs and debuffs decay back to original should decay 1 stat point over (n) clockticks.

So you need to keep track of the original stats (which are a function of actor raw stats (HP/MP/PA/MA/SP), and Class Stat Modifiers.  Class Growths don't matter for this, since growths only matter when you gain a level.

Once this is accomplished, you must keep track of current stats (which are wrought by stat buffs and debuffs), and equipment stat bonuses (which change the hardcoded minimum stat, since the only way to remove their stat bonuses is by removing the equipment).

If you plan to include a timed delay, you need to keep track of the clockticks since the stat buff or debuff occurred, for HP/MP/PA/MA/SP, for every actor on the battlefield.

Possible uses for each of these stats:
*HP
**An ability or status which temporarily increases or reduces Maximum HP.
*MP
**An ability or status which temporarily increases or reduces Maximum HP.
**An ability, status, or mechanic which checks if Max MP = Current MP, and then increments MP by a static amount or a percentage, every (n) clockticks.
*PA/MA/SP
**A mechanic which decays artificial stat changes back to their original values over a period of time.

EDIT

Basically, just read this topic to find out what I'm talking about.  Also, a lot of people think that support ability bonuses and elemental bonuses/penalties should be applied after base damage is calculated.  So please give us the means to modify these battle mechanics in tethical, so we can make a game that's better than FFT.

[lirmont]

If that forumla is not part of the original FFT platform, it will be up to a user to change it to that.

I know I'm a broken record at this point in saying it's not currently done yet, though. My current plan is to support a transaction-based structure so games can be documented and reviewed (like you'd document a game of Chess, except more verbose). Meaning, the system will snapshot everything related to characters and skills used, and games will be able to be rewatched. I want database queries against part of this structure to be how win/loss/draw totals are determined. The important part is that changes to original statistics (re: permanent statistics; not to be confused with raw statistics, unless you're wearing no armor, have no race bonus, and are not effected by magic) will be able to be watched just like in a game. It's a big endeavor though, and, since I've never done anything coding-wise with savestates before, I haven't come up with a solid plan for how I'll store the data.

One option is to do it in a spectator-style, human-readable sentences, then parse the sentence to know what's going on (like how someone might describe an event):

1. Red team is lirmont.
2. Blue team is someone else.
3. Red team places some character at some starting location as some class with some stats.
...
7. Blue team places some character at some starting location as some class with some stats.
...
11. Moving. Red team's character moves to location some location. CT is now some CT.
12. Move and act. Blue team's character moves to location some location. Blue team's character begins casting Holy. CT is now some CT. CTR is now some CTR.
...
100. Some team wins. Some team's win-loss-draw record is now some win-some loss-some draw.
101. Some team loses. Some team's win-loss-draw record is now some win-some loss-some draw.

(or)

...
50. Some team has disconnected without rejoining for more than X minutes.
51. Some team wins by default.
52. Some team wins. Some team's win-loss-draw record is now some win-some loss-some draw.
53. Some team loses. Some team's win-loss-draw record is now some win-some loss-some draw.


I say this because responsibly taking a snapshot of ALL data would mean making a copy of every table just for use with this feature, which is not a bad thing, but it would certainly be more of a final step (i.e. "this game will never change starting now"), which will never happen inside of a engine.

[Pickle Girl Fanboy]

If that forumla is not part of the original FFT platform, it will be up to a user to change it to that.

As long as you don't have to be a Python programmer to change it, I'm happy.

[lirmont]

This is an example of changing a formula: http://ffhacktics.com/smf/index.php?topic=8157.msg162571#msg162571

At the moment, it only supports evaluation, but it is just a prototype. The final version (and probably the prototype version) will support changing formulas right there.

[Choto]

Hey Lirmont and Kivutar, I'd like to help out with tethical where I can. I read through the control panel and bars threads, and admittedly am a bit lost on where the current progress is at. I have a decent idea of what your goals are, but I couldn't quite follow everything you posted about lirmont, as my programming knowledge is limited. Right now I'm taking programming in C++, Java, and learning ASM on my own, so I know pretty much the basics of each language. I'm not opposed to learning python as well but can't guarantee i'll be successful learning all the languages at once. What I can offer is a decent familiarity with vanilla FFT, what some of the ASM or logic processes look like behind the mechanics, and opinions and ideas about how different mechanics could be handled. In farting around with my own patch, I also have ideas for new things I'd like to see incorporated which I can subject to your judgement for implementation. The majority of my effort has gone into class design, about which I have some philosophies, so when the time comes I may be able to contribute there.

I can't say how much time I will have to devote, but as FFT is a big interest to me I will try to do what I can when I can. Let me know what you need ideas or opinions about, or what you would like me to investigate and i'll help where I can. Thanks!