project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Psawhn

Pages: [1] 2
1
Artwork / Fuel Tank V2
« on: May 29, 2011, 10:19:43 pm »
btw, if you have a 512x512 pixel texture for the fueltank (models/aircraft/craft_item_fuel/fuel.png) you've made, we could use that also...

I made a 512x512 image, and a normalmap, for the fuel tank:
https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/licensed/fueltank/
(Licensed under CC-BY-3.0)
I had to update the UVmap because the separate seams were running into eachother and causing some odd effects (The new images won't work with the old model). The problem is that I don't know how to export out from blender 2.57 into md2 format. I can export into a different format such as .obj, .x3d, .3ds, so someone who owns different software with a 3D exporter needs to finish the conversion. Is Destructavator able to do it? He seemed to be better at blender->ufo.
(Actually, I just went ahead and stuck everything in the /converted subdirectory linked above.)

2
Artwork / Image: Alien Origins Ufopedia
« on: May 26, 2011, 03:24:27 am »
Hi guys;

Sorry I've been away for so long. Ugh, engineering/university.

I've been playing 2.3.1 to get back into things, and I noticed that in the game there's no image for Alien Origins, nor is there one that I can find in the repositories. I was inspired by some Astronomy Photo of the Day pictures, so I have a couple candidates:


I modelled the radar telescope in blender, so I can rearrange any element of the scene. The astronomy image in the background is a NASA image so it's public domain. I've found another image that I actually like better (it's the milky way) but it's CC-attribution-noncommercial so I figure that'd be incompatible licensing. I can look further for a compatible image with milky way if that looks better. (I think I've found some on flickr that are only CC-attribution).

The telescope itself is untextured, crude, unoptimized, and ugly for anything but a sillhouette. See here:

I'll make all source files available if you guys like it.

3
Artwork / Coolest things ever! - 3D Printed Models
« on: June 13, 2009, 02:30:23 am »
I have, in my hand, the coolest ever UFO:AI related things! :D



The engines in the Stingray actually snap in, and they rotate as far as they're supposed to!

Unfortunately the plasma gun that was supposed to snap into the underside of the hoverbot didn't come. I think, because of the way I uploaded the model, they didn't even realize it was supposed to be attached to my order.

The service I used was called Shapeways. http://www.shapeways.com . They're based in the Netherlands. You just upload a model to their website, and they'll print it out and send it to you. They charge based off of volume of material used, so the Stingray cost $13 USD and the hoverbot cost $17 USD.

I'm not quite happy enough with the models at the moment to open them up for other people to buy, but that's one thing I might try to get done over this summer. Once I allow it, I can allow anyone to go to the website and buy their own. In the spirit of GPL I don't think I'd charge any markup for these, even though I'll have the option.

I think this opens up great potential. UFO:AI figurines? Tabletop games?


4
Artwork / Alien Wormhole Device
« on: June 07, 2008, 07:44:22 am »
I haven't done much at all to it. I added some thick cables connecting the upper and lower platforms, and also created a flat-plane with a bunch of cabling, using a texture with alpha.

I just noticed that the polygon count is rather high at 1200. Most of those are quads, so I estimate about 2400 triangles. How much should I lower this by? A lot of detail is hidden in those tiny arms which might not even be visible later on, so I should probably get rid of those.

I have some texturing questions, though.
Do textures with alpha need to be either on-off transparency, or can there be multiple shades of alpha. (Means I'd have to fiddle around with the texture in GIMP).
How many different textures should I aim for? I doubt I can fit all the textures I need onto one 256x256 image without looking quite pixellated, and even a single 512x512 might not be enough.
How much of blue alien materials, or green glowy radiators, should I use, or are those limited to the outside hull of vehicles?
Anything else in particular to keep in mind?

[attachment deleted by admin]

5
Design / Interception Discussion
« on: May 04, 2008, 12:58:03 am »
This is mainly about the proposed interception on the wiki: http://ufoai.ninex.info/wiki/index.php/Gameplay_Proposals/UFO_Interceptions. I think that this discussion would be more accessible here on the forums than in the talk page for the wiki article.

I really like the proposed system, and is very close to what I had in mind when I dreamed of what the interception system should be like. I do want to make a few additions.

Targeting/Tasks
In the geoscape, craft are able to target almost any other geoscape object. Their task would be context sensitive to the type of object, and for UFOs their mission. For example:

-A PHALANX interceptor targeting a UFO would intercept that UFO group.
-A PHALANX dropship targeting a ground mission will deliver troops to the ground mission.
-A UFO targetting a waypoint will generate an event based off its mission at that waypoint. (There could be provisions for a distinction between nav waypoints and target waypoints, sort of like X-COM)
-A PHALANX interceptor targetting a ground mission would provide TARCAP, or possibly even tactical recon or close air support.
-And importantly: any craft targeting a friendly craft will provide escort. I feel this is flexible enough to allow small UFOs to escort larger UFOs, Interceptors to escort Dropships, and even to set up a wingman-like system where interceptors escort other interceptors.

During an air battle, these targeting mechanics work the same way. A craft targeting a friendly craft will provide escort, and targeting an enemy craft is obvious. Any craft involved in combat, but is tasked to an unrelated mission, will ignore other craft and proceed to their destination unless an enemy craft comes within weapons range.

When a craft leaves combat, it resume its task unless its target is gone. If a craft retreated from battle it will proceed to its home base.

Air Combat Maneuvering / AI
All craft in combat follow a simple AI to maneuver in combat, and all combat is essentially 2D. The player gives generic commands, and the craft will follow its orders. Most of the time a craft will head directly to its target at cruising speed, but with variations:
-A craft targeting an enemy craft will attempt to get behind its target. It will do this by flying an intercept course to its target, until it is at the maximum range of all of its enabled weapons. If within this range, the craft will orient itself directly facing its target, and adjust its speed to stay at this range.
-A craft being fired upon by a missile will attempt to 'beam' the closest missile detected. (If the missile is not detected it will not attempt to evade.) This means that it will turn so that the missile is 90 degrees to its left or its right. This gives more time for ECM to affect the missile, and makes the missile travel a longer path with tight corners (in case the craft can defeat the missile kinematically.) A craft retreating from battle will fly directly away from the nearest missile instead of trying to evade it.
-A craft with a combat waypoint (the player uses the target command in the collapsible waypoint) will fly towards the waypoint. When it reaches the waypoint, it will resume its geoscape-assigned task (escort, target, intercept, other).


Aerodynamics
All craft and missiles use the same aerodynamic model. They have the following stats:
Max. Speed, Drag, Acceleration, Turn rate, Fuel, Max G force.
The AI will specify a speed it wants to go, and the craft will use its acceleration value or drag value to get to the target speed.
A craft will always head in the direction it faces. When turning, it will lose speed as a function of its drag, turn rate, and current speed.
Human interceptors will be limited in G forces to 9, but alien and combat UAVs may have higher limits, and recon UAVs and dropships may have lower values.
UFOs will likely have high drag and acceleration, missiles low drag but high acceleration, and human craft moderate drag and high acceleration.
Missiles use the same aerodynamic model. They always fly an intercept course to their target. If they run out of fuel, they will continue pursuing their target, but their speed will drop relative to its drag (as well as losing speed in turns). If the speed drops below a certain value the missile is removed from combat.


Weapons
Because the craft maneuver around, their weapons need not have 360-degree firing arcs. Direct-fire weapons like guns, PBWs, and rockets will have an arc of 15-30 degrees, and missiles and turrets could have a much larger firing arc. A weapon will always fire if its target is within range and within the firing arc, as long as the weapon has ammo and is enabled.

Weapons have five factors to their accuracy: Base accuracy, pilot skill, target pilot's skill, ECM, and ECCM. Each weapon will have a different weighting for each factor. The Base accuracy is the intrinsic accuracy of the weapon (guns would be low, missiles high). Pilot's skill would be relatively high for guns, and low for guided missiles, for example. ECM and ECCM are modified based on the player's research, and are also factors for guns (targeting computers) as well as missiles.)
For direct weapons, all factors are applied when it fires.
For missiles, base accuracy and pilot skill are applied at the time of firing, and ECM and ECCM are applied constantly over the missile's flight. Tgt's skill is applied at the moment the missile hits. If the missile fails its to-hit check at any of the stages, the missile stops tracking and goes dumb. If the target was evading the missile, it instantly knows it has evaded the missile and resumes its task.

Weapon damage vs. HPs and Armour are calculated the same way as in the ground war.

Armour and HP
Armour will use the same system as body armour for troops: damage is reduced based on weapon types, and applied to HP. Armour failure is not modelled.
Craft have 3 separate types of HP: Systems, Structure, and AM Containment. System and structural HP use the same damage values from calculations, and damage will be applied to a craft's system before it is applied to a craft's structure. This allows the following mechanics:
Damage applied to a craft reduce its performance linearly, up to half the speed and turning rate at the maximum systems damage.
A craft with full damage to its systems will crash land. This represents the state at which its controls, powerplant, and aerodynamic performance will no longer keep it in the sky. Pilots will eject and crew in dropships will start to bail out, until the craft crashes into the ground. A crash-landed UFO will create a crash site.
Further damage to a crashing craft will be applied to its structural HP. If the damage exceeds its structural HP, a craft disintegrates in mid-air, and any crew or aliens still in the craft they are killed, and a disintegrating UFO does not create a crash site. This allows 'critical hits' of alien weapons on human craft to kill unarmoured craft with no chance of the pilot ejecting, and multiple missile hits on a crash-landing craft will destroy the craft (possibly killing troops in dropships.)
I like having a difference between damage sufficient to crash a ship, and craft simply exploding. This also allows a more important aspect to armouring ships: pilots and crew have a better chance to survive aerial combat, not just a simple "the fighter lasts 20 more seconds against aliens before it explodes."

Craft and ships that use antimatter also have a separate HP value for antimatter containment. Damage calculations are applied again to this (possibly with additional or different armour values) to allow chances for an AM containment breach before the craft sustains enough damage to crash land.


Interface: BTAxis' proposed interface is pretty much all that's needed. A player can assign a craft to target an enemy, a combat waypoint, or a friendly craft to escort. A player can also give orders on the geoscape to craft in combat, which most of the time will cause the craft to leave combat as it goes to its new target.



With the exception of weapons' firing arcs and accuracies, I feel that my ideas are expansions on BTAxis' original concept, rather than changes. I also think that these changes will add considerably to the immersiveness and 'fun-factor' of the aerial warfare aspect of the game. I also do not think that these additions will add much to the development work - the ground work for most of these aspects must be implemented anyway, and I've only offered my ideas on how it could be taken slightly more in depth. Some ideas (like an escort command) I think will ease the task of forcing UFOs to create flotillas, as well as creating more strategies for players (escorting dropships, pseudo-wingmen.)

6
Artwork / UAV Model
« on: May 03, 2008, 07:17:43 am »
I had a conventional UAV model floating around my hard drive for another purpose, and I figured I might as well retool it as well as try out some new texturing techniques.

(Thumbnails are clickable)



The UAV has divertless intakes (like on the F-22/35) and a swing-wing design, which should allow it to have rapid deployment at supersonic speeds, then a long loiter time. The exhaust nozzle shows that the engine has a high bypass ratio, for higher efficiency.

Hammer away on the crits, Winter. :D

Edit: The polycount's 800 triangles.

7
Artwork / MIMIR Telescope/Carrier Animation
« on: January 21, 2008, 10:56:29 pm »
It's almost ready, I think.

https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/MIMIR_final60001_0425.avi

There are several things I want to fix:

Starfield: Overall I'm happy with the look and feel of the starfield I'm using. There are just some weird streaks that I suspect result from the post processing combined with adjacent pixels. I'll have to find a way to fix that, somehow.

The engine is lit by sunlight. It should stay dark until it lights up to fire.

Jaggy zoom boxes.

The atmosphere in the zoomed version should have a longer falloff. Overall I'm very happy with the look of the atmosphere. (Too bad it turns white as the camera turns away from the planet. I wonder how to fix that.)

There are black borders around stars that can be seen through the atmosphere.

I can also add graphs and charts and a bunch of numbers, to make it look more NASA-sciency.

So. Feedback? Direction? Criticisms?

8
Artwork / GUI Screens
« on: November 16, 2007, 12:12:58 am »
I actually have an idea for creating GUI screens in Blender that could make the process a lot less painful.

In the meantime, though, here's a modified base buildings screen. I didn't like how the previous version squished everything and still made it hard to see anything on the left. (They are two separate images, like in the originals)
http://smg.photobucket.com/albums/v388/Psawhn/UFO-AI/Menus/?action=view&current=buildings_ur.png
http://smg.photobucket.com/albums/v388/Psawhn/UFO-AI/Menus/?action=view&current=buildings_lr.png



None of the information in the box took up the entire width, so it is shrunk a bit and moved to the top-right.

I hope it covers up fewer of the buildings. If it still covers stuff up, I could probably move it underneath the building preview without too much hassle.


Edit:

Actually, it wasn't quite that hard to create a blender template menu creator thingy. Using the menu creator, it's much easier to create menus like this:


Link: https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/menu_creator.blend

Instructions are opened when you open up the file. But as a reminder: you need to reload the bumpmap0001.png image after first rendering a new menu layout.

It currently doesn't have an easy way to make those pipe/wiring/greeble connectors, though. I might add something like that later on.

Edit#2: Went through and made a second generic test menu thingy:


Aligning the bright green lines is actually rather difficult - it might be much easier to do it in an outside image editor. Metal greeble things probably also need to be added after the fact, too.

9
Sounds and Music / Modified Gun Sounds
« on: November 15, 2007, 05:03:01 am »
I was feeling that a lot of the gun sounds in the game lacked the "oomf" I felt they needed - the shotguns being the worst. That's not to knock Alex's work at all - it's excellent! These are more a matter of taste than anything else, and all the original work is Alex's anyways. :)

I used a combination of existing sounds from the game to make these modified versions. Most of it was just adding multiple versions of the same sound at different frequencies.
For the bolter rifle, I added a bit of a charge-up 'bzzt' from the electrolaser sounds.


Assault Rifle: https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/ufo_sounds/assaultrifle2.wav
Bolter Rifle: https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/ufo_sounds/bolter2_b.wav
Bolter Cannonade: https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/ufo_sounds/boltcannonade_b.wav
Micro Shotgun: https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/ufo_sounds/microshotgun2.wav
Riot Shotgun: https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/ufo_sounds/riotshotgun2.wav
SMG: https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/ufo_sounds/smg2_b.wav
Sniper Rifle: https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/ufo_sounds/sniperrifle2.wav

10
Design / Some thoughts about current descriptions
« on: October 29, 2007, 07:46:10 pm »
Winter's said that he's tried to get the description for techs and stuff as true to reality as possible. I've just been thinking about some things that probably deserve a mention in the UFOPedia, but won't require any coding changes or modelling changes at all.

Antimatter engines:
There should be a mention as to how the radiation from a proton-antiproton reaction is contained in the antimatter engines. Antimatter reactions produce deadly amounts of gamma radiation, and we don't want to turn every landing site into a fallout zone. Alien materials could probably stop gamma rays, but there needs to be a way to stop radiation coming out the back end, or from turning the propellant radioactive.
An alternative design is to use the antimatter reaction as a power source to heat up a propellant, shooting it out the back end like any other rocket.

Not to mention is how easy it would be to detect these engines in space. Current technology can detect the Space Shuttle's main engines from Pluto, and its RCS thrusters from the asteroid belt. (Yes, I stole those numbers from atomic rocket http://www.projectrho.com/rocket/rocket3w.html.) Probably the best way to get around this is to 'jump' in (or whatever the FTL device is called) to the upper atmosphere, otherwise a network of satellites in orbit would be able to detect incoming UFOs before they even reach Earth.



Plasma Weapons:

The current method of using a heat-resistant plastic to contain plasma is a roundabout try of getting around the 'plasma weapons don't work' deal, but it still doesn't quite work. Some months back, somebody posted the idea to some forums and they pointed out that this plastic would make near-impervious armour.

Last night, though, I thought of a different idea for the weapon. Instead of bothering with shooting an ionized gas and containing it, maybe the plasma gun actually shoots a superheated gel near its high boiling point (1000 to 3000 Kelvin). The gel is stored cold, and is only heated when fired. A fired shot would have the same effects as the current system, including a blaster shot's explosion through splashing and superheating of the area.
A grenade would spread this gel all over, combining napalm-like effects with concussive force.

In this version, plasma could instead refer to the process through which the gel is heated. The gun could heat hydrogen to a plasma state, and inject this into the gel in order to rapidly heat it. The ionic charge this gives the plasma/gel would allow magnetic accelerators to fire it. Once the gel is in flight, there's little to keep the plasma contained, and this leaks out and gives the projectile its glowing trail.

This gel could have undesirable properties at room temperature, restricting its use as armour or insulation. Perhaps it could be a powdery, caustic substance that reacts readily with air.

Machine gun:
I'm worried about the plastic belt the rounds are chained in. If it disintegrates upon exposure to air, then the magazine must be kept vacuum sealed. This does not sound like a reliable, rugged weapon for the battlefield. Bits of plastic from a partially-decomposed belt link could also get into the mechanics and jam the gun until they evaporate completely. Worse, if the case is damaged, air can leak in and disintegrate the chain before it is even loaded into a gun, rendering an entire clip useless.


I hope you don't mind these suggestions, Winter, I'm just trying to help. :)

