Useful Features Being Removed

[tjheldna]

Lately using LE it feels like there are features being removed or changed with no real warning. One of the items is referring to the beta branch.

 

Here are my examples:

• Custom collision meshes - This is the one I miss the most, I'm never going to stop on this one, so useful. I've decimated the file size of every .phy file I've optimised and no doubt making a difference in game.
  
• Resize and position collision shapes - key adjustment values for collision optimisation. The editor has no idea of where I want the shape or it's orientation, so why let it choose it for me?
  
• Skeleton View in model editor - great for debugging your exported rig
  
• Target entity field now a text box - I've used it now and if it wasn't intuitive before it's even more so now. I'm not sure why the way this field used to work is now the devil.
  

Being a strict C++ user and no use for the game player etc it actually feels like features have not only ground to a halt, but going backwards.

 

I'm not mad or anything, I just want to voice that these changes are effecting my LE workflow in a negative way.

 

Cheers

[Roland]

I have seen same thing and beeing a Linux user it's even more attenuated. To me it seems that instead of fixing some issues, the components or functions causing the issues are just removed or crimped down. This IS a bit worrying as the backwards compabitlity can not be fully trusted. Hopefully this is a temporary thing going on and not a new way of stripping things down to having just the most $$$ generating things left in there.

 

I'm not mad either but a bit worried.

I don't want a LE4 where C++ or Linux or whatever suddenly is gone

[gamecreator]

Custom collision meshes

[Josh]

Writing the tutorials was a big help because there were a few places where I thought, "This is not easy, I can't recommend people do things this way." This led to a few improvements that are easier to learn and use. In the case of physics shapes, it was found after preparing the scifi model pack that this was a major deficiency...without revising this, it would be impossible to add any new DLCs, or expect people to release ready-made items.

• Custom collision meshes - This is the one I miss the most, I'm never going to stop on this one, so useful. I've decimated the file size of every .phy file I've optimised and no doubt making a difference in game.
  
• Resize and position collision shapes - key adjustment values for collision optimisation. The editor has no idea of where I want the shape or it's orientation, so why let it choose it for me?
  

These are available by enabling the EnableLegacyFeatures in the config file. The auto-generation tool in the model editor (or building shapes into the model with named limbs) is the recommended approach.

• Skeleton View in model editor - great for debugging your exported rig
  

This has been disabled for now due to a serious bug that could arise in some situations. it needs to be rewritten to work correctly. I expect this will be revised soon.

• Target entity field now a text box - I've used it now and if it wasn't intuitive before it's even more so now. I'm not sure why the way this field used to work is now the devil.
  

I listed this a few weeks ago as one of the usability improvements I wanted to make here. I don't always get the workflow right on my first attempt, and it's important to improve things when a better way is found. I've taken measures to make the workflow backwards compatible with the old approach.

I have seen same thing and beeing a Linux user it's even more attenuated. To me it seems that instead of fixing some issues, the components or functions causing the issues are just removed or crimped down. This IS a bit worrying as the backwards compabitlity can not be fully trusted. Hopefully this is a temporary thing going on and not a new way of stripping things down to having just the most $$$ generating things left in there.

Linux has been somewhat frustrating, because it consumes ten times more special attention than Windows or Mac, I do the most I can with an underlying system that is just not designed for GUI software, and because people don't know the details of what I am working with I feel like all that effort is not understood.

 

Archive builds are made before each major release, so it's always an option to revert to one of those builds if you don't want the program to change. Otherwise, it is going to be constantly refined and improved. I make a lot of effort to maintain backwards compatibility.A lot of open-source software projects, in particular, get ruined by feature creep and lack of focus. The goal of Leadwerks is to be as easy as possible to learn, and to maximize the number of games released in the Workshop (Standalones are good too, but Workshop games seem to be gaining the most traction). I believe in order to reach those goals, some amount of continual change will always be necessary. The alternative is to just keep building features and code on top of features, never changing anything. When software developers are indecisive, you end up with things like this:

 

Overall, I would say the current development is a period of refinement of existing features, with a conservative rate of new feature addition. I would much rather have correctly working, well-designed, and well-documented tools rather than having lots of poorly implemented undocumented features. That is a decision that has to be consciously made, you can't just have everything and have it all work well.

[gamecreator]

These are available by enabling the EnableLegacyFeatures in the config file.

And they're legacy because support for them is discontinued? If not, why not keep them as an active feature?

[Josh]

They're being left in because it's no problem for me to do that, in most cases. Sometimes a feature is made obsolete by the addition of something new. For example, the physics shape tools in the model editor eliminate the need for shape properties in the properties panel, and would actually create confusion because the program would present the user with an option that was really the wrong way to do things.

 

