Harmonica

Ah, my bad, I was clearly not caffeinated enough when I wrote that bit. You're correct, I meant strings.xml, and thanks for helping him out.

Skitso's removal of the hidden movement image led me to want to mod this minor aspect of the game myself. I always love the suspense of the hidden movement and alien turn in general but the image flashing up was a bit obtrusive. - I have changed the alien turn to now be dimmed slightly in general (the same level throughout). The only exception to this is if you're fired upon by visible aliens and your troops have their reaction fire - I think this is working as intended and it's not distracting. - When there is hidden movement, the darkness encroaches around the edges of the screen, and there is a printed text telling as much. I have designed it to avoid screen flicker (originally I tried dimming the screen only during Hidden Movement but the flashing was annoying) and I think I have succeeded. - I moved the text to the top left of the screen, and changed alien turn to say 'Stand by...' (since the alien turn also includes neutral movement). Preview: note that this was a terror mission so the screen may be darker than usual How to install: Download the file attached to this post 1. Back up the relevant original .lua files in assets\scripts, and your assets\strings.xml file. 2. Extract blackhiddenmove.png to Xenonauts\assets\uitextures 3. Extract hiddenmove.lua and hiddenmove_large.lua to Xenonauts\assets\scripts 4. Add some lines to your assets\strings.xml file: You can CTRL+F and find 'hiddenmove.text', now select that entire block enclosed between <Row ss:AutoFitHeight="0"> .... </Row> and replace it with these lines: <Row ss:AutoFitHeight="0"> <Cell><Data ss:Type="String">hiddenmove1.text</Data><NamedCell ss:Name="_FilterDatabase"/></Cell> <Cell><Data ss:Type="String">Hidden Movement</Data><NamedCell ss:Name="_FilterDatabase"/></Cell> </Row> <Row ss:AutoFitHeight="0"> <Cell><Data ss:Type="String">hiddenmove2.text</Data><NamedCell ss:Name="_FilterDatabase"/></Cell> <Cell><Data ss:Type="String">Stand by...</Data><NamedCell ss:Name="_FilterDatabase"/></Cell> </Row> In order to do this, I recommend using an editor like Notepad++ since this is a long file, or you may be able to use Wordpad. Notepad is generally not recommended since it handles larger files poorly (and files in general). notes If anyone has any problems installing this or during use, please post and I'll try to help! If you don't want the 'Hidden Movement' or 'Stand by...' text, you can of course change those lines to read whatever you want (if you leave them blank that would probably work as well - but I haven't tested this). I intend to perhaps mod the battle screen more thoroughly in future so I may revise this mod as well. darkened_alien_turn 1.01 - Harmonica.zip darkened_alien_turn 1.01 - Harmonica.zip

Yeah - I just made the modification I mentioned myself, and you're right, the dark screen is more noticeable. But I can't do away with that 'hold onto your butts' sensation when it all goes dark It's okay at about 64 alpha. I wonder if there's a way to have the screen stay dimmed during civilian movement.

Well, the hidden movement thing is kind of classic but I think the image should be full screen. If I had a suggestion as an alternative to this style, it would be simply to darken the entire screen with 'hidden movement' text.

As the title. I get a buffer overflow error and crash if I place a large spectre (eg the irrigator) onto a grid that is too small for it to be placed (eg in that case a 1xsomething map).

Well it hadn't crashed for me at all in all the time I've been using it so far. Not sure what else would be the cause. If I attempt to add any Spectres by dir it crashes after that. edit: couldn't get it to work by deleting or moving bits and pieces of the set. Deleted those atlas .pngs in the Farm tiles folder and did a Steam verify scan and after it had replaced the files, the editor is now working again. (of course now I have to work out how to repatch your mod in) So... I don't know what the cause is, anyone else have this issue? Later today I will backup the vanilla files and go through re-adding Skitso's files folder by folder and see it it starts crashing again.

After installing this map pack I'm getting crashes when using the submap editor. Any idea why that might be the case? Specifically, I try to add spectres from a folder (Farm tiles) and it crashes. edit: going to hazard a guess it's something to do with those atlas images.

If anyone has like me had problems whilst following the tutorial on page 1, with getting anything to show up in paint mode, I'll point out that for some reason you might have to double-click the spectre in the list box once you've added it. I've loaded up the editor and starting editing and I've had to do this 9/10 times, for some reason. I don't know if that was obvious, but without that step you're not painting anything and single-clicking won't show you the preview image on the top left (ie of the rock). I couldn't figure out why after moving around the extracted tiles all over the place, adding folders, rescanning, etc, they still wouldn't paint. Well, that is why! Anyway I hope to get cracking on some maps now that I've got that failure out of my system.

