Updated 2.0.11 beta to CodePlex.
- Renamed AutoXActionFlags to just ActionFlags
- REO and AXM now throw an exception when too many PLIDs or objects added
- AXM and REO now accept an IEnumerable with their sub-packet thingies
- Added ReplayOptions.RIPOPT_FULL_PHYS
- Changed AXM.Info from ICollection to IList
- Added PLID property to OutGaugeEventArgs
- Size field in BTN and MTC now updates to correct size after those packets are sent
- Fixed error with index in EncodingHelper.GetBytes
- Fixed crash when string was too long and was at the end of a packet
- Fixed bug in Tyres class
I must have gotten them mixed up, I've fixed it.
Hey all, my internet has been down since Thursday, so I've not been able to get on. It's fixed now so I'll look into these bugs! 
In terms of the MCI issue, as Morpha says sometimes you can get a MCI before all the NPL packets have been received, so your internal connection list won't be complete.
Edit: You simply need to check that the player for that CompCar exists in your connection list before processing it. This is nothing to do with InSim.NET, it's just an artefact of the way InSim works. InSim.NET does not track the state of LFS (except whether the socket is connected), so you need to handle these sorts of synchronisation issues in your own code.
This is what I normally do in my MCI handler.
What do you mean 'queued'? InSim.NET does not queue packets, it raises the packet event the second the packet is received. Any synchronisation issues like this need to be handled in your own code. As I say above, InSim.NET does not have any knowledge of the state of LFS.
In terms of the MCI issue, as Morpha says sometimes you can get a MCI before all the NPL packets have been received, so your internal connection list won't be complete.
Edit: You simply need to check that the player for that CompCar exists in your connection list before processing it. This is nothing to do with InSim.NET, it's just an artefact of the way InSim works. InSim.NET does not track the state of LFS (except whether the socket is connected), so you need to handle these sorts of synchronisation issues in your own code.
This is what I normally do in my MCI handler.
void MultiCarInfo(InSim insim, IS_MCI mci) {
foreach (var car in mci.Info) {
IS_NPL npl;
if (_players.TryGetValue(car.PLID, out npl)) {
// Deal with CompCar
}
}
}What do you mean 'queued'? InSim.NET does not queue packets, it raises the packet event the second the packet is received. Any synchronisation issues like this need to be handled in your own code. As I say above, InSim.NET does not have any knowledge of the state of LFS.
Last edited by DarkTimes, .
I was using IS_PLC to set the player cars and I realized that if you were storing the list of cars as an array of strings (or in a database table etc..), then you needed a way to convert that list into a CarFlags enum so it could be sent in the IS_PLC packet.
I had a snoop around the .NET Framework looking for something simple and I came up with this.
I had a snoop around the .NET Framework looking for something simple and I came up with this.
<?php
CarFlags GetCarsFlags(IEnumerable<string> cars) {
CarFlags flags = 0;
foreach (string car in cars) {
flags |= (CarFlags)Enum.Parse(typeof(CarFlags), car, true);
}
return flags;
}
// Use it like this.
CarFlags c = GetCarsFlags(new string[] { "UF1", "XFG", "FBM" });
// Or like...
insim.Send(new IS_PLC {
UCID = ucid,
Cars = GetCarFlags(new string[] { "UF1", "XFG", "FBM" } ),
});
?>
Last edited by DarkTimes, .
Pushed a new changeset onto CodePlex with a few fixes. I found a pretty big bug in the EncodingHelper class that was causing weird issues when sending packets with strings (especially if the string was at the end of the packet).
I also added an IEnumerable to the constructor of IS_AXM (and also IS_REO) which allows you to pass a collection of ObjectInfo objects (or bytes in REO's case) when you create the packet. This makes sending one a little neater (I think).
Hopefully it's all working OK.
I also added an IEnumerable to the constructor of IS_AXM (and also IS_REO) which allows you to pass a collection of ObjectInfo objects (or bytes in REO's case) when you create the packet. This makes sending one a little neater (I think).
<?php
using (InSim insim = new InSim()) {
insim.Initialize(new InSimSettings {
Host = "127.0.0.1",
Port = 29999,
Admin = String.Empty,
Flags = InSimFlags.ISF_AXM_EDIT,
});
// Create collection of objects.
ObjectInfo[] objects = {
new ObjectInfo {
Heading = 128,
Index = 20,
X = -1115,
Y = 2009,
Zchar = 24,
},
// Add more objects etc..
};
// Send AXM passing objects to constructor.
insim.Send(new IS_AXM(objects) {
PMOAction = ActionFlags.PMO_ADD_OBJECTS,
});
}
?>
Last edited by DarkTimes, .
It should be:
But really short is fine. It's this whole CLS compliance thing in .NET, bad to have a public property that's a signed byte, so I made it a short and it gets converted internally.
sbyte z = (sbyte)(MCI.Info[i].Z / 16384);But really short is fine. It's this whole CLS compliance thing in .NET, bad to have a public property that's a signed byte, so I made it a short and it gets converted internally.
Last edited by DarkTimes, .
Yeah, I had originally made the Info an ICollection, which does not allow indexing, which is why I changed it to an IList. The StackOverflow exception was because the IS_AXM constructor kept calling itself.
I pushed a new changeset onto CodePlex with a fix.
I pushed a new changeset onto CodePlex with a fix.
You cannot bind directly to a TINY_* (although I've thought about adding that before), you need to bind an IS_TINY and then check the SubT.
Yes, InSimError is raised when any exceptions occur on the packet received thread. You don't need to wrap everything in try/catch blocks.
insim.Bind<IS_TINY>(TinyReceived);
void TinyReceived(InSim insim, IS_TINY tiny) {
if (tiny.SubT == TinyType.TINY_AXC) {
// AXC received.
}
}Yes, InSimError is raised when any exceptions occur on the packet received thread. You don't need to wrap everything in try/catch blocks.
OK, I started looking into it and realized I'd made a bunch of mistakes with sending the AXM packet, so I fixed them and pushed version 2.0.10 out to CodePlex.
In terms of sending an AXM packet, here is an example of how to do that. This places a red cone on a the start/finish line at Blackwood GP.
In terms of sending an AXM packet, here is an example of how to do that. This places a red cone on a the start/finish line at Blackwood GP.
<?php
using (InSim insim = new InSim()) {
// Initialize InSim with AXM_EDIT flag.
insim.Initialize(new InSimSettings {
Host = "127.0.0.1",
Port = 29999,
Admin = String.Empty,
Flags = InSimFlags.ISF_AXM_EDIT,
});
// Create AXM packet.
IS_AXM axm = new IS_AXM {
PMOAction = AutoXActionFlags.PMO_ADD_OBJECTS
};
// Add object.
axm.Info.Add(new ObjectInfo {
Heading = 128,
Index = 20,
X = -1115,
Y = 2009,
Zchar = 24,
});
// Send packet to LFS.
insim.Send(axm);
Console.ReadKey(true);
}
?>
Last edited by DarkTimes, .
Meh, that's fair. I guess no library has it completely solved, so I retract that. Was a time a while back when no InSim library handled strings correctly, but now we have pyinsim and InSim.NET which do 'good enough' conversions. Frankly I think 'good enough' is acceptable.
If I understand you correctly, then InSim.NET does this (except for colors admittedly), but that's only because all strings are converted to and from unicode when receiving and sending packets. InSim.NET does not give you access to the bytes, you just treat all strings as unicode and the conversion is done behind your back.
Edit: for me a more pressing issue is to figure out a fast way to determine how many bytes a unicode string will be once converted to a LFS string, without actually doing the conversion. This would allow me to do some useful optimisations in InSim.NET.
Last edited by DarkTimes, .
Question is would the time needed to convert LFS to unicode be better spent working on something else, like better physics or more content? Sadly the answer is yes. It would be great if LFS natively used UTF-8, but I don't think it's worth it now, plus there are libraries available which have solved the problem.
The most straight-forward way is to create your own connection class that you store instead. This would be a very simple one.
class Connection {
// NCN fields.
public byte UCID;
public string UName;
// Etc..
// Custom fields.
public bool IsOfficer;
}
Dictionary<byte, Connection> _connections = new Dictionary<byte, Connection>();
void OnConnectionJoin(InSim insim, IS_NCN ncn) {
// Add to dictionary...
_connections.Add(ncn.UCID, new Connection {
UCID = ncn.UCID,
UName = ncn.UName,
IsOfficer = false,
});
}
Check out the forecast for today, showers look likely.
http://news.bbc.co.uk/weather/forecast/5017
Edit: seems it's not possible to link to a day forecast directly, click on Sunday.
http://news.bbc.co.uk/weather/forecast/5017
Edit: seems it's not possible to link to a day forecast directly, click on Sunday.
Last edited by DarkTimes, .
Uploaded version 2.0.9 beta, what has stuff for 0.6A1 in it. It's a beta, I've tested it, but it will likely have some oddities.
I'll try and release an updated InSim.NET tomorrow. I've added all the updates but I need to test them.
Last edited by DarkTimes, .
If I understand you 'program' it by driving around and recording your inputs. A solution then would be to use the new add/remove objects packet in the next LFS version to randomly change the track layout in subtle ways. You could have a bunch of pre-designed layouts and randomly switch them every so often. That would mess them up quite a bit, and you could detect cars that frequently hit layout objects and make them, I dunno, do a captcha to prove they're human or something.
Last edited by DarkTimes, .
You need to store the connection list that is sent by the game and then you can pull information out of that when you need it. Have a look at the 'managing_players.py' script in the examples folder.
Last edited by DarkTimes, .
Gah, sorry, but this is a pet hate of mine. This function...
bool carAtCoords(int i)
{
if (MCI.Info[i].X == X_POSITION && MCI.Info[i].Y == Y_POSITION)
return true;
else
return false;
}should really be...
bool carAtCoords(int i)
{
return MCI.Info[i].X == X_POSITION && MCI.Info[i].Y == Y_POSITION;
}and
bool carIsStopped(int i)
{
int currentX = MCI.Info[i].X;
int currentY = MCI.Info[i].Y;
if (currentX == prevX && currentY == prevY)
return true;
else
return false;
}should be
bool carIsStopped(int i)
{
int currentX = MCI.Info[i].X;
int currentY = MCI.Info[i].Y;
return currentX == prevX && currentY == prevY;
}I know that MadCatX probably already knows this, but I always see stuff like this and it deeply annoys me. The result of an expression can be passed around just like any other value. You don't need to explicitly return true and false, the result of the expression is a boolean anyway.
Anyway code-rant over.
You make a very good point about tooling. The reason I code for Windows is because Microsoft has the best tooling of any platform vendor. A long time ago Microsoft realized that the key to Windows success was to have as many third party apps as possible, so they have sunk an extraordinary amount of cash into developing their tools support. Microsoft get a lot of stick, often deservedly so, but the two main teams, Windows and DevDiv (developer division), have been churning out brilliant software for over twenty years. Apple may lead the way in terms of UI, but Microsoft are the best when it comes to developer support. Ironically Apple's support for developers is completely zero. It sucks ass. Really, really sucks ass. I get accused sometimes of being an MS fanboy, but I'm really not, I'm just a fan of DevDiv.
Last edited by DarkTimes, .
What!? Reread your original post, you have not told us what the hell it is you're looking for. All these people are trying to help you and you're calling them "stupid" and "idiots". Please try and imagine what it's like to read your posts from someone else's point of view, because they make absolutely no sense whatsoever and you come across like an imbecile.
Sounds like a scope issue, is there a variable named time somewhere? It sounds like you're redefining the variable time to be an int.
Like this:
Like this:
import time
# Redefine time to be an int
time = 10
# AttributeError: 'int' object has no attribute 'time'
print time.time()
Last edited by DarkTimes, .
Um, sorry to be pedantic, but .NET isn't a language, it's a platform on which languages are built. From the top of my head .NET includes C#, C++, VB, F#, Python, Ruby, plus other sub-languages such as XAML and its ilk. Of course that's only the surface, as it also includes MSIL, an awesome generational mark-and-sweep garbage collector, a JIT-compiler, as well as a hundred other esoteric technologies. Asking someone to vote on .NET in this poll is like asking someone to vote on Linux.
Anyway despite the above I'll always vote for Python, as it's easily the best programming language ever, and never ceases to be an utter joy to work with.
Anyway despite the above I'll always vote for Python, as it's easily the best programming language ever, and never ceases to be an utter joy to work with.
Last edited by DarkTimes, .
Just for information, here is what I thought while reading your post.
So you haven't started yet and may not have any idea what you actually want.
Again sounds like you don't know what you actually want. Also you're making it sound like I'd be lucky to be selected, whereas it's really the other way round. Ideas are easy, programming is difficult.
Oh dear, you're offering to pay someone, always a bad sign. If your idea was really that cool or original (I mean it's so awesome you can't talk about it yet, right?) then a programmer would be willing to work on it for free. Most programmers would forgo payment for the chance to work on something fun and new.
Again you're acting like a programmer would be lucky to work with you, whereas actually it's the other way round. Ideas are simple to come up with, I have ten ideas before breakfast, but people with the skills needed to realize those ideas, well, those guys are considerably rarer and harder to find.
So basically, nothing in your original post made me want to help you, in fact several thing sent off warning lights in my head. You need to appeal to the programmer within, you need to come up with something cool and original. Many, many talented programmers spend a lot of time working on LFS for free, you need to ask yourself why they do this, and then come up with something that tickles their interest. If you had an idea I really believed in, I'd build it for you for free and I'd be perfectly happy.
So you haven't started yet and may not have any idea what you actually want.
Again sounds like you don't know what you actually want. Also you're making it sound like I'd be lucky to be selected, whereas it's really the other way round. Ideas are easy, programming is difficult.
Oh dear, you're offering to pay someone, always a bad sign. If your idea was really that cool or original (I mean it's so awesome you can't talk about it yet, right?) then a programmer would be willing to work on it for free. Most programmers would forgo payment for the chance to work on something fun and new.
Again you're acting like a programmer would be lucky to work with you, whereas actually it's the other way round. Ideas are simple to come up with, I have ten ideas before breakfast, but people with the skills needed to realize those ideas, well, those guys are considerably rarer and harder to find.
So basically, nothing in your original post made me want to help you, in fact several thing sent off warning lights in my head. You need to appeal to the programmer within, you need to come up with something cool and original. Many, many talented programmers spend a lot of time working on LFS for free, you need to ask yourself why they do this, and then come up with something that tickles their interest. If you had an idea I really believed in, I'd build it for you for free and I'd be perfectly happy.
Last edited by DarkTimes, .
FGED GREDG RDFGDR GSFDG