FreeGameDev

http://www.mediafire.com/?t0vq2v23907084x

here is the current version of the city track.

the drivelines for the alternative routes aren't added yet. i will have to check how this works. and maybe the alternative routes need some item balancing.

the polygon count is comparable to tux tollway.

the exporter still doesn't take the orientation of the physics boxes into account. hiker, have you looked into this? but in my case it's no big deal. the wrong orientation looks ok too.

edit: oh! i noticed a problem with the reset plane. the physics boxes collide with it. would it be possible somehow to ignore the collision for them and only reset the karts?

edit2: is there a keyboard shortcut for taking screenshots?

horace {l Wrote}:the exporter still doesn't take the orientation of the physics boxes into account. hiker, have you looked into this?

No, I haven't can you open a ticket for that (on our new 'trac' tracker (https://sourceforge.net/apps/trac/supertuxkart/)?

...

edit: oh! i noticed a problem with the reset plane. the physics boxes collide with it. would it be possible somehow to ignore the collision for them and only reset the karts?

Hmm - technically yes, bit it would involve quite a bit of restructuring (track exporter, xml file format, handling in STK to set proper collision flags) - so I would prefer a different solution. Maybe I'll get an idea when I try your track

edit2: is there a keyboard shortcut for taking screenshots?

No, there's isn't. ATM we only have one key which removes the kart and GUI, so that the screenshots look better, but no builtin screenshot button.

Cheers,
Joerg

what is the key for disabling the gui and kart?

Hi,

ctrl+F8, though atm it only works in debug builds

Cool track, I like new trees and larger road

thanks!

i checked out the new exporter. it takes ages to export now. the console outputs lots of vertex normal stuff or something like that (i can't read it - it scrolls by too fast and it didn't finish yet). is this some kind of debug output you forgot to comment out or what is the reason for this?

i also read something about normal problems on trac. what is this about? physics or graphics related? if you don't want averaged normals everywhere then you have to use the edge split modifier in blender.

...
i think for consistency the "mass" property should also support strings.

...
does anyone have an idea already about solving the reset plane issue? an invisible reset plane kind of is necessary there since otherwise you could do a shortcut jump.

Hi,

indeed a debug feature was added to the exporter, but I forgot to disable it, sorry. If you use the exporter from latest SVN, it's off (or if you know a bit of python, just set the DEBUG variable to False)

The normals issue has to do with the physics, Joerg started coding an experimental feature where the physics engine uses the normals and interpolates them to get smoother driving. And indeed a process was started to fix normals in tracks

regarding the invisible plane, I'll let Joerg answer, but I'm afraid at this time we don't have any built-in fix; except to design the track in a way that doesn't require many reset planes

horace {l Wrote}:i checked out the new exporter. it takes ages to export now. the console outputs lots of vertex normal stuff or something like that (i can't read it - it scrolls by too fast and it didn't finish yet). is this some kind of debug output you forgot to comment out or what is the reason for this?

I think auria enabled debug output for the b3d exporter. You can either set DEBUG=0 in b3d_export.py, or check out the latest version, where I have disabled this (auria, hope that's ok??)

i also read something about normal problems on the trac. what is this about? physics or graphics related? if you don't want averaged normals everywhere then you have to use the edge split modifier in blender.

That's some test for 0.8 - don't worry about this.

i think for consistency the "mass" property should also support strings.

Thanks, fixed.

does anyone have an idea already about solving the reset plane issue? an invisible reset plane kind of is necessary there since otherwise you could do a shortcut jump.

The usual answer is to ask if there's isn't a way to model the track so that people can not use the shortcut? But I'll have a look at the model.

Cheers,
Joerg

PS: Sorry for the late answer, I apparently forgot to click on 'submit' yesterday.

http://www.mediafire.com/?202dlc4h43cyb93

here is a new version. now with drivelines for the alternative routes. (the ai karts seem to decide once and then always take the same route for some reason?)

i have changed the reset planes. now the problem isn't very noticeable anymore because the boxes slide down and don't stop midair.

edit:
water is a bit of a problem too for physics boxes though. there would have to be some simulated buoyancy and some force could be added in direction of the uv-animation.

if you press reset while you are on the first quad of an alternative driveline, or if you automatically get reset after the last quad you have been on was the first of an alternative driveline, then you get set to a wrong position. this is a bug i guess?

horace {l Wrote}:if you press reset while you are on the first quad of an alternative driveline, or if you automatically get reset after the last quad you have been on was the first of an alternative driveline, then you get set to a wrong position. this is a bug i guess?

What is this wrong position exactly? You should be placed one quad back, so basically where the fork is.

Cheers,
Joerg

Very nice work, I added you track to SVN (feel free to further refine it though)

regarding the AI choosing a single path, this is a known problem, I created a ticket

regarding water, we are planning a new improved support for water that should improve the situation

if you press reset while you are on the first quad of an alternative driveline, or if you automatically get reset after the last quad you have been on was the first of an alternative driveline, then you get set to a wrong position. this is a bug i guess?

I'll let Joerg check that one

thanks!

What is this wrong position exactly? You should be placed one quad back, so basically where the fork is.

you don't get set to the fork but to the start line of the track most of the time. or sometimes to the wrong fork it seems.

...
maybe it would be best to remove the physics boxes from the track for 7.1? or will the new water already be in there?



edit:

The normals issue has to do with the physics, Joerg started coding an experimental feature where the physics engine uses the normals and interpolates them to get smoother driving. And indeed a process was started to fix normals in tracks

i think it also would make sense to fix the normals for visual reasons in some tracks. of course having stuff smooth shaded can be an artistic choice too but some tracks contain areas where the shading simply looks wrong. all track makers should get informed about the importance of blender's split edge modifier.

btw. the robots that hold the starting banner in xr591 have their normals inverted. should such stuff also be reported on the bug tracker?

The water should be in 0.7.1
Anyway the boxes wouldn't be the first problem with water, in 0.7 and before (as well as current SVN), bowling balls roll over water, etc.

Regarding XR591, I guess this could be worth a bug report, yeah

horace {l Wrote}:

What is this wrong position exactly? You should be placed one quad back, so basically where the fork is.

you don't get set to the fork but to the start line of the track most of the time. or sometimes to the wrong fork it seems.

OK, I'll have a look (generally it's a good idea to put things into our tracker, otherwise we might just forget).

