[DreAdFaq]

After some tool digging, I came to the conclusion that there still aren't any table editors out there. I was thinking of doing one myself, something ala HH's tableview with editing.

Would that be interesting? What would you expect of such a nifty little tool? Would it interest you at all?

[Unknown Target]

Someone was already going to develop one, but I guess that fell through. I just use notepad, though, so it doesn't make a difference to me.

[Kie99]

What's wrong with Wordpad?

[TopAce]

I think people got used to WordPad too much. But if you think you could come up with a good programme, go ahead.

[redsniper]

it would be nice to have a tool that could automatically put in entries and stuff with the correct formatting so that you don't have to type it in yourself.

[karajorma]

I'd appreciate having a parsed list of ships at the side so that I could simply click on a name and go instantly to that ship. Most of my table editing time is spent either searching for a name or scrolling.

I'd be careful about what you put in though as the SCP seem to change the requirements of a table entry on a weekly basis If you do write a program make sure it's flexible enough to cope with tables having new options 6 months from now. (i.e don't do anything stupid like assume that a certain flag will be 6 lines down from the top etc. )

[DreAdFaq]

I'd appreciate having a parsed list of ships at the side so that I could simply click on a name and go instantly to that ship. Most of my table editing time is spent either searching for a name or scrolling.

Personally, I'm hoping to get a grid-like interface similir to TBLView's, with a list of all the different tables on the left. Don't know if that's going to be any good though, with different entries in a table having different structures.

EDIT: but of course, I'm always open to suggestions. Wouldn't be worth the trouble if no-one but me likes it

I'd be careful about what you put in though as the SCP seem to change the requirements of a table entry on a weekly basis If you do write a program make sure it's flexible enough to cope with tables having new options 6 months from now. (i.e don't do anything stupid like assume that a certain flag will be 6 lines down from the top etc. )

Actually, I wanted to go a bit further. It's not like the TBLs have much structure as they are, anyway. It'd be great if they switched to xml tables, or something like that, but I suppose it isn't worth the trouble.

Anyway, the first part of the plan is to simply get a parser that can read them as simple pairs of strings. So you could even enter $that idea is: good, and it would come up with a ship somewhere that seems to have good ideas

If I get that working, I'll start working on getting support for inherent types for properties and stuff like that.

[WMCoolmon]

Originally posted by karajorma
I'd appreciate having a parsed list of ships at the side so that I could simply click on a name and go instantly to that ship. Most of my table editing time is spent either searching for a name or scrolling.

I'd be careful about what you put in though as the SCP seem to change the requirements of a table entry on a weekly basis If you do write a program make sure it's flexible enough to cope with tables having new options 6 months from now. (i.e don't do anything stupid like assume that a certain flag will be 6 lines down from the top etc. )

Look up test_shiplib. It hasn't been updated in a looooong time but it is sort of what you're asking for.

It would probably be best if you split it up so that you could have a generic table field (ie just rows and columns) or, if someone designed it, a full dialog view that would be specific to an individual table.

If the latter is present you could let the person toggle the former.

Also, what would be really nice is if you could just feed the program the name of your fs2_open directory, and the mod you want to use (if you can do it in Java, have it read from the registry on Win32 systems if none is explicitly specified by the user). Then it loads the default tables that will be used, and lets you see where they are...that way if you had a table somewhere in your directory tree, overriding the ones in the retail VPs, you could just bump the program open and find out where it is really quick.

[DreAdFaq]

Look up test_shiplib. It hasn't been updated in a looooong time but it is sort of what you're asking for.

Is this something in the source? I googled for it, but to no avail.

It would probably be best if you split it up so that you could have a generic table field (ie just rows and columns) or, if someone designed it, a full dialog view that would be specific to an individual table.

That was what I started out towards. But you can never have a completely generic table, because FS2 structures don't always have the same number of properties (i.e., columns). So you'd always have to do some sort of 'magic table wisdom' to group for example subsystems together.

EDIT: forgot to add the current plans I'm still wondering about the feasability, but I hope I can get a sort of type-config framework. Meaning that the editor would come with some config file (probably xml) that specifies what it knows about certain fields. Then I could use that to do input checking and trigger advanced editing controls. (i.e., if it's an RGBColor, makes sure its in RRR,GGG,BBB format and show a color-picker instead of a textfield). I could probably handling grouping with this too. And if the SCP decides to add a new property, updating the editor *should* be as simple as supplying the correct type info.

Also, what would be really nice is if you could just feed the program the name of your fs2_open directory, and the mod you want to use (if you can do it in Java, have it read from the registry on Win32 systems if none is explicitly specified by the user). Then it loads the default tables that will be used, and lets you see where they are...that way if you had a table somewhere in your directory tree, overriding the ones in the retail VPs, you could just bump the program open and find out where it is really quick.

Definately something I want to do in the long run. Possibly even including VP building or hot updates (i.e., open file from VP, edit, rebuild from memory without having to save TBL to disk first) in the end.

But first, lets actually get the tables working

[WMCoolmon]

I meant that you'd have a config file that would basically be the .tbl, except with etc in place of the actual values, which the parser would then use to grab them from the .tbl and show them in a table form. That way, when a new table came out, all you'd really need to do would be to pass around a new_table.tbf file, and the program would handle the rest.

Pretty much what you described.

[DreAdFaq]

You know, the deeper I get into this, the crappier the table structure starts to seem.

For example, why on earth use $end_multi_text if properties aren't new-line delimited anyway??? Why are some things prefixed with '+', others with '$', and yet others with '@'? And if there have to be prefixes, couldn't they at least have refrained from using them in values?!?

Heh

EDIT: (mental note: count to ten and think before hitting 'post' from now on )

I meant that you'd have a config file that would basically be the .tbl, except with   etc in place of the actual values, which the parser would then use to grab them from the .tbl and show them in a table form. That way, when a new table came out, all you'd really need to do would be to pass around a new_table.tbf file, and the program would handle the rest.

The ability to handle almost any table was a design goal from the start. Hopefully, I can do it in such a way that 'magic knowledge' will only be used to provide extra functionality. So you could even use it as a totally crappy mission editor

[DreAdFaq]

*sigh* Up till now, I've spend more time trying to make up a coherent 'table format' than I've spend actually coding.

Some tables are definitely NOT going to be supported in the first version, simply because they have absolutely no resemblance to 'regular' tables like ships and weapons. This would include stuff like strings.tbl and credits.tbl.

Also, some properties have a colon, but not a value of their own. For example $Trail: +offset blahblah. For a moment, I thought '+' properties might be meant to be attached to the preceding property, but that would mean most of a ships description is part of it's 'species' property. Not pretty...

To cope with this, I'm thinking of having a '+blahblah' force the start of a new property, and interpreting things between double-quotes as escaped content. As far I as I can tell, this shouldn't break the 'regular' tables in root_fs2.vp. Haven't checked the rest. But it would mean that it could only handle future TBLs if they:

 - Do not use the '+' character outside a double-quoted string, except to denote a new property.
 - Close every open double-quote.

The second item probably shouldn't be a problem (wouldn't surprise me if not doing that would break FS2 itself anyway), but I find item #1 to be a bit restrictive.

Any thoughts/ideas/comments?

[Grug]

I was contemplating of writing a table editor a while back in Java, but decided against it because... Java.

Anywho, the reason was because I was doing heaps of Table editing at the time, and it is quite time consuming.

My concept was based strongly around Weapon Table editing. The idea was to have a preview window which displays the weapon effect as it would appear ingame. One could also preview a cockpit view which would show what it looks like being fired.

This would save hours for me, as I'm constantly going from tables to test ingame. Being able to see how it looks ingame right beside where your editing the data would be a god-send.

Good to see someone is working on at least a basic editing proggy.

[DreAdFaq]

@Grug: hold those thoughts Things like that definitely won't be implemented until at least basic type support is complete. And most of that would probably require the help of someone familiar with the things FS2 does with the the data.

Anyway, for know I've chosen to simply disallow values starting with '+' (they're interpreted as new properties). Which means that I can now do a raw parse of ships and weapons TBLs. Hooray!

For now I'm awarding myself some R&R, before I start testing other TBLs and working on a type system.

[WMCoolmon]

Things with a $ are either in the root of the table, or they're part of a big tree system of organization (subsystems)

+ values are sub-properties of some other label, that depend upon its existence.

I haven't seen an @ value before and taken note of it, but in ship and weapon names they done the ships/weapons that should be in the demo exclusively, ie in a demo build only things with @ preceding them will be loaded.

[Deepstar]

Hmm.. i think a Table Editor is a great idea.. because i don't know, what a few datas doing ingame (like $Allowed Dogfight P/SBanks: in ships.tbl)

[Unknown Target]

$Allowed Dogfight P/SBanks are for Dogfight weaponry, which is used in multiplayer (to balance out the craft).

[Grug]

How's this going Dready?

I've been starting to do table editing again lately and the formating is raping my eyes. =/

I could live with a super basic version that just supports formating of some sort so that I don't have to edit 1000 bloody tabs and spaces for each flaming entry...