Yeah, that's true - that's what I meant. Sorry I meant base as in the submaps themselves.

The art in the game is beautiful. Are the base layouts going to be randomised like everything else? Can we create base maps for use by the game?

Map randomisation, map editing, skill points, inventory loadout, action points, the kitchen sink.

Both amazingly useful images, thanks for those. I knew there was a trick to the ground tiles I was missing!

Thanks for all the tips and information. Inevitably so far I have succeeded in biting off more than I can chew in my multiple mapping attempts. I always start off like this. Best way to learn, perhaps, anyway. Now I'm working on something that is more straightforward but is quite effective, which is a map where the team lands on an apartment block roof and has to clear the various rooms and hallways on all sides - which are all made up of randomised submaps, of course. Currently just 10x10 areas but I might try doing the 5x5s at some point. My main problem is getting tiles to match up. The editor is powerful and robust but it would probably be easier if you could select a grid tile and cycle through tiles to see which will fit in nicely. Unless there's some 'proper' way to layout ground tiles that I'm missing...

I have just starting tooling around with the map editors. I didn't realise they were already available for the alpha release, oh well. I think that the map randomisation aspect is one of the biggest selling points for Xenonauts. Ideally after release my game can pick from hundreds of available maps. I intend to create a lot of maps. But I have a question to those who are more experienced: could you outline your basic workflow or thinking process when it comes to creating maps? I am trying to get my head around how to plan out adding a map to the game. For example, I live in a rural area so I thought I would focus on creating some simple rural type maps. Do I start with the sub-maps themselves? Do I think about an overall 'type' of location I would like to add? (ie, a particular style of farm) Getting my head around how the game will randomise my level-editor layout composed of my submaps is difficult. Here is how I currently think I need to plan it: 1. Think of a type of location/environment to design, ie a farm with surrounding land. 2. Sketch roughly the areas that might be added to the level editor: ie, field/forest/field/barn, etc etc. 3. Pick one of those areas (ie forest), and create sub-map for it. Now work on variations of this submap until there are 3/4 of them. (ie, for a forest, different arrangements of trees, land, maybe sometimes a structure in there too). 4. Go through the rest of the submap areas in the same way. 5. Create multiple other level editor maps using same submaps but laid out in a different arrangement? Does that sound right? So, maybe an entire single level editor map will not vary too much - different shaped barns with different interiors, different trees and fields, and so on [always a forest in 1,1 submap space, always a barn/structure in space 1,2, etc] - but because the game will pick out of the various new 'farm' submap arrangements I created that then gives more variation? Or, do I have it wrong, maybe I should make many more submaps, and vary them a lot, but only create one overall level editor map. So for a [forest area] I would in fact sometimes have almost no trees with a bit of a field, and a hut in there. Sometimes dense trees you cannot pass through. Sometimes a road through the forest. Etc. Then when the game adds from that submap it is very different each time, rather than just always trees in different spots. Which method is better? My head hurts I would love a step-by-step guide to create a basic (ie, small urban with houses) layout that I could follow - I have looked (and read the wiki) but cannot see one.

Echoing the 'they look amazing'. The graphics are exactly what I want. Understated, in some ways, but with plenty of intricate detail suggesting the reality. And letting the tactical battles take center stage. I absolutely cannot wait to get stuck into designing layouts for battle maps, too. (We will still be able to do this, right? Probably the main reason I ever was interested in Xenonauts was the potential for having a huge cache of layouts for the game to draw upon when it throws out its battle maps - and adding to myself/from the community).

Standard practice: shoot down UFO, night falls, send out landing party, but hover near the crash site playing poker and drinking until morning. Get an hour or so's sleep. Touch down and go blast some aliens! Woohoo! ...write up that friendly fire incident report.

I like the clean and clear look. Suits the era of the game and suits the style of the game. The art is amazing as ever (probably the first thing I saw of the game itself back when you announced it was the art, and it still looks as enticing). Overally I really like the look and can't wait to play with it in the finished game. However, all that said, with this in mind ..I think the middle option offers the best levels of contrast and brightness from a usability perspective, and that grey tones generally look aesthetically more stylish than a brighter option. It would be great if the background images for dialogs/screens are modable OR there's an xml file somewhere that has a value for text and dialog background colours, so users can make changes if they need to. Peoples' eyes all have different tolerances for these things. You said you didn't want critiques which is fair enough, I know design work is laborious and somewhat thankless, but please externalise as many UI elements as you feel comfortable doing, Chris.. edit: a more stark comparison is having minimised this forum window and tabbed to Steam, the dark grey UI is instantly far less sapping to use. It looks ugly as hell but it doesn't tax the eyes.

