Nice time, but be careful of the walls. The new patch will detect the ones you hit hard.

Quote from EQ Worry :

Great, thanks , having it in server log will allow for later diagnosis, but it is not really easy to respond to server log items in real time (though not impossible, under certain circumstances). Having the admin commands, or attempts at them, forwarded to InSim would make things of course much easier. But I'm very happy with this 1st step, thank you.

Isn't it possible to use tail and then forward messages to an InSim client? Combined with grep, even high priority messages can be filtered and dealt with, and in virtually real time too.

I think Bernie did a slick manoeuvre there. He didn't want to be seen by the Bahraini Royals or other Middle East States as being the decision maker. He simply left it to the technicalities and teams to make the call.

Wasn't it Ted Kravitz who forecast this exact outcome?

There are just too many reasons not to go there this year.

Quote from Scawen :

No, there is never any fragmentation, because the static vertex buffers for all added objects are created at the same time - that's why it can take a quarter of a second / maybe half a second depending on computer speed to generate the buffers if there are 800 objects on the track.

I can't emphasise enough, and this is why I took ages to write an essay about it in the ISPackets.txt : programmers will have to be careful with that bit in PMOFlags and you absolutely MUST NOT set it routinely in the PMO_ADD_OBJECTS packets. You set it once in the last packet of a long list of objects, at a time when you are happy for people to spin off if they are driving around a corner. Don't set it if you are adding / moving a small number of objects around - just leave the new ones unoptimised.

Thanks for the clarification and emphasis. It was your ISPackets.txt warning that made me think of avoiding re-optimisation, but for the wrong reasons, and it's now clear.

Quote :

That doesn't happen in the editor now, it does a thorough check before you move objects, and doesn't perform the operation if it would go wrong in any way. But there are no such checks in InSim. Intersecting objects would be deleted in that case.

I was going to suggest flashing the selection/object while in editor mode.

Quote :

Unfortunately, dedicated hosts cannot detect intersecting objects. If objects sent from a dedicated host have the exact same X, Y, Index they will not be added. But if they are slightly different and still intersecting, they will stay there. If the packet is sent from a client, the objects are instantly deleted if they intersect.

Does this mean an InSim packet on the dedicated host will allow intersecting objects then? If abused, it could lead to some very interesting... erm... sculptures?

I edited several times to try and be concise.

Quote from GeForz :

I assume:
Multiple objects will just be reported as seperate objects in the packet, each with own x,y coordinates.

That's my assumption too from reading Scawens post and the new LYT.txt.

Quote :

And for the control object: The insim app could also remove the "control object", i.e. you configure the insim app like "!build garage" and then add a predefined object like a cone. The insim app then removes the cone and builds a garage relative to the coords of the cone.

Quote from Dygear :

You could do the command `autox build garage` and it will wait for you to place an object. After you do place an AutoX object, InSim sends the IS_AXM with the details of the 1 object that was placed by you, the InSim application then goes on to use the AutoX object you just placed as the Geomertic center and adds the other AutoX objects around it, finally removing the object you placed at the end. I can see this working quite well, except for one thing.

I was originally thinking the same, but realised that creating and deleting an object would fragment the static vertex list. Where there are many objects, my understanding of Scawens posts, is that the list is best optimised for better frame rate. If my interpretation is correct, an analogy can be made to file fragmentation on disk/memory, and the optimisation simply makes objects contiguous. I may be wrong and often am though.

Quote :

struct ObjectInfo // Info about a single object - explained in the layout file format
{
short X;
short Y;
[B] char Zchar;[/B]
byte Flags;
[B] byte Index;[/B]
byte Heading;
};

First is, why is Z called Zchar? Was that an error? Should it not just be Z.
Second is how did you manage to Index 800 objects with a value of 0 - 255?

Not sure about the Zchar, but you might be getting muddled between the index of the array of all available objects (see note 5 of new lyt.txt) and the total number of objects.

Quote :

Sorry to be pedantic but could you make the Index the structs first value, as it's the most significant bit of data we will have.

struct ObjectInfo // Info about a single object - explained in the layout file format
{
[B] byte Id;[/B]
[B] byte Flags;[/B]
short X;
short Y;
[B] char Z;[/B]
byte Heading;
};

No two objects can occupy the same space, so each unique object can be identified easily, thus

Quote from Scawen :

