Its long been the case that Mods don't lock threads just because people disagree, sometimes strongly about various things and everyone has an equal right to make their opinions known and such is welcome and encouraged even if it goes against a majority opinion. Majorities are not always necessarily right but thats democracy as it were. Threads are usually locked if inappropriate in any way or deteriorate to unacceptable offensiveness and so on, so as to break the AUP or rules and or bring TGC into disrepute. There are other reasons but generally speaking having an opinion and speaking up is not one of them.



Much like a majority opinion is not always necessarily right so to is the case with many things - products and software and many other things. Software user interfaces included so just because other software users specific interface features, no matter how professional and expensive for example a piece of software might be in many cases such software classed as and accepted as professional world class software and sometimes world leading class used by the vast majority of people have depending on an individuals opinion interfaces which are indeed extremely poor and bad in day to day use though they may look pretty, professional, complicated and expensive so must be good Yes. Well no they are not necessarily.



There are many users of TGC products which use on a daily basis and over time have and do use literally hundreds of software programmes and many of us have experience of both making games and using most of the game engines which have been around for the last 20+ and more years at least so do have some considerable understanding of what its all about.



As to game engine editors and Reloaded in particular personally I don't have many issues with it as a priority at least and have more concern with core engine issues and features that provide for making a game relating to construction and content deployment of a complete game to end users as a priority and their experience of playing it and not my experience of making it.



Having said that first off I would have to say that Reloaded and its Editor and the use of Editor based around the 3D world, real time editing and compile and so on is an approach that has been much needed by indie developers and is a boon to development which no other engine at this level quite provides and despite any similarities to earlier FPSC versions Reloaded is nothing like it looking past the visual interface. It is a different animal and a far better development tool by a large order of magnitude. This will prove to be the case in actual developments by users and it does and will allow users to develop in a smother and better pipeline and to output much more complex, larger and better games as a single individual developer. No other software will provide for a single indie developer to put together a game in such a timescale. There are many benefits despite users wanting much more and fair enough there.



Personally I though I am OK with the current editor, am used to the style of working and developing with it and can also live with it I agree that the Editor along with the rest of the product can be improved withing the bounds of what makes things better and not for the sake of what it looks like. There must be a real and not perceived benefit in practical application and not if its something that just looks nice and someone else has it. This is not a UI competition or software designers interface design ego trip. Too much of that in pro software which hinders practical day to day use by bad design.



This is not the first time this has been brought up as with most engine and or feature requests. Suggestions and requests for improvements to the interface and editor have always been asked for over the years as with anything else.



There are probably quite a lot of things and a fair list which have been spoken of over the years. I have no personal preference or objection other than ease of use and avoiding hindrance to development for "All" users by making day to day use more difficult than the worth of it.



There are improvements that could be made and any development software of any kind would and should have access to a wide range of things internally to itself being accessible and usable if possible without resort to external environments. e.g. Internal access to setup.ini and script editor and so on. No argument there as often said by me "the more the merrier".



The only concern is that the usability should not be impacted and that's almost impossible as any device only has a certain amount of real estate screen, so the task is always to minimise the impact in a way that enhances and not detracts by things becoming a screen or other nusiance and the disadvantages overiding any benefit.



Whatever many things could be very helpful for example an object/entity list with object name/user definable with object/entity "Number" so that one could use for instance a select object and go to command in editor directly so the specific object can be edited in the 3D editor. Such might also have the benefit that if for instance an crash error occurs as it sometimes does due to an entity error for any reason and there may be many then if you can easily find an offending entity by number from any error message when a level will not run amongst the thousands of entities users could have in a level then you can remove it and correct the issue.



I am sure there are many such improvements and additions could be made. The point is that nothing should detract from the software use as an aid to development so any additional main editor window features should be as menu items, dockers or windows and such like that are not hard coded as part of the real estate screen space but are callable, collapsable, hidden, minimised removed and so on. We don't need anything using up any more current editor main level view window screen space in the main editor. No 4 screen views or properties panels or anything else that cant be hidden or removed by the user themselves if them find them a bind in practical day to day use of the editor in their development sessions.



Widgets can be a bind if they are not smooth and precise and respond well to selection.

Hi Lee



This is the perfect top 5 list for the editor. We need to GREEN light these features.

Hi All, I have added the IDE Editor Enhancements to the voting board:



http://fpscrvote.thegamecreators.com/



If you have votes in the character creator and want to support these new editor additions, move your votes across and show you care Once I am through finishing the 'extremely core stuff' this voting board will be our way of seeing which way the wind is blowing!

Thanks, Lee, for putting it to the vote. I am thankful that you are here and willing to listen and improve the product based on feedback.

Got my vote.

voted also, 4 points.

