buckmaster

I quite like the idea of getting scene traversal to use a thread pool, though I think that would involve the container system (IIRC), which is nowhere near threadsafe. I did do some exploration in that direction when working on recast/walkabout, so I could multithread container queries to build geometry. It wasn't super pretty.

That's exactly what I was doing, and they didn't look smooth until I made those changes.

I've been using Twillex and it's pretty great, though I noticed that it doesn't look at all smooth in T3D unless you do this (i.e. use ScriptTickObject and its callback).

Would it be possible to load several COLLADA shapes in parallel, even if we couldn't load new resources in the background? Might speed up that initial level load time. Skinning has always been mentioned as a candidate for parallelism, though @MangoFusion's GPU skinning may make that obsolete. This seems like it could be a good way to go for many types of problem. Taking discrete pieces of an algorithm that involves a lot of computation, and parallelising it within a single discrete time slice in order to make it go faster. Not long-running systems which interact with the main thread over any length of time. As always, Mango has it right. Definitely all good things to keep in mind.

Looking so good! That last Cornell video was lovely. How does this interact with PBR?

I got to try out a DK2 today - my first time in any Rift. Less FOV than I expected, though I was trying out a web app which had an abominably low framerate, which meant I was trying not to look around, which may have made it feel more claustrophobic than it would have otherwise... I'm super glad James decided to take this on! Excited to see how it goes.

Whoops, I forgot about this. Mostly because the 'language' is actually just a bunch of global functions and a single data structure. That said, working with Laravel is nearly as pleasant as any other modern dynamically-typed web framework. Props. I am indeed one of 'those Haskell guys' and incredibly glad to be.

By include you mean link to? Seems like a good idea. Feel free to make a pull request. Here's the community menu.

Also, everybody, remember that GG also has T2D forums to maintain. I'm sure those folks will appreciate new anti-spam measures. To be fair, that's untrue. The checking isn't as diligent as we'd like, but it does happen. Great idea! I plan on taking time after 3.7 to write an up-to-date page for the engine on devmaster, and someone could crib from that for IndieDB.

Feel free to make a pull request. Here's the community menu.

I agree. I suddenly had an epiphany and came here to ask why the heck we were adding a resources forum when we had a wiki, but having he forum as the 'development lab' for later finalisation on the wiki seems like a good approach, if anyone ever bothers to port things over to the wiki.

@Ron Kapaun Luis tells me we should be able to pre-release 3.7 at the end of the month.

Let me be clear - you mean 'loaded' as in created on the server from a script file? Like: datablock FooData(Foo: Bar) {}; datablock FooData(Bar) {}; Because AFAIK this sort of copy-constructing doesn't make it across to the network at all - the object doesn't retain any 'parent' information.

My thoughts exactly. I suspect `sed -i` will be a great help. And then just checking for console errors. My approach last time I tried this was basically to just copy the profiles.cs over to the tools/ folder then do a batch rename. Not the best solution, but it mostly worked.

Ah I see, that makes sense. I've had my share of infinite loops from scripts :P.

The scripts don't take a huge amount of space. It's the art assets hat do that, though hopefully we can de-duplicate some of those. The tools folder is about 6MB, so that's a saving. But doesn't make much difference compared to 300 or however big the whole thing is :P.

More reproducible crashes is good! Someone expressed the opinion a while ago that it should be very, very hard to crash the engine using scripts. I agree. The more cases like this e can find and fix, the better.

Ok haha. Does LPV do shadows currently? Surely it could...

This hasn't been announced extremely publicly, but the issue has been hanging around on GitHub for ages now, with a corresponding discussion at GG. I thought I'd bring it up again since we're nearing the release of at least the preview version of 3.7. The idea, briefly, is to move all the stock template scripts around so that we don't have so much duplication. Two examples are the entire core/ directory, and more egregiously, the tools/ directory, both of which are identical duplicated in Full/ and Empty/, and would have to be duplicated in any other templates you added. This is frustrating and irritating, so we thought we'd do something about it. My proposal is to move common script code into a top-level directory Packages, which looks like this currently. There's, for example, a Core package, and an Editors package. This way, those scripts aren't duplicated. So, before, your folders looked like this: Templates/ Full/ tools/ Empty/ tools/ But now they'll look like this: Templates/ Full/ Empty/ Packages/ Editor/ tools/ This means that when you create a project, instead of just copying the template to the new project, you must also copy the package scripts you want. I've made some changes to the Project Manager to do this automatically, the way it currently copies templates. However, this also required some additional infrastructure: a template.xml file in each template dictating which packages should be copied (since you don't just want all of them). Unfortunately I wasn't able to get this to work with the Project Manager UI, so you can't choose which packages to include at project generation time - if you want additional packages, you either need to edit template.xml, or copy the package manually after project creation. @Azaezel mentioned that this seems like a large change to be introduced, especially without much fanfare. My reasons are that it doesn't actually change the structure of a project, or any code - just moves it around. Projects generated the new way should look identical to projects generated the old way. And it does cut down on a lot of duplicated code that needs to be updated twice every time. Anyway, the point of this post is to raise awareness, but also to make sure I haven't made any fatal miscalculations that mean this is a bad idea. The obvious large downside is that this change will break any pull-requests involving changes to the templates, but I'm happy to weather that and help fix/resubmit them.

Why are the shadows so jaggy, but the light cutoff so smooth?

Yeah, I know. The main reason is because once you've created a project, it still looks the same as a project created in 3.6. There's also no change in functionality. The source files are just moved around. We've been wanting to do this for ages, so... it doesn't involve you modifying your projects, just custom changes to templates, but we think it'll be a welcome change even to people with their own custom templates (and who has those, really? I get the impression that everyone just modifies Full). I made a forum post and people seemed supportive of it, so I figured it wasn't all that controversial. I'll make another post here soon to see if it would be too rapid a change.

The template refactor? Since when?

A crash? I think we should try to make the script API as crash-resistant as possible. Any chance you could see what's happening in the engine to allow it to crash? A minimal example script would also be appreciated :).

So, I kept meaning to reply to your email... :oops: I wasn't around when this was set up, and I want to clearly state why I've been more involved here compared to t3d.net. I don't want to cause any offence! Basically, people have jumped aboard. I tried to post a few times over there, but there weren't really other topics. Lukas has also been very present and responsive at setting up the forum software so that the community feels an obvious benefit to transferring over. Obviously we were super grateful for the .net hosting, but what those forums really needed was a developer who could implement features, I think. Anyway, we'll see how this new home goes. The .net is basically yours to do with as you see fit. I'll start a discussion within the SC whether we make you an offer for it - I do think a redirect would be the most pertinent solution.

3.7 will refactor the templates such that the editors aren't duplicated in each template, but live in a single location. After that, I'll be doing exactly this, renaming all the editor profiles to be editor-specific and copying profiles the editors depend on from game code so there's complete separation. If anyone wants to make a start I'd welcome it. I plan to introduce a namespace for editor GUI classes, so game profiles can be named without a prefix.