Very interesting to read more about the oft talked about tile creation process

Spoiler: It's not patched to perfection

That's a good adage. And I suppose it suggests that the sensible thing is to aim for quality and sod the rest Aka done when it's done.

It's only a troll if people react to it and nobody really did that. Everyone understood immediately that he had the wrong attitude. I think there's a valid discussion to be had around managing expectations with games development, since it's always something that has been an issue for many projects over the decades games have existed. They're just fundamentally unlike most other creative projects and estimating arrival times seems to be more of an art than a science. Obviously this is why many devs don't do their announce until they are well on the way towards 'going gold' and they have their release route map. Indie developers have more of a luxury with how and when they tell people about their game, the 'slow burn' of an early announce can be great alongside test releases, for example. For commercial games development, early announces with no prospect of gamers actually playing the games in the mean time are a bit of a curse. They're also used pretty manipulatively by many studios to start their promotional hype off very cheaply via word of mouth, without any intention of fostering the community's interest that early. Then you have the middle ground of the 'faux-beta' for some games, released relatively near to release but featuring often a decent chunk of gameplay - even if the dev has no intention of bearing in mind community suggestions, and the game is pretty much developed by that point. It's definitely a difficult decision and I don't really envy people who are in that decision process (developing myself, but announcing is a long way off). In this era, perhaps, with people absolutely willing to pay early to support on-going development and alpha releases such as with Xenonauts, maybe there's a chance to move beyond the obsession with release dates. After all, when are games ever finished? After release they might recieve further patches or updates or additions. Even after the developer moves on from the project the fans will probably take over the curating of the games development. They're pretty organic things. Just look at games like Transport Tycoon which didn't really see any after-release development from Chris Sawyer but is currently reimagined as OpenTTD featuring a vaster and richer feature set, and a great stable multiplayer. I think that there's an entitlement problem seen with some early backers of projects, but at the same time, since the Kickstarter method is relatively young (and only a few of the games with larger funds have actually arrived), this is understandable. People don't know what they're actually paying for. It's always surprising how little research people do before handing over their money, but if you are aware that you're funding ongoing development of an independent title, then how can you begrudge developers taking their time? It's their baby, after all.

The Overwatch penalty is an example of them not thinking things through. Why would someone on overwatch, who is essentially settled into a good shooting position and surveying the terrain in front of them, suffer a penalty to aim? That's ridiculous. If anything they should receive an aim bonus, but perhaps they suffer a move penalty when they come out of overwatch, or they take a turn to come out of overwatch or something. Things like that irk me. I don't mind the way it plays sort of like a tabletop/boardgame adaptation on the whole, but the logic of things are bemusing. I must say though the game is growing on me purely as a spectator sport. I have been watching a few friends play it and when I'm not suffering the floaty controls and somewhat dubious RNG rolls myself, it's fun to watch. If I take the controls and try to navigate the interface I lose patience fairly quickly (it plays great on a gamepad but I've been banned from using that on their copy. And I do just want to play with a damn mouse and keyboard). The depth argument I think revolves mostly around the freedom you had in the original, vs limitations in this (inventory, battle tactics, squad creation). People liked having customised soldiers toting specific weapon and equipment combinations. They liked having squadmates shuffle equipment and ammo during a battle. That stuff is engrossing.

Jagged Alliance 2 still looks great. And what about games like Close Combat? The maps in those games are simply bitmaps with height mapping but they look crazy beautiful (to me, anyway) to this day. Lovely attention to detail and digital painting. And of course there's things like Another World... A different kind of artistic skill to producing 3D that looks good. I still remember the era where everyone decided to transition to 3D and all those games looked ugly as hell to my eyes (Dungeon Keeper 2 vs 1 for example).

They could have kept the specifically classed soldiers, but let you choose what class you wanted them to train under. Then the soldiers might gradually improve their stats during training, and if they make it out of training alive then they become a proper 'assault' or whatever. That for me is a proper use of a more simplistic mechanic (compared to skilling soldiers yourself as in the classic game).