I'll look at pull requests on GitHub if they are per-feature (not one giant pull request for everything), but there's no way I'm going to manually merge by hand from a zip file. I doubt it has tons of bugs as you say since it has reliably stable performance from those who use it in EG. As for MySQL last I remember was it couldn't be added due to licensing issues. That would be useful to have though.
fatrolls - Tue Dec 09, 2014 9:55 pm
Post subject:
It had bugs for one the PacketClustering was not properly implemented didn't take into account packets already over 255 in size as the size byte could only represent 1 byte so the size sometimes cycled on itself and crashed (very long chat messages)..
It had bugs like connecting to ASSS and couldn't support those C plugins like baseduel/eliteduel/duel that were coded for PowerBot I believe. I added support for them
bugs all around to be honest I think the BigChunk !getfile !putfile were broken fixed those.
I guess it's just a very outdated version on github
cycad - Tue Dec 09, 2014 11:30 pm
Post subject:
ASSS compatibility is a non-goal for opencore, so I'm not at all surprised about incompatibilities there. That's because ASSS was designed considering what Continum will accept whereas opencore was designed considering what subgame will produce, and those aren't the same.
That being said clustering shouldn't crash so I looked over the cluster parsing code (phand.cpp:230) and don't see anything wrong there?
Your're right those bots you mentioned were for PowerBot which is a different core so those wouldn't work with opencore without modification. That's not a bug although it is cool you added support for those PowerBot plugins to opencore.
What's on GitHub is .19pr1 (prerelease 1) so it has mid development, non-functional features and file transfers are one of them. .19 did eventually come around but the source was lost when the VPS I did dev on crashed, and I realized I didn't care enough to rewrite what was gone. This was in 2007 when I abandoned the project.
I can't post more detail or look at code since I'm on travel using an iPad and this post has taken like 2 hours. Maybe next week if I don't get RSI from using this thing.
fatrolls - Thu Dec 11, 2014 3:26 pm
Post subject:
What I meant was
https://github.com/cycad/opencore/blob/master/opencore.cpp
at line 1032
and how its used at 1110 & 1112
you can see the flaws there.
look at this line:
&buf[offset], "AZ", p->len, p->data, p->len);
|
You do know that the packet length can possibly exceed a byte (255) and overflow into a small value making the packet completely de-synchronize. Have to avoid clustering packets if they are over 255 in size.
I know those were stolen from TWCore and TWCore has the same flaw I reported they dont seem to care about fixing it the correct way but quickfixed it by limiting chat messages to 243 characters even though 250 is allowed by continuum.
cycad - Thu Dec 11, 2014 10:07 pm
Post subject:
It's not wrong and neither is TWCore. It's the format that subgame accepts so it's a limitation of the protocol, so guess what -- nobody is stealing from anybody; both groups have correctly implemented packet generation. I'm not sure what you're trying to accomplish with an asinine accusation like that about stealing code.
The code you are referring to is a non-exported function so it doesn't do bounds checking. You can't just call into it with bogus data and expect it to work. Exported functions that do eventually make that call limit the message size accordingly to prevent the non-issue you've described.
This thread has really turned counterproductive so I don't think I'll be responding further unless there's something relevant to current dev or subgame reversing that we can talk about.
fatrolls - Thu Dec 11, 2014 11:43 pm
Post subject:
You seem to be missing the point of what i'm trying to point out no idea why you are turning so aggressive, I read somewhere from your source code that you borrowed it from TWCore.
Why don't you just admit you what really happened someone poorly guessed how the packets worked in Subspace and everybody started following that standard
Packet clustering is used when many packets suppose to be sent at one time and could all fit in one packet which is under 255 bytes in size, other then that it should always just use reliable packets (ignoring core packets of course)
You can read any file like
https://github.com/cycad/opencore/blob/master/encrypt.cpp
it says it's ported over from TWCore so I assumed the clustering was as well.. as it's identical in TWCORE you're probably not as sharp as me haha but that's not a problem no need to be so ignorant about the whole deal I'm just trying to help out.
You seem to be forgetting how your bot worked the send_outgoing_packets is what flushes all packets. We both know you don't call the write_packet directly if you wish to send any raw packets they all first go through send_outgoing_packets
So if that function is used to send all the packets your bot generated, if you are sending out which could involve a chat packet which is over 255 in bytes in length therefore it shouldn't be processed as a cluster packet but it may (if two packets meet up together in the same loop which does happen)
That chat packet may in
n->queues->h_prio
or
n->queues->n_prio
both get processed by pull_packets function which will attempt to create a cluster for all packets, since the next function write_packet can only be used to send 1 packet at a time, so it tries to cram as much information into 1 packet as it can instead of sending multiple packets that are pending to be sent the same time. But that's the flaw overlooking each of the packets sizes first.
In your source you attempt to create a cluster packet if atleast 2 packets are on the list. So lets say the first packet is over 255 byte in size packet and the second is a normal maybe 16 byte packet
the pktl will be 2 for the cluster layout
MAX_PACKET = 512
MAX_PACKET - pktl = 510
Run this check
(p->len + ch_size <= len - offset)
with
(255 + 1 <= 510 - 0)
simplified its
(256 <= 510)
which will process the packet as a cluster even though it's not suppose to be a cluster.
I understand maybe the packets magically are all checked somewhere before they are even checked whether or not they can be clustered, but unfortunately both TWCore and your OpenCore doesn't have that check anywhere.
Yeah I fixed it pretty crappy but I fixed it.
Why do you think TWCore caps out messages to 243 letters and not the full 250 letters? if you check their source code
http://www.twcore.org/browser/trunk/twcore/src/twcore/core/net/GamePacketGenerator.java
as you can see on line 744 the chat packet composes a low priority packet
if you look what kind of packets they have at class from line 1537.
You'll see they have normalPackets and cappedPackets which both get processed by 1 pipe on line 1566 which is getNextPacket()
It also has the same limitation as your bot on the line 84 where if there is only 1 packet on list it's sent reliable yet if there is 2 packets on list it sends as clusteredpacket
what characterizes it a cluster packet just because there 2 packets on the list? (same way as your bot)
As you know reliable messages don't send a size byte to indicate how big a sub-packet inside it is.
Cluster packets are sent as reliable messages.
Reliable messages can also send packets such as big chat packets without clustering them in the first place
if it was implemented properly then you can send chat messages up to 250 characters long without any issues and I've fixed that in OpenCore, but in TWCore they said they would fix it but don't really care.
Why did TWCore pick the special number of 243 as maximum chat packet even though in continuum I can easily send a 249 chat length message no problem hehe.
Here is my explanation for that
Chat packet
bytearray.addByte( 0x06 ); // Type byte
bytearray.addByte( messageType );
bytearray.addByte( soundCode );
bytearray.addLittleEndianShort( userID );
bytearray.addByteArray( msg );
bytearray.addByte( 0x00 );
|
Reliable packet
outgoingPacket.addByte( 0x00 );
outgoingPacket.addByte( 0x03 );
outgoingPacket.addLittleEndianInt( m_nextOutboundAck );
outgoingPacket.addByteArray( message );
|
chat packet
1+1+1+2+X+1 = 6
reliable packet
1+1+4+X = 6
Now combine that where the bot crashes since it all passes through a clustering system
255-6-6 = 243
As you can see they try to force the chat packet to always fit into a cluster packet first of all reliable messages can't be clustered but I haven't really looked whats going on
So don't tell me bullshit as you can see it's the same flaw.
I know what I'm talking about I'm experienced at what I do, I actually make big money from reversing.