Wow, that punk really gets around!

Considering GG can't be easy game maker and AAA engine at time, perhaps TGC should develop some "non easy game maker"
parallely?

It means a Gameguru for advance users engine, and GameGuru for hobbyists, so everybody happy.

3com

3com, this is a nice idea. but it will not work...2 gurus
because humans always want the best, so everybody then would chose the "advance users engine" and not the one for "hobbyists" ...
and then they would complain why it's not "easy to use"

In my opinion, TGC proves it can be done.
So far it is pretty impressive, but as always (certainly if not checked and done hastely) it will lack the quality that people expect.
Hence the discussion about the core of GG and also little things like doors vanishing when they are being closed or the textures that are wrong on the doors, look through a window and one looks through walls as if they are not there.
Stupid little things, but they can be enough to give GG negative reviews.

Goodnight all

You know the primary reason for that is bad models right?

It does it because part of the model clips another part of the model when animating and it tricks the occluder into thinking it's blocking line of sight to itself.

The other reasons it happens are,

1. Again a bad model, the origin point is inside the bottom edge of the model so it's fractionally underground and when it animates the occluder thinks the terrain is occluding it.
2. Bad poitioning, the model clips another entity while animating so the occluder thinks the other entity is in front of the animated object and occludes it.

None of these are really GG bugs (i've had the same issue with the same models in S2 engine), mainly bad modelling or bad placement of models. Yes, the occluder could be refined to ignore clipping if say less than three three vertices clip or something, but that's just a refinement, not a bug fix.

Yes i know, but the valuable asset pack 2015 is TGC verified which obviously leads me to think the models are decent.

And they do look decent apart from scaling and obviously textures on doors.
However, after much trying i've put the door outside in open space and it also vanishes after closing, so it must be a bug in GG.
The door does not touch the ground, so that can't be the reason.

I have sliding doors in my level,three doors on each side that slide into each other.They don't disappear ,but I don't need them you can walk through them when closed anyway.Any thing animated seems to play up in GG.some textures look great in the editor ,but when playing level they go all to crap.go back to the editor and there great again,only happens with some models and not others.all textured with the same texture sheet.i have animated bots that will look great some times and rubbish another time.There is defiantly a problem with animated models someware.
(I will post pics when I get home)

Dave

Have you tried turning the occlusion slider to zero .....
Just tried it and that seems to stop then vanishing

Then it sounds like the model has a vertice or edge that clips with another vertice or edge in the actual model while it is animating, causing the occluder to think it's blocking itself and occluding it.

As Synchromesh said turning the occlusion slider to zero should stop it happening, i don't like doing that because it shuts off occlusion for everything else, but it works usually.

Edit: just noticed you mentioned it was a VA door. If it's the ones i'm thinking of i had exactly the same problem with them, and i found with those models it was exactly as i said above, when the door animates the edge of the door is overlapping the frame, another one had two vertices that should have been connected as one, but were loose and overlapping eachother, when it animated they split apart fractionally and the two edges they were attached to clipped. With those models your only hope is to either fix it in a modeling program or disable occlusion.

hi guys, I had this issue with some doors, however, you might want to check the FPE and look at the anim start frame/end frames. Ensure start frame is not 0 and check the end frame is correct. If the start frame is 0, try changing to 1. Also, notanoccluder = 1 can help.
For doors that you can walk through when they are closed, the collisionmode should be set to 0. Door frame collision should be 1.
Doors should also have isimmobile =1

Hope this helps

That's Great info .... Thanks BOTR ..

It's not really the right topic so i'll stop about the doors, it was merely a point to make towards Lee and his crew.
This can after all greatly affect the overall image of GG and that's a shame because it is in my opinion a very cheap! good game engine for people like me who lack the knowledge to coding and modeling.

Thanks for the answers guys, i'm gonna have a look at the fpe file and see what happens if i turn down the occlusion

Currently i'm just busy with terrain and entities in order to learn from it.

Eh guys, nearest to this thread, you can find some interisting solutions about occlusion, Lee are baking for the next update.

https://forum.game-guru.com/thread/216444

Some time I've got thats issues with different meshes, even someones composed for a lot of pieces, in that case I had merged them into single mesh (attaching all parts), and it works.

It looks like making frame + door a single mesh, do not raise the error.

Conclusion, better wait Lee fixes via next build. Just my thoughts.

3com

So with respect to the voting board, perhaps the reason some items are getting more attention than others is the actual weighting involved in the choices.
I am willing to bet they are a simple point value (1-5).

This means for you to get items you are very interested in, you have to vote 5 for what you want and 1 for what you don't.

The problem is that the intermediary values on these types of boards cause a massive skew towards very average and generic items.

The solution is to offer a limited amount of choices (i.e. you can only vote for 3-5 total) or to weight the choices differently.

I personally would run it from 1,2, 3 ,5, 7 values. This way you have a simple hedge towards items that are considered 'very good' or 'top priority'.

Not sure who is in charge of the voting board, but that's my idea.

I've actually found that having the door and frame in the same model makes it more like to vanish.

I just merged one of my animated models and it cured my texture problem,so that's cool .

Dave

Man , I have sit and read this thread from start to end, and I must say,
there has been said a lot of things. fact remains that not one of us would be here if it was not for GG / Lee
and the passion we have for games.

I'm a new comer and have not spend 3 year like some of you with GG.
but what I have seen here in a short couple of months is, Game guru is still the passion for a lot of
you gamers here, and im sure Lee is doing the best he can. with the support of some of the most talented
people around here that I have seen, ( and a little less mouning, ) im sure Game guru have a long live still ahead.

from my side I don't think unity or unreal is the way to go.

@Lee Thanks man , for a awesome job.

Pcs.kiler

The standard door script that comes with Game Guru does that - the script needs some work.

Try this modified script. It is not perfect but it works much better.
- collisions turn back on so you can't walk through the door after first use
- prompt messages change and appear after door has finished animating
- prompt messages for door when using key now work

The player has to be quite close to the door before they get prompted to open\close.
- if you want them to work when the player is further away adjust the PlayerDist < 85 to your liking.

Hope that helps.

Back on topic. I have doors that overlap the frame when opening closing, and also doors that touch each other when closed, and I have no issues with them disappearing, even with occlude up to 100.

The disappearing problem has to be sorted in both the model and the fpe.
- the model should not use the first and last frame of the animations
- the fpe should not call the first and last frame of the animation

Reliquia...

I've adjusted the fpe file anim from 0,30 to 1 and the result was a vanishing door as soon as the animation starts, when i close the door it reappears until the end of the animation and then it vanishes again.
The rest of the fpe file settings were as mentioned by BOTR.
Then after adjusting the fpe file anim back to 0,30 i've tried to turn back the occlusion, only when it is 0 does the door stays visible.
Then i've put some other models from Rolfy's interactive starters pack and some beach houses.
Funny thing, with occlusion at 100 and no tweaking, the door works as it should, it does not disappear when it closes again
But delete the other models, close GG, start it up and load the map again, it is back to as it was before, the door vanishes when it is closed.

I meant to add that if you change the start frame from 0 to 1 then you add 1 to the end frame. To double check I open up the model in say Fragmotion and check the anim frames, so usually it should be 1,31 in the FPE and not 0,30. Usually works, but maybe the issue is different for you.
Also check isimmobile=1, notanoccluder=1 (see example FPE code below generated by my welder tool that works in GameGuru, example is the castledoor from the castlepack).

;Created by SegAutoWelder v3.5.7.7
;header
desc = castle_door1(use)

;visualinfo
textured =
effect = effectbank\reloaded\entity_basic.fx

castshadow = 0
transparency = 0
;orientation
model = castle_door1(use).dbo
offx = 0
offy = 0
defaultheight = 50
offz = 0
rotx = 0
roty = 0
rotz = 0
scale = 100
collisionmode = 0
defaultstatic = 0
materialindex = 0

;identity details
ischaracter = 0
isimmobile = 1
forcesimpleobstacle = 3
notanoccluder = 1

;statistics
strength = 100
explodable = 0
debrisshape = 0

;ai
aiinit = appear.lua
aimain = door.lua
aidestroy = disappear.lua

;sound
;(IF AUDIO FILE NOT FOUND, FPS FILE COULD BE POINTING TO INCORRECT DIRECTORY,CHECK FPSC AUDIOBANK AND SEARCH/COPY AUDIO FILE OVER)
soundset = audiobank\user\scenery\doors\lock.wav
soundset1 = audiobank\user\scenery\doors\close.wav
;spawn
spawnmax = 0
spawndelay = 0
spawnqty = 0

;anim
animmax = 1
; (IF DOOR DISAPPEARS DURING ANIMATION OR IF YOU CAN STILL WALK THROUGH DOOR AFTER IT CLOSES
; CHANGE 1ST FRAME 0 TO 1 BELOW AND ADD 1 TO LAST FRAME E.G. ANIM0=0,30->ANIM0=1,31)
anim0 = 1,31
playanimineditor = 0

Very interesting conversation in this thread. Not a whole lot regarding Lee's following statement:

"Longer-term however, I am eager to learn who in the GameGuru community would see the logic in swapping out 'Lees DX9 engine and core tech' for something more modern such as the 'Unity' or 'Unreal' technology layer. The interfaces, file formats and built-in editors would be much the same as we have now, but the underlying layer of technology would be serviced by another company to provide those much requested elements such as PBR for realistic rendering and multi-core performance (not to mention cross platform capabilities)."

I am a retired old timer programmer (assembler). I am currently learning Unreal. While it is much easier than using an assembler language for development, it can still be overwhelming at times. The REAL value of GameGuru is the "absolutely easiest to use INTERFACE". Imagine a product with the GameGuru interface providing you with the power of Unreal - need I say more. The GameGuru staff (which is small) would only have to concentrate on the interface between GameGuru and Unreal instead of having to "recreate" all of the functionality of a quality game engine.

Sounds like a plan to me.

Funny as it may seem, I landed here because I still toy around with FPSC.

And I thought, let's check out GG (after all I have bought the Steam version and most of it's model packs) and play some of the games. At least I thought there must be a BIG new bunch of (at least) single level zombie-apocalypse-on-a-spaceship demos/games made since I checked last year....but no. Where are they? Another full year has gone by and even counting the embarrassing ones, there aren't more than a dozen new games around? And the people who did the more notable ones are mostly the same who also did their share of FPSC games?

