Do you want the old UI System to be removed?

[Henrik]

And here it is, sir:

http://www.youtube.com/watch?v=dtDko9ujCYM

[seenooh]

Hello Henrik,

Thanks for your efforts. I bet everyone will be looking forward to seeing the rest of the series.

Good luck.

[iniside]

Don't let anyone tell you what is "bad design", Kismet is just fine for prototyping, and if you even want to use it in a commercial game idea and it's simple enough, who's to say that's wrong. In fact, I can tell you for a fact someone who did very well in the MSUC used thousands of Kismet nodes to do something that "should have been done in script", and even if they've since changed it, it was good enough to win them prize money now wasn't it? Everyone works differently and has different needs, so nevermind others, just do it the way you believe provided it works.

I will post a link to the first video in less than an hour.

Prototyping maybe. But not for making entire game. It's just won't work as long term solution. To much to change, hard to maintain, hard to update, hard to make changes across entire solution. Well, that's why programming languages actually exist. And are not threaten by some visual scripting things like kismet or flow graph (or other flow-based programing for that matter like Windows Workflow).

I said it from my own experience. Yes it can be done in that way, but it;s very time consuming, inefficient and just break all possible rules for good make application.

[gegebel]

Gegebel you will get your wish. I am making a Scaleform video tutorial series and the guys at Scaleform & Epic have been very kind in helping out, so I think it will definitely address the concerns of people such as yourself who want an absolute simple starting point, this series is designed to get people creating fully functioning menus and dialogs in under an hour, and from there, build up the knowledge they need for more complex interactions.

Don't let anyone tell you what is "bad design", Kismet is just fine for prototyping, and if you even want to use it in a commercial game idea and it's simple enough, who's to say that's wrong. In fact, I can tell you for a fact someone who did very well in the MSUC used thousands of Kismet nodes to do something that "should have been done in script", and even if they've since changed it, it was good enough to win them prize money now wasn't it? Everyone works differently and has different needs, so nevermind others, just do it the way you believe provided it works.

I will post a link to the first video in less than an hour.

Thank you very much, Sir

[gegebel]

Prototyping maybe. But not for making entire game. It's just won't work as long term solution. To much to change, hard to maintain, hard to update, hard to make changes across entire solution. Well, that's why programming languages actually exist. And are not threaten by some visual scripting things like kismet or flow graph (or other flow-based programing for that matter like Windows Workflow).

I said it from my own experience. Yes it can be done in that way, but it;s very time consuming, inefficient and just break all possible rules for good make application.

You try to tell me I can't do a game because I can't use UScript.
Maybe it's hard work, but it just proves one thing: I'm ready to put the time in what I want in order for it to work.
I think it's cool YOU can program, well I can't so I search solutions in order to get what I want and UIScene combined with Kismet just did that for me.
I'm not searching for an easy solution, I just want something that works for me, which is why I was happy with UIScene. I could make things work without having to code a single line.

[Lacabra]

wait, what's the advantage to removing features

[Quanta]

wait, what's the advantage to removing features

What's the advantage of leaving it in? They have no intention of maintaining the feature going forward, so leaving it in is likely to cause problems when it inevitably breaks.

[ORi]

Prototyping maybe. But not for making entire game. It's just won't work as long term solution. To much to change, hard to maintain, hard to update, hard to make changes across entire solution. Well, that's why programming languages actually exist. And are not threaten by some visual scripting things like kismet or flow graph (or other flow-based programing for that matter like Windows Workflow).

I said it from my own experience. Yes it can be done in that way, but it;s very time consuming, inefficient and just break all possible rules for good make application.

I'm curious why you say that? I mean Kismet nodes and grouped nodes, when built correctly are like classes(maybe because they are classes) so they should be as reuseable as OOP code when designed correctly and you can create instances of variables. its more for people who prefer to think visually.

I think we can both agree that what matters more is HOW you code rather than what language or system you use, spagetti complex can happen either way.

The only truth I recognize from what you say is that it maybe less efficient (slower) than direct coding but then so are any script languages when compared to compiler languages and compiler languages when compared to machine languages so in most cases unless you are building a massive undertaking (The kind that can give the CPU a hard time breathing) I would think that is negliable.

I would leave in UIscene as long as it doesn't conflict with anything but I do like Scaleform and Actionscript because its much more powerful.

[Blade[UG]]

gegebel, I think you are confusing Kismet and UIScene. Kismet is one thing, UIScene is something else.

[Henrik]

