Road Kill Kenny

Well this is relatively good new. Thanks for explaining this Josh.

5am Monday for me.... hope I can make it XD Edit: woops actually 3am... lol worth it

Dang never realized how difficult it is to read code when there is no white spacing / tabing lol. I assume it copy pasted that way. Looks a lot different to my Content Factory but it looks fine to me. However, if you are loading from .sbx then I guess it makes it more difficult to register entities to the factory.. Unless you either make your own scene loader that parses the .sbx file (which is just a .txt file) and loads things as appropriate use databases.. hmm... just realised thats why mine seems so different... it's because my content factories have database functionality and handle the database reading and storing data as well. Makes sense now lol.

It sounds like a bit of a dodgy work around to me. (sorry no offense) I think it's better if you just have a content factory class to keep tabs on all of your entities and free them and create them as needed. That way all the entities themselves are in one place and the other appropriate classes have access to the content factory.

Don't know about everyone else but I do keep track of all my LE::TEntity instances.

Right just checked... it doesn't show up for me either lol

Well... if you logged into leadwerks forum and you are using the profile you used to buy leadwerks (would be odd if you weren't) then you can find your keys under 'Client Area' in your profile drop down thingy...

So....... are you gonna tell us?

Specs of both computers?

I don't know the how everyone else would do it in the industry, however this is how I would do it: 1. Shoot a ray-cast from both the left and right foot bones directly vertical 2. If if either ray hits something at a distance greater than X (you decide was x is.... close to 0 I'd say), - adjust the model offset from the model to the controller by moving the model down by the amount of the longest raycast. - Move the foot bone with the shortest raycase distance up by whatever that distance was. Ensure that if the raycast length difference between the left and right are no greater than Y otherwise it will look silly.... In this case the character should probably fall down the hill or slide down it or somthing. This should give the effect of your character adjusting their footing while on hills. I've seen this done a lot in 3rd persons and this is just my way of understanding it. To edit animations manually in run time by moving bones check out this short little tutorial of mine that I did a while ago: - http://www.leadwerks.com/werkspace/page/articles/_/programming/character-animation-tricks-tutorial-r83

Haha that's kinda funny. The reason those curves didn't turn out properly when you traced my original design the first time is because that design was a schematic design and not to scale in anyway. In fact I was just using paint.net to draw it roughly. Anyway looks good glad to see I could contribute in some way in the short time before I went full ball on my own project. Anyway good job turning it into a proper model from the schematic. peace out.

lol @ the slogan.. everything is sounding good. Keep it up

New video on HAARP. Getting pretty close to finishing the first build of the GUI editor part. Then I'll move onto the level loading & gameplay stuff which will be very exciting. http://www.leadwerks.com/werkspace/page/videos/_/wip-haarp-gui-editor-almost-finished-r147

Almost. The images themselves are not stored in the database. The file paths for the images are tho. And yeh all other data is stored in the database instead of hard coding it.

That is what I was doing. I loaded all the models I needed for a level and hid the ones that were not necessary. Kinda like a content factory. However, doesn't that take up a lot of memory space to store all the data for all the models? Same I actually like Microsoft..

Yeh that sounds kinda cool. However, I actually query all the data I need and store it in memory myself anyway at launch and in loading screens. So databases are only ever queried in loading screens while in game or if you are using the editor. Once the data has been passed onto the elements I can free up that virtual database. I'll keep it in mind for future tho. Sounds like it could work nicely.

Hi All, I don't like posting images of H.A.A.R.P in the Leadwerks gallery thing because I don't want it to clog up the image thing on the Portal with pictures of H.A.A.R.P. Admittedly it isn't that visually stimulating and I'd rather let the people doing sunsets and cool graphic things to have their images there. Therefore, I've decided I'll just make a thread for H.A.A.R.P and post images here. Today for the first time I used H.A.A.R.P to assist in creating UI elements for the UI editor itself. As you can see below I have made a few elements and put them in the correct positions and such. All I have to do to make it part of the H.A.A.R.P editor and not part of the game is change one cell in the element record to say "HAARP" and a line or so of code in the program. It's good for getting precision positions of the elements visually and it makes even making the UI editor much faster. Also you may have noticed I'm making a parameters tab in the left side panel (which is actually a window element in disguise) Although the buttons around the element selection box is good there is no way I can get enough buttons and such to fully edit everything about the UI elements. Therefore, I made this properties panel which can edit other edits such as listed below. It is also good because You can get exact measurements for positions and dimensions which update in real-time when you move them in the screen. You can also type in positions and dimensions into those number boxes as you would expect and it will update the element. show label element type label text label offset label font label color Other Element specific things All elements (for first build) are complete and soon they will be fully editable with this property panel. Following, I just have to finish HAARP switchboard and a few little odd's and ends and it will be on to the good stuff. I know that everyone says you shouldn't start with a UI and you should do gameplay. However, this has sort of been an experiment in itself so I wasn't confident to use the 'DDD' and the "make as you play" concept on gameplay straight of the bat. I was more comfortable doing it with a user interface system but now I feel I am confident enough to do it for 3D and gameplay as well. I can't wait to dive into it.Luckily my entire system is based on Finite State Machines so I can work on that in complete isolation to this as if it were another little program.

