View Full Version : Build 1.0.37 should be available soon
09 May 2005, 13:06
Just sent Dazzy at the VFR Addon Site the latest upgrade to the Autogen program. One thing that numerous people had asked me for was that when creating multiple houses along a freehand line, that the houses aligned themselves with the slope of the line. I had coded that tool quickly and the simple programming was to just have the houses align themselves N/S/E/W. Well, got into the code last night and figured out how to make it work. There's a new checkbox on the main screen for turning on that alignment now.
Another new checkbox makes all multiple houses have random sizes and spacing, a feature that makes them look more like the real world, especially in housing developments where homeowners have multiple choices on models.
Fixed a couple of small bugs and have created a ton of autogen homes in the last few weeks using the program. The Phoenix scenery is becoming such eye candy that when I go into FS to see the results of my last editing, I find myself flying around for an hour.
Next feature I'd like to add is a custom bridge creation tool. Already have the ability to lay down a sequence of GUI objects such as bridge segments but you end up with only the center segments and if there are separate end ramp segments, it's still difficult to place those. I envision a tool button that allows you to choose the matching bridge segments you want to choose visually from the availble GUI objects, draw a line on the image tile and the objects are placed at the right distance apart and alignment. Trick will be determining the distance between the segments. Probably will have to be some trial and error thing since I'm not sure one can query the underlying model information and get that from the stock GUI objects.
The other software I'd like to write is a visual aid to making tweaks to photoreal scenery tiles. In a huge project such as my Phoenix project, there are a few areas where the scenery blocks are off by a little bit from one another since it was often difficult to find real world coordinates to match to. It's especially noticeable when a road goes through a tile and suddenly jogs to one side. Redoing the entire block of tiles is awkward, especially after you've invested time in defining autogen since now your autogen would no longer line up. What I envision is being able to display areas of tiles together in the bad areas, selecting multiple tile images, merging them together, and sending them into a graphics program of your choice. You can then make some minor graphical edits to the merged tiles. Once completed, the program will them split them back up into the separate tiles and encode them back to the DXT format. Is this something anyone else has done or would see a use for?
I've said before, I just need to think of a problem, and you come up with a solution. Here's an excerpt from an article I'm writing, mainly for those involved with my current project:
"Art has also looked at ways of streamlining the placement of buildings. You can put in a row of houses (as opposed to a row-house) by defining a rectangle, and you can also draw a freehand curve, along which houses will be placed, albeit each aligned north/south rather than to the curve.... . I'd like to see a bit more randomness in building size, also, and maybe one more tool -- a super-block tool, which places houses in a defined rectangle, interspersed with trees for that urban look."
Ok, you've given us the align-to-curve and randomness. Can I please now have my Super-block tool? :)
10 May 2005, 00:22
hmm, could be. Sounds like a fun idea. So do you think I should risk putting this back out on Avsim as a production utility? I'm still nervous about the VB installer not working on all machines. Nearly everyone I know has gotten past the problems but there's at least one person that is just stimied. I'm certain there's something unique about his setup or he has his firewall and/or antivirus system locked down too tight but it doesn't take but a few complaints for Avsim to pull the program.
The latest version ought to show up soon. I emailed it to the wrong address this morning. Resent it tonight.
So do you think I should risk putting this back out on Avsim as a production utility?
My initial reaction, if I was you, would be to say stuff 'em, but for one thing -- for serious scenery designers, your AOC isn't some little tweak, it's a real step forward. I've published a lot of photoreal scenery (see the Godzone project (http://godzone.windowlight.co.nz) etc.) and I wish I'd had something like this 2 years ago.
But hey, if the world isn't ready for it, then all the more for us!
10 May 2005, 17:17
so you are Robin Corn ?
If yes - your tutorials were excellent to learn gmax and scenerydesign !!!
Saved a lot of time for me and answered many questions i had ...
Greetings from Germany -
Thanks, Enzo, yeah it's a bad habit not signing my name...
10 May 2005, 19:51
So do you think I should risk putting this back out on Avsim as a production utility? I'm still nervous about the VB installer not working on all machines. Nearly everyone I know has gotten past the problems but there's at least one person that is just stimied. I'm certain there's something unique about his setup or he has his firewall and/or antivirus system locked down too tight but it doesn't take but a few complaints for Avsim to pull the program.
If AVSIM doesn't lighten up on this, they are in for some problems.
I've been playing with C# and the .NET environment. If I start to develop tools using this, I'm not going to include .NET runtime codes.
They are part of WindowsXP SP2... but many users are afraid of SP2 ( some even afraid of WindowsXP ). The .NET runtimes are sizeable, but can be found at MS if someone doesn't want to update. ( I suppose I could include a link, but then I'd be blamed when they somehow botch it's download or installation ). Someone using Windows95 will surely complain that the tool doesn't work
I'm not alone in looking as C# or VB.NET as a development language. .NET is going to become much more popular, and may even be needed for applications in future releases of Windows.
My position is this: if you don't want to use WindowsXP SP2, or cannot download/install the .NET runtimes on your own, then don't use the tool!
So if AVSIM can't understand that the enduser has the responsibility to get the correct runtimes for VB6, and that your tool is in a state of evolution, then that's their problem.
Just post a link to where the code can be found in the AVSIM Scenery Design forum, and they'll have to press a couple more mouseclicks to get it. Your tool is worth a little end-user effort to get it and to install it.
Besides, there are probably hundreds of users that never got the MS autogen tool to work!
My $0.02, and the end of my ranting. :)
11 May 2005, 13:19
What gets me about sites like Avsim is that there seems to be this point where, if a program gets enough distribution and acceptance, their rules for no complaints seem to get pushed by the wayside. This is only a hunch of course since I have no idea of what complaints they get but it seems absolutely reasonable to me that even the best, most stable scenery utilities out there must still suffer from installation and compatibility woes and, knowing how whiney and impatient users are, there have to be complaints going into Avsim. Yet many applications have been available in their libraries for years.
After my recent experiences with distributing my autogen application and some recent nightmares at work, I don't think it's possible under the Windows operating system to create an application and installation package that is guaranteed to work on every possible workstation setup. I think that .NET is going in the right direction in some ways but there are such drastic changes within VB.NET in regards to data handling that it is simply not the logical choice for many business applications. Of course, knowing Microsoft, in a few years we'll lose the support for the development environment many of us have bought into in VB6 and will be forced into a single option of the .NET architecture. That is until the next major rewrite occurs and then .NET obsolescence will begin.
For many years, because of the very limited budget our company was on for IT, our development platform was dictated by limited resources to DOS, XBase data files, and a limited Novell WAN. We chose Clipper as our development language. The XBase data was free and easily managed. Clipper was purchased by Computer Associates and eventually the support and upgrades to it went away at a time when the language was fairly stable, feature-filled, with a huge amount of aftermarket addons for libraries. Without that constant change of the development language, our business applications also took on that stability and my programming speed and accuracy increased by leaps and bounds. As Windows came along those old trustworthy DOS applications continued working with minimal support as the newer Windows applications broke constantly and required a huge buildup of staff for support.
I certainly don't advocate continuing on in DOS development except maybe in some imbedded devices where lean and simplistic is better but I got spoiled by developing with a "finished product" for so many years. One didn't need a primer on syntax every 6 months and repeated upgrades of operating system files to be compatible with your latest project. You didn't need to spend hours researching a bug because your code was self-documenting and didn't require convoluted OOP class structures and lookups for some simplistic task. Installation was simple. You copied in a new executable that had all functionality contained within its own code.
Even though VB6 is much more complex than those old DOS apps, it still retains that feel of a product rapidly reaching its maturity and stability. As with Clipper, it's code is fairly self-documenting if one uses intelligence in variable and function names. I was able to hit the ground running when I first delved into programming with it. I've yet to find something I cannot do in a standard business application. VB.NET was a different beast. Simple tasks require complicated setup and I'm not so sure of the payoff in performance or functionality. Yeah, the apps port well to the internet but in my job I have no real use for that.
Anyway, enough of a rant for today. I'm not getting any programming done at work, something my mortgage payment relies upon.
11 May 2005, 18:53
I've read recently that VB6 is no longer being produced by MS. :(
And VB.NET, for others that may not realize, has very little in common with VB6.
I program only for this hobby, so my journey into the .NET environment is just an adventure.
For business, it may seem like a leap off a cliff! But I think the future of Windows programing is going to be various incarnations of the .NET for some time to come. Just a guess.
.NET also allows code of different types in the same project, so ADO, C#, C++, VB.NET and ASP can all reside in the same project and happily be compiled together to MSIL psuedo-code for runtime interpretation.
How's that for a tower of Babel? :laughing:
vBulletin® v3.8.3, Copyright ©2000-2013, Jelsoft Enterprises Ltd.