[INFO] Development Journal

[[did]Madis]

Once this is done it'd be awesome if the mappers / modders in SLV community would come together and create a completely overhauled version of the mod and all the popular maps.

One can dream, right?

[Shadow]

Yeah that would be indeedy great... and yes - one should dream !


While being deep into implementing Native/C++ Hardcoded Features and Functions I see that EPIC could have had implemented many math, string, vector, rotator functions of Unreal Engine 2 even for Unreal Engine 1, even Quaternions were supported at that time on C++ Level (based on UnMath.h of the 436 Public Headers), EPIC simply didn't implemented them for Unreal Script use

Still missed out Advanced Math and General Purpose Functions featured by Unreal Engine 3 are implemented by me too, who wants Unreal Engine 3 Open Source ?

[Feralidragon]

While being deep into implementing Native/C++ Hardcoded Features and Functions I see that EPIC could have had implemented many math, string, vector, rotator functions of Unreal Engine 2 even for Unreal Engine 1, even Quaternions were supported at that time on C++ Level (based on UnMath.h of the 436 Public Headers), EPIC simply didn't implemented them for Unreal Script use

Not wanting to defend them or anything, but looking at it now, there are a lot of stuff they could have implemented, and most important, FIXED (PHYS_Trailer free rotation there but not working, it just keeps a 90º pitch angle wherever and however is the owner, if it worked, many UScript only based stuff could be easilly achieved with zero lag in a online match ), but if we look back in the time they developed all this stuff, they were in a huge rush and pressure to finish the game in time, and even afterwards when doing the patching to an acceptable level. They just weren't paid or got time enough to finish all these things.

And btw, the UT3 release was also delayed, and still I saw that many features they bragged and showed about UEngine 3 aren't simply completed at least in their own game. They might be completed in GOW, but not in UT3 which should make the use of it even better, but oh well, you get the point.

For instance, if you see any UEngine 1 based game (I have one almost as old as UT), even they have more stuff implemented and even their own particle system which Unreal and UT could have at that time as well.

So, if you want to see completed stuff under all the Unreal Engines, don't look in the UT or other Unreal series, look in other UEngine based games instead. Their own games which brought all these engines have half of the engine not working or simply not completed, but then you see another game using almost the same engine (with just some tweaks from the other company), and there you go: incomplete and non-working features actually working.