An object is identified by (X, Y, Index).

On that note, currently if an object intersects another while moving, it is dropped from selection and is effectively lost. What happens when objects in a multiple selection intersect with an existing object? I'm assuming we would need to avoid this via InSim too, but how to detect intersection? Would these objects be silently dropped too?

In regards to multiple objects in shift+U (editor mode), where will the origin of the multiple objects be, first selected object, or the geometric centre?

Will it be possible to inject sets of objects via InSim while in editor mode? ie add further objects with relative offsets/rotations/indices from the last editor added object detected via ISF_AXM_EDIT

Example: Bale garage
Place first bale in editor, then use an InSim app to build a garage based on the last placed object position and rotation.

Is it possible to have a new generic "InSim object" available from the editor control objects list?

This would simply be a token that can be detected and trigger an InSim app to send a pre prepared payload. In the example above, the "InSim object" is used instead of the first bale, and the first object in the payload is placed at the vertices. I suggest a control object so it is invisible under normal circumstances, but would enable bulk object addition via InSim.

I hope this isn't considered to be more noise.

Quote from Silverracer :

Works fine for me on Z34, both in SP and MP.

Are you sure that the tracks were set to standard config when you tried it?
Granted I've only tried a couple of AS, KY, WE and FE combos, but the AI could join and drive in the standard configs...

Yes bog standard.

Quote :

Edit: Did you play around with the data/pth folder after you read Scawen's post? If any of those files are missing you'd get the same error message. Since you said WE, KY and AS, and these are the files in the pth folder...

Good suggestion, and yes I'd replaced the .pth files with the files from the smx pack a week or so back while testing out another theory. Checking the file dates reveals that the SMX pack are quite a bit older. That kind of breaks the whole purpose of my experiment based on those files.

Although my AI was pitting correctly during a race, I always ended the race before they entered garages, so I guess those .pth files control that. Edit: and leaving the garages during qualifying of course and why I had the problem now.

Thanks.

Last edited by Squelch, Wed, 8 Jun 2011 01:07. Reason : Added bit about leaving garages

I've found a bug that seems to have gone overlooked so far.

I receive "AI can't drive on this configuration" and unable to start if I set a qualifying period with AI drivers present.

The tracks affected are.

Kyoto
Aston
Westhill

All standard configurations.

All other tracks work ok, and this problem did not exist in z31 at least.

Quote from Flame CZE :

It's not available in hotlap mode.

Hehe! Beat me to it. I didn't realise I was in hotlap mode. Thanks.

I just tried to access the autocross tracks, but it's greyed out and cannot be selected. I have absolutely no idea why should be, and hadn't noticed before. Anyone else?

Quote from E.Reiljans :

Erm.

The NVIDIA binary PhysX SDK is 100% free for both commercial and non-commercial use.
The SDK contains headers, libs, dlls, samples, and documentation

Quoted right from http://developer.nvidia.com/physx-downloads

I stand corrected, and should have said restrictive instead.

It would be impossible to release an open sourced game/simulator that uses PhysX for example.

I've had a little play with Rigs of Rods and it is pretty impressive. The Outerra engine looks quite nice too.

Quote from Victor :

Give it another try now please.

That works perfectly. Thank you Victor

In the spirit of congeniality, I genuinely wish you good luck with your mid terms.

Quote from tristancliffe :

How about because it isn't in the rules. It's an unwritten rule. Part of the code of conduct. If every 'rule' from life had to be written down we wouldn't be able to breathe.

The gentlemen's agreement is the only rule, and yes it is unwritten. Perhaps honourable conduct should be the phrase to use?

Quote :

Sadly, young people today work on the principle that if it isn't written it doesn't count. That's why young people are nearly all morons.

Fair shout, and you are now formally invited to join the Miserable Old Git club

Last edited by Squelch, Sat, 4 Jun 2011 13:37. Reason : Sppeeeling!

Quote from scipy :

Good trigonometry joke there! Imo, if anyone is being obtuse it's people who get things wrong post after post.. kinda like you do. Referencing things that supposedly stopped something from being an advantage when they did next to nothing about the "problem". I find that very annoying and plain ignorant.

As far as my manners go, if you really had a search through some of my previous posts, you would've noticed that the manner in which these posts were written is a drastic improvement in ways of how I've used to treat people like you.

My friend let me spell it out.