I think he meant he made his UIscenes do stuff (or appear) using kismet.

[iniside]

I'm curious why you say that? I mean Kismet nodes and grouped nodes, when built correctly are like classes(maybe because they are classes) so they should be as reuseable as OOP code when designed correctly and you can create instances of variables. its more for people who prefer to think visually.

Because kismet is associated with mao you are using it.
Also you can't just reuse code like in OOP. Yotinu have to duplicated your solutionm over and over it's not opitnal for high dependable solutions (like games ;p).

I think we can both agree that what matters more is HOW you code rather than what language or system you use, spagetti complex can happen either way.

Of course. But kismet is not generating any visible code for user. You can make some complex operations withing it but you can't reuse them later in other project. Because they are connected stricctly to map. As I said hard to update and maintainm what if will find bug ? Or want a new feature or some old feaure are removed and have been using them ?

The only truth I recognize from what you say is that it maybe less efficient (slower) than direct coding but then so are any script languages when compared to compiler languages and compiler languages when compared to machine languages so in most cases unless you are building a massive undertaking (The kind that can give the CPU a hard time breathing) I
m because I didn't would think that is negliable.

Then you dont see any truth, because I said nothing about perfomance. I talk about project maintaing. Which is much harder with tools like kismet and flow graph. These tools were made for simple map scripting not for game making.

[Alex_Depth]

What's the advantage of leaving it in? They have no intention of maintaining the feature going forward, so leaving it in is likely to cause problems when it inevitably breaks.

Because a number of people are using the old HUD method and submitting an update that breaks their game isn't very nice now is it?

[ORi]

Because kismet is associated with mao you are using it.
Also you can't just reuse code like in OOP. Yotinu have to duplicated your solutionm over and over it's not opitnal for high dependable solutions (like games ;p).


Of course. But kismet is not generating any visible code for user. You can make some complex operations withing it but you can't reuse them later in other project. Because they are connected stricctly to map. As I said hard to update and maintainm what if will find bug ? Or want a new feature or some old feaure are removed and have been using them ?


Then you dont see any truth, because I said nothing about perfomance. I talk about project maintaing. Which is much harder with tools like kismet and flow graph. These tools were made for simple map scripting not for game making.

To each his own preference I guess then, As far as Bugs Kismet is far less likely to have any because its made of prebuilt code segements, since everything is simplfied to inputs and outputs there is less room for error.

Also I didn't test this but I find it unlikely that they wont allow to transfer kismet networks from one project to the other or save custom made node groups for later use and if it is the case im pretty sure that lack of functionality can be easily amended in later releases of UDK...

also you might want to read your post after you post them because you invented a few new words which im not familiar with.

[iniside]

To each his own preference I guess then, As far as Bugs Kismet is far less likely to have any because its made of prebuilt code segements, since everything is simplfied to inputs and outputs there is less room for error.

Also I didn't test this but I find it unlikely that they wont allow to transfer kismet networks from one project to the other or save custom made node groups for later use and if it is the case im pretty sure that lack of functionality can be easily amended in later releases of UDK...

also you might want to read your post after you post them because you invented a few new words which im not familiar with.

I knowI niticed it now. I still get used to new keyboard

[Henrik]

Can't you make archetypes from Kismet and reuse it that way? Or simply cut and paste.. or have a master map that streams in your levels, and contain the kismet in the master map.. you can also export kismet to code iirc, so... plenty of ways to reuse it.

[Blade[UG]]

Because a number of people are using the old HUD method and submitting an update that breaks their game isn't very nice now is it?

The old HUD has absolutely nothing to do with UIScene. You could also make HUDs with UIScene, just as you can with Scaleform .. but most people never did, because the data handling in UIScene is obscene.

[Quanta]

Because a number of people are using the old HUD method and submitting an update that breaks their game isn't very nice now is it?

They could always stick with the version they've developed on if it's that big of an issue. Or they could refactor their UI system to make use of Scaleform or the Canvas system. Either way, UIScene isn't going to be maintained. Learn to move forward. Or don't. It's up to you.

[Amala]

hai,

Am new to UDK and unrealscripting, am trying to create UI scenes but wht i know is it has removed from udk. so how can i create ui scenes without Flash and Scale form am using unreal scripting, and canvas. By using canvas i hav created health bars and images but i dont hav idea about how to create menus and buttons.

pls anyone can help me....

Thanks in advance..

[skwisdemon666]

A two year old thread might not be the best place to look.