maybe it would be best to remove the physics boxes from the track for 7.1? or will the new water already be in there?

The 'new' water would still require a proper modeling, I am not going to simulate real water. What you should already be able to do is model a surface under the water (think of a sea bed or so), set its texture to be reset, and set the water surface texture (not the object) to be ignored. Then the boxes will fall through the water, and rest on the sea bed. Is that good enough?

btw. the robots that hold the starting banner in xr591 have their normals inverted. should such stuff also be reported on the bug tracker?

Anything should go in the tracker, it helps us a lot with not forgetting things.

Cheers,
Joerg

Rehi Horace,

there are a couple small issues in city track, I wonder if you could fix them?
often it's easy if you miss a curve to get stuck on the other side of a fence (see screenshots)

the blue fences would need to be taller (or just removed), whereas the walls around the road that goes up the mountain would perhaps need to be closer to the mountain so you can't be stuck between wall and mountain?

Also, we were thinking it'd be nice if you could find a little something that would make this track unique, at this time it's rather similar to Tux Tollway

i thought the reset button exists for this reason? fixing everything where you could get stuck would make some tracks quite boring in my opinion.

edit: by the way, it looks like the automatic reset detection traces down in the direction of the kart's bottom normal. i think it would better to simply trace down in the negative direction of the global up axis. then in the second screenshot setting the rock texture to "reset" could help.

yes, the blue fences could be removed. at the moment i can't fully imagine how it would look like without them but probably it would be ok.

but the walls aren't easy to fix. moving them closer to the rocks would be a lot of work.

hm... why do you think the track is too similar to tux tullway? i don't think so. it's much more curvy, slopy, more buildings, more alternative routes,... maybe tux tollway can add something unique? a different sky box? (the city track was there first and is older than tux tollway.)

actually i didn't plan to change much anymore on this track. just some item balancing on the alternative routes if necessary and adjustments to the physics boxes, water, reset planes,... in case any new features get added for that.

i took a look today... the fence prevents shortcuts in the area with the buldings. so it shouldn't be removed.

but i will try to make the fence and the wall a bit higher.

i made the fences and the walls a bit higher. it's definitely better and much harder to get over them now. if this isn't enough i could add invisible polygons.

Thanks, I committed this version, that's much better indeed

Now, we would still like to perhaps find something to make this track a bit more unique, so if anyone has an idea please comment

if there still are problems i can add invisible walls that go a bit higher.

i still don't get the "unique" problem though. they both have a tunnel and use the same sky cube (my track is designed for my sky cube) but otherwise i don't see the similarities to tux tollway. there are many unique things like the giant rock with the bridge, the construction site, the river, the area with many buildings,...

It could be argued that Snow Peak and um... Northern Resort is just as similar, if not more. :P

As for me, it is good enough. I don't mind if some details would be added to this track, though right now it is _much better_ than nothing.

maybe i have a crane model that i could add to the construction site. i don't know if i still find it in my backups. i will look later...

horace {l Wrote}:maybe i have a crane model that i could add to the construction site. i don't know if i still find it in my backups. i will look later...

Someone on IRC mentioned an airport. While obviously it doesn't make any sense to model a complete airport, perhaps you could add a plane that takes off from somewhere behind a mountain (or a helicopter flying around?)

Another option would be a wind turbine (though that would actually fit better in tux tollway imho). The old forum had a model once, not sure if that could be recovered.

Cheers,
Joerg