Obtuse: The over revving before the clutch model was introduced, allowed a speed increase without absolutely no penalty. This was done while the gears were neutral, and was a win/win situation. The clutch model fixed it somewhat, and prevented the speed increase. I know you know this, and you still remain obstinate.

Ill-mannered: Your treatment of some forum members is frankly appalling. Treatment of AudiTT earlier in this thread is one such example of your insensitivity. Yes he was off the mark, but English is not his first language, and he relies on translation software to read these forums.

Arrogant: Your ego leads you to believe I read your past posts. You're wrong. I was researching the clutch-button exploit, and came across your name in relation to cheating, that's all. You seem to believe your opinion is correct at all times, and I haven't come across a single instance where you admit to being incorrect - and no I haven't searched.

Let me stroke that ego of yours. Some of your posts are insightful, knowledgeable, and useful. If you could only respond in a similar way as this you might find you don't rub people up the wrong way.

Quote from scipy :

Imo, the only things to fix in LFS transmission modeling are:

1. Proper ignition cut. The way Scawen has currently coded it is wrong and slow, the ignition cut doesn't mean killing the ignition of the whole engine (and I'm pretty sure it does just that, although then turbo boost would be dependant only on throttle pedal position). In real life it's enough to cut the ignition on only 2-3 cylinders of the 6 or 8 cylinders in the engine, just enough to unload the transmission and enable the dogs to catch next gear. This is why XRR is still slower than FZR in accelerations, too much time lost with the current ignition cut (it'd be much faster to just give it the regular lift-type sequential, and yes, it would outweigh any disadvantages of losing some boost for a split second).

2. Having the option of autoclutch only on downshifts in cars with sequential gearboxes (ign. cut and regular), because that's how shifting is done in 98 % of the cases of dog-boxes in real life, making it a lot easier to blip the throttle (without chancing a miss-shift or riding the throttle as many idiots do).

3. Gearbox damage. Stresses on gear teeth and dog rings can be calculated pretty easily and a wear model could be introduced, this would be especially handy in endurance racing and it would force people to learn how to take care of their cars (and not skip blipping the throttle).

4. Clutch heating/wearing model re-done. Currently you can still flatshift in a 500 hp car during the whole 1-hour stint and not have your clutch temp go into the red area, and this is ok, racing clutches made of C/SiC don't really care about being slipped or their temperature, but what they do care about is being constantly stressed with impulses during flatshifts (and not only the clutch, but the whole drivetrain). This is another area where a vibration/stress model would be benefitial (especially for flatshifting in road cars).

5. As yaper said above, dog H boxes on racy slower cars (FWD GTR, FZR). Maybe even a DSG transmission for the never-coming Scirocco.

Your post back then infers that the whole drive train needs refinement, and gearbox inertia is one of those refinements which could be made. I thouroghly agree with those observations. There is currently no requirement to double clutch a dog (crash) gearbox with the current model, and similarly synchronous gearboxes do not need the finite time they do in real life to come up to speed where the gears rotations are drastically different. The ultra fast clutch that the exploit enables, bypasses any chance of a missed gear, and making autoclutch quicker is not the solution imo.

Can we please agree to disagree on some matters, and not get personal?

Quote from Scawen :

This would probably be possible somehow but it's not really easy so I won't do that in this version.

Thanks for considering it at least.

Quote :

This is a good idea and I just tried it, and strangely enough it does already work this way, without me doing anything!

Why it works is because it's a multiplayer editor, and someone else might be editing at the same time, the list of selected objects cannot be a list of object numbers as I'd do in a local editor (because object numbers can change when other objects are deleted). In fact autocross objects are so compact (8 bytes each) that the list of selected objects contains all the information needed to create those objects.

So by simply not clearing the list of objects when you load a new layout, the selected group is still beside your mouse pointer when the new layout has loaded. What you cannot do at that point is add to or remove from your selection because those operations require that the selected objects actually exist in the layout. But you can rotate or paste them.

I guessed you might be using an internal buffer hence my retraction. It's nice to know it isn't being cleared, so therefore makes it available to the next layout which that is also excellent.

If the contents of the buffer (array?) could be put onto the clipboard too, it means we could paste them into a text editor to create a library of layout feature snippets without having to meticulously recreate them manually. The system in its current form would suffice, so clipboard support is only an enhancement that can wait.