Lol I ended up adding a number box too. Kinda needed it for the editor

The last week I have been working hard to add all the missing UI elements and widgets that were previously missing in H.A.A.R.P. Before I was testing everything with just buttons and check boxes but I couldn't really go on without testing on more types of elements to ensure everything was working in the right way. Therefore, over the past few days, in my time after work, I've been madly re-coding the UI elements that I have previously made to be compatible with Data Driven Design and more specifically H.A.A.R.P itself. I have added the following Elements now: - Buttons - Check Boxes - Text Boxes - Labels - Sliders - Drop Down Boxes - Windows Although the above list is not a comprehensive list of all the elements you could ever think of or possibly need, I think that it is plenty for the first build of H.A.A.R.P GUI. I may have to add game specific elements or H.U.D elements later such as HP Bars etc. but I will leave that for another time. Below is a screenshot with all the elements randomly placed over the screen. Please excuse the graphics I used for most of them it is simply just for testing. You can put any graphics you want for these elements, you simply have to save the .dds files in a game folder and the click on the green folders on a selected element to change the images used. here is a picture of the Drop Down Box Selected. As you can see there are 8 little green folders because the Drop Box uses 8 little textures to put itself together. It could be less, however, the size and dimensions of the Drop Down Box become more restrictive. These little green folders automatically detect how many textures a UI element uses and displays the relevant number of folders. Element Diversity: There are a lot of elements in any Gui to begin with but there are also many different sub types of elements. For example, a slider element can be either horizontal or vertical. In Designing the H.A.A.R.P elements I have taken this into consideration and enabled setting of element sub types. The type ID is stored in the database and can be changed in the editor. The behavior of an element depends on the typeID specified and if I need to create more behaviors for a single type of element i simply have to code the new behavior with reference to a new typeID. Another example of this is Buttons. You can have a button that is simply an image, However, perhaps you want to only use one image for all your buttons and just write text over the top of that to make the Buttons different. Well, you can do that with H.A.A.R.P. Simply changing the Button type from 1 to 2 in the editor will do this. Font & Element Labels: Labels as an element is one thing, but what if you want a label for other elements so that they can be identified. For example, a slider might need a label that says "Master Volume". I could simply make another Label element, but that would just be much too much work and take up more memory than is necessary. Instead I have given every single element the ability to show its own label at a specified offset from the start Position of that element. The font style and color of the label can also be edited in the editor simply by changing a few number. Below is an image of a button element drawing its own label. As this button is actually part of the editor I had to manually write the label name, color and offsets into the database. You may notice I didn't set a font for this one. It should be noted that all this is taken out of the database including, 'whether to show or not to show a label', the label font, the label color (RGB), the label offset from the element. Everything comes from the database and nothing is hard coded. This allows for the ultimate control and ultimate re usability of the code. Saving & Deleting: I have recently implemented Saving of the UI elements new information back into the database. This task wasn't particularly hard as it just involved parsing the information from an element into an SQL statement string and then querying the database. However, Deleting elements was another story. Although it may sounds simple, I battled with deleting elements for 3 days in mega frustration. It may sound easy but my database is set up is to make the least amount of columns possible. Therefore, there is a Generic_Element table which holds all data that is generic among all elements. This table kinda represents all the values stored in the element base class which is inherited to make a derived element specific class. On top of this table, I also have a table for each type of element and it holds all the element specific data. In order to make this work the tables need to reference each other. Each element has a generic ID and an element specific ID so deleting becomes difficult when you have multiple tables and you have to cross reference everything correctly, not to mention it having to be in-sync with the run-time information as well. Now deleting wasn't even the hardest part, in fact it was as simple as parsing the generic ID and the element specific ID of an element into an SQL statement string and querying the database. However, once this has been completed all element above the deleted element have to have their ID's rotated downwards. This was really difficult more as a logistical thing than a coding thing. It took me a long time and much frustration to figure it out. However, I have won and the deleting algorithm is down pat now. Below you should be able to see what I mean about the databases. Although this setup causes problems in deleting. It is more beneficial than it is detrimental. Separating The Editor From the Game: When I started making and designing HAARP I decided it was very important that this "In game editor" did not interfere with the performance of the game when it is actually being played in any way. Therefore, I constructed the HAARP editor completely separate from the game code and simply given editor access to the game objects via pointers. Once the editor is turned off there is literally no effect on the game whatsoever except for a single 'if' statement. Also once a game is completed, I simply have to comment out a single #define line and it is as if the HAARP editor never existed. I am happy that I made this decision early on in the piece because the complexity of the editor is much greater than that of the actual screen state code. All the Screen state code really does is cycle through all the elements and updates them. The elements are designed in a way that they fully manage themselves and their own relationships with other variables, functions and screens. This blog turned out way longer than I had anticipated. Oh well. I hope you enjoyed it and maybe learned something. - Ken

