Feature requests?

[kattle87]

Most important feature ever: "find" !
u should implement something for finding objects, states and so on in the "project" menu... even if u just implement global searching by name, well, it's easy to implement and really usefull when your projects gets big _AND_ when u open a project from someone

bye!!!

[jph_wacheski]

Thanks for making this very cool system! and even though I have not yet explored all the cool feateres in it,. here are some things I would like to see added,. I hope more coderes get involved to majke more components that give more fun and interesting features,. .

a midi generating component for algotyhmic generation of beats and melodies., drum grids and arpeggiations., or a nice step seqencer,. with like 16 or 32 sliders that let you set sound perametes,. . i used to play a lot with this one; [ http://www.sonicspot.com/seq303/seq303.html ]

a simple-to-use 2d (eventually 3d) physics component!

music player components to support MOD and V2 playback,. it would be nice to have the two way comunication possible with the MOD playback,. i.e. send a recorded-in-the-MOD-file value to the game logic,. thus game actions can be sinqed to the tunage,. .

gamepad support, with rumble suport for my 360 controler,.

oh could the Condition component have a different and unique icon? perhaps a triangle..,

I will come back and add what ever else ocurres to me,. keep hacking away !

[Kjell]

Hi,

New weekend .. new requests Some small ones to start with ( apart from the first ).

ZGE
- Softimage XSI ( dotXSI ) format support. Or COLLADA alternatively.

Shortcuts
- Ctrl+S as "Save project" shortcut instead of "Toggle lock preview selected components".
- Delete key as "Delete component" shortcut.

Interface
- Scroll wheel support in panels.
- Entering a value in the Property editor definitively using the "Enter" key.
- Being able to edit the Expression property of a ZExpression component directly in the Property editor.
- Instantly open the Expression property of ZExpression in the Custom property editor upon selecting a ZExpression component in the Component tree. *I'm aware that this will probably be a hack, but might speed things up a little when working with allot of these components.

#Bugs
- KeyPress special characters don't work in preview window.

Thanks for Pi and Ctrl+Up / Ctrl+Down ( something I was going to request ) in 1.7.3

Best regards,
Kjell

1st Edit: added *

[Kjell]

Hi,

I'd like to see the Collision properties ( and it's associated OnCollision state ) of a Model removed and replaced by Collision components ( in a similar fashion as KeyPress ). I think this will still be intuitive enough for beginners, but opens up the possibility for models without collision, having multiple collision checks on one model, and parenting a collision check to for example a Condition component. A Raycast Collision component would also be desirable.

Additionally, there seem to be no values accessible on actual collisions? Values like ObjectIntersected ( object ), IntersectionPoint ( vector ), IntersectionNormal ( vector ) are quite essential in most games.

And it might be a good idea to organise the Add component window by using a tree or folders, grouping the components that fall into the same category.

Regards,
Kjell

[VilleK]

Kjell, all your suggestions are very good. I'll see what I can do for next release.

About collision handling I'm aware that the current implementation is not sufficient. At the same time I'd rather not make changes that breaks backward compatibility with existing projects. Information about the collision state should be passed on to the expression in OnCollision, however the expression system does not support passing parameters. Maybe this can be solved with new hidden readonly properties on Model named CollisionIntersectionPoint and similar. I'm not sure.

[Kjell]

Hej VilleK,

Understandable .. but you might want to change it sooner then later if you agree with the deficiency. Take some time to let it sink in

The same thing goes for Light(s) / Camera(s) by the way. Currently you have those values fixed as App properties. I think the component idea that you have going on is very strong, flexible and expandable .. so having PerspectiveCamera / OrtographicCamera / OmniLight / DirectionalLight / BoxCollision / SphereCollision ( etc. ) components would in my eyes be more true to that concept.

This is a design issue though .. and we all know that those are always difficult to deal with

Perhaps for now you can add a CollisionStyle: "none" option to save some computing time on Models that don't need any collision? Or is this automatically skipped when no components exist in the OnCollision state?

Keep it up
Kjell

[VilleK]

Perhaps for now you can add a CollisionStyle: "none" option to save some computing time on Models that don't need any collision? Or is this automatically skipped when no components exist in the OnCollision state?

Collision tests are only made between models with the Category-property set to match the definition in a DefineCollision-component. So for instance a Model with Category set to 0 does not have any collision tests and no cpu-time is wasted on this.

I agree that components for defining a camera setup (and lights) is a good idea. It's noted

[jph_wacheski]

I would not worry too too much about backwards compatibility,. if someone has a project started i would expect them to finnish it in the ver. of the tool that it was started,. if it CAN be presereved great,. however, if not then they always can use the older ver.! should make life easyer for yourself

collisions as they are now do seem a bit too limited,. in this vaders game power-ups for the player should fall,. however since when the player collides with the invaders or the pixels; the player is removed. So however I define the power-up, when it collides with the player,. . poof its gone..,

one simple way to handle multi-collisions would b;
add a component called "who_hits" or whatever you like to call it, and then, if one needs, they can create one in the on.collision event, and select from a pulldown one of the names of the defined collisions. :. for each definition different events can easily be triggered,.