This is similar to, and may be a result of some changes that were made to fix the problem found here.

http://www.lfsforum.net/showthread.php?t=73656

It seems that a user who has not activated their wiki account in the database in the past has their user name dropped from the post method.

This only happens when the correct LFS Web credentials are input. A wrong password, invalid name etc are handled in the correct manner by displaying further prompts. The correct credentials throw the following error;

Quote :

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "User::addToDatabase". Database returned error "1062: Duplicate entry '' for key 'user_name' (213.40.20.1)".

So far, other users with activated accounts have responded saying they have no problems, however at least one other user who also has not activated their wiki account, has confirmed the problem exists for them with the same error.

Mod note:
While this may look like a dup report, it has a different mechanism to the previously reported problem, and may be a result of the fixes that were made. Furthermore, this new report might get noticed as being new and not overlooked as noise in another thread. Please delete this as necessary. I have asked for the relevant posts to be merged with this one.

The last I'll say on the matter here I promise.
[Off Topic]

Quote from scipy :

Again.. you can still flatshift in nearly all road cars in LFS and keep the clutch below red temperatures. Didn't you watch any recent replay of a hotlap?

Gear change timing also changed.

I'm not sure if you are being deliberately obtuse, ill-mannered, or plain arrogant. I did a bit of searching of the forums, and found your name linked to other unsavoury practises, so no wonder you defend this behaviour.

Quote from Scawen :

Forgive me for being out of touch, but what exactly is the button clutch exploit? Please only reply if you really know exactly what it is, not a vague idea.

This thread from 2008 discusses the problem, and I'm sure it was discussed way back on RSC, but internet archive wasn't able to capture those pages.

http://www.lfsforum.net/showthread.php?t=45980

[/Off Topic]

Thanks for confirming that GAVD999. I suspect the lookup between the two databases (LFS web and LFS wiki) is broken. The user name for an inactivated wiki account is dropping through to a default value.

That looks like a fantastic set of changes, and I can't wait to play with them.

Quote from Scawen :

Autocross editor :

All autocross objects are now available at all tracks
Multiple object selection - press CTRL and click object button
Selection can be deleted, copied (O), moved (M), rotated (, / .)

Just a quick question;
Will multiple object selection have clipboard support?

I'm thinking that some layout features could be copied between two instances of LFS in editor mode using this feature.

Edit:
Actually no. I just thought that through, is probably a big ask, so please treat it as misplaced feature request.

Last edited by Squelch, Fri, 3 Jun 2011 16:52. Reason : Changed view

The Autosport article is good but not entirely neutral. It makes the assumption that Hamilton "booted" Maldonado off, where many others have questioned whether it was indeed a racing incident. To use the same language as the article, the pass attempt on Massa was reckless, but Massa's attempted pass/block was plain dangerous.

I'm split on the outcomes. The Massa incident was Massa driving dangerously, Hamilton was reckless in continuing the attempt. The Malonado incident was a case of inexperience on Maldonados part, and over optimism on Maldonado making the right call on Hamiltons part, and therefore a racing incident.

If these incidents are taken in the context of what has already happened this season. Maldonado is in his rookie year, so should be cut a little slack. Hamilton has already pushed the boundaries several times and needs to keep his nose clean. Massa is desperately trying to justify his seat at Ferrari, and is trying so hard to the point of being a liability.

Ok thanks.

My tests have been made on xp32 to win7 x64 and a variety of browsers.

It seems the post method is completely ignoring or dropping the user name.

Quote from Whiskey :

I logged in without problems

Could you try again to see if it's working now for you too?

PS: Firefox 4 here

No luck, same error even with a hard page refresh

The strange bit is the user name field not being right. Have you logged on to the Wiki before whiskey?

Hi,
I just tried to log onto the Wiki and got the same database error.

Quote :

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "User::addToDatabase". Database returned error "1062: Duplicate entry '' for key 'user_name' (213.40.20.1)".

I'm actually entering my user name, but it doesn't seem to be posted.

Edit: Upper/Lower case makes no difference. First time login, therefore no cookies. Firefox 5.0 beta. Scripts enabled.

Edit2: Google Chrome, IE, and Firefox 4 all return exactly the same error.

Last edited by Squelch, Fri, 3 Jun 2011 11:45. Reason : Added more info - Edit2

Agreed, and my apologies to all for running off topic.