11
Artwork / Miscellaneous Models
« on: September 27, 2007, 08:20:36 pm »
I should probably help out more with the little stuff that needs doing. :)




Here's a fuel tank for the aircraft.

.blend: https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/fuel_tank4.blend
.tga: https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/FuelTank.tga

12
Feature Requests / A few things.
« on: September 27, 2007, 05:49:59 am »
These are all from the newly released 2.2 beta installer.

Maybe not quite so much a bug, but the priority of the game (as seen by windows task manager) is set to "High." On my machine (Windows XP Home SP2, AMD Turion 64M (1.58GHz), 1.12GB Ram) this causes the keyboard to be very slow and unresponsive. Even simple tasks such as entering names in text fields is difficult, and it makes the game nearly unplayable. (I still maintain a high framerate, 60fps, throughout)

Setting the thread priority to normal via Task Manager fixes the problem. Is it possible to change the game setting so it is 'normal' by default?


Other bugs:

In the 3D geoscape, the aircraft path trajectory line is drawn incorrectly when the aircraft is behind the horizon. Instead of the line reaching from the horizon to the target destination, it is drawn, through the globe, from the aircraft's position along the correct path, but stopping short of the destination. The length of the line corresponds with the destination's distance to the horizon.
I'm guessing this is the same algorithm that clips off the aircraft's trajectory line when its destination is behind the horizon.

