When will the 1.02 out?

#141 Now that has been introduced into the discussion, I highly recommend that all interested parties read the thread on Quarter to Three completely. I've found that it's the most non-biased and "both sides represented" thread on the matter.

Please note that as far as I am aware, no GG employees even visit that site (except obviously for me), and I know for a fact that the couple of people that post opinions similar to what we post here are not in any way related to us.

Now, on to Andy's quotes:

--The GDC presentation was a tech demo, not a game.

--Epic provides contractual deadlines they promised to meet in their licensing agreement, we do not (now do you understand why we do not?). The only actually provable clauses of the suit as far as most informed opinions seem to be stating are the ones where Epic promised "this will be ready on this date", and it was not.

Personally, in the thread I link above, one of the quotes from a poster named "Charles", when speaking about the Unreal Engine, says:

Quote:
Probably because Epic is covered in their license agreement. That would be my guess anyway.

But there's this idea out there, which is vastly wrong, that you can take a prebuilt engine, add some art, tweak some scripts, and ship a game. This is just not true. No programmer with any experience would ever say that this is even possible.

You get an engine and it is a very basic and moldable construct. It is *not* a magic bullet.

Hell, even Pariah, crap that it was, had something like four times the speed of the base unreal engine we started with. AND it had more graphical bells and whistles than what was available at the time. And all that was done by a couple of really good graphics programmers.

I personally had to make some seriously painful changes to core logic of the engine just to get some basic stuff like attaching a character to a vehicle to work properly.

Unreal Engine is made to be a functional FPS engine. If you want anything even remotely different you have a LOT of work to do. Anyone exercising due diligence would find this out ahead of time. It's not a secret.

And this is true of any engine out there. You can't buy an engine on the market and add art and scripts and then just magically ship a game.

That's talking about an engine that costs hundreds of thousands, if not millions of dollars depending on your licensing agreement.

#142 But at the very least, unreal has (and this is probably what you pay for) a really smooth asset production pipeline... and decent physics... and... and...


..and they publish change logs... :P

#143 @Stephen - That quote shown above has nothing do to with TGEA. The fact is, you guys advertise with bullet points on several functions & features that are in TGEA. Well, that's false. Those functions & features are broken.

When people buy TGEA, they want everything that you advertised. You made GDC videos and yet, you post those vids as if that's TGEA today. Your product page for TGEA is very, very, misleading. This has nothing to do with a "magic bullet", it has to do with deliverying a product as advertised/promised.

My company already has a license for Unreal Engine and a few others. I'm in charge of this game project because I am (and still) convinced that TGEA is the way to go. But it's been very difficult to explain to my management why things are broken in TGEA. It's even harder when they find out that there were no plans to get TGEA functional as advertised.

I'm no anti-GG, believe me. There's no hate from here except for TGEA love. We just want things fixed and all the whistles and bells that have been promised. Heck, I don't care if everything doesn't get fixed as long as there's somekind of progress. Right now there's ZERO.

#144 Well, attempting to continue to be as unbiased as possible here, considering (just as a way of keeping my own bloodpressure down), have noted a few high points, low points, and hopefully wake up calls here. (And apologies if this seems overly analytic. I *do* program, after all)

1- theres 'something cool' coming down the road later. No one that isn't enthusiastic themselves about it would possibly make that statement. So theres a bit of anecdotal evidence that work still progresses, and that folks aren't in a produce, sit and wait for qa, produce more loop, but actively still working the engine.

That'd be a plus.

2- That 'something cool' hasn't been included in the next rev. Wich I for one have to interpret as a lack of staff to crosscheck everything you folks want to accomplish.

That'd be a bit of a dissapointing minus.

3- Theres a bugtracker folks check. Always good to know folks know how to keep abreast of the situation.

Plus.

4- That bugtracker hasn't been used for tgea. If it works, and youre not using it...

Minus.

5- Your own employees were not aware till it was pointed out that 3 and 4 were the case...

That, to my mind at least, would be a wakeup call that somethings not right with *internal* communications, and of course, this by definition leads to *external* miscommunications, like we've seen in this thread here.

So the question is, with those 5 points in mind, is anything in particular being done to address the issue? I notice you've got a new PR guy... perhaps something to bring up?

