buckmaster

Awesome. Did the fix ever work for Richard or did he actually not test the latest one? Anyway, good to know it's working. Is your work OpenGL-ready? And what order does stuff happen in again? Could you make a branch with all the unpulled terrain changes in?

I just can't ever imagine a time when knowing the category would be useful, but if we can't change that then never mind!

Hmm. It appears I can't reproduce the issue in VS2008. Clean and rebuild not changing anything?

So, I was originally quite on board with the idea of doing stuff like storing levels in TAML because of the separation - you could open a TAML file, read it into memory, view it, edit it, operate on it, without creating any actual objects. This seems like it would be a win for editors - but on second thoughts, wouldn't it make it difficult to write editors? Say you open a 3D scene in the editor, which is represented as a TAML file that describes a list of (nested?) objects. What do you do now? You've got to create graphical representations of all those objects, of course, and lay them out in 3D space in the way they're represented in the file, the same way they'll be created when you play the level. But how do those representations get created, without actually instantiating objects anyway? Do you have to write separate rendering logic to render a TAML scene, before actually creating the real scene? isn't that a ton of code duplication? The obvious answer, of course, is that you load up a TAML file, create all the objects it describes, then edit them like we do currently, and same them all back out to TAML afterwards. But then what benefit does TAML have?

Well I said I wanted the image in the top-left linked, which would make sense. But if we can't do that then IMO having the home link where it was is fine. Also, any chance we could remove the category link? For example, where it now says Forums > General > General Wouldn't it be better to just have Forums > General Where the last link is the actual forum, not the category? Until we have a toooon of categories, I reckon it's just more noise...

Sadly now we can't get to the landing page from here :(.

Maybe if we renamed it, they wouldn't notice! Seriously though, I do think a rename is a good idea, so as not to confuse the persistence system with the file format. And, really, .taml should probably just be .xml. Maybe the system should be TASL (Torque Application Serialisation Layer) or TAS (Torque Asset Serialisation)?

TAML is a persistence layer (and markup language) in use by T2D for saving resources like levels and animations. This page from the T2D wiki has a really good overview. I want to make it extra clear that TAML refers to both the persistence system itself, as well as a particular backend that looks like XML (Torque Application Markup Language, AFAIR). But the TAML persistence system is apparently able to persist via JSON and binary backends as well. @LukasPJ has already implemented TAML in T3D in some form, which I'm not too familiar with but I'm sure he can elaborate on. @Hutch recently expressed some opinions on the use of TAML, which prompted me to create this thread. We should have a bit of a discussion about how we want to carry forward in this direction. I'll write in more detail later, but I want to kick off the discussion by saying I'm very much in favour of separating code and data. Which means, TAML for data, and TorqueScript for code. At the moment, our .gui and .mis files, for example, are actually code, which is executed like code. I think separating them would allow for better editing and tooling. I'll finish for now by quoting Rene Damm, from some private correspondence we had a while ago which I've asked for his permission to share:

Oh no way. This problem just started happening on the GarageGames CI server with VS2008. I'll try to test when I get home, though I only have VS2012 installed. Testing locally on VS2008 last night seemed fine, though that was only a debug compile. I'll see how it goes with release.

T3D has been ported to OSX (by these guys), and we're aiming for official support soon (not this version, but hopefully the next one, due out in... several months' time). I think if T3D is the engine you want, then it's worth waiting, and possibly even jumping in to help out (we can always use more testers with Macs, which will help us support that platform better). But, I think if T3D doesn't have some killer feature that'll make your game that much better, or if you don't feel you have to have an open-source engine (or if existing OS engines work fine for you), then there's no real reason to wait. Maybe you should make a game with something else, then come back and visit us in a year's time and see how far we've come ;). I guess it depends on the work you'd rather be doing. If your passion is making a game, you don't really care about game engine internals, and it's feasible to implement your game in a general-purpose game engine (i.e. you wouldn't need to modify the engine source), then you should probably use some other popular engine. But if you like to get your hands dirty, learn about how game engines work, modify it to suit exactly what you want to do with your game, etc., then welcome aboard!

Came here to leave this

I just made a fairly significant update to the Project Manager and the structure of the packages. I realised that if, for example, you wanted a package to be a git repository, then the .git directory would be copied from the package to your game template, which was a bad thing. Ditto with, for example, a package readme. So I've edited the PM to look for a 'package/' directory inside the package. Now a package ends up looking like this: Packages/ Editor/ stuff here package/ tools/ This makes it more gooderer and stuff. I also renamed the 'path' attribute in template.xml to 'name', since that makes sense.

@Gibby what sorts of changes were causing problems for you? Also I'm sure you're aware but Walkabout will be included in 3.7 :).

Is this the sort of thing that could be run in a background thread for realtime updates? *strokes chin* Also, for a final solution, would the goal be to allow a handful of volumes to be active at a time so you can cover your level geometry more tightly in several smaller volumes, and select the ones that are most visible?

Lukas made a forum for the SC to post changelogs, but we already post them on the wiki. Which does everyone prefer? If we keep the changelogs on the wiki, I think we should delete the changelogs forum, and rename the SC forum to 'Steering committee announcements', and not have a subforum for announcements.

@rlranft too late, I did it ;).

What you raised was basically an issue saying 'please fix this'... usually a pull-request happens after you have already done the work and want to submit it for merge! But no matter, I've done it myself now :). Not sure how facebook does links these days. It used to let you choose from all the images on a page.

I started doing that too but I've trained myself out of it. Might be best to remove that link, but link the image in the top-left.

A vehicle pack with example vehicles sounds like an awesome idea!

Could we make this say 'forums' instead? That just seems so much more explicable.

Right, I get that. I was just confused when you said 'loaded' since I usually take that to mean the datablock loading phase of networking. The whole copy cunstruction thing is kind of bizarre, especially the deferred name resolution. It's like TS is pretending to be declarative/immutable in this one very specific area, which is probably so rarely encountered anyway due to datablocks being created in the editor. Meh.

Well, I wanted silky smooth, and I got it ;). Having a window resize callback is a very good idea. I think @Azaezel proposed it a while back. Not sure what happened to the idea.

The copy stuff gets resolved on the server before data is sent to the client. It's basically exactly the same as a copy constructor - FooData(Foo:Bar) means copy all the fields from Bar first, then apply the overrides/additional fields below. Then Foo gets sent over the network with all those settings. It's not saving network bits, it's saving typing.

I should note that with bug reports, unless the code is obviously wrong, we'd really appreciate instructions on how to reproduce the issue, with stock script templates like Empty or Full if possible. It means we can more quickly validate the problem/solution than having to work it out ourselves!

http://cdn.meme.am/instances/55527853.jpg