1
Discussion / Re: Target zone explanation?
« on: September 20, 2015, 04:30:08 pm »
Great stuff - thanks for that. I was already at my maximum brightness on the monitor, didn't occur to me to look at xrandr.
Cheers.
Cheers.
News:
New board
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.
Pages: [1] 2
2
Discussion / Target zone explanation?
« on: September 20, 2015, 02:12:56 pm »
Hello,
Very happy to see the pathfinding bug is fixed, so back to playing UFO:AI on 2.6-dev.
I just did a base defence, and after a few turns I 'spontaneously' lost the game - presumably because the aliens had occupied the target zone (power plant) for a certain number of consecutive turns or something?
I couldn't find any explanation in the wiki or the forums. Can someone let me know what's going on? (I realise the feature is under development, so am not expecting it to be fully balanced or set in stone).
Thanks.
P.s. incidentally, aside from the pathfinding bug, the biggest problem I've been having is the gamma not working (at least on Linux-64 with Intel graphics). Night missions are more or less unplayable unless my room is in close to total darkness. Would be amazing if someone could fix that
Very happy to see the pathfinding bug is fixed, so back to playing UFO:AI on 2.6-dev.
I just did a base defence, and after a few turns I 'spontaneously' lost the game - presumably because the aliens had occupied the target zone (power plant) for a certain number of consecutive turns or something?
I couldn't find any explanation in the wiki or the forums. Can someone let me know what's going on? (I realise the feature is under development, so am not expecting it to be fully balanced or set in stone).
Thanks.
P.s. incidentally, aside from the pathfinding bug, the biggest problem I've been having is the gamma not working (at least on Linux-64 with Intel graphics). Night missions are more or less unplayable unless my room is in close to total darkness. Would be amazing if someone could fix that
3
Discussion / Openhatch profile for new contributors?
« on: January 04, 2015, 09:03:54 pm »
I'm not affiliated with these guys or anything, I just heard about it through Pioneer Space Sim's forum.
It's a project seeking to matchmake between open source projects and potential contributors. Seems to be being talked about a fair bit at the moment, but I don't know how large an effect it really has.
Anyway, I've read that you guys are looking for contributors too, so I thought I'd mention it.
https://openhatch.org/
Cheers.
It's a project seeking to matchmake between open source projects and potential contributors. Seems to be being talked about a fair bit at the moment, but I don't know how large an effect it really has.
Anyway, I've read that you guys are looking for contributors too, so I thought I'd mention it.
https://openhatch.org/
Cheers.
4
Discussion / Re: Balancing smoke grenades
« on: December 09, 2014, 04:22:27 pm »
The issue is largely on outside maps. If you throw a smoke grenade, then walk into the smoke, you are essentially invisible. You can step out of the smoke to locate enemies, step back in, and kill them without much risk. It isn't foolproof, as enemies will randomly walk into the smoke and find you, but it doesn't feel realistic or fair to me - I think a soldier firing from smoke without moving should cause enemies to fire back (even if inaccurately).
I took it as read that you ought to expect to lose some soldiers on hard / very hard.
I took it as read that you ought to expect to lose some soldiers on hard / very hard.
5
Discussion / Re: Balancing smoke grenades
« on: December 09, 2014, 01:39:25 pm »...
So, we have those who say smoke is OP, and now someone who say it is pretty much useless, and of course those who say it is *the only way* to play, so say smoke is nerfed, will that make the game impossible hard for a few/some/most people?
It'd depend how you did it. But I think it's definitely an exploit that if you stay in smoke, you'll basically never get shot - it certainly feels like cheating.
Some mechanism that meant you had to keep moving to avoid return fire would feel more realistic, and it'd still be possible for a patient player to stay fairly safe.
6
Bugs in development version (2.6-dev) / Re: Memory Leak?
« on: December 04, 2014, 05:33:20 am »
I haven't rebuilt in a while (finishing my campaign first) but I noticed this too.
Turning the 'Cache models in menus' option (not its actual name probably, but it should be easy enough to find) on makes things much quicker for me once the whole thing loads (6GB system though). But even then I have to restart every so often...
Turning the 'Cache models in menus' option (not its actual name probably, but it should be easy enough to find) on makes things much quicker for me once the whole thing loads (6GB system though). But even then I have to restart every so often...
7
Discussion / Re: Why is this so goddamn hard?
« on: November 22, 2014, 04:16:31 pm »
1) It's often really a case of choosing the right weapon (therefore squad member) for the moment. A bit like scissor paper stone in a sense.
All weapons have weaknesses, so figure out what is strong against what. A plasma rifle isn't massively fast, so a faster weapon - like a shotgun or a plasma blaster - will beat it up close on reaction fire. It's not massively accurate either, so something like a sniper or laser rifle will normally beat it at range, though that's riskier.
That said, you'll always lose some soldiers (unless you keep restarting...). It's that kind of game.
2) Yeah, that's a bit of an issue - sometimes the story contradicts the game mechanics. The reality is any soldier who ends his turn in smoke is invisible to any enemy who isn't directly next to him. And if one enemy can see you, they all can - though that's also true for you seeing the enemies.
3) Reaction fire only works in the field of vision (I think it's 120 degrees). So if you throw a grenade from behind something, or attack from behind or the sides, or shoot from within smoke, you won't trigger it.
Also, use bleeding to your advantage. If you can hit a non-robotic alien then safely leave it to bleed to death, do so. Snipers and automatics are both useful for this.
4) You can destroy buildings by right clicking on them, and with a bit of planning you can make the starting base fairly robust. It comes down to reducing surprises, controlling where they meet you. Also, put a guy in the CCTV room of the control centre if you haven't.
All weapons have weaknesses, so figure out what is strong against what. A plasma rifle isn't massively fast, so a faster weapon - like a shotgun or a plasma blaster - will beat it up close on reaction fire. It's not massively accurate either, so something like a sniper or laser rifle will normally beat it at range, though that's riskier.
That said, you'll always lose some soldiers (unless you keep restarting...). It's that kind of game.
2) Yeah, that's a bit of an issue - sometimes the story contradicts the game mechanics. The reality is any soldier who ends his turn in smoke is invisible to any enemy who isn't directly next to him. And if one enemy can see you, they all can - though that's also true for you seeing the enemies.
3) Reaction fire only works in the field of vision (I think it's 120 degrees). So if you throw a grenade from behind something, or attack from behind or the sides, or shoot from within smoke, you won't trigger it.
Also, use bleeding to your advantage. If you can hit a non-robotic alien then safely leave it to bleed to death, do so. Snipers and automatics are both useful for this.
4) You can destroy buildings by right clicking on them, and with a bit of planning you can make the starting base fairly robust. It comes down to reducing surprises, controlling where they meet you. Also, put a guy in the CCTV room of the control centre if you haven't.
8
Discussion / Re: Why is this so goddamn hard?
« on: November 21, 2014, 10:41:57 pm »
Unless your soldiers are accurate and well armoured, you probably want to avoid straight shooting matches with any aliens. The key is out maneuvering them.
1) Are you using reaction fire? If they walk round a corner and into your squad, guns at the ready, they're dead.
2) Are you using smoke grenades? If there isn't any cover, make some.
3) Try equipping some soldiers lightly. If they're light enough, they get bonus TUs, allowing you to run further, fire more times per turn...
4) A big key to base defence is how you build the base. Use bottlenecks so you can choose where to fight them - I like the power plant, personally.
1) Are you using reaction fire? If they walk round a corner and into your squad, guns at the ready, they're dead.
2) Are you using smoke grenades? If there isn't any cover, make some.
3) Try equipping some soldiers lightly. If they're light enough, they get bonus TUs, allowing you to run further, fire more times per turn...
4) A big key to base defence is how you build the base. Use bottlenecks so you can choose where to fight them - I like the power plant, personally.
9
Discussion / Re: Balancing smoke grenades
« on: November 21, 2014, 02:07:43 am »
I'm playing 2.6-dev at the moment (built from source a while back, but as far as I've gathered nothing has changed since). Stun damage from smoke is effective, but still not enough in my opinion.
My suggestions:
1) Time units add stun damage, not just movement. A person sitting still in smoke doesn't accumulate stun damage. Simply counting up TUs instead would make a lot of difference - no more aimed shots from sniper rifles.
2) I think movement should be penalised in smoke, maybe taking 50% more TUs. Maybe negate the penalty for the rest of the turn if IR visor is used.
3) Firing positions should be revealed from within / behind smoke. I'm not a programmer, but this is roughly how I imagine this working:
If a human fires while hidden from the aliens' LOS by smoke, the square they are on (or one chosen by probability distribution, so probably accurate or nearby, occasionally further away but still hidden by smoke) is marked as a low value target until either an alien gets LOS on that square, or some limit like 5 turns elapses (in case the player keeps adding more smoke).
In practise this would mean that aliens would shoot into smoke if you've been firing from it and they couldn't see soldiers / civilians. Area effect weapons would present a big risk, and you could only fire relatively safely if you kept moving.
My suggestions:
1) Time units add stun damage, not just movement. A person sitting still in smoke doesn't accumulate stun damage. Simply counting up TUs instead would make a lot of difference - no more aimed shots from sniper rifles.
2) I think movement should be penalised in smoke, maybe taking 50% more TUs. Maybe negate the penalty for the rest of the turn if IR visor is used.
3) Firing positions should be revealed from within / behind smoke. I'm not a programmer, but this is roughly how I imagine this working:
If a human fires while hidden from the aliens' LOS by smoke, the square they are on (or one chosen by probability distribution, so probably accurate or nearby, occasionally further away but still hidden by smoke) is marked as a low value target until either an alien gets LOS on that square, or some limit like 5 turns elapses (in case the player keeps adding more smoke).
In practise this would mean that aliens would shoot into smoke if you've been firing from it and they couldn't see soldiers / civilians. Area effect weapons would present a big risk, and you could only fire relatively safely if you kept moving.
10
Mapping / Re: Getting meshes from Blender to UFO Radiant
« on: June 05, 2014, 11:30:23 pm »
Sure.
The file is just Blender's infamous 'default cube'. I've never made any 'levels' in Blender, so if you want me to make something resembling a test one I'm happy to do so, but would need quite specific instructions about how it's got to be built (does it need materials and textures, what dimensions should it be, should it all be a single mesh, that sort of thing).
Also attaching the script (from Blender 2.70).
Would be *awesome* if you could get this working - even just to make individual brushes, and even if the textures still have to be done in Radiant.
The file is just Blender's infamous 'default cube'. I've never made any 'levels' in Blender, so if you want me to make something resembling a test one I'm happy to do so, but would need quite specific instructions about how it's got to be built (does it need materials and textures, what dimensions should it be, should it all be a single mesh, that sort of thing).
Also attaching the script (from Blender 2.70).
Would be *awesome* if you could get this working - even just to make individual brushes, and even if the textures still have to be done in Radiant.
11
Mapping / Re: Getting meshes from Blender to UFO Radiant
« on: June 05, 2014, 09:54:38 pm »http://www.wrwrwr.org/blender-ufoai-map-exporter
that might also be of interested - but i don't know whether it still works.
I believe that's the same script as is in the UFO src directory, designed for Blender 2.45.
Unfortunately Blender had a *major* UI overhaul for 2.5, so even if people are familiar with 2.4x UI (I'm not), they're probably going to be hesitant to go back to it.
I tried setting it up on a Lenny VM and it seems to work, but it also requires UFO (or at least the texture directories... not sure) to be present to actually do the export. I think I'm giving up on that avenue, though if there are any Blender coders out there who know how to update the script you would be my eternal hero
12
Mapping / Re: Getting meshes from Blender to UFO Radiant
« on: June 05, 2014, 06:39:44 pm »
I'll fix anything I find that's wrong, but I'm only a beginner with both UFO and Blender, so don't expect much.
How do I get a wiki account?
It says 'mikehg is not a valid username', and I don't have permission to create an account.
How do I get a wiki account?
It says 'mikehg is not a valid username', and I don't have permission to create an account.
13
Mapping / Re: Getting meshes from Blender to UFO Radiant
« on: June 04, 2014, 09:07:45 pm »
Ah, OK. Thanks for the hint - I was barking up the wrong tree I think
What I was trying to do was to use a Blender mesh to make a Radiant brush, but now having a look at the other maps it seems that for complex objects they should indeed be models.
I'll have a play around with that and see if I can get it to do what I'm after...
Cheers.
What I was trying to do was to use a Blender mesh to make a Radiant brush, but now having a look at the other maps it seems that for complex objects they should indeed be models.
I'll have a play around with that and see if I can get it to do what I'm after...
Cheers.
14
Discussion / Re: Impressions on 2.5 vs 2.4
« on: June 04, 2014, 04:49:33 pm »
Shit-Esc by default.
15
Mapping / Getting meshes from Blender to UFO Radiant
« on: June 04, 2014, 04:39:14 pm »
Hi,
I'm trying to make meshes in Blender, then import them into UFO Radiant 2.6-dev to use as map details, and not having a lot of luck.
I've found the script at src/tools/blender/export_ufoai.py, but I can't persuade that to work on recent Blenders (it seems from looking at the contents to be designed for Blender 2.4x, which isn't going far on Debian Testing... I suppose I might have to put Lenny in a VM)
I've also tried the Quake exporter built into Blender, but that crashes radiant.
Does anyone have this working currently? What versions are you using?
I'm trying to make meshes in Blender, then import them into UFO Radiant 2.6-dev to use as map details, and not having a lot of luck.
I've found the script at src/tools/blender/export_ufoai.py, but I can't persuade that to work on recent Blenders (it seems from looking at the contents to be designed for Blender 2.4x, which isn't going far on Debian Testing... I suppose I might have to put Lenny in a VM)
I've also tried the Quake exporter built into Blender, but that crashes radiant.
Code: [Select]
**-DEBUG: release: "unnamed.map"
**-Message: Loading map from /home/mike/Blender/monument/cube.map
**-DEBUG: capture: "/home/mike/Blender/monument/cube.map"
**-DEBUG: textures capture: 'textures/'
Texture load failed: 'textures/'
**-DEBUG: textures capture: 'textures/tex_common/nodraw'
src/tools/radiant/radiant/brush/FaceShader.cpp:93
assertion failure: FaceShader::getFlags: flags not valid when unrealised
----------------
./uforadiant(_Z17write_stack_traceR16TextOutputStream+0x2d) [0x701393]
./uforadiant(_ZN24PopupDebugMessageHandler13handleMessageEv+0x6b) [0x6ea27f]
./uforadiant(_ZNK10FaceShader8getFlagsEv+0x6a) [0x801bce]
./uforadiant(_ZNK4Face8GetFlagsEv+0x22) [0x7ff9f4]
./uforadiant(_ZN5Brush8getFlagsEv+0x5c) [0x7e4288]
./uforadiant(_ZNK13BrushInstance21evaluateViewDependentERK10VolumeTestRK7Matrix4+0x74) [0x7f4d3e]
./uforadiant(_ZNK13BrushInstance15renderWireframeER8RendererRK10VolumeTestRK7Matrix4+0x2f) [0x7f53a3]
./uforadiant(_ZNK13BrushInstance15renderWireframeER8RendererRK10VolumeTest+0x65) [0x7f54c9]
./uforadiant(_ZNK17RenderHighlighted6renderERK10Renderable+0x84) [0x7b9582]
./uforadiant(_ZNK17RenderHighlighted3preERK5StackI9ReferenceIN5scene4NodeEEERNS2_8InstanceE23VolumeIntersectionValue+0x184) [0x7b970a]
./uforadiant(_ZNK14ForEachVisibleI17RenderHighlightedE3preERK5StackI9ReferenceIN5scene4NodeEEERNS4_8InstanceE+0xe3) [0x7bc4d3]
./uforadiant(_ZN13CompiledGraph3preERKN5scene5Graph6WalkerERKSt17_Rb_tree_iteratorISt4pairIK14ConstReferenceI5StackI9ReferenceINS0_4NodeEEEEPNS0_8InstanceEEE+0x5b) [0x72f801]
./uforadiant(_ZN13CompiledGraph17traverse_subgraphERKN5scene5Graph6WalkerESt17_Rb_tree_iteratorISt4pairIK14ConstReferenceI5StackI9ReferenceINS0_4NodeEEEEPNS0_8InstanceEEE+0x136) [0x72f9a4]
./uforadiant(_ZN13CompiledGraph8traverseERKN5scene5Graph6WalkerE+0x36) [0x72f3a8]
./uforadiant(_Z12Scene_RenderR8RendererRK10VolumeTest+0x6f) [0x7b97b7]
./uforadiant(_ZN5XYWnd4drawEv+0x49a) [0x7b6496]
./uforadiant(_ZN5XYWnd14callbackExposeEP10_GtkWidgetP15_GdkEventExposePS_+0x69) [0x7ae8bd]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x12d4f5) [0x7f699c5294f5]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x138) [0x7f699adc23b8]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x21d3d) [0x7f699add3d3d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xaa9) [0x7f699addb6f9]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82) [0x7f699addbce2]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x23d114) [0x7f699c639114]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main_do_event+0x3e5) [0x7f699c528165]
----------------
zsh: trace trap ./uforadiant
Does anyone have this working currently? What versions are you using?
Pages: [1] 2