[VilleK]

So however I define the power-up, when it collides with the player,. . poof its gone..,

You have the Application.CollisionCategory property which holds information about which category the model collided with. So if you have separate category for enemy-shots and powerups then you can test this property with a Condition-component and act accordingly.

It is early in the morning now so apologies if I misunderstood your post

[jph_wacheski]

ah ha! Quite true. I just tried it ,.and it works,.

Code: Select all

 return app.CollidedCategory<4;

the pow_up is set to 4 and the other two are less, so this works well,.

now i just have to build a bit more gameplay into this and get a bit more of a beat going,.

[Kjell]

Collision tests are only made between models with the Category-property set to match the definition in a DefineCollision-component. So for instance a Model with Category set to 0 does not have any collision tests and no cpu-time is wasted on this.

Ah of course, should have realized that.

I agree that components for defining a camera setup (and lights) is a good idea. It's noted

I think one of the main benefits of having a Camera component ( similar to the Model component, but then with FOV / Zoom / Falloff etc. ) is that all properties such as position / rotation / custom_variables can be stored in the component itself. This then also paves way for multiple camera support / easy camera switching when adding for example a ActiveCamera property to the top-level App. Or even better, have a RenderState ( boolean ) for each camera along with RenderRegion ( rectangle ) / RenderPriority ( int ) to enable people to create split screen / screen-in-screen madness

*By the way, please don't get discouraged by the amount of requests I've been posting in a relative short time. From what I've seen so far, ZGE is a great tool as is, and most shortcomings can already be overcome by "hacking" your way around

Kind regards,
Kjell

[Kjell]

Some basic fog properties.

App
- FogType ( Linear || Exponential || Squared ) :list?
- FogColor :color

App.Fog:Linear
- FogStart :float
- FogEnd :float

App.Fog:Exponential || Squared
- FogDensity :float

Regards,
Kjell

[VilleK]

Hey Kjell, with all your requests flooding in maybe we really should set up a wiki for this as you originally suggested . Seriously your suggestions are all very good and realistic, so thanks for taking time to write them. Even if I can't implement all of them myself, perhaps more developers can help later on.

The most general technique to get a fog-effect in ZGE is using a pixel shader. If you google for "glsl fog" there are many examples. However this of course have the downside of not working with old graphics cards. So a couple of properties for fog the old-style way could be useful after all.

[Kjell]

Hej,

Some material / texture related requests.

Import 3DS-file
- UV data support ( some kind of UV data does seem to get imported, but haven't been able to get it to work properly ).
- Automatically generate material / bitmap components when importing 3d data containing materials & texture references.

Material
- Alpha texture property ( for non-GLSL alpha / masking ).

*BitmapFromFile:BitmapFile
- X and Y values seem to be swapped when importing a file ( when trying to import a 32x16 texture, it previews and imports it as 16x32 ). Bug?

Kind Regards,
Kjell

[jph_wacheski]

Ville did you miss my post, or just had no comment on those suggestions,.

well,. I have a few more!

there is a 'bug' when ZGE loades here on my machine,. the window is maximized but is set to windowed instead of full desktop. the big windo is always a bit down from the top of the screen as well,. it is easy to hit the maximize button and the ZGE ide snaps to full screen correctly however should it not restore to the last settings? i.e. full screen instead of windowed.

some way to adress objects by name and instences by number would be very usefull,. i.e if there are 10 model_one's we could say model_one[n].Velocity.Y+=.1; where n is an instance number 0-9

or just to be able to use model_player.position.x in the AI of another model would be convinent,. I do understand that you are doing some majic building the exe so tinny,. so I am not complaining as all! if this impossible I will understand., I was able to figure out how to initialise a veriable and pass the player.postion.x to that variable and then use that for the AI,. it just seems a bit limiting,. I am used to using these two functions in GML often;

point_distance(obj_a.x,obj_a.y,obj_b.x,obj_b.y);
point_direction(obj_a.x,obj_a.y,obj_b.x,obj_b.y);

I have found how do do the trig to get the distance and direction however, not being able to look up the value of other objects still constraines,. (if you could add those two functions, in some form, it will make controling objects movements simpler,. to my limited brain anyhow.

that remindes my I have not been able to get the SteeringBehaviour=>SeekModel to work,. they always seek 0,0,0 any idea what I'm missing there ?? if not I'll have anothe look at the example to see if I can figure it,.

are you planing to expand the txt file support to include writing files as well? I would like to build a level editor but we can only load from txt currenly, no writing. ?

more mesh primitives with deformers please,. and how about some more bitmap functions,. blur, blend (two bitmaps), sharpen, draw grid, more noise function,. etc. i suppose most of these can b achived in BitmapExpression and I am collecting a bunch of cool expressions to post soon,. just thinking about what would b cool and make things easier for the users like me,.

well so far I am very pleased with the ZGE ! it produces super cool procedural and genreative games in tinny exe files that i lov. , peace and lo-fi lov!