UFO:Alien Invasion
Development => Mapping => Topic started by: H-Hour on April 16, 2010, 01:40:37 am
-
With r29422 the +city RMA is available in skirmish mode and includes a Fighter UFO, a Firebird, and spawn points for aliens, humans and civilians. There are lots of little fixes and additions I want to make here and there (like adding cars!), but at this point there shouldn't be any show-stopping bugs. I say shouldn't, but it hasn't been extensively tested. I haven't even been able yet to compile and load just to test the new UMP file. But it should work.
I'm hoping people will now try out this map and give me some feedback. This is my first map for UFOAI so I need feedback on a wide range of things to make sure I'm getting things right. In addition to major bugs or bad functionality and performance, I'd like to ask especially for the following feedback:
1. Were you able to do things on the map that met your expectations? For instance, were you able to move where you thought you should (based on past experience with the UFOAI maps), or were you able to move somewhere that you think maybe you shouldn't? I want to make sure the player isn't frustrated by the map's design, and that it matches their expectations (with the exception of things that the engine can't handle, like jumping over railings, etc.).
2. How does the AI perform on this map? Will they shoot down from the balconies, will they find the stairs and change floors? Or do they sit up top too much? Should they spawn more spread out? Etc.
3. Did the map present you with interesting tactical problems to overcome? Were there enough locations for your men to take cover? Were you able to use your men fluidly, across the whole map, or do you find that there is too much of a bottleneck? When dealing with this last question, keep in mind also that in the future this will be one building amongst several, so much of it was designed to relate to other buildings. But it should still be an interesting map alone.
4. Does the map appear to be a convincing location? It's supposed to be a parking garage, in case that didn't come across. There will eventually be signs to make that clear and to fill out the "clutter" of an urban space. But does the architectural piece work?
Many thanks for any feedback you can give on this. I hope it will make it into 2.3 and so I would like it to be as well-balanced and fun to play as possible.
-
One note about.
tiles contain dropships and ufos need to have proper names, because game use special mechanisms to define they.
-
kildor is right - see the naming schema for the other rma themes and please also make sure that the ump file contains the needed names. last but not least you should also add the supported ufos and dropships to maps.ufo to be able to select the proper aircraft when starting the map in skirmish.
btw. removing the lightmap from the advertisement stages material will add some nice self-lumination effect to them.
-
For now I'd prefer not to make the name changes if that's alright, but will certainly do it before 2.3. Because I'm still finishing up the building, I don't want to start having duplicate files floating around. Eventually the building will be used as a tile for the scout, one for the fighter and one without any UFO (post-2.3 when more of the city comes in).
Does that work? It's my assumption that the definitions are used primarily for the Skirmish map selection screen, but it should still be playable without them on a temporary basis, correct?
-
the selection is also done in the campaign - if there will be an ufo on geoscape that you shoot down it can of course only spawn the mission if the correct terrain, ufo, dropship and so on stuff is set (btw. for being used in teh campaign all three dropships must be added to the list - otherwise this will just error out)
-
If you want to start testing in campaign mode right away, I'll take care of this first. But I was hoping to spend some time tweaking it before moving towards the final implementation.
-
that is not (yet) needed form my side - i was just explaining things ;)
-
Little WIP shot on the sign texture I'm working on.
-
very nice - if the glow stuff is in the material system that might be even looking cooler.
-
Would it be terrible if I rebuilt the herakles pod for my dropship tile? It is currently about 32 units too wide to fit along a street. I could rebuild it just a tiny bit thinner, I don't think anyone would notice... On the plus side, I'd build it in Radiant so it wouldn't need to be a model anymore.
-
Would it be terrible if I rebuilt the herakles pod for my dropship tile? It is currently about 32 units too wide to fit along a street. I could rebuild it just a tiny bit thinner, I don't think anyone would notice... On the plus side, I'd build it in Radiant so it wouldn't need to be a model anymore.
I think Raptor is even bigger, but not sure. I vote for leaving it as a model. They should look the same on all maps.
-geever
-
That Raptor only barely fits on a dropship tile, and even then it looks too small to contain all the troops.
-
Yes, the Raptor will need to appear on a 2x3 section of tiles (although it could fit 2x2 if reduced by 128 units of length), but the heracles dropship is really close to fitting along a single street. The benefit of having it on a single street is that it can be placed at more locations throughout the +city RMA (as more buildings are built), so that the player won't always be spawning in the middle of a big street.
It was my understanding that all dropships and UFOs were slated to be rebuilt in Radiant so that they can benefit from proper lighting.
-
Really? That's news to me.
-
Well what do I know? I believe somewhere along the line I picked up that impression from mattn, but that could have been a misunderstanding on my part.
-
rebuilding the ship models into brushes? i don't think this should happen. for the big ufo - where some detailed interior is included - we will stick to brushes, but for the others we should keep the meshes and fix the lighting issues in the code.
-
rebuilding the ship models into brushes? i don't think this should happen. for the big ufo - where some detailed interior is included - we will stick to brushes, but for the others we should keep the meshes and fix the lighting issues in the code.
Ahh ok. Another question related to how the campaign system handles the dropship tiles. Does every assembly have to support all three dropships? Right now the city RMA has to use a fixed tile layout. But I was planning on putting different dropships in different areas, so each one would need its own assembly (the dropship wouldn't simply be switched out on an otherwise similar tile that appears in the same location). Is this possible, or does every assembly have to accomodate all three dropships on the same size tile that appears in the same location?
-
Four dropships.
-
Four dropships.
What am I missing? I've got prefabs for Firebird, Herakles and Raptor available in UFORadiant. All of the RMAs I checked have tiles for these three dropships only.
-
You're missing the Hyperion (http://ufoai.ninex.info/wiki/index.php/Aircraft/Hyperion-class_Armed_Dropship), which isn't a surprise because as far as I know, the Hyperion model is still lacking a texture.
-
Am I right in thinking that it will not make an appearance in 2.3 and is therefore not an immediate concern?
btw, BTAxis, your posts are not showing up as "new posts" when I click the link at the top right of the forum page (H-hour, my messages, new posts, etc.). I've noticed twice today, but perhaps there's just a delay in the time it takes for a new post to appear as a new post, since we've been on each other's heels quite a bit.
-
Am I right in thinking that it will not make an appearance in 2.3 and is therefore not an immediate concern?
Yes.
btw, BTAxis, your posts are not showing up as "new posts" when I click the link at the top right of the forum page (H-hour, my messages, new posts, etc.). I've noticed twice today, but perhaps there's just a delay in the time it takes for a new post to appear as a new post, since we've been on each other's heels quite a bit.
I've never actually used that. I just watch the icons next to the forum and then click on the last post link if someone posted. Means I sometimes have to check if there were new posts in more than one topic, but most of the time it works out.
-
This post showed up in my new posts list, so there must just be a small delay that I was dropping into. I guess I should probably focus on work more. :)
-
Another question related to how the campaign system handles the dropship tiles. Does every assembly have to support all three dropships? Right now the city RMA has to use a fixed tile layout. But I was planning on putting different dropships in different areas, so each one would need its own assembly (the dropship wouldn't simply be switched out on an otherwise similar tile that appears in the same location). Is this possible, or does every assembly have to accomodate all three dropships on the same size tile that appears in the same location?
Anyone know the answer to this question? If I'm not clear enough let me know.
-
tiles that match the naming schema for the dropships (see other rmas) must exist. but they must not be the same tiles only with different dropships - you are totally free here. you just have to ensure that every dropship has a tile in your theme, as the player can send whatever dropship he like to send to your missions. this is not true for ufos, you can also only support one ufo, but your missions won't appear that often on geoscape then (see maps.ufo ufos entry), the dropships entry in maps.ufo is only for skirmish - as for campaign it's assumed to have them all anyway.
-
Thanks! That's easy enough.
-
Ok, I'm at the stage where I'm trying to work out the dropship tiles and I'm having some trouble. In order to make things easier, I've put all dropships on a 3x2 tile that fits into the same place in the overall configuration. However, if I set the *rm_drop +craft_drop_firebird "1 1" it fails to load. I've gotten it to load by setting a fixed craft with the following assembly:
assembly garage
{
size "8 6"
fix +str_cross "0 0"
fix +strv_1a "0 1"
fix +strv_1a "0 2"
fix +strv_1a "0 3"
fix +strv_1a "0 4"
fix +str_cross "0 5"
fix +strh_cwl_1a "1 0"
fix +strh_1a "2 0"
fix +strh_1a "3 0"
fix +strh_cwr_1a "4 0"
fix +bldl_4x4_2a "1 1"
fix +strh_cwl_1a "1 5"
fix +strh_1a "2 5"
fix +strh_1a "3 5"
fix +strh_cwr_1a "4 5"
fix +str_rail_cross "5 0"
fix +strv_rail_btm2a "5 1"
fix +craft_drop_firebird "5 2"
fix +str_rail_cross "5 5"
}
It will work if I replace +craft_drop_firebird with the other two crafts. However, if I replace that line with the proper line to allow the user to select the dropship (*rm_drop +craft_drop_firebird "1 1"), it will not load.
Any ideas?
I've committed everything to where I'm up to now. The current version of the UMP uses a fixed tile so that it will load for anyone who decides to play it.
-
Why does it fail to load? What error do you get?
-
Could not assemble map with assembly [assemblyname].
Sorry, can't load up now to get the exact text, but it's the standard can't assemble message.
-
Please paste the whole assembly. I suspect you didn't properly define your tile borders (which are ignored with +fix).
-
Its in the trunk (http://ufoai.svn.sourceforge.net/viewvc/ufoai/ufoai/trunk/base/maps/city.ump?view=markup&pathrev=29545)
-
Oh, right, sorry.
I think I figured it out. Your tile definitions are indeed wrong. What happened is that you were assuming that the letters in the borders connect to the letters in the borders of the neighboring tile. This is not the case. They connect to the *body* of the neighboring tile. So if you have "i" in the border of one tile, it can only connect to a "+i" in some other tile.
For example, take these two tiles, which in your fixed assembly are vertically connected:
tile +craft_drop_firebird
{
5 5
0 i i i 0
j +da +d +da k
j +ca +c +ca k
j +ca +c +ca k
0 ce ce ce 0
}
tile +strv_rail_btm2a
{
5 3
0 c c c 0
j +ea +e +ea k
0 i i i 0
}
These tiles can't connect, because craft_drop_firebird only has +d in the top row of the body (not the border), while strv_rail_btm2a can only connect to +i. It also doesn't work the other way around, because craft_drop_firebird can only connect to +i on the top side while strv_rail_btm2a doesn't have +i in its body at all.
The following setup will allow craft_drop_firebird and strv_rail_btm2a to connect:
tile +craft_drop_firebird
{
5 5
0 i i i 0
j +d +d +d k
j +d +d +d k
j +d +d +d k
0 ce ce ce 0
}
tile +strv_rail_btm2a
{
5 3
0 c c c 0
j +i +i +i k
0 d d d 0
}
d matches +d, i matches +i.
-
Thanks for taking a look BTAxis. I think you've actually inverted them and that is what makes them appear incorrect. But I think the tile definition is correct (at least between those two tiles). +strv_rail_btm2a should actually go BELOW the dropship tile, and the borders/bodies should match on the c's and e's. The +i's connect them to street crossings, and should not constitute a border between these two tiles. I've attached an image as it may be a little easier with a visualization.
-
Hm, okay. In that case I'm not sure what's going wrong. I'll try messing with the ump to see if I can make it work.
-
Okay, I got your map working (took some time to compile), but it takes extremely long to load up (over half a minute). That's worrying. I'm also getting an assert when I zoom up to the UFO on the roof of the building (attached), which may or may not have to do with the fact that the map extends slightly above 512. I also noticed some wrong levelflags.
The good news is that I made a test assembly with only craft_drop_firebird and strv_rail_btm2a, and they do indeed connect properly to one another, so it seems the tile defs are in order (at least in concept).
assembly test
{
size "3 4"
+strv_rail_btm2a "1 1"
*rm_drop +craft_drop_firebird "1 1"
}
Still no clue why the garage assembly doesn't work with the *rm_drop tile.
-
Yeah, mattn has been struggling with that assertion for a while now. I think he thought he had it fixed, but I guess not.
Any ideas on the long loading time? Is it the # of brushes/lighting that's likely to be causing the problem, or the scale of the textures?
My understanding was that the lighting was "baked in", so to speak, during compile so it wouldn't be loading with the map. And I don't think the brushes for this one building would be that much more complex than some of the larger existing maps (like the bomber). The scale of the textures is something that can be reduced, but I'm not sure if mattn would like that.
-
loading times are number of brushes and texture sizes - i suppose the textures are eating to most of it (though this is just a guess, did not do any measurements yet)
-
mattn, would it be doable to make the loading of textures and such be part of the loading progress bar? As it stands the map itself loads up fairly quickly, but then the game gets stuck on "waiting for mission start" for some time and THEN it shows you the battlescape UI and gets stuck some more. It would seem appropriate to only switch from the map loading screen to the battlescape view when *everything* was loaded. Enough for the fact that for most maps it doesn't take all that long to get the mission started.
-
hm. then it's not the map itself - but the pathfinding.
-
btaxis, could you please post a backtrace for that assert?
-
Backtrace (http://pastebin.com/zZCniUNX).
-
Interesting that second delay is the pathfinding. I really haven't had very much time to work on this the last week or two, but I would be interested in exploring that with you mattn (or anyone who knows the pathfinding well), to see if there's anything I can do to make that process shorter.
Right now I would say the second delay is as long as the loading screen for me.
-
that would be duke, i'm a pathfinding novice ;)
-
@ H-Hour:
If you want to improve your city with additional models you really should check out Sitters Homepage:
http://www.md2.sitters-electronics.nl/models.htm
Just a tip, if you need cars, toilet accessories, stairs & many other supercool models... 8)
I know we are using many of those already, but imho many others could & should be incorporated into our game also...
Sitters is a real low-poly/ high-detail modelling expert & we should imo use more of his skills than used already (Thanx Sitters !) to improve our stuff even more here !!!
-
...
-
I can imagine many of those already ... parking in your megagarage ... & looking super 8) there... ;) :D ;D
-
Sitters does indeed have many excellent models. I look forward to using some of them once the lighting-on-models issue gets resolved, something I believe is planned at some point in the post-2.3 future. Until then I'll be using as few models as possible.
-
This will be resolved much earlier for sure...
Arisian & Mattn are working hard on this @ the moment & are already very far progressed with it...
-
nope - we are working on a shader based solution - but this is not exactly the same thing that H-Hour is talking about
-
& pleaaaaaassssseeeeeee bring back the old columns as those were looking much better & much more massive & I do not think that the new ones optimized any compiling times or get rendered much faster, they just do not look that impressive anymore. You sometime wrote that you stored them & can easily change them back, please do me a favour & do that.
(Quote from MCR brought in from a different thread because I know you'll see it here and I don't want to clutter the windows binary thread.)
That may be something I'll take another look at after I get everything up and running. But for 2.3 I'm trying to get the UFOs and assemblies working right.
-
Thanks.