Messages

31

Design / Re: Improved Air Combat (coming soon...)

« on: June 14, 2012, 05:45:11 pm »

I've put an updated version on the server for my website.

This one is compiled to work in 32-bits, so nearly any Windows user with OpenGL capabilities on their machine can try it.  I built it with 32-bit MinGW, TDM build, so it should be easy to recompile for anyone who knows a little programming.

There is also an import .a library (for Irrlicht, which is needed for the demo) for Linux users - I didn't have time to build a Linux binary, or a makefile, but if you run Linux and know how to compile stuff you could probably figure it out with the source files.

Note that Irrlicht is seperate, my own code does not depend on it, it is only used in the demo to display the created models on-screen in 3D in a window and allow the mouse and arrow cursor keys to move around.  My own code for the terrain generator just uses a few basic standard libraries from C++ and could be plugged into nearly any graphics or game engine.

If anyone has trouble running the demo, one can also load the OBJ and texture files in Blender or another modeling program.  Depending on what engine my code is put into, the Y-axis of the graphic textures that are generated might or might not have to be flipped.

If you're playing with the source code, you'll notice I no longer have it all stuffed into one almighty header file, it is now broken up into multiple .cpp and .h files, all of which are in the terrain folder under ./include.

I'll mention a few technical things in the coding section of the forum.

32

Feature Requests / Re: Mortars

« on: June 14, 2012, 03:58:11 am »

...I'm not suggesting super heavy ones. I'm thinking of this, instead of this.

Ah, thanks for pointing that out - that's where I misunderstood.  I apologize - I've been in and out of involvement with this game for so long that I've gotten used to (more like sore and somewhat desensitized in a way, I admit,) having to defend the way the game is designed and argue back against occasional people who come to the forum and ask for nuclear weapons, huge super-bombs and other crap that would destroy game balance and wouldn't fit in well at all, to the point where in this case I made a few assumptions.

Oh, that and the occasional request for a light-saber or some other silly bulls***.  Keeping the game intact from that type of nonsense can also be "fun."   

33

Feature Requests / Re: Mortars

« on: June 14, 2012, 01:42:47 am »

Guys, I know I've been away from this project for a while, but after coming back and reading through this thread, I have to admit I'm a little *against* mortars in the official game.

Much like proposals for air strikes, air-to-ground bombs, and other really heavy stuff, please remember that in the setting of the official game Phalanx troops are supposed to go into an area and more surgically remove a threat withOUT causing a huge disruption by blasting things to the Christian hell, withOUT drawing a lot of attention to what should be a secret or low-profile organization so aliens don't target them, and withOUT causing massive damage to a populated area of a nation that is expected to support the organization.

Yes, I realize that in video games it can indeed be fun to simply chuck a big A-bomb at a group of bad guys and just nuke the f***ers, but it kills the realism we fought so hard for in making this game - much like how this game tries to go for *hard* sci-fi stuff and not the soft fantasy-ish like material.

I'd also like to point out that real-life military veterans and experts that I've known and talked to (including one in my family, who fought in two world wars) who really know the practical consequences of blasting large areas with powerful weapons to root out enemy units often run into this type of mentality with inexperienced people who don't realize the problems with such an approach.  Many "arm-chair" idea givers who have never been in the military favor this thing with blasting large areas like that, but the real experts are against it.

Yes, in the history of wars and fighting they have indeed tried that type of thing - It doesn't work as expected.  I don't claim to be such an expert myself so I can't list all the reasons why, but the real experts who have really *been there* know that it is a BAD idea in many cases.  Most actually prefer to go into an area and remove JUST the threat withOUT causing massive damage to the area while doing it.

All that being said, I think this would be better as a MOD, and should go in that section of the forum, and not show up in the official version of the game.

34

Design / Re: Improved Air Combat (coming soon...)

« on: June 13, 2012, 10:34:05 am »

I forgot to mention that if the UFO AI graphics engine could support a "detail map" texture - via a second texture on a model with different texture coordinates, something like what is in this screen shot would be possible, which would look nicer.

35