#145 Andy: please send me an email with point by point list of the several functions and features that you state are marketed, but not implemented and/or broken. I hear people make that statement often, but have never gotten raw, point by point statements where our marketing material indicates something is present that is not.

I just went over our entire marketing information from the product pages here, and I honestly don't see any points that aren't solid. I do agree some are in marketing-speak, and to some extent that's just the way it is, but at the core level I still don't see the points people are trying to make.

#146

Quote:
But at the very least, unreal has (and this is probably what you pay for) a really smooth asset production pipeline.

I have anecdotal comments from a variety of artists over the years that fundamentally detest the unreal art pipeline at every level. I also find it very frustrating that so many people continue to declaim BSP/CSG shapes saying "but Unreal doesn't do this!" when in fact they most absolutely do. Everyone has their opinions.

Quote:
and decent physics... and... and...

were you looking for "extremely difficult networked physics"?

We don't hide the fact that our physics are designed and optimized for networkability, instead of "accuracy". Given client-server simulation synchronization, network speed/performance, and "accurate" physics, we focus on the first two at the expense of the third. Nothing says that you cannot modify these priorities for your game, and that's why you have the source code.

#147 Here is the changelog for 1.02 as presented to me June 1st. Please note that there may be some additional fixes not listed here as well, I have not asked for any changelogs since then as I have been busy. TGEA 1.02 is next up in QA and had been pushed back as stated above somewhere in this thread due to numerous factors.

The QA department at GG is growing rapidly and as a result there are some growing pains as processes are put in place and new hires have to come up to speed on the engines so please bear with us and understand that QA is doing everything it can to get these releases tested and out as soon as they are made ready for us to test.

I can't speak for any of the other concerns in this thread so I won't. : )





--------------------------------------------------------------------------------------

Effective changes:

-added static mesh dynamic and static lighting (changes also affect
interior static lighting and may affect interior dynamic lighting)
-added static mesh rendering and materials (should work with all shaders
and look like other interior surfaces with similar materials)
-fixed DTS dynamic shadow crash bug
-added smooth shading to interior rendering and checked it against
generated shaders (there are so many possible shader combinations I'm
sure I missed a few)


Commit comments:

-added static mesh dynamic lighting support
-fixed static mesh face culling and removed previously added cull
override for interior render manager
-fixed static mesh DX prim vertex number bug
-removed second call to load material textures
-fixed dynamic shadow crash bug
-cleaned up commented out code
-updated interior vertex buffer to use vertex based normals and tangent
space data
-added tangent space data to static mesh vertex buffer
-better naming and comments for the temp index used in vertex buffer
generation
-updated lighting system to TGE 1.5.2
-updated MathUtils::transformBoundingBox to use scale
-updated ConstructorSimpleMesh to latest version
-added necessary interior support methods (data may still need loaded on
the back end)
-added triRayCheck.cpp/h
-static mesh rendering
-static mesh base materials
-static mesh lighting and shadows (port of TGE 1.5.2 code to avoid
shadows from static mesh collision hulls)
-support for overriding render manager culling mode (for static meshes)
-fix for better shadow edges on lighting normal maps
-support for scaled static meshes
-improved static mesh rendering performance
-culling update reflect pass support


-------------------------------------------------------------------------------------

#148 @Kenneth Holst - You are the man! Thank you for posting the changelog! This clears up a lot!

#149 Much apreciated. and for clarity, to go aaaaaalll the way back up to the first post there: static mesh. that'd be the dts, or dif version? (having had to make the financial decision on 1.5x or tgea back when, not really up on the dynamic shadows on static mesh bit that was announced for the core product, I'm afraid)

#150 @Andy-

It's Clark not Chris. :)

I never said the next release was only bug fixes from the forums. I said it included that. I also mentioned a couple other things.

BTW, can you send me a list of the issues that are holding you up (or point me to the forum threads)? I get the sense from you that you think things are terribly broken, and I'd like to see what can be done to try to fix these things.

@Kirk-

We have a bug tracker for TGEA (and for all our products) and our employees are all aware of it.

The mistake I made was thinking it was public. I checked before posting about it, but I checked wrong (I looked at "manage users" while selecting the project while I needed to "manage projects" and select the project).