When equipping a weapon in the base equipment screen, the bottom line of the weapon information text superimposes on the weapon firemode text - resulting in incomprehensible gibberish ;) . The weapon statistics needs to be moved one line upward.

The sound of the shot/explosion that kills an alien is inaudible, but the scream sounds niicee. :)

The Stingray Interceptor (listed as Dragon interceptor. Nice name ;)) can be produced without requiring research. I haven't yet tested to see what happens when this craft is built or sent on missions.

Only the TR-20 Rocket Pod and Rockets can be produced, and they are listed as "base-defence weapons."

When equipping a craft with Polymer Armour, there is no 'warning' (aside from the text in the UFOPaedia) that it will take 24 hours to equip. Removing the armour immediately still takes 24 hours to strip off. Perhaps armour can be added/subtracted incrementally in a counter?

There are no night lights on the dark side of the 3D geoscape.

And under not-quite bugs/ suggestions:

In the aircraft equipment screen, if a model is not found then the previous model loaded is kept. Perhaps a generic "Model Not Found" model can be used?

The aircraft equipment screen is very counter-intuitive. A better method would be pop-up menus when a player clicks on the (+) add icon, which the player can then select.

The UFOPaedia interface is difficult to navigate: the buttons should be grouped in one corner of the screen, maybe two, and definitely not among all four corners.