Yeh cuz Linux really is the future of game development.... :l

That's great. Will make debugging much easier. Especially with the data driven design stuff because often you will get crashes that are caused by bad info in the database rather than the code and it takes a long time to identify that that is the case.

Hooray! Lets keep it that way.

Awesome. I like custonizable... whats next after the user interface is finished?

There are two things I've been working on since my last blog: HAARP Sound Manager (For UI Sound only atm) & HAARP Switchboard The HAARP Sound Manager is not very much different to what you would expect from most games sound manager layers except for the fact that once again it is completely data driven. All data on sounds are stored in the database. Each UI element holds an ID of a sound to play at certain times for example: Button Element: 1. Hover Sound 2. Click Sound The challenge is how can this be set up dynamically. Well this part is actually quite simple. Each sound has an ID in the database, each Button has two sound id's stored in two different columns, one for hover sound and one for click sound. All that is needed once the data has been extracted from the database is to cross reference the sound id's that the button has with the actual sounds referenced by those id's and you can easily give a relationship dynamically based on the database values. However, things get a little trickier when you want to allow the creation of these element to sound relationships in the HAARP editor using the wires like I can already attach states. To solve this I came up with HAARP Switchboard. HAARP switchboard is basically a set of classes that allow easy visual relationships to be made between UI elements, sounds, functions and variables. Basically a swithboard can be created and that switchboard can have any number of plugs. The switchboard can be moved around the screen in edit mode and the user can plug elements into those switchboards however they want. Depending on the switchbaord being used it can hold many different types of data: For example, a post processing effect switchboard may have a plug for SSAO, Godrays, FXAA etc. and plugging check boxes into those plugs on the PPFX switchboard would link the two together and give a dynamic relationship so that when the check box is checked, that effect will be active and when it is unchecked the effect will not be active. I am even considering making the option to have dynamic switchboards which can be created by the user in game. So as I was doing the sound system I thought I would start with the simplest of simple switchboards and this is the UI Sound Switchboard which only has a single plug. The sound switchboard holds a sound in it and different sound channels from UI elements can be plugged into it and based on those relationships will play a sound. Have a look at the screenshot below: Perhaps the very first thing that you would notice is the wires going everywhere. These wires are important to show relationships between elements, sounds, screen transitions, variables and functionality. The green line is a screen state relationship. As you can see it is plugged into the options screen. If the user exits from edit mode and clicks on the options screen they will automatically be transitioned to the options screen state. (It is important to note that even these states listed are not hard coded but dynamically drawn from the databases. Later I will add functionality to create new screens in the editor). The blue lines show sound relationships to the UI elements. As you can see there are two plugs and two wires for sound. This is because a button has 2 sounds, one for initial hovering and one for when the button is clicked. Therefore, the first plug is the hover sound and the second is the Click sound. If this were a check box it would only have one sound plug for when it is clicked as no hover sound is necessary. The editor will dynamically detect the number of sound channels a UI element has and dynamically create these plugs based on that number. It should be noted that these sound channels can be unplugged by just dragging the plug onto nothing and then there will be no relationship and sound will not be played through that channel. It is arguable that the whole visual idea with wires running everywhere can make things a bit cluttered. Therefore, I have implemented features which help remove this clutter. First of all there is a wire toggle. The user will be able to toggle different types of wires so that only certain types show or none show at all. This lets the user focus only on the wires they want or no wires at all. I have also made it that when even when all the toggles are off the wires will show on the selected element. This way you will see only a few wires. I am considering have a toggle all wires on the selected element HUD to improve it even further. So the long story short is that HAARP Switchboard is the methodology or technique that I came up with to dynamically and visually make relationships between two seemingly isolated pieces of data without any hard coding of the data whatsoever. Although the sound switchboard is different to say an options menu switchboard it will still work on the same principals Other Things I've Done Since Last Time: Added a text box to top right with an OK button which is used to set the background texture. Added a number of tabs to the HAARP Editor Side panels for future use for more space and functionality Improved the databases dramatically so that even more settings can be set within the elements from the database, meaning less code in the main areas of the editor code

Sounds like a plan.... too bad we can't make quote pyramids. That would make this thread way more interesting.Edit Edit: Wait I take that back. Quote Pyramid created