We have used the bug tracker in the past for bounties (small code projects for pay that community members can do) but not community bug reports. That was my mix-up. But we do have a bug tracker internally and we certainly do use it. We currently rely on the forums for getting bugs from the community.

#151 @Kirk: I'm one guy, and I track the status internally of(as well as teach) 4 engines, many of our 3rd party packs, and at least a dozen internal projects that aren't even in the public's eye yet. I made a statement based on slightly out-dated information I had received internally, and I shouldn't have done so without confirmation. On the whole, I normally am very tightly coupled with the internal communication processes, and can give out reliable information when it's authorized. As I mentioned in the post above, I do (and did) apologize for not confirming that specific point before posting.

As has been noted, with the community getting bigger, and our product line getting bigger, we are adding staff, and working on internal communications/process issues.

3/4 above: We use SVN as well as a bug tracker internally for all of our products. Clark, as director of the engine tech group, uses these tools more than just about anyone else in the company (except for QA of course). His only misunderstanding was that the bug tracker is not public...and yes, that was a process breakdown in both communication as well as general community interaction (it's been debated back and forth, and there are advantages and disadvantages to bug trackers being public, as well as it staying private, and I don't have a commitment at this time for it being either way.

5: see my response to 4 above.

#152 Please don't take this definitively, but in our "internal definitions", static meshes are specifically related to dts shapes placed within a BSP via Constructor--in other words, "props" within a DIF (created from Constructor).

Without being able to check (it's Saturday), I'm reasonably certain all those change log lines referring to "static mesh" are related to that specifically.

#153 @ stephen:

Quote:I'm one guy, and I track the status internally of(as well as teach) 4 engines, many of our 3rd party packs, and at least a dozen internal projects that aren't even in the public's eye yet.

Ouch. All I can say to that, really. Know that would give me screaming ulcers. That being said, hopefully things start to settle on down and solidify a bit then. Doesn't help anyone on either end of this to go putting out fires continuously. As to committing either way on a public bugtracker... Let us as gentlemen agree to dissagree on the wiseness of that then, and simply say you help your company accomplish things, I help mine do the same, and no two folks are ever going to see totally eye to eye on anything.

#154 @Kirk: It is a recognized issue, and we've already taken steps. Matt Fairfax is taking over primary engine side forum management (he's just on vacation right now), and Matt Langley does TGB specific forum management, and Dan Maruschak is now primary on TorqueX.

We have other projects going on for the education side (TorqueSchool being just one of them), and as was noted in this thread, we also are taking steps on the "Social Media" side of things as well.

It's just an always evolving process, and one that until recently has been on the back burner due to resource requirements.

By the way, having a side-line conversation with our Director of Development, and he wanted me to mention that we are looking to hire many positions, including skillsets related to engine development, QA with experience in engine development, shader gurus, and rendering gurus, as well as many more. Check out the following blogs for additional information:

GG Still Looking for Senior Engineers

We really do listen to the community's concerns, and we agree with many--when the community stated that some felt we had too many projects with two few resources, and we agreed.

We're now looking to fill quite a few key roles for the short and long term future, so if you know anyone that may be interested, have them send in a resume!

#155 @Stephen - A lot of the issues seem be to cleared in the changelog. There are other functions that are broken such as the "Mission Editor" and several functions with the "Torque Lighting System". For example, you can't add fxlight and the decals are still messed up.

@Clark - I don't know why I thought your name was Chris. Sorry about that.

I appreciate both of you being geniune and explaining the communication breakdown. It's fine really, because I think just about every company out there has some sort of communication breakdown. I know my company does.

I think both Stephen and Clark were just trying to help, by providng somekind of information to help address the issues in this thread.

#156 @Stephen, Kenneth, Clark and anyone else at GG.

Props to the whole group. These postings today have been exactly what I would hope for. Everyone's tone has been very professional and cordial. We have some solid information about the fixes. I believe we all realize there are no promises here and for whatever reason, some of the issues listed may or may not be in the final release. But at least we have an idea where things stand on the engine. And that helps.

#157 @mb - I forgot to compile a "cliff note" version of what happened today here in the forums.

Let's see, I'll try to tell you a little a bit....

Both Tony & Carmela bought a new car for Anthony. Unfortunately, Anthony wrecked it.

Silvio blew his top about the breakdown in communication. Tony was there shaking his fist and telling them, "If I told you a thousand Jersey times, I'm gunna tell you again. Keep your mouths shut! Where the hell is Ralphie?" and left the room. It was clear from then on that it was Ralphie that was responsible for giving the wrong info to Stephen & Clark.

This is just a small version.

#158 @Andy: I know it's a pain, but can you be more specific? I use the mission editor in all my boot camps, and I have no issues--it's most probable that you are drilling down to more specific areas than I do, but I'm not aware of specific outstanding functionality, or reproduction cases to confirm and resolve.

@All: You guys have seen a couple of us, as employees, publically display frustration, and that's never a good thing. I'm not trying to make excuses, but we as a company, each and every one of us, believe in the vision statement of GG, and we want to empower each and every person with the tools to accomplish what they dream. To provide a bit of insight hopefully, where our frustration fundamentally lies is in the communications process between us, and frustrated community members.

I realize that not every end user of GG products are experienced developers familiar with the concept of detailed bug reports, reproduction cases, accurate descriptions of issues and similar concepts, but it really is important that when you feel that something is not working as it should be you describe it accurately, and gives us a mechanism to reproduce what you are describing. When someone says "lighting doesn't work", it is not an effective use of resources to do much beyond saying "ok", and placing the report in the trash can...not because we don't agree, but because we have no idea what it really is the end user is reporting.

Conversely, bug reports or feedback that provide cohesive, succinct information on a problem combined with a reproduction case get fixed almost instantly in some cases (if it's an obvious fix), and at worst get prioritized within other sets of development requirements for future resource allocation.

Finally, it is important to realize that from a customer's perspective, they are making a game, and come to the relationship with very specific requirements and needs. From our perspective, we come to the relationship as a game engine, with very specific requirements and needs that apply to our market as a whole. Sometimes, these sets of needs cannot be reconciled...your game may require a specific feature or capability that is fundamental to your project, but cannot be addressed at a "total engine market" perspective.

I'll give an example of this: shoreline waves. Many users feel that the ability to realistically render shoreline waves (to mask the various issues between terrain block and water block overlap) are critical to their projects--and yes, we agree, it is very important to deal with that scenario for each project.

The problem is, the approach, technique, and implementation for each project should be different for each project. From the game engine perspective, the amount of resources (developer, designer, artist) it would take to implement a comprehensive solution for all (or even a majority) of cases is simply not possible with the resources of a small company. No matter what solution we might be able to provide, it won't be appropriate for some users of our product, and the resource allocation to provide any implementation at all simply isn't a smart business decision, when those resources could be used for other needs.

Is this frustrating from a purchaser's perspective? Yes, I recognize that it is. It means that for your game you will have to research techniques for shoreline rendering, and implement them when your time could be spent on "other things more important to my game".

I do want to point out however that it's also very frustrating from our perspective, because when it comes down to it, every single user has a different definition of what a "game engine" is, and every single user has a different expectation of what a game engine should provide for them.

Just to reinforce, I'm not trying to make excuses for any of the employees (including myself) that occasionally express frustration back at you guys--it's not professional, and shouldn't happen. I do however think it's important for all parties to recognize that the perspectives are different, and in some cases fundamentally opposed, and it's important for both sides to do what they can to work within those constraints.

#159 - Stephen,

While it may be unprofessional for you guys to exhibit frustration at us, I must say I readily would prefer that to silence on what is being worked on (information). Most of us are not looking for a "list" of planned items where we can later slap you in the face with it, though I recognize this will happen by some people at times. What Ken posted above would surfice for now.

Andy has made some quick references to specific items we to have found.. lacking(along with mapping sounds to texture abilities ie addMaterialMapping). We would be glad to provide more specific information if it already hasnt been done, and/or is required.

Thanks GG guys for stepping forward as you have done.


LK

#160 I would like to see an email from you guys...it's much easier to track that specifically than it is to link across discussion threads that cover so many topics as they grow.

That's open to everyone, but please realize that I can't respond to --everyone--. It's simply an easier way to track specific bugs/issues in specific areas. Bug reports in the bug report forums (with repro cases when appropriate!) are also quite useful, as long as they don't turn into discussions that may branch off topic.