Pixel Perfect

All in all, given the timescales and the fact that the team had never worked together before I think you did quite well and certainly better than any Leadwerks Community Project in the past which from memory failed to produce any playable content. I'm sure valuable lessons have been learnt by all contributors. It's a shame but, with LE3 on the horizon, it was always going to be questionable whether you'd get the input you needed by continuing with the project.

Looking very nice Andy

lol

No, it's been stated there will be no support for terrains in the initial release.

You're welcome. The tempation is always there to just pass and reference pointers directly but it gets more difficult to keep it all togther as the complexity grows. It's less efficient but a lot more robust to use a proxy.

Thanks Flex, thats pretty much what I did in klepto2's code and it seems to work well enough, although the simple flipped plane is a quick solution too!

Yes, but you indicated that some of these pointers will be held by other classes too, which is where it all starts to go wrong! The only point I was trying to make is never pass pointers if you can avoid it. If any object needs info on another object then don't pass it a pointer, pass it some unique reference and query its manager for the information, if it's manager's deleted it it will pass you a relevant return, if you call a pointer to something that no longer exists you're going to crash! I honestly can't remember the last time I had a crash using this type of access to data because the access is always via the object that knows if the data still exists or not.

I've been playing with klepto2's day night system (very nice it is too) but spent some time last night modifying the code to try and get round this issue I'm having with the sun still casting shadows when the directional light is below the terrain which just looks weird. I noticed this years ago when playing with a simple day night system myself. The terrain does not appear to cast shadows if the light is shone from beneath it meaning that any shadow casting objects on the terrain still do! I've had some good success by introducing a dual intensity system, one for the sky (left as it was) and a new one that kills the directional light intesity when below the horizon. Just wondered if I'm missing a setting somewhere that would prevent this in the first place?

Thanks shadmar, might have to be a customised shader unless anyone else can suggest anything as it's for an animated rain effect and needs to be in the transparent world but using the blend mode. I might switch to particles for this though so it might not be a big issue.

Yep, never reference things that go out of scope. Whatever mechanisms you use to prevent this are entirely up to you. Just a concideration Rick but I don't loop and call instantiated game objects update functions directly at all but use an event driven system that each game object simply subscribes to and they get called automatically every time I raise the event in the game loop. This is done by having support in a gameObject base class that all game objects are derived from (in much the same way that mumbles was describing). When an object gets deleted its destructor unsubscribes itself from the event system ensuring it never gets called once its been destroyed. This way only the creating object (usually a manager type object) needs to maintain a list of pointers and is responsible for deleting any objects it manages, no other pointers are involved to complicate the issue. All access to the Manager owned objects is via the Manager although the Manager may pass pointers to other Manager objects to its siblings so they can call other Manager public functions as required.

Joking aside, and there have been some funny responses in this thread, BES has it exactly right. The engine is currently an ongoing work in progress and is a private project aimed at producing at least some playable demoes of two game ideas I have. I am also teaming up with an artist in a joint venture to explore the possibility of producing another first person shooter in a genre we have a common interest in. Thanks for your interest though Juggernaut and, as BES indicates, I might well release the engine once my game projects have reached completion (and of course as it uses LE2 you would need to be a licenced owner of the SDK). I suspect you are probably looking for something you can use now though!

I seem to recollect we had a 'lighting=0' setting for the material files which disabled lighting effects on the material. It looks like this is no longer available, is there another way of doing this?

No problem with the furniture, buildings with interiors would be great ... could we have windows that at least allow for easy texture replacement for transparent glass if not transparent already. Having opaque windows destroys the illusion of reality! Even better

That looks nice but to be honest I would only be interested in buildings with interiors and transparent windows.

Thanks Mack, so it's class.lua. MG had suggested class.lua too. I was going to replace the entire set actually, rather than append to it, unless you know of any reason why I shouldn't. I'm assuming there are no hard coded references to these. It's just my engine already defines a set of Entity Type names and associated values and I'd like to continue with that and have it reflected at level design time within the Editor. So how many of the Lua script files are redundant legacy stuff? Guess I need to sit down and go through all the script structure at some point.

I wish to implement my own set of Entity Types when assigning EntityTypes in the editor; as the currently provided ones in the properties system don't meet my requirements. Am I correct in the following assumptions: The properties combo box simply returns an integer representing the entry position of the chosen type which is output as the collision type in the sbx file. The collisions defined in the collisions.lua file are then implemented based on the constants defined in the collision_const.lua file So all I would need to do is redefine the set of Entity Types for the combo box in base1.lua and add my own constants and collision definitions? I assume the Engine implements this in the same way as the Editor.

LE3 is still in development and you can't buy the engine ... it's not for sale yet! When it is released the price will be announced. The only engine currently available to purchase is LE2. Whilst I appreciate it would be nice to know in advance, this is true for any product in development. There is always some point in time which beforehand, the price is not known. People just have to be more patient.

accents are not a 'problem' NA, would be a boring old world if we were all the same

Nope ... I wouldn't stand still for too long, they'll daub you in green paint for that Oh ... and it's Cymru (Wales), Welsh or Cymraeg is what they speak and what's so hard about saying 'Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch' See, this is much more fun than talking about boring old release dates!

sounds illegal

Looking very natural indeed. Nice work yet again Pascherik.

To be fair, Josh always said it would be ready when it's ready! Wishing it here all the time, like a lot of you do, will just increase your frustration. It's a commercial decision on Josh's part as to when he makes the release details public and until that point you are not going to hear anything.

lol

Congratulations guys, you came together as a team and actually delivered and that counts for a lot. Just keeping a community project going to the point where you have something playable is a feat in itself! I'm sure, as Aggror's summing up is testament to, that you have all learnt a lot from this experience which will stand you in good stead for any future project/team work. Well done

Although far from ideal team work usually involves some compromise and it's important that team members are kept 'in the loop' and involved. It's team work that gets games completed in the end so if it works that's fine, it's all smoke and mirrors anyway. The end gamer cares not what coding methodology underlies the game, just that it works and it's fun to play