Design / Improved Air Combat (coming soon...)

« on: June 13, 2012, 09:56:24 am »

EDIT:  The updated version of the demo (version 5) is at http://www.destructavator.com/ufoai/terrain_test_5.7z
EDIT:  The updated version of the demo (version 6) is at http://www.destructavator.com/ufoai/terrain_test_6.7z
Note: The download is just under ~70 MB, and the pre-compiled Windows version (built for 32 bit) requires SSE2 (which shouldn't be a problem unless you have very old hardware).  It also uses OpenGL, and as such I'd recommend using the latest graphics drivers direct from the manufacturer (NOT Windows Update) for best performance.

EDIT (again) Please also look at: http://www.destructavator.com/ufoai/TigersEye1.7z
and http://www.destructavator.com/ufoai/TigersEye2.7z
Sorry, I used the wrong compiler, the working version for 32-bit is at: http://www.destructavator.com/ufoai/TigersEye3.7z

-- For reference, on my several-year-old Dell desktop (i7 CPU, 2.67 GHz) with an almost-as-old Nvidia GTS 450, I can run most terrain selections in the demo at full screen with anti-aliasing cranked up all the way and get around 150 to 190 FPS while viewing most parts of the generated terrain and objects in the demo, using Windows 7 HP.  Also, the demo is not currently multi-threaded, right now it is built to use just one CPU core.

The technical, coding thread on this is at: http://ufoai.org/forum/index.php/topic,6772.msg53968.html#msg53968

OK, I've been working on developing code and stuff for a new system for air combat / interception.

It'll work in a 3D environment, and unlike the battlescape all aircraft and things will move and fight all at the same time, although the speed and pause controls from the geoscape will still be available - in fact the player won't leave the geoscape at all, it'll all take place in a custom UI node on top of the main geoscape view.

As I picture it, if the combat starts with the player's aircraft chasing the UFO, the UFO will start in the center of the map, with the Phalanx aircraft at an edge, approaching the UFO.  If the UFO is coming after a dropship or player craft, this is switched, and if both are coming at each other, all opposing forces start at opposite edges of the map.

The biggest obstacle I ran into was trying to get background terrain - I needed to code something that could quickly (with an optional seed value) generate background terrain that wouldn't leave the player waiting a long time, and also be displayed as a 3D model in the scene graph able to be rotated and moved around in realtime.

I've worked hard on this, and I've now gotten together some terrain generation code that can do these things in a work-able way.

Don't expect anything photo-realistic like Terragen 2, that wouldn't run fast enough for realtime animation for a video game.

The code I've written isn't fully complete, but could generate different types of terrain for various areas on the map, so arctic terrain would be made over Antarctica, mountain terrain over a mountain region, etc.  It could also make lunar or alien-world terrain.

Oh, and any aircraft that pass beyond the border of the generated map would be considered to have escaped combat (for the moment).

The code I wrote also retains data for each spot on the terrain, so when a UFO is shot down the game will know if it fell in a lake, on some trees, on a mountainside, etc.  This information would then be passed to the battlescape, so a ground battle in a matching map would occur.

I also plan to extend this to generate buildings, cities, trees, etc. and place them on the terrain.

Right now, if anyone wants to demo the terrain generation, it is currently compiled to run with 64-bit MS Windows, using OpenGL via the Irrlicht 3D Engine (also on SourceForge), just for a quick demo.  If you can run it, use the cursor arrow keys to move around and the mouse to tilt and steer to move around the landscape.  Use the usual ALT-F4 to close the program.

For the technical side, this code generates and writes WaveFront OBJ model files of the terrain, water plane, and other objects.  It also generates a texture map for each, and the texture pixel data, although it doesn't include any PNG writing library of its own, but has get*() functions for getting the data.

I kept this version of my code very general as I intended to use it in not only UFO: AI, but also other games and programs.  For UFO AI I plan to modify the code and extend it to feed the generated terrain directly into memory instead of a file, as well as the texture, and of course render it with the game's engine, not Irrlicht.

You can download the demo at http://www.destructavator.com/media/terrain_test.zip .
EDIT: Look at the top of this post for the latest download.

36

Artwork / Re: New Bloodspider Model

« on: August 01, 2011, 02:29:52 pm »

There is a brand-new md3 exporter for Blender 2.58 available.

I tested it and it is working, but I have tested to export only static models yet:

http://xembie.com/2010/md3-exporter/

It should work with animated models, also. In the worst case we can just export the keyframes and rebuild the animation in another program capable of md2 support (like mm3d).

If we got the model in md3 we can convert it to md2 easily, as there were problems with md3s in-game recently, but maybe Mattn has managed to eliminate those already, he would have to answer that...

Also it would be nice, if he could bake a normalmap in Blender and provide that also (especially for the low detail LoD model).

Making a nice diffuse texture for the model should not be the biggest problem once we have the animated model and a UVmap of it.

YES!  About time someone wrote an exporter for something at least close to what we usually use for UFO AI!

MCR, you deserve a pat on the back, thanks for finding that.   

As far as issues with loading MD3 models in-game, I don't know how functional that is at the moment myself, but if it does have problems I'm sure they'll be fixable.  I do a lot of work with some other 3D graphics engines and SDKs outside of UFO AI, mostly open-source, and one of them has its own MD2 and MD3 loaders that could be used as a guide (comparing code) if our own MD3 loader for this project happens to be broken.  I don't necessarily mean copying code direct or anything, but it could be good as a general reference if we get stuck getting our own MD3 loader to work.  (The 3rd party SDK I'm talking about is in C++, so we couldn't just copy code anyways, although it is capable of loading models for OpenGL as well as use with SDL, which if I'm not mistaken is close to what UFO AI uses.)

On the other hand, if our own MD3 loader works fine, then we won't shouldn't have any problem, and we can *finally* get Blender-made stuff into this project again.

37

Artwork / Re: New Bloodspider Model

« on: August 01, 2011, 11:00:20 am »

Regarding the animation thing:  It isn't an issue at all when creating the model - The modeler can, in their modeling software, use either manual vertex animation or a skeleton when creating the model and it's animations, no problem at all there, as long as they have a proper MD2 exporter.  An example is the python MD2 exporter for the old Blender, which automatically converts any animations created by a skeleton in the modeling program into vertex MD2 animations when exporting.

Back when I was making models and animating them for this project (in Blender) that's exactly what I did - I used a skeleton inside Blender for rigging and setting the animations and poses, and when I hit the MD2 export button the computer would convert everything, with the resulting MD2 having vertex animation.  The skeleton was only a "helper" tool, only inside the modeling program but not carried over into the game at all.

So as long as a properly written exporter is available, it doesn't matter how the modeler creates the animations inside the modeling program.  Does this make sense?

38

Sounds and Music / Re: song for game/feedback

« on: July 27, 2011, 12:22:10 am »

I apologize - I admit that I can be prone to a "gut reaction" to certain things, and if I came across too strongly I'm sorry.

I'm just a tad bothered seeing long-established/approved works pulled back out of the game like that, especially in such an abrupt and almost spontaneous manner without everyone's input and proper discussion.

Side note:  Sorry for the very late reply, I had a lot happen in real life lately.

btw: i came up with the idea releasing a "soundtrack" on our indiedb profile - featuring all the music which were, is and will used in UFO:AI.

Yes, that would actually be a nice thing to have, I'd suggest releasing it when 2.4 finally gets out.

39

Sounds and Music / Re: song for game/feedback

« on: July 16, 2011, 12:26:37 am »

I have to agree and side with H-Hour on his points - Musical tastes vary quite a bit, and just one or two developers have NO right to force-feed their own personal tastes down the throat of the player and "straightjacket" them into listening to only one style they might not like and not have a choice.

For a long time I've glanced at reviews of the game on third-party sites, and looked at comments from people who have downloaded and played the game.  When it comes to comments about the soundtrack, not surprisingly some favor it with a "thumbs up" and others really would want something else.  I even recall one player who hated the slow ambient stuff, calling it "electro-jazz" and saying "it puts [him] to sleep..."

I'd also like to point out that many of the tracks that were recently commented out in the .ufo file were already approved a long time ago after much work, and it is counterproductive to development to carve out and remove things from the project to the personal likings of one or two developers every time a new developer joins the project.  This is a perfect example of what Winter was talking about when he came to the project, things constantly being pulled out, put back in, changed back and forth as people joined and left the project.  It stifles developmental progress of the game and creates chaos.

That being said, if the variety is too jarring and consistency is desired, the player should still at least have some choice, with a menu option, downloadable packs, whatever.

I don't make it a secret that I would personally favor a good hard-rock action soundtrack for parts of the game, but I at least am aware that not all gamers like that type of thing, some would prefer other material, and I respect that, I don't try to force my own taste on others.

On a side note, I actually do have much better-sounding air combat tracks and better versions of the old ones I've never uploaded, but I'm putting that off until we get around to starting a branch for implementing 3D air-fight sessions that would use such tracks.  It'll be a while before things get to that though.

40

Bugs prior to release 2.4 / Re: Intro cinematic crash when clicked

« on: July 10, 2011, 10:10:55 am »

On my windows machine I also have this issue.

I think I may know where at least part of the problem is:

Back when we included the Xvid codec library in the dependencies to compile the game, I remember that version of Xvid had some issues - I've been following development of Xvid a little for at least a couple of years now - and shortly after we included what was then the current Xvid code in the packages used for Windows the Xvid team released a new bugfix version that fixed various issues including ones that would cause crashing and other unstable behavior.

I don't think we ever updated the code we used with the newer version after it became available, so that on Windows we were still building with an unstable and buggy library.

Mattn probably doesn't have the issue on Linux because many Linux distros grab updates to development libraries and other resources used to compile software - I know at least Debian and all the *buntu versions do this.

By comparison, Windows only gets updates natively from Microsoft, which only provides updates for the OS itself, other MS products (Office, Powerpoint, Visual Studio, etc.) and sometimes drivers that are approved by Microsoft (which are typically out-of-date).

Third-party stuff such as Xvid, OGG codecs, etc., and especially any open-source stuff and other libraries, even MinGW, do NOT get automatically updated with Windows Update.  If Microsoft has nothing to do with it, it must be updated by hand, meaning checking the website of a library development team and downloading a new version when one comes out.

Linux can update nearly all of its components via an automatic updater, Window doesn't, and this is a sucky drawback to Windows.

I have a feeling that the Windows libraries used to build the Windows version are still using dated versions of libraries, while the Linux users are able to easily compile and build with the latest versions thanks to their periodic updates.  This may include the old, buggy, and unstable Xvid codec library (which has been updated to new versions several times since when we first included it in the game).

41

Artwork / Re: Geoscape Icons

« on: July 04, 2011, 02:49:45 am »

RaXaR?  Holy Sh**!  It's nice to see someone who was with the project from waaaaayyyyy back show up again!  What have you been up to?


BTW,

i know destructavator had a working md2 export/import script for blender 2.5 - i will ask him - we also have support for dpm, obj and md3

Well, I wouldn't quite call it "working" (functional), more like "I started to mess around with taking the old script and trying to shoehorn it into the new version of Python and new Blender API to make it work in the new Blender, but only got so far..."  I will say that getting a new script working is likely coming up on my personal TODO for this project though, as I've got models I've made myself I'd like to offer for the game that I haven't announced yet.

First I need to return to the auto mission code and see where that is at the moment - I was out for a week or so as I've had to deal with the death of someone close to me, and I admit I haven't had the easiest time getting over it.

42

Windows / Re: Win64 installer?

« on: July 04, 2011, 02:33:25 am »

The one downloaded from this link:
http://sourceforge.net/projects/ufoai/files/UFO_AI%202.x/2.3.1/ufoai-2.3.1-win32.exe/download

It doesn't seem to work, and I have no idea how to compile/run the 64 bit version, or where to start with it anyway.

Can you please elaborate on "It doesn't seem to work" a bit, such as the exact error message you are getting (screen shot? log?), or exactly what doesn't seem to work right?

I have several computers I multi-boot with various operating systems of different versions, between them I have several installs of Windows 7, one 32-bit and two of them 64-bit, and I've run this game on the 64-bit installations of Windows 7 without ever having any issues related the version of Windows.  To be fair, I have several programs and apps that won't work on 64-bit Windows as they insist on only working in a 32-bit environment, but the vast majority of my programs and utilities work in 64-bit Windows regardless of what type of Windows they were compiled and built for.

Also, can you please tell us if you are running a "true" Windows installation or a virtual/shell environment?  In my experience sometimes running Windows within a special non-native environment can cause compatibility issues.

IIRC the installers on Sourceforge may have been cross-compiled from Linux, which sometimes causes things to go wrong, but I haven't seen this issue come up before.

I'll download and double-check the installer myself anyways though.

BTW, I've actually been trying for some time to build a 64-bit compiled version of the game, using MinGW-w64 toolchain, although I've had limited success as it seems to almost but not quite fully work.  It isn't a developmental priority for me at the moment though, as I need to finish up something else in the code before I really get back to such an experiment.

43

Discussion / Re: My soldiers never gained experience during automissions. It would be helpful if

« on: May 15, 2011, 05:46:02 am »

However I'm not sure if it's a good idea to give experience for "nothing". I think "If you want your soldiers to improve, make some effort - do missions manually" is a valid argument too. It will need a decision on our side..

-geever

Well, once I get at least part of the new system working, not all of the soldiers will come back alive or in total health, so although there will be some experience gain there will also be some sacrifice.

Even when the new system is totally implemented all the way at some point, I would think that there would still, on average, be at least *some* benefit to doing a real mission over an automatic one, to discourage the player from over-use of the new auto mission system.  Exactly how that will be done I'm not quite fully sure of yet - I've got several ideas - but first I need to get it to work and compile, and *then* tweak and fine-tune things.

Side note:  I just recently got the master branch to compile from within C::B, although it is unfortunately with an old and outdated copy of MinGW (the newer versions I've tried have some issues working with the game's code).  This should hopefully work for now, but eventually it could be an issue as it (the version of gcc) is behind the version used for the Linux port, which I'm guessing could make bugs that would occur on one platform but not another.  I have over a half dozen versions of MinGW installed on my hard drive for various projects - some even for 64-bit programs - and I'm a little "irked" that only a very old copy would work with UFO: AI, but I guess I'll worry more about that later.

44

Bugs prior to release 2.4 / Re: UFOPaedia or UFOPedia

« on: May 15, 2011, 05:27:02 am »

Well, as I said, we need to either pick one form and stick with it throughout, or offer both (or more than one) form in the game.  Most big games, office suites, and other programs that Ive seen have at *least* two - which tells me that United States English and Euro/British are the most common (though I've seen some software that have several more choices, including some more obscure forms).

Trying to argue or "prove" one form to be "better" than another is totally pointless.  No matter how hard one tries to rationalize it or back it up with any supporting argument, someone else can do the same to push it the other way.

If we resort to such back-and-forth debate we might as well argue over the colors red vs. the color blue, and which color in general is "better" than the other.

"Red is better!  It is stronger and can look brighter!"

"No, blue is better, it isn't harsh like red is!"

...etc., etc., etc., onwards into total absurdity...

The one difference, where such a comparison doesn't apply, is that with colors the two can be mixed into purple, which is a valid color.  In this case though, with the language issue, there isn't any "purple" mix that would really work, it should either be consistent with one or be split for the end-user to choose.

45

Bugs prior to release 2.4 / Re: UFOPaedia or UFOPedia

« on: May 14, 2011, 03:24:15 pm »

Well, at some point we'll need to either decide between the two or split the English texts into two forks (which is what most games and many other programs do).

As I said, if we end up sticking with just one and it isn't American, I don't care too much and I won't get upset, but right now we have an ugly mix of more than one variant, and at some point a choice will need to be made.

Should we ask Mattn for a command decision on this one?  Or put up a poll?