It's sad but it's true lol, so that's no surprise really, and I believe you're only halfway in realizing not only that, but many more things could have been implemented (they could have added a cubic and a spherical collision hull also to their meshes, even if they didn't rotate, and they would have the same performance as their cilindrical one, if not better in those 2 cases).

Keep up the good work, so if you are in c++ now, it means that you're done with all the software? Or are you leaving some software stuff to the end?

[Shadow]

While being deep into implementing Native/C++ Hardcoded Features and Functions I see that EPIC could have had implemented many math, string, vector, rotator functions of Unreal Engine 2 even for Unreal Engine 1, even Quaternions were supported at that time on C++ Level (based on UnMath.h of the 436 Public Headers), EPIC simply didn't implemented them for Unreal Script use

Not wanting to defend them or anything, but looking at it now, there are a lot of stuff they could have implemented, and most important, FIXED (PHYS_Trailer free rotation there but not working, it just keeps a 90º pitch angle wherever and however is the owner, if it worked, many UScript only based stuff could be easilly achieved with zero lag in a online match ), but if we look back in the time they developed all this stuff, they were in a huge rush and pressure to finish the game in time, and even afterwards when doing the patching to an acceptable level. They just weren't paid or got time enough to finish all these things.

And btw, the UT3 release was also delayed, and still I saw that many features they bragged and showed about UEngine 3 aren't simply completed at least in their own game. They might be completed in GOW, but not in UT3 which should make the use of it even better, but oh well, you get the point.

For instance, if you see any UEngine 1 based game (I have one almost as old as UT), even they have more stuff implemented and even their own particle system which Unreal and UT could have at that time as well.

So, if you want to see completed stuff under all the Unreal Engines, don't look in the UT or other Unreal series, look in other UEngine based games instead. Their own games which brought all these engines have half of the engine not working or simply not completed, but then you see another game using almost the same engine (with just some tweaks from the other company), and there you go: incomplete and non-working features actually working.

It's sad but it's true lol, so that's no surprise really, and I believe you're only halfway in realizing not only that, but many more things could have been implemented (they could have added a cubic and a spherical collision hull also to their meshes, even if they didn't rotate, and they would have the same performance as their cilindrical one, if not better in those 2 cases).

Keep up the good work, so if you are in c++ now, it means that you're done with all the software? Or are you leaving some software stuff to the end?

ha, you're so right yeah.. I was just curious ^^

Well yes, I'm at 90 % with Unreal Script Stuff.. and I needed some vacation from it
I'm currently transforming all global static functions into native functions and studying the actor management, level management (as good as one can guess that from public headers ), so here's the FINAL checklist before going into open Beta Testing in March:

• - Refining my Physics Engine and Vehicle Code, most certainly putting it to C++ too
  - Finishing the new Menu/Console System (which will support 3 different menu systems at the end)
  - Making stuff from LSoNP Render indipendent, optimizing it, implementing it into SDK (New Render Base, Hardware Post Processing, Distance Fog, Static Meshes)
  - Adding Vertex Shader Support (I want realtime water damnit !)
  - Trying to add New Terrain Mapping / Tree / Foliage Generation
  - Finishing work on the Unreal Avatar Gameplay System (won't be C++ since it's only gameplay code)
  - Adding/Finishing additional hardcoded Features: Bone Attachment, PhysX Support, Height Fog, Hardware Particle System, Hardware Projectors, Stencil Buffered Dynamic Shadows

Since moonangel COMPLETELY hacked Unreal Rendering with his alpha-state Render (yes he indeedy wrote his own Unreal Graphics Engine back in LSoNP Times) I might be able to really achieve these (visual) hardcoded features.
The clue is: There's no hidden fucking bullshit, everything is open source and written by me so that "everyone" should understand and work with it.

So.. yeah.. progress since November '09 was so intense that I'm nearing completition, at least for a stable Beta (UDK is still Beta too..)

[papercoffee]

So.. yeah.. progress since November '09 was so intense...

This is not intense .... this ...is ...SPARTAAA!

No kidding... this is the greatest thing I've ever seen what someone, out of the comunity, is doing for a Game.

I want this cellshading for the FF-mod

[Shadow]

hehe, thanks.. posts like that keep me motivated ^^

yeah your weapon mod would greatly benefit from the sdk

Update of the day:

Decided to stay with only 2 different Menu Systems, abondoning Unreal-Style UT Menu, I have simply not enough time and want to focus on the completely new Menu System, small overview..

Features

- easy to set up and customize
- Supports backgrounds, static images, support for dynamic images / software shaders (images with dynamic features like color fade, squeezing etc.), 3D Backgrounds and preset/custom layouts (XThemes)
- Supports custom cursors (users can add new custom cursers easily), even for different actions (loading, clicking, releasing, error etc.) - cursors can be 2D (images) or 3D (particle systems, meshes)
- All menus and settings of the UWindow System (so no one cries loosing something "important")
- New additional settings and menus (Demo Manager, Media Player, Multiple Screenshots Menu / Rotating Preview Shots, Mod/Mutator Manager and other magickal things)
- XMenus is easy to expand, menu layouts and themes can be changed in realtime, all media (images, sounds, text and music) can be simply changed and placed via Class Property Menu (so no cryptic canvas and uwindows scripting required for custom menus)
- derives from sdkObject.uc so all new native functions can be accessed directly (without the class'sdkObject'.static.Function call)
- supports multiple windows
- Menu Particle Effects Support


I hope I can show some media soon

Anything the community wants for the new menu system ? Then NOW is the time to request it !

[[did]Madis]

It's beyond me how someone can be this productive.

Hats down, Mr. Shadow.

[Shadow]

yeah for me too xD



JOURNAL DATE: 24.02.2010 - X-Menus are coming !

CHANGES / UPDATES

• 99 % of critical and complex functions are turned into Native/C++ Functions
• First stable Build of the X-Menus GUI !

OVERVIEW

Here you can see the very first shot of the alpha version of the new GUI entitled "X-Menus". It is a highly customizable GUI, offering the following services and features:

- easy to set up Custom Menus
- Background can be Image-based or 3D Environment, or both
- Menu Mechanics can be 2D or 3D, or both
- Menu Layout can be geometric order of elements or a dynamic Desktop with customized Icons and Functions
- Quick Menus for Right Mouseclick for fast and easy Graphics/Audio Settings
- support for different Styles, or Themes, changeable at Runtime
- Menu Elements are dynamic: Popping Up Images, Fade FX, Sounds, Mouse Hover FX, Menu Particle FX
- features many Tools: Music Player, Map Preview Database, Demo Manager, Mod Manager, Mutator Manager etc.

and much more !


MEDIA

[rohitggarg]

Now that looks like a kewl menu ..

[Feralidragon]

So basically you open a custom background map (like intro) and the rest is taken care with UWindows/Canvas? Cool

So, if I want to interact with the "map menu" behind, that's also possible? (I mean, let's say I place the menus in the map itself, and you have a cam that travels/rotates in that map depending on what menu I choose - just asking btw, not a request lol):

[Creavion]

Oh yearh. Hmmm, a redisgned UT1 menu, this would be cool. Pretty good work, as always!

[Rakiayn]

that looks very cool

[Shadow]

thanks all
it was quite a lot of work, first getting to know how UWindows works, then looking how modern menus work and what features they have, studying UWindows I must say: Show me one who is able to code a MORE complicated menu system..

then I made up my mind and coded 95 % from scratch

So basically you open a custom background map (like intro) and the rest is taken care with UWindows/Canvas? Cool

So, if I want to interact with the "map menu" behind, that's also possible? (I mean, let's say I place the menus in the map itself, and you have a cam that travels/rotates in that map depending on what menu I choose - just asking btw, not a request lol):