The information dialog for building new base facilities occludes the bottom (and especially bottom-left) base facilities. Only because the screen is squished is it possible to mouse over the facilites to see what they are. The information box should be moved to take up space from the facilities list, leaving the base screen unobstructed (and unsquashed).

The extra menu for Healing/Implants on a soldier is superfluous - there should instead be buttons for each soldier in the main hospital screen (which looks nice :). (Can the menu system handle this?)

The sounds for many human weapons are too high pitched and too quiet. They lack "oomph" essentially. That's not to knock Alex's work at all - he's done a good job :). Still, a shotgun should sound like a shotgun ;).

Plasma explosions are no longer blue. It could have just been a trick of my eyes, but I was sure that they were slightly bluish before. :P


Anyway, it's still a great job all y'all have done. You've definitely inspired me to work harder on some more artwork (missing aircraft equipment, maybe), perhaps even daring to look into menu files.

13
Artwork / More Hoverbot
« on: September 26, 2007, 05:51:41 am »
I'm still trying to fix this thing up. I completely reworked the UVs and redid the textures (helped along by Blender's render baking, which let me carry over the base colours from before.)

First of all, there was STILL some really damn ugly distortion on the turbines, even though I completely reworked those UVs with that in mind! I think the only way for me to get some decent detail on those things is for it to have its own 512x512px texture. (I did the math. Right now it uses up enough pixels to have its own 256x256px texture, and it still isn't enough.)

So instead, I opted to try to make the turbines nearly completely seamless. Aside from one little part in a corner in the rear, it seemed to work. Personally, I like the result.

Because I reworked the UVs, there's much less wastage of texture space - as a result, there should be a little bit less jagginess, but I don't know if it's noticeable. If you can still see some, I doubt it's blender's fault - the resolution I get from the texture is just too low. Despite using 512x512, the geometry is complex and there's a surprisingly lot of surface area to pack away.

Anyway, here's pictures of the newest version: (clickable thumbnails)




And the downloads are here:
https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/hoverbot/hoverbot_lightcannon_final_RC2.blend
https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/hoverbot/hoverbot_lightcannon_7.tga
https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/hoverbot/hoverbot.anm
https://webdisk.ucalgary.ca/~djetowns/public_html/misc_files/UFO_AI/hoverbot/hoverbot_lightcannon_7.xcf

It's still fully animated and ready to be put into the game - the .anm file is valid for the animations in the .blend. Everything that's not on layer 1 can be ignored when exporting, too, and the entire bot is one mesh.

Here's hoping that this thing is pretty much done! I've put waay too many hours into this project than is healthy :D.

14
Artwork / Saracen Renders
« on: July 14, 2007, 04:06:15 am »
I've already posted these in the Loading Screens thread, but I would like some feedback on these.




I modified the saracen .blend file and textures a bit. ;) Among the features I added are:


Thruster fans, landing gear, and fan/gear/weapons bays.


Vectoring vanes for the main thrusters.


Topside thruster fans, and the open panels were closed in for aerodynamics. :)

The fans were inspired by the X/F-35 JSF. Combined with those and the rear vanes vectoring thrust downwards, the craft can do a short takeoff (just like documented in the wiki/ufopedia).

Hopefully I can make some more scenes, like a hangar equipping scene, and a takeoff/landing scene. :)

Pages: [1] 2