So I sat down and tried it myself....for half a weekend. And I'm back where I was 3 years ago. TCG has abandoned FPSC, an engine that enables you to easily create indoor maps but is practically useless for outdoor levels and is severely limited all around - to market GG, an engine that enables you to easily create outdoor maps but is practically useless for indoor levels and is severely limited all around.

Don't get me wrong, I don't regret the money I spent on both FPSC and GG, just as I don't regret the money I spent on all those Warhammer armies. In both cases just toying/tinkering around gave me endless hours of fun, even if I rarely finished anything (xcept for my 8000 pts Ultramarines army)

But I don't see a future for GG, actually I still value FPSC as very robust and if Lee happens to give up on GG too, I will definitely not invest time or money in ANOTHER TCG engine.

i hear ya...

Hopefully the new building tool helps out with the interior stuff. I personally just need more perfected snapping and precision tools/method. Still waiting on all the awesome stuff FPSC had that GG does not currently (swimming, water raising and lowering in engine and in game via script, particle system, material indexed impacts, player+enemy footfalls, and debris, wide range of shaders, etc).

I'm glad the ability to load more than 2 sound files is now possible. Before we were limited to just sound0 and sound1 in the FPE, but in FPSC it was near limitless with the audio command in FPI. Glad GG caught up. Though it took quite a long time... far too long. For games that may require multiple lines of dialogue from a single entity, it was near impossible in GG for the longest time. This was aggregating me. Additionally many of the creatures from FPSC were limited to just two sound files yet used to reference more than 2 back. So it really was starting to become apparent that GG had limitations.