Because everything needs to be documented, it would be silly to write documentation for an old feature that is too hard even for me to use. That's what I mean when I say the tutorials are like a specification of the user experience. It forces us to be firm about what the right way to do things is. This is really good because it means we all understand how things work, and real improvements can be made if something isn't up to par. If we're all sort of crafting our own workflow, then those issues never get discovered.

[Roland]

Thanks Josh for your comments. I fully understand the problems with keeping things exactly alike in details for two different OS and that many things can be dependent on some third-party libs or pieces. If I remember correctly the editor is still done using Blitzmax and maybe that was a time saver at start, but maybe not in the long run (just guessing here). Anyway, Keep up catching those nasty little devils called bugs and issues and we will be fine. And don't you even DARE thinking of removing C++ or/and Linux support or else a Viking ship will start heading over from Sweden

 

[YouGroove]

Linux has been somewhat frustrating, because it consumes ten times more special attention than Windows or Mac

Ten times more attention it seems Linux is just as annoying as Android. Windows and Mac only could have been the best option perhaps.

 

That's what I mean when I say the tutorials are like a specification of the user experience. It forces us to be firm about what the right way to do things is. This is really good because it means we all understand how things work, and real improvements can be made if something isn't up to par. If we're all sort of crafting our own workflow, then those issues never get discovered.

If you make a vote, i think the majority of people will ask drag and drop instead of what you think is the best way.

[Roland]

Ten times more attention it seems Linux is just as annoying as Android. Windows and Mac only could have been the best option perhaps.

Absolutely NOT if you are a Linux user and payed for Linux.

[YouGroove]

Absolutely NOT if you are a Linux user and payed for Linux.

 

Reading Josh post it just seems Linux is still more complicated and consuming lot more time then Windows.

Be rassured , i'm not the LE3 Linux developper , and this is not the topic here.

 

The only thing that has not been removed and that i want is plugin feature to unleash LE3 power.

[shadmar]

collisionhull

Lately using LE it feels like there are features being removed or changed with no real warning. One of the items is referring to the beta branch.

 

Here are my examples:

• Custom collision meshes - This is the one I miss the most, I'm never going to stop on this one, so useful. I've decimated the file size of every .phy file I've optimised and no doubt making a difference in game.
  

 

This still works, just have a group called collisionhull within your mesh, like this :

[tjheldna]

Hi Josh, and thanks for your comments I appreciate it.

 

In the case of physics shapes, it was found after preparing the scifi model pack that this was a major deficiency...without revising this, it would be impossible to add any new DLCs, or expect people to release ready-made items.

 

Don't get me wrong, your phy shape implementation is fantastic. I believe the big difference here is creating a model pack and using the models in a level are two different things. Issues like navmesh generation, wasn't on my mind when modeling till I realised that the door frames was stopping the generation because it had collision on it (the fit is as tight as I can get it around doors). Also I don't want all the collision detail in window frames, house fixtures etc, but want the detail in the model so there are savings to be had. You can see the phy file sizes being decimated in my comparisons and sure this will make in game savings too.

 

I do propose a solution:

• In your modeling program you can have a child mesh which needs to be named 'HINT' or something
  
• In the model viewer if you select 'PolyMesh' and you have the child named 'HINT' a shape is generated from the 'HINT' model else it uses the actual model as it does now.
  
• The 'HINT model is removed when the level is run similar to the method using Brushes.
  

I recon that would keep everyone happy.

 

These are available by enabling the EnableLegacyFeatures in the config file. The auto-generation tool in the model editor (or building shapes into the model with named limbs) is the recommended approach.

 

I'm wary of becoming dependent on a feature that is labeled legacy

 

This has been disabled for now due to a serious bug that could arise in some situations. it needs to be rewritten to work correctly. I expect this will be revised soon.

 

No worries, this tool has saved me in the passed with rigs not exported properly. Being able to visually see it when the imports/exports don't line up is where this feature really shines.

 

I listed this a few weeks ago as one of the usability improvements I wanted to make here. I don't always get the workflow right on my first attempt, and it's important to improve things when a better way is found. I've taken measures to make the workflow backwards compatible with the old approach.

 

I took a look at the new way in an older project I have. In general I think it's now open to a lot of user error, some form of fool proof way of validating and assigning a uniquely named model has to be done imo. That being said because I was working off unique names anyway it didn't break anything.

 

@Shadmar

 

I mean with being able to create your own exported collision mesh and use that easily. With the house models I'm doing the collision has to be very tight.

 

Cheers

[tjheldna]

