I think I didn't like the way 255 would mean a maximum height of 63.75 and it seemed that 60m would be a better maximum height. And that allows 15 'reserved' values that could have a special meaning in future.
I am not coming up with an answer for that strange server issue. Has it only happened since you installed R12 on the server? If so, is it easy to revert to R and see if it makes a difference?
I'm guessing it has nothing to do with the new version, as I can't think of any related changes in the code. Does the same problem happen to all guests who join? Are there any other DCon instances on the same server computer? I wonder if it could be something to do with the computer time clock, running slow or fast. Can the server computer be restarted?
PMO_GET_Z, // 8 - request Z values / reply with Z values
And the documentation for how it works.
// PMO_GET_Z can be used to request the resulting Zbyte values for given X, Y, Zbyte
// positions listed in the IS_AXM. A similar reply (information only) will be sent
// with adjusted Zbyte values. Index and Heading are ignored and set to zero in the
// reply. Flags is set to 0x80 if Zbyte was successfully adjusted, zero if not.
// Suggested input values for Zbyte are either 240 to get the highest point at X, Y
// or you may use the approximate altitude (see layout file format).
I'm not sure it will be released today, probably not as I've got something else I'd like to have a go at. But then hopefully tomorrow.
OK, I am mentally tired from trying to get a layout editor improvement finished. You can now select marshalls / circles at the same time as other types of object but that was more complicated than it sounds.
So bear with me being a bit slow!
Can we get back to the basics, exactly what do you want to do? I understand you are trying to make layouts from a old track work on a new one. And this could be applied to moving a layout from one track to another I guess (e.g. BL car park to WE car park).
Are you trying to run through existing layouts and get all the objects of a certain type set to ground level? In particular concrete objects so you can't use the Zbyte 240?
And are you doing this by your code reading a layout file and passing it into LFS as AXM packets?
If the above is true I'm wondering if the simplest thing could be an InSim packet for local use only, that simply asks for the height for a given ObjectInfo (X,Y, Zbyte) and LFS replies with the Zbyte that would result from that. So you could run through a list of objects one by one and do what you want with the answer?
I don't know much about VOB mods, but some of them can have the correct physics mesh so they can be used online without harming any other players. From the crash address I was given, it looks like the crash was when reading an object, so that's why I'm asking if any of the people who got a crash, were using a modified VOB. But no-one has answered yet so I'm still worried about the possibility it could a be a problem in some standard installations.
Either way, I'd better add a thorough validity check when loading an object because a crash is not acceptable in any case. But it would be reassuring to know that it was caused by a modified VOB, otherwise there's a more serious bug here.
I am just wondering if something special could be done for this.
Possibly a sort of query to find the highest ground position at X, Y.
Or perhaps an object placement packet marked as "set height"
I'm wondering if this can be done at the local level or does it need to work in multiplayer.
Sorry for the fuzzy thinking, I'm busy in the layout editor at the moment so I'm just trying to figure out what would solve it for you, be simple to implement and ideally useful for other situations too.
CTRL + right click to copy a colour
SHIFT + right click to paste a colour
The shadows are all done a very good way in the new version I am working on, but it is totally impossible to update the public version with the new shadows. Eric is working on all the tracks to get them working with the new shadows. It's the thing I am trying to get back to.
I'd really like to do Arabic at some time. It's just the sort of thing I like to do because I like LFS to be accessible to everyone and I'd be interested in learning how the Arabic alphabet works. But it is much more difficult than you imagine. We are talking weeks of work for me before you guys can start to translate it. Of course languages like Arabic and Hebrew have the difficulty of being right-to-left text (but with occasional left to right Latin text within that) and this means a lot of rewriting of many functions in Live for Speed.
There will be a lot of studying for me to do and a lot of problems to solve. I can't just click my fingers and magically all the code is done.
Now, I hope you will understand, I am in the middle of some extremely important graphical work and need to get the tyre physics finished. This must be done or Live for Speed sales will dry up completely and we will have to go and get another job. There is no doubt at all, this is a higher priority than adding a couple of tricky languages.
Unfortunately I was interrupted by someone taking our servers down two weeks ago, so I had to stop all the work I was doing and make a new patch in this old version of LFS which can resist the attacks. So that attack has slowed my development by maybe three weeks so everything that I will do in future will come a little later than it would have been
The new PMO_POSITION packet does have the Zbyte set, but I don't that is what you are asking.
I can't set the Zbyte in the reporting AXM in the case of a dedicated host receiving the packet, as it doesn't know where the ground level is.
I'm getting a bit confused trying to think of when that Zbyte adjustment could be done and when it would need to be done. Maybe I need a more specific case to try and understand where it would be helpful and to think if it can be done without causing problems.
One thing to note though, it is acceptable and usually OK to simply use the value 240. From the notes:
It seems from this crash address that LFS was loading an object and crashed while checking for a type of reflection material that it can do a better way now.
I think when you first open LFS, in the first instant it loads humans, car objects and the helmet.
As you say it works on a fresh install, could it be you had some VOB mods installed before? I suppose it is possible that a VOB mod could be incorrectly formed in such a way that it didn't crash before but does crash in this new function.
I'll try to figure out exactly which line it crashed on but it would be interesting to know if a modified model was to blame, and why it doesn't crash on most installs.
I have heard that from one other person. I asked for more information but he wasn't able to give it and just reverted to the old version. I would really like to have this information so I can fix the bug. Otherwise the crash will still be there when we release the official update!
What I need to know is:
- Crash offset or crash address
- Exception code
In older versions of Windows the information was offered to you in the crash dialog when you pressed "more info" or similar. I think in more recent versions of Windows you can find the information in an event log, accessed through control panel.
If you can give me this information that would be great and I can try to find out what causes the problem. If you would like more information on how to find the crash address, please tell us you Windows version.
Information: We did intend to release the full version this weekend but for various reasons we have decided to go on a few more days. I hope to put another test patch here on Monday or Tuesday. But for now it seems R12 works well.
New free view camera position text command /cp
/cp will copy a text camera position to the clipboard
The resulting text can be saved in a text file, forum, etc. or into
another instance of Live for Speed to reproduce.the camera position
Many translations updated - Thank you translators!
Slight reduction in some excessively bright driver models
New value PMO_POSITION for IS_AXM packet to report a blank position
New packet IS_CIM reports a connection's interface / editor mode
That is really off topic as it's nothing to do with the test patch.
But, for a quick answer, the new tyre physics is based on a mathematical model for producing the output forces from the current state of the tyre (velocity, rotation, camber etc.) instead of a 'made up' combination of lateral and longitudinal forces from 'made up' slip curves to try to match the data. It provides a more realistic response for steering and application of throttle and brakes, affect of camber and so on. It feels good to drive but is not finished and I would like to get it done for the big update we are currently working on (which is a really important graphical update).
I guess you could find more information about the tyre model by searching for my posts, but you would have to search back quite far. I'm a bit too busy to go looking for it now.