GG is so close in most respects ( from my perspective anyway )
I can achieve 99% of projects I try but am always hindered by the 1% of unfinished or unavailable features ( Mainly AI and third person in my case ) Yes I know the engine core needs attention but that's not actually stopping me creating at the moment

These are the main things i am waiting for myself, as well as some more (grr cant rememeber words!) shaders and the like, everything else can be achieved to varying degrees by workarounds and LUA.

One thing specific that i really want, i'd love to see AddPlayerWeapon(e) changed so you could replace (e) with the location and name of the weapon that way we can issue new weapons in game without having to use the actual models, this would be especially handy for creating am ore streamlined ingame store etc.

Oh come on! here I thought I've illustrated that you can make indoor maps perfectly well and fast.

I agree wolf you have prove this on so many levels. we do so much without the EBE. as great as the segment system was in fpsc it had it's limits could not go far with the type of level design you have in your game now. conskit was a failure because lets face it who would want to build a level brick by brick. guess no one did not see the bad idea in that. now we are back to segment walls and windows. You all speak about how good unity is but the modellers in the unity store creates their own inside level kits for unity. which is what we have now in the store and what Wolf has use in his game. snap and grid mode is the way to go with guru. the segment system call on a lot of draw calls in fpsc which only allow for small maps to be created. these kits in the store use less of that and memory. if Lee could just get the characters obstacle system around these kits in the store then we would be better off using them. for EBE we need some type of batching keep the draw calls low. my proof that is in Lees video Broadcast #54 : A Sneak Peek At The New EBE T 13:08 you can see his draw calls was high. placing things down piece by piece is not fast at all. EBE is more work then you all think and will many flaws like the segment system.