Thanks Shadmar and Macklebee for your help it is really appreciated. Seems Josh was 1 step ahead of me with the collision and you can do it directly from the modeling program like I was wanting, I must have missed that memo or not understood something. I take back all the swear words I said to the editor when I was doing it the hard way.

 

Thinking about it it's better looking stupid and finding now when I've 5 houses completed compared to 50 still I have some work to do.

 

Thanks again

[Josh]

I talked about it in my blog but haven't covered it in the tutorial yet. That's probably the best way to get hand-made collision. My original design was just really hard to use.

[Einlander]

Not mad here either, just frustrated. For me it's the little bugs here and there that accumulate that you cant actually fix easily. I've basically stopped submitting bug reports because the some bugs just don't seem to be fixed (search for all my bug reports). Then to top it off, you start doing one thing today, and tomorrow its no longer a valid workflow.

 

All I hope is Leadwerks doesn't fall into the trap of the dev doesn't like it this way, so the users MUST not like it either. Or, I never used it so others MUST not be using it either. A dev knows how they want their software to be used and how things are supposed to be done. A user isn't the dev, they need to learn to think like a dev. Opinionated software is what leads people to curse at thier computers when they see a clear connection but the software stops them from doing it.

[Rick]

I'm sure this wasn't intentional but I recall Josh posting an article once about MS having a moving target for their platform that developers had to deal with. The idea was that they were more doing it on purpose but I see Leadwerks (and other software) doing the same thing so I don't think these kinds of things are on purpose. I think they are just a natural part of software. You have to release a product at some point even if it's not ideal at the time of release. Then you go back and refine it and change things. So maybe Josh will take it easy on MS now that he's doing the same thing

[Olby]

I'm sure this wasn't intentional but I recall Josh posting an article once about MS having a moving target for their platform that developers had to deal with. The idea was that they were more doing it on purpose but I see Leadwerks (and other software) doing the same thing so I don't think these kinds of things are on purpose. I think they are just a natural part of software. You have to release a product at some point even if it's not ideal at the time of release. Then you go back and refine it and change things. So maybe Josh will take it easy on MS now that he's doing the same thing

 

Haha, well said MS is indeed evolving much like LE is. We also have things come and go, actually the days of having a solid release are gone. Just look at games, how many patches/DLC's later they're playable? Back in the days it's either hit or miss, now with Steam and internet there is no point in making a well polished product. Shame though.

[Rick]

True Olby. A day doesn't go by that I don't have a game automatically updated on steam. Now that updates are automatic and done behind the scenes and are generally unobtrusive to the gamer devs can get away with this kind of thing.

[Josh]

The documentation has been updated to explain the use of hand-made shapes saved in a model file:

http://www.leadwerks.com/werkspace/page/tutorials/_/models-and-animation-r8#section6.2

[Einlander]

Haha, well said MS is indeed evolving much like LE is. We also have things come and go, actually the days of having a solid release are gone. Just look at games, how many patches/DLC's later they're playable? Back in the days it's either hit or miss, now with Steam and internet there is no point in making a well polished product. Shame though.

True Olby. A day doesn't go by that I don't have a game automatically updated on steam. Now that updates are automatic and done behind the scenes and are generally unobtrusive to the gamer devs can get away with this kind of thing.

 

I consider games and development tools 2 different things. Games need to be updated with new things and fixed as needed, it's expected. But that has risen to sloppy behavior on the part of game devs. Ship it broken and fix it in production seems to be the mantra now. And DLC for things that should have been in the game, or are already on the disc.

 

Development tools to me are an entirely different class from games. People expect the tools to work reliably, predictably, and to be patched when needed. New features are a bonus. Leadwerks on the other hand Is always being updated, but you would be hard pressed to tell me what has changed, been fixed or optimized. I actually had to go make a list of notable changes. Changes to a developers tools have a greater affect than "fixing" a game. Every change affects how a developer approaches how they make a game. If a new change is to cumbersome, they may have to reinvent the wheel or abandon an approach. This last change with the drag and drop targets has caused me to create self registering pivots that report to a parent entity and a platform that navigates them. I should not have needed to do that.

 

Beware of changing things for change or sake or because it's "easier", because sometimes it's not worth it.

[Josh]

If there's a problem with the entity script fields I would like to know more about how you are using this. Maybe it is possible to create new names for all linked entities in the older map format, so that they can be brought forward with no hiccups. I put this out on the beta branch first so that people can try it and tell me if something doesn't work, before it goes onto the default branch.

[Josh]

I talked to a couple of people and revised the behavior of the entity script fields. An update is available now on the beta branch:

http://www.leadwerks.com/werkspace/blog/1/entry-1478-entity-script-fields-update/

 

Please let me know how this works for you.