RaceCon latest version, updated 15-June-2008.

Nigel

Thanks Nigel

Cheers, Nigel.

Thanks Nigel.

I get a "couldn't open xxx.rpy file not found" message when I try to open a replay.
This is no problem for me, only wanted you to know that I have checkt the program.

Nice to see whats in all those 3do. trk. mip. and all the ather files is hidden.
I am no track bilder, only consumer

Thanks for sharing

Hi Nigel, thanks for sharing.

Was the rpy file in the replay directory or somewhere else ? In some cases RaceCon works best when things are in their usual place.

Nigel

They were in the replay dir!
My GPL map is in a other place.
So I made a standard install C:\Sierra\GPL\Replay :
but get the same message,
also when I place the xxx.rpy file in the root.dir where RaceCon is

But like I say, no problem!

Opening up a replay in RaceCon loads a screen that displays the track layout with the replay superimposed, like you can see in GPLRA. So it assumes that the replay directory is in a GPL install, with a track directory alongside it. The absolute path shouldn't matter. You will need the track the replay is from to be installed though.

Nigel

thanks nigel
great tool

tommi

New version. I've made a lot of improvements to the drawing of cars, plus there's now enough functionality to add track sounds. Here's some instructions for the latter.

I'd suggest looking at a track that already has sounds in RaceCon - that will give you something to copy. You can run RaceCon twice simultaneously, or you can open both in the same RaceCon, whichever you find easier.

Take Kyalami for example - if you expand the Root node you can see the ssourcelist node under it. This is what I call a 'Handle'. Handles have names, whereas everything else has numeric ids. If your track doesn't currently have the ssourcelist handle, the first task is to add it. To do that, right click on the Root node and choose 'Insert Handle'. That will add the handle, but it won't be named as yet, which makes it look odd. You should be able to see the extra + box for it. If you left-click just to the right of the plus you should be able to select the nameless handle - once you do the middle pane will show its details - mainly a type of 'Handle Pseudo-Node'. (True nodes are the ones with numeric ids).

To give the handle a name, right-click where it says 'Name' and you can enter 'ssourcelist'. Once you've done that the handle's name will appear in the tree view.

Now back to Kyalami - if you expand the ssourcelist node you'll see it has one child node, an Object List with id=244. To create a similar node in your track, right-click the ssourcelist node in the tree view, and choose 'Insert Object List'. Then if you expand the ssourcelist node you'll see it now has an object list child node, with a stupidly large id. This id is just a placeholder until the 3do gets saved, at which time the numbers all get reassigned and it gets a proper smaller one.

In Kyalami again, expanding the Object List node shows us it has five child Transformation nodes, one for each sound location. Currently your Object List node has no children - to add one, right click its node in the
tree view and choose 'Insert Transformation'. For the moment one sound will do us, but you can repeat this any number of times.

Now if you expand the tree view nodes out, you can see the new Transformation node (again with large id). There's two things you need to do to the Transformation node. Firstly set the X,Y,Z Translation values to
match the position of the sound. That can be done by right-clicking where it says 'X Translation' etc. For sounds the rest of the values don't matter and can be left as they are.

Secondly the Transformation node needs to have an External Object child node. To do that, again you need to right click it in the tree node view, and choose 'Insert External Object'. The External Object is the thing that links to a different 3do. You can specifiy the name of that 3do by right-clicking where it says '3DO'. As you can see from Kyalami, it shouldn't have '.3do' on the end.

That's everything you need in the track 3do. It's probably best to close RaceCon at this point, when you should be prompted to save the track 3do. Then reload it and check that everything is as it should be. The ids of the nodes you've added should now have small numbers, but everything else should look
just as before.

Then you need to perform similar steps for the TSO 3do that has the sound. Adding the ssourcelist and the Object List is identical to the above. But instead of adding a Transformation node, now choose 'Insert Number List' . That will create a Number List node with no numbers in it. To add the
numbers, right-click where it says 'Count' and set the count to 2. It adds zeroes by default which happens to be what you want.

Please ensure you have backups of the 3dos you're editing. Racecon will completely recreate the 3do when it saves, so if there's anything it doesn't understand properly it may go horribly wrong. However as far as I know it doesn't have any problems in this area.

For anyone that wants to be bold, I think there's a simpler way that should work. Rather than having to add sounds to the trackside objects, I think everything could be done inside the track 3do. The difference is that where the External Object node would normally be, I think you can substitute the Number List node, still set up the same as above. If anyone tries that perhap they could post the results here.


Click to view attachment

Nigel

.

Many thanks Nigel

thank you!
Im gonna try it

New version with a find feature to find a specific 3do node via its id.

Nigel

Nigel,

what actually is an id compared to offets i tend to think in from my workings with gpl editor?


Steffen

They are the same - the id is the offset from the beginning of the 3do section I think. It's possible I take a few liberties with them though, but I don't precisely remember.

However RaceCon supports other Papy games as well as GPL. The 3do files used by the games prior to GPL were similar, but the N4 ptfs are completely different, and I've forgotten whether those ids are offsets or something else.

Nigel

Fixed the bug where if you closed a changed 3do window it wouldn't prompt you to save changes.
Added support for editing a couple more 3do items -

Deleting distance splitter children.
Change per-vertex colour for shaded polygons.

Nigel

Thx Nigel for this tool

Thanks Nigel,


i just found how incredibly useful this tool is in watching car edits.