No, you have illustrated that YOU can do that. We mortal beings are trying to catch up, though

Good grief! No! Location and name have no place in a command like that! If you want that sort of info, use variables or an array. What if there were 100 swords called steel sword? At the same location? How would a command like that help at all? I mean if your planning to add a weapon, then generally the player is next to it (as in picking it up), so location is not really relevant and using the actual name of the weapon is really bad coding in general. Using the entity ID number is by far the best method. Need to look through your weapons? Far easier using numbers to loop through than having individual names.

Whatever reason you have for wanting this, I'm sure there's a far better way round it

I still want more speed. Every project I start ends up being abandoned because of this. I've been giving GG a rest for a while of late due to it's speed. In the meantime I've been playing a few games instead. Playing them reminds me of just how far GG has yet to go before even getting close to them speed wise. There pretty old games as well. So, I'm taking a bit of a break as I don't see this being addressed soon. Every project is the same, starts well, I start to get my teeth into it and then boom GG can't handle it. It never takes much. I do so much testing of early levels to check how fps is doing it isn't funny. In the end it never matters, I always end up with speed issues. The only way around it is to limit your game to very small levels, or not many unique entities. Even then loading times are not great and so having to load a level every five minutes or less may well be very annoying. It's annoying in Half Life 2 and the loading takes seconds! In that though I have literally had to load between levels at 30 second or so intervals, which just breaks immersion too much, despite it being so fast to load.

It's getting better, bit by bit, but very slowly. For me I know I will be very glad to see that red polygon bar actually drop down. It is always in the red from the beginning before I even add anything. I think the terrain is a big drain and could do with improving as well. Flicker, not a great issue to have. In this day and age it is almost intolerable. Z buffer clashing is awful and there is generally just a lot of flickering edges that just should not happen. Some of this used to be better, but was dropped for speed increases. now as said, I'm all for speed, but not at the expense of my eyeballs. The only impressive levels I have seen in GG tend to be in the dark. There's a reason for that...