yes that's right, by the canvas (not UWindows, X-Menu is completely indipendent), there're a lot of ready to use functions like Mouse Position Detection, Hover Effects etc.

The X-Menu System can interact completely with all existing actors in a map, there'll be additionally helper actors connected with the system inside a map, like Menu-Movers. Imagine this: A Mover looking like a Gear is a symbol for "settings" the new mover class has options for what happens when you get with your mouse over it, if you don't want to use movers you can use meshes alternatively, performing defined animations for specified actions, or pictures by default.

Also In-game Popup Menus can be now created easily with actors that are placed in a map.

One of it's greatest features is the dynamic changeability of styles, layouts and rendering. You can arrange menu elements in runtime concerning their position, formation, style etc. or draw the main menu as a desktop... there're endless possibilities, so all in all there're 5 types how a (main) menu can be rendered:

1. - as a standard menu frame, creating a list or a simple window with contents
2. - as an advanced menu frame, elements can be arranged by layout definitions, arranging them in a circle, as a list (standard) or other geometric shapes
3. - as a 2D desktop menu frame, everything is rendered as symbols, widgets and icons on a desktop, they can be moved, arranged, docked etc. right clicking shows options, double clicking opens the associated next menu

4. - as a 3D desktop menu frame, same as the 2D desktop menu frame, but with (3D) elements that rotate, occlude, have depth on screen etc.

5. - as a full 3D environment menu frame, the menu consists of models and movers that represent menus and elements

Also NO coding is required to build up an own custom menu (-system). Simply subclass existing base classes and set up everything via the class properties window... the SDK features 2 example menu systems, one SDK-style Menu, and one UT-style Menu (whose alpha version can be seen on the image)

This is how the system works:

1.) we have sdkMasterConsole.uc, holds definition for both X-Menu and UWindow System
2.) choose which gui to use in the sdkXMenus.ini (or in the X-Menu Settings itselfs, that however requires a restart)
3.) UWindow System is initiated as usual
4.) sdkMasterConsole initiates the Master Frame Menu, which holds a dynamic linked lists of countless of elements, creating by standard a Main Menu Frame (Frame is not visually meant) that holds a couple of elements, like menu bars, sub menus, widgets (as seen on the pic)
5.) the Master Frame Menu iterates through the menu list ticks and draws them (accessing the master frame's menu list you can quickly iterate through the menulist like using iterators)
6.) On the widgets, menus, bars etc. you can then have Tick(t) calls and render own menu-dependent widgets etc.

ALL classes are objects, minimizing memory and cpu usage, critical functions are in c++.

Especially character setup, map menus etc. have been completely redesign in matter of functionality, the new map manager for example features a diashow of (highres) preview pictures, on standard the manager draws a nice looking "list" of map symbols, hovering over them gives you a small preview diashow and a quick overview of the most important facts (player count, theme etc.), double clicking let's you directly playing it, right click opens a popup menu with options and direct link to the big diashow map viewer..

So yes.. it's like a little own OS for unreal tournament..

[papercoffee]

......marry me!.............................................. no, wait that's not what I wanna say ...darn.


<= This is are the words.......... Phew!

[robin13]

uhm take a look at the menu,it says single player then instant action. but SP and IA are kinda the same thing
anyway so far