how can i make sensible use of the viewpoint window ? is there anyway that i can change it other than just axis wise? i saw the viepoint dialog window didnt let me change things and there was no center, rotate or zoom feature as e.g. in 3doeditor.


Steffen

Not currently - controlling the viewpoint is one of RaceCon's big weaknesses, which I meant to do something about but have never gotten around to. What do you consider a good example of how to handle this - 3doeditor, or is there something better ?

Nigel

GPLEditor for example would be a not so good example, viewpoint selection is acceptable (doubleclick on vertex with shift pressed) but rotation with moving the mouse is horror.

3doEditor is a good example. doubleclick on vertex for vertex or polygon options, including setting this to the new viewcenter. additionally and this i find most useful zoom and east west and nort-south rotation controls at the window bottom.
what would be a good enhancement over 3doEditor is that rotation is not only possible around the origin but also around the vertex selected as viewcenter, good to check details. or to keep things simple only rotation around the vertex selected as viewcenter and origin being a possible default viewcenter even if there is no vertex at 0 0 0. but maybe rotation around anything else but origin is difficult to implement. in case so the basic 3doEditor funcionality would be of great help already.

your threads always turn into some christmas gift wishlists

Steffen

Hi Nigel, I told you before that this it´s a good tool for editing GPL.
Now we change some *.3do in the main track, and don´t need to change it in every layer (distance view or section track). This program do it selves when you change it on one place.
But this don´t happen with the mips too.
When you change a *.mip (ex: asphalt.mip to asphal2.mip) in a section of track, it don´t change automatic in the others distance points. Must to change step by step on every distance view.
Can this be changed, maybe can be faster editing, if it´s posible to solve this.

thx in avance

_nes

I think that's something I'm unlikely to change in the forseeable future, RaceCon will probably stick to simple changes that affect only the current node.

Nigel

Ok, thx Nigel.
Still it is a wonderfull tool

Can I make a few requests for additional features?

When editing vertex colours:
- an option to use hexadecimal values, and/or a 0-255 scale.
- the ability to change all vertex colours at once for each polygon, i.e enter an rgb value and all vertex colours for the current poly are set to this value.

Also...
- edit poly colour.
- edit texture co-ordinates.
- change poly type, and keep any values in tact. E.g change an 81f to an 820 and keep all texture-cords and poly colour; or change textured to untextured and keep poly colour. Not sure how complicated this would be to implement..
- edit offsets for child nodes.


BTW I've just noticed that the plane selectors are 'upside down' - what you have as the "far child" is actually the "near child" and vice versa; similarly the front/back children for flavour8 nodes are named the wrong way round.

I'd rather leave this as it is - my code uses floating point values for colours everywhere, so if I did provide the alternatives they'd immediately get converted back to floating point anyway.


Assuming I add the support for changing polygon types, is this still useful ? This would just result in an unshaded polygon.


I think I should be able to do these.


You'll probably need to be more specific here, as they'll need separate coding for each type, and doing them all would take a while.


I think that depends on your point of view. For instance with the simplest of the plane nodes, the one with only one child, I call that child node the 'front' node. To me that makes sense because if you view it from the intended side, you're seeing what's on the front side of the plane which is the child node. If you switch to the wrong side you don't see anything. With respect to the plane equation, it turns out that means that if the equation result is positive you're viewing from the front side, if it's negative you're viewing from the back side. I think all the rest of the child nodes are then named in a consistent fashion, taking a positive plane equation result to be the front and a negative result to be the back.

Possibly the way I name the nodes adds a bit of confusion, e.g. I call the simplest type "Plane Cull Front". That's not meant to mean that it culls the front side per se, merely that the child node called 'Front' is a candidate for culling, and won't be drawn when due to the viewpoint it has become the back.

That was probably clear as mud

Nigel

I was thinking it might be easier from a user's point of view - I'm more familiar with rgb values in hex or 0-255 than in decimal. This is probably largely due to the fact that until now I've had to use a hex editor to to alter vertex colours; but also most graphics software uses hex or 0-255 for colour - I don't have any that uses decimal.


When shading 3dos I often find I want to shade a polygon all the same colour. So to shade a triangle red, for example, I need to set the colours of each of the 3 vertices to the same rgb value. I'd find it useful to be able to just set the rgb once and have it 'copied' to all the vertices which make up the polygon.

What I mean is changing the offsets to point to other parts of the tree. For example in a two-child plane selector you could edit the offsets for both children to be the same, rather than duplicating the entire contents of one child in the other. Admittedly this probably isn't something which would be used very often.

I think front/near/above etc. mean on the side of the plane in which it's facing, irrespective of whether it's facing positively or negatively. For example in a flavour9 node the first child is seen when the viewer is above the plane, even if the plane equation results in a negative value (consider a cube 3do). In RaceCon the first child of a flavour9 is consistently called the "far child" but I think it should be called the "near child" because its contents are what can be seen when the viewer is above the plane.. In a flavour8 node the second child should be 'on the plane when seen from above the plane', i.e the "front child". This completely threw me when I was editing vertex colours for polys in these positions as I ended up shading the wrong side...

Updated version downloadable from first post.

GPL node type 5.17 (the main one used in car skin 3dos) is now editable. The mip names can be changed, and by clicking on the MIP Count you can change the count, either increasing or decreasing the number of mips.

I also fixed some bugs in the saving code of some of the lesser used node types.

Nigel