I like the sound of current progress and hope Lee continues to add core improvements along the way. There's only so many little projects I can work on while waiting for GG to improve to the point where I can make a game. I think GG is almost there (if you have custom media for your game. Specifically for your game and designed to keep speed up.) If you can get that, then your scene will probably run quite nicely, especially if you can turn off that hoggy terrain.

Rolfy's demo included with the latest update shows it can be pretty smooth and still look decent (in the dark at least). Same goes for my WIP New Beginnings, although I have spent hours and hours on the second level and so far had to scrap it twice because of speed issues. The first part, which I did a video on is near complete, just needs a few timing issues fixing and is nice and fast overall. Still in the dark though ;p

Wrong location :p You are misunderstanding what i mean, i mean location as in where the files are stored in the file structure "modern\\col911" etc. The whole point of my idea is so you can give your player a weapon without placing the corresponding weapon on the map.

It would be something like:

addPlayerWeapon("modern\\colt1911")

and so forth.

Yes, I can gain about 20 frames by turning off water and terrain in GG which is way too much for these features.
I'm 100% with DVader in terms of speed... we really need better performance...I still see this happening with the illusive rendering engine overhaul one day. (we already have an improvment with Lees last update which I am grateful for.)

I don't agree with the notion that GG games only look good in the dark, I think you can do decent scenes with it and that the lack of filtering and smoothing is not that bad, but I guess that is up to personal preference. Lack of AA and jagged edges is something some people can't live without and others don't notice....I'm somewhere in the middle. Second bright example from the same game. Third bright exampe, interior.

I don't want to show off (well...maybe a little, but I have a w.i.p for this.) but I feel that a lot of statments on here don't take community achievments into consideration.



Well, thanks Ertlov! You have to prove to me that you can't do it as well before I believe it, though. Plus I wrote some tutorials on how to do it. Combine this with basic leveldesign knowledge and a touch of madness (which is something you have more than a touch of) and you are good to go.



I agree! I'm currently trying to do something with zones and waypoints, but its just not the same...it clearly feels like a workaround.
I try to get the same quality of enemy AI as I had in my old games and I think I can manage that through tricks and sorcery in GG but I think we NEED that AI fix. Especially for people less willing to delve into the occult dephts of GG.

...and here I wanted to mostly stay out of this thread.



-Wolf

Scenes can look good in bright light on occasion, those pictures look pretty However, to keep speed to a decent level you generally have to reduce draw distance and such to keep speed up. Generally easier to do that in the dark Especially with a city scene like you posted. It's just easier to hide some of those annoying flickering z buffer clashes on a lot of the media available in the dark. The media is partly at fault here, TGC's city pack has several objects that really suffer badly with flickering windows and such. Mainly caused because the windows are simply stuck on to the side of the buildings, rather than actually part of the model. Hence GG has difficulty working out which should be shown first because the faces are so close. I'm not sure if GG could improve this by tweaking the camera's settings a little, I know it was possible in DB to reduce flicker quite a lot with a simple change to the default camera view settings. Same with AGK and probably many other languages out there.

There are also some rogue objects as I like to call them. You can have a scene running well, add in a few of these objects and fps drops like a stone. When I notice these I normally let Lee know, as it's normally something he can fix, so there's obviously much to consider when looking at performance. Sometimes it's not just GG at fault, the media can sometimes be very hoggy. That's why sometimes you can knock up a level and it runs great, other times it chugs, it can be as simple as a couple of objects that are in the scene that GG doesn't seem to like.