I will second the request for a transform gizmo. Trying to keep track of an object's local rotation is nearly impossible using the Shift+number keys.



For anyone who doesn't know what a transform gizmo is:

@bond1 i like how you used a teapot lee will surely make it happen now

One small thing I'd like to add is that you really should have a dedicated tools or GUI programmer on your team. That guy should be focused solely on creating a great IDE by hooking into the game engine core. Then, instead of these features just being an after thought or need to be voted on, they could be incrementally added and improved on a daily basis. That would free the core engine programmer up to work just on core engine features. Tools programmers are generally a different breed and have a whole different grasp on the needs of the users of those tools.

@tomjscott : You have to remember they are a small team doing an excellent job and no doubt on a tight budget for it, More people more cost more charge to the end user

They might be able to find a volunteer to do it.

The problem with that is not many people with the skills will do a job that in-depth and time consuming for free... it isn't easy to redo the editor with all the features everyone wants.

Personally I will not vote for this as its not to me a priority over and above numerous other things some of which are in the vote list and some which are not even in the voting list which should be in priority to this and additionally it will not suit everyone across the range of the user base in my opinion but perhaps will for those who are more advanced or experienced users posting here.



Widgets in particular rotational tools in this case are fine if they work well but world, local, entity rotation can be a nightmare with widgets unless its done well whereas keys with fixed rotation values have precise values per keystroke and are certain. A lot of users wont know one axis from another or if its local, world or whatever. Thankfully a rotational widget is fairly intuitive but widgets can get to become very complicated.



Rotating world scene or entities as said is fine if the actions work smoothly and precisely so performance must allow it on all machines. If you are struggling for performance and fps, dropping frames, low on memory and so on rotating can be erratic, jumping, juddering and so on and can drive a person nuts. I have seen it happen so doing it well is necessary. If I am rotating I expect it to be pixel perfect and exact so anything less is infuriating.



None of that is a reason not to update this and the editor of course so go for it but do it well please.



It just wont get my vote in priority over other things as someone who is not particularly concerned at this stage as a game maker to worry too much about placing an object entity precisely when I cant even build my complete world to place my objects into that needs to be full of the many other things and other features that don't yet exist or are not yet in place and many others that are not yet even contemplated or listed in the feature voting list.



Seems like some users want to just get on and build something now and cant wait so they can add their objects to place or rotate as a matter of priority. I am looking for a lot more world features before I would worry about finishing a game by tweaking placements of minor objects when their are major world/game making features to look to seeing yet to come and needed introduced. At this stage of development we are at very basic world object building stage, not that we have buildings even yet - excluding entities of course.



I am all for features lets have them but I wont be placing a lot of things on tables and alike for while myself so don't need this as a priority.



Tools programmers or any other programmers do not necessarily know what the majority of game makers want or need or whats best for them at all. They certainly don't know what I want unless they ask and its likely they wont have a clue whats best for me and that goes for any other user. A different breed is probably correct in which case the wrong breed what is needed is the same breed on the same wavelength.



Thankfully TGC themselves are now on the wavelength of indie fps end user game makers and hopefully will continue along that line in their order of priority of development thinking.

It's a chicken and egg situation. A great IDE will bring more pledges, which will pay for the GUI coder, needed to create the IDE, and so on. All we can do is grow organically and improve the IDE in stages until the pledge levels allow us to bring in someone full-time. In the meantime we have a core team capable of implementing the IDE features relatively quickly once we discharge our other duties so I am not concerned, but it may take some time to materialize if the IDE gets few votes.

Voted 3 points, so medium priority for me, more important things need seeing to first, but it would be nice to have them eventually as they are standard in most other engines.

Reallocated the one point from AI, since that's happening anyways.

allocated one point, conkit and 3d importer higher up the list for me

No, you are not understanding this at all. I'm talking about a person who not only understands programming great GUIs, but someone who is fluent in level design and making games. You see, core engine programmers don't need to know anything about that. That's what I mean by a different breed. The guy who codes DirectX shaders and pushes polygon optimization isn't usually the guy who is designing levels and building games. He may have done that too, but not necessarily. So, I'm saying you need a guy who is a great programmer who is fluent in building game levels. That guy is definitely going to know what you need because he's someone who is very experienced in doing it himself.

The game development landscape seen rapid changes, and as such level designers, isn't a proper job description any more, has been for a long time.



In general, level designers are the 3d modelers, the scripting people, shaders and other menial tasks you would have generally have passed to other members of the team, due to budgets, engines changes and general changes in game development, level designers only doing that has long past.



In such a competitive industry, the general trend is a more rounded game developer. ErrantAI has worked in this industry before he would gladly point out how wrong your assumption is, that the head doesn't know what the tail is doing.