My opinion of GG at the moment is this (I'm probably repeating myself). If a couple of good artists and coders got together, making custom media for the game to help keep polycount and drawcalls down - Then, I think GG could be pushed quite a way and although your still not going to beat Skyrim or GTA 5, would at least look good and run fairly fast. Probably not open world though, although media would improve that as well, most improvements would benefit a more traditional shooter. The biggest drawback here would be AI as we all know really needs a bit of TLC. One thing here is the fact most media will not work with AI without altering the FPE files. I think this should be attended to for all TGC's media at least. We know that buildings with interiors and floor sections will generally want AI to be able to walk on them so why not make that default? I realise this is a time consumer, but I'm sure some forum users would be willing to lend a hand here I've started making copies of items to fix them when I find them, but I end up with a bit of a mess of identical items that way. I also fix the items directly, but never quite sure if that is going to be reset the next update.

I agree that you don't have to have a dark moody scene to look good, but in GG that is just more difficult to accomplish at a decent frame rate. Personally, I think the filtering options should be put back in, with an option to turn them on and off yourself. Most games have this ability. Many negative comments about GG games is the severe lack of options in this area. We used to have it, but it was removed for performance upgrades. I don't consider removing features like this a performance upgrade, I consider it a cheap way to get fps back. Give us the option to enable disable according to our PC's spec. Talking of cheap performance options, reducing the distance AI animate and work with to 2000, is again a pretty cheap option. It doesn't take into account a sniper weapon for instance. It used to be 3000 and was pretty bad even at that when you consider you can see them clearly in a T-pose or simply frozen in place/floating when viewing with a sniper weapon or just on a hill looking down. I generally have to enable always active anyway for AI to behave even remotely well, so I won't see any improvement here anyway. I can't have AI freezing when clearly in view, it just looks awful. Perhaps a option to change each entities max distance range in the editor would be more useful for many.

Anyway, I'm typing a short story again, so I will leave my thoughts there. I may moan at times, but it's all in the hope that GG will be improved in the future

You can do this already with e,g,:



Cheers.

That only gives you a temporary weapon with no ammo, as soon as you switch to another weapon you lose it. The function needs to be added to AddPlayerWeapon and made as a permanent weapon

if you want it a permanent weapon use

SetWeaponSlot
SetWeaponAmmo

Can place the weapon in any of the 1-10 slots and adjust the ammo. The weapon IDs relate to the list you can see in the 'Has Weapon' drop down box in start marker properties.

Thanks cybernscence I'll check it out tonight, if that works I have a great idea for a script.

Just one more question (after that i won't derail the thread any more), how does that work with weapons that characters drop?

As far as i know they use AddPlayerWeapon(e) and when you pick them up they assign to the next slot available. Now, if a character drops say a colt911 and it goes automatically to slot 1, then later on i use a script that gives them a sword that's assigned to slot 1 it will override the slot 1 and replace it with a sword.

Is that right?

Now, for normal weapon pickups placed in the map i can use a custom weapon pickup script to assign them so it won't mess with slots. But is there a way to avoid the issue with weapons dropped from characters?

This is why i'm hoping that AddPlayerWeapon (e) could get a change so we could specify which weapon to add.

I fully agree with all who said, let's finally reset this feature vote list. As was stated many times before, many of these things can already be done by scripting, even by an amateur like me. What we (okay I) really need is a day/night cycle and a new water system (including swimming/diving) and of course access to all the engine functions/features via lua script. Maybe the last is the most important. For example, if I would have access to the sunlight and the skybox, I could do my own day & night cycle.

Of course, I didn't forget about the core features, I mean performance improvements and all the visual aspects, where Game Guru is ages behind nowadays game engines, unfortunately. But - for example - a new day/night/skies/water system would improve the visual aspects and possibilities of this game engine so much, that many new buyers could be gained.

Sorry, my English is not so good, but I hope that you understand what I mean.

@ Belidos

didn't notice your edit until now

You could script something like this to add weapon to next available slot so as not to override those already held:



Assuming I'm understanding you correctly

I have converted a lot of the segments from FPSC over to GG. They work okay with the snapping features. However once you make multiple floors it becomes very problematic unlike FPSC. I may release those segements and make a quick tutorial so at least people can start making single floor rooms with them.

I'm just feeling a tad impatient these last couple months. Whenever that happens I try to do whatever i can to help move things forward with what little i can do.

I like GG.
I have tried Unity and Timberland, or whatever it's called.
Both are a pain in the ass to use. Far to complicated for part time users like me to spend valuable free time on. Plus they are very buggy on PC.
To get the really high quality graphics for both then either buy premium models costing $100s each or make them yourself, whch takes around 3 month for a fully rendered 4 appartment house.
Chacter AI scripts, forget it. GG is a million miles in front of them both for off the shelf scripts.

What these other platforms provide is dedicated team work that can produce AAA work.
GG can't do that at the same level in 2016. But the graphics that GG can produce is very good. In the tunnel and sewer models on the Store, these are as good as what UNITY and TL can produce, almost, but they are very acceptable in any PC game. Because they are a confined visual, ie a tunnel, with good lighting and atmosphere, awesome stuff.

Some of the work that I have seem on youtube from UNITY and all other game engines are not even as good as what GG produces. The way that trees, plants and grass move with the wind is just so so bad. I like the way that GG plants move, They look natural.
The buildings and scenery is flat, the AI script activation and related animations are sad adverts for the engines they were created on. But these are people using these engines as a one man team and the output is bad. GG with one man teams produce first class graphics with awesome lighting. GG can produce the game for visual pleasing.

It then comes down to FPS. That game reviewed by JIM on youtube, that was just bad game design. The demo level I made with over 40 Ai characters still works well at 25 fps. It's all down to game design. The fps drops every time the player moves in the scene, which means that the scene has to be re drawn. The buildings have to re-done.

Solution, don't mix lots of characters with lots of re-rendering. USE Lightmaps. Cut down on pollys. Out of all the games I have played, which is hundreds, I couldnt tell you what a scene looks like when I am shooting the baddies. The scenery is not the focus of game creation, it is the player interaction. For evidance of this just look at No Mans Sky, Civilization 6, Minecraft, LEGO, Engineers, and many many more.

So why do I like GG.
Becasue it is fast to produce intricate player interaction games. And when I want high level detal, like at the end of a shootout or the begining, up the graphics details, this is the main parts of a game that gets noticed the most.
GG can only improve. And every little change all helps to make the interaction between player and the game much better.

Very well put, Mortt! I share the same sentiments about GG. I've never tried Timberland, or whatever it's called, though, but I have tried several others. This engine (and Lee) just needs some TLC and a whole lot of time to mature. I think most around here feel the same way, otherwise they would have moved on by now. Some have moved on, of course, but occasionally pop their heads in here from time to time. For me this is just one of a few hobbies/interests, so time (barring death) is on my side. For others, it isn't. They have actual time commitments to their projects. Most of the fun I've had so far has been learning just what all is involved in making a decent game. There is indeed much more than I ever thought when I took my first bite about 15 yrs ago or so! I am just one man and my day job sucks anywhere from 8-14 hrs a day out of me. What I have learned in the TGC forums has been a slow process, as free time is very valuable to me as well, but well worth it! These guys are great in my opinion, as are the forum members!

In the meantime, let's see if we can keep this thread going until the OP has to request that the title be changed!

Return FPI back, please! Lua and extremely large map size killed FPSC-Reloaded .Now this engine is only suitable for making screenshots... (((

Is it? I'm working on a game, you know, one that moves. People like Duchenkuke,unfamillia, Bugsy and Ertlov have already released some games (to name a few) and I hear Bugsy is going to release a new one soon.

LUA adds possibilities and so do larger maps. You don't have to use the space but its sure nice to have for backdrop architecture.



-Wolf

You can't be serious?

o_O

I hate Blu-ray ... I want Betamax back ?