Game dev companies have daily meetings, so every one knows exactly what the other department is doing, each any every department works closely with one another so that every thing runs smooth, considering they are working on a budget and pressed for time, they can't afford not to know what the programmer isn't doing right, or wrong spending several months working on in house tools only to find out they aren't suited to the task, when you have 400 million dollars on the line simply isn't good enough.



There is procedures, schedules, timelines, and guidelines to be followed, what you suggesting simply doesn't make sense.



In simple terms you don't need a programmer who is a level designer, it's pointless considering how the industry actually works.

@wizard of id, you just made a lot of statements that assumed a lot about what I know and said and don't really have anything to do with what I'm saying at all. I don't think it's that hard to understand that a person developing the IDE tool needs to be s

Then Oh ye of little faith assume no one else is incapable of working closely with the people involved, your making a mountain out of a mole hill.



TGC will make it as they see fit, get feedback and make changes as necessary, again you making TGC look like a bunch of inept coding monkeys that is incapable of doing proper research and a proper design document before hand.Lee did his homework on this project and has done so with every other project, he is more than capable of delegating work as envisioned by the community.

Um, yeah, right. We have to vote for editor features that are standard, basic functionality in almost every 3D engine editor and 3D animation package on the market. I don't think I'm making them look inept or that they haven't done proper research or design. I'm just pointing out the facts.

I think Lee has listened and responded to all views in this matter and any further debate about how it should be implemented is pointless. TGC have again shown they will listen to a majority view presented in the proper manner, what more do you want?



Cast your vote and leave the rest to them, it's over

Suggestion: Get gamer magazine companies (Game Informer or PC Gamer) attention for more people to pledge on FPSGC!

I'm simply responding to people's posts who are disputing my points.



But I disagree that further debate is pointless. This is just a symptom of a bigger problem. That problem being that TGC doesn't seem to have a good grasp on what is really needed in this area. If they did then we wouldn't have to vote on getting this in the engine. And there are literally dozens and dozens of enhancements that could and should be made to the IDE before this is all said and done. But people like me have to outline every single one of them and then we need a consensus vote from the community to get them in the product. The point being that they should understand the needs and plan for them from the beginning. But the need for things like scene hierarchies, perspective editing, transform gizmos, and exposing an entity's transform properties instead seems like a wish list bonus feature to them. These are essential features. I can't even believe I have to point these things out to begin with.



And again, I'm behind this product 100% and believe it can be great. But not if we sit back and are silent.

I personally think before it goes any further an undo feature should be developed right away. As it is it's going to be hard to retroactively add it now, and the more editor features are added the harder it's going to get.







I'd agree with this, although I assume the vote is just which features will be added first, rather than which will be added at all.

Absolutely. I would agree with this. I forgot to put that on my list of editor features needed.







Well, I'm not so sure. The way talk has been from Lee, it doesn't sound like it.

You do know that and undo feature will add an additional memory foot print pending how many undo levels there is.With limited memory to work with already a undo feature in classic was already broken any ways.Which is why it wasn't added as yet or won't be, having complete control over removing entities soon and editing terrain there has been no reason why an undo feature needed to be added.



Undo feature simply uses enough memory to warrant other solutions, and I am not being selfish here memory is every thing, it is a feature I can do without didn't use it in X10 nor did I use it in classic, the ability to remove an entity and or edit the terrain is good enough an undo as any.



Secondly FPSC map editor and the engine are standalone's in other words there is no reverse engineering needed, there has always been two sets of code one for the editor and one for the engine, even thought they work in unison it is easy to apply upgrades to both or just the one.



Lee would have never added some thing like this to the list if it wasn't easy enough to do in the first place, he would have warned right away that it would set back development time ect.

It'd add a negligible footprint. If you move an object you only have to store its previous position, ie. a float vector which is about 12 bytes.



In any case, it doesn't matter. Being able to undo a silly mistake is absolutely vital unless you feel like reloading the project and losing all your progress since your last save. It's a bog-standard feature in any editing software and this should be no exception.

I can't believe I'm even reading someone say this. Undo is essential in any program of this type. And it is a negligible footprint.



@Seditious, you are right on. This is just more evidence that the team on this project hasn't really understood what is needed in the area of an editor. I really can't believe we are even debating this topic.

Sorry it's like talking to a brick wall.



Exactly what will you be using the undo feature for ? Whooops I moved that entity, lets move it back or use the dreaded undo feature to do it for me, whoops I made the terrain to high lets use the paint tool and reduce the height, why there is an undo feature.



Explain the memory foot print of 2500 entities.Which by the way I have in my current level, then explain, scripts applied shadows done in real time, shaders applied and various other little bits information. You are working in a real time environment you telling me there will be 12 bytes memory foot print really ? Height map, vegmask, the list goes on and on and on.



In an ideal world, yes, but this isn't an ideal world, there is several others things that uses memory as well, and it isn't that simple, oh look and undo feature.



You can only have so many undo levels, before memory encroaches a perfectly good level, or you can force the software to only use 50mb then every thing else is lost.Considering what else has to use the allocated memory block, not just entities, you maybe able to do 5 levels of undo then you still forced to manually remove what else is left.Considering you will be using LOTS of entities in the new engine to build worlds and lets not forget the conkit, model importer ect, ect.



Which is why there will be an entity removal tool soon, which will allow removing entities by a click and drag highlighting method.



A show of hands how many people used the classic undo feature.? The feature didn't work correctly in classic in the first place.Kindly point to the billions of threads where people complained about that ?



Because other software has this magic feature it is automatically expected in every thing else.Is it really necessary, no is the simple answer, quite simply there is no direct need for a feature like that when you able to address issues with the provided tool set.



Really this is my appeal to you to sit down and before replying, angrily and without proper motivation, What do you consider a mistake and what can't be "fixed" with the provided tool set ? Seriously think about it, it isn't a unreasonable request to consider ?

Hi all,



Lee has responded and this has gone to a public vote, if enough users feel this is a high priority then we will treat it as such. Regardless, we are aware that these features are important and they will eventually be intergrated, if not sooner than later.



We have taken the conscious decision that this project be community led, but I would remind everyone that community led does not mean who can shout the loudest. I ask that everyone calm down now and await the result of the vote.



Many thanks,



SC

With all due respect, you have no idea what you're talking about. Undo simply undoes the last operation, so you only need store information pertaining to what you changed. If you moved a few entities, you have to store their previous positions. If you edit the terrain, you store the relevant vertex data. It really does not use much memory, and should not be too hard to implement if done early enough. It's really not a feature any editor can do without.

An undo feature is critical, in my opinion. I have already asked for this elsewhere, previously; especially for the terrain editor. Classic didn't have native terrain, so that is a mute point.

If I accidentally delete an object that it took me a very long to place just right. The tools aren't going to help me magically put that entity back in its perfect place. It will take much work. That's just one example of undo. In addition, even if you can redo your work using the tool set, that redo does take more time than simply using ctrl-z a few times. In the case of terrain, if I have a section that I think needs work and I mess it up then I can easily undo it back to the "exact" place it was instead of trying to "replicate" what it was, but not quite getting it right.



And Seditious is right, you have no clue what you're talking about regarding undo. First of all, undo features typically have a limit of how many undo/redo levels you can do. And each level of undo is simply the storing of the operation performed. It isn't about storing the memory of an entity or mesh. So, a series of undo levels might be as follows:



sculpt terrain @xyz

level terrain @xyz

place entity 5 @xyz

raise entity 5 @xyz



And operations such as sculpt terrain could be represented by simple enum values. This is very simple to do and easy to reverse or redo those operations. And we aren't asking for unlimited undo levels either. I would say even 100 levels would be far beyond anything anyone would need in real life.

many times I have asked for an undo button, mainly because of putting things inside or ontop of other entities. though im not so sure it will be as useful soon as I previously thought.

I think an undo function is a must at some point. Say you have spent ages sculpting a terrain, then you decide to add grass or re-texture and accidentally stay on the terrain editing tool. You can quite easily wipe out a lot of work in a few seconds before you realize what you have done. Also the texturing never seems to quite delete properly, so if you texture a floor then decide to remove it, there is still a faded floor visible. Undo would revert it back nicely in both cases.

Another scenerio is you have placed a building and several objects all neatly inside. You decide to move an item and end up moving the entire building because it is difficult to click on small entities inside a building. Placing it down just so unless you happened to grid it at first can be quite the pain if not impossible. Normally meaning you have to remove the interior items and start over.

Perhaps you just click the building by mistake while moving the mouse? Again this means much tinkering to get things just as they were.

The number of times I have placed an object with the auto flatten enabled by mistake and it wrecks my scene is quite high. An easy mistake to make sometimes with keyboard shortcuts.

I definitely agree an undo is needed at some point. Mostly for terrain stuff, as I'm sure some of the problems I mention will be fixed anyway in time.

At very least an option to press escape and the object you clicked reverts to where it was last placed would help with those annoying mistakes we make occasionally.

yep alot of ways to use a undo button i agree, have done most of those on your list dvader m8, over the months lol.. users errors are going to happen alot but less with practice and time. but im sure as the editor evolves it will become even less needed, even more so as lee has taken onboard alot of whats been said here that he has added to the votes.

Have you seen how many attempts to make an engine have been made? This will no doubt end the way the others have. They are already behind in the times.

This thread has been responded to and is now just going around in circles. We have already added an additional item for users to vote. If this proves popular, we will change priorites.



As a result, I'm now locking this as I feel it has served it's purpose.



SC