-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Botcpp Work #26
Comments
Do you really need to call new though? That would surprise me.
One interesting fact is that even if we have the .so and the symbols in
place, the builtin/lua bot seems to take precedence.
This is why i was wondering if we somehow need to register that we are
taking over conttrol
…On Fri, Dec 21, 2018, 21:56 Nostrademous ***@***.*** wrote:
This Issue/Post is mostly for tracking things tried. Below compiles and
doesn't crash, but doesn't take an action.
What I put in my Act()
extern "C" void Act(int team_id, CMsgBotWorldState_Actions * actions_pb) {
// Act seems to be called practically _exactly_ after Observe is called.
// Since it is called once per team, all team-decisions need to be made here. That means
// that we need to communicate all actions. Probably that means we need to return the actions
// protobuf somehow. I think returning the protobuffer itself, from this function makes
// the most sense.
// This call is fully blocking the entire game, so possible they are indeed waiting for a
// synchronous return.
cout << "Act\t" << (void*)actions_pb << endl;
//if (game_state == 4 or game_state == 5) {
if (actions_pb) {
//CMsgBotWorldState_Actions * actions_pb = new CMsgBotWorldState_Actions();
actions_pb = new CMsgBotWorldState_Actions();
mtl_pb = new CMsgBotWorldState_Action_MoveToLocation();
loc_pb = new CMsgBotWorldState_Vector();
loc_pb->set_x(0.0);
loc_pb->set_y(0.0);
loc_pb->set_z(0.0);
mtl_pb->set_allocated_location(loc_pb);
mtl_pb->add_units(test_id);
actions_pb->set_dota_time(dtime + 0.1);
actions_pb->set_extradata("EXTRA");
CMsgBotWorldState_Action * action_pb = actions_pb->add_actions();
action_pb->set_actiontype(CMsgBotWorldState_Action_Type_DOTA_UNIT_ORDER_MOVE_TO_POSITION);
action_pb->set_player(4);
action_pb->set_actionid(0);
action_pb->set_allocated_movetolocation(mtl_pb);
CMsgBotWorldState_Actions_OceanAnnotation * oa_pb = new CMsgBotWorldState_Actions_OceanAnnotation();
CMsgBotWorldState_Actions_OceanAnnotation_Hero * hero_pb = new CMsgBotWorldState_Actions_OceanAnnotation_Hero();
hero_pb->set_playerid(4);
oa_pb->add_heroes();
actions_pb->set_allocated_oceanannotation(oa_pb);
std::string s;
google::protobuf::TextFormat::PrintToString(*actions_pb, &s);
cout << "Our Message:\n" << s << endl;
}
return;
}
What I see in dotaservice:
dota_time: 43.8411026
actions {
actionType: DOTA_UNIT_ORDER_MOVE_TO_POSITION
player: 4
actionID: 0
moveToLocation {
units: 5
location {
x: 0
y: 0
z: 0
}
}
}
extraData: "EXTRA"
oceanAnnotation {
heroes {
}
}
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#26>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHXSRB2rePi6ntjWHZKNkT3rYVWd3HQHks5u7Ur7gaJpZM4ZfFPn>
.
|
No, I don't have to call new I guess and it should be the same. I am not sure what the pointer points too though. Could be an uninitialized pointer so better be safe. Honestly, I'm not sure it isn't passing a CMsgBotWorldState * instead of a _Actions. Perhaps even something else. Regarding the "interesting fact". Yeah, I noticed this as well as I noted it in the other issue when I posted the function sequence. Basically it does:
|
Also, a few things to consider - we are basing a lot of the _Action* stuff from a public repo where you found the protobuf definition, but it's the internet - no guarantee it's correct. Now, I did find all the structures as "strings" in the libservice library so they are probably correct, but worth considering what are facts versus assumptions. Also, the CMsgBotWorldState protobuf is not necessarily complete. The *_Actions should really be referenced somewhere and if you check the bottom the index values are not in complete sequence, index values of 9, 18 and 19 are missing. It is possible that 9 is a |
interesting observation indeed.
…On Sat, Dec 22, 2018 at 12:22 AM Nostrademous ***@***.***> wrote:
Also, a few things to consider - we are basing a lot of the _Action* stuff
from a public repo where you found the protobuf definition, but it's the
internet - no guarantee it's correct. Now, I did find all the structures as
"strings" in the libservice library so they are probably correct, but worth
considering what are facts versus assumptions.
Also, the CMsgBotWorldState protobuf is not necessarily complete. The
*_Actions should really be referenced somewhere and if you check the bottom
the index values are not in complete sequence, index values of 9, 18 and 19
are missing. It is possible that 9 is a repeated
.CMsgBotWorldState.Actions actions = 9;
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHXSRLtsKo7wVA8O6fHW8Wsar9IO2c_Vks5u7W0ggaJpZM4ZfFPn>
.
|
Also, another note. It looks like they are using google::protobuf::message_lite for protobufs 0x10000 is the max size of a serialized world state |
Running that code in a debugger shows that the decompiler is wrong. 0x10000 never exists, not sure why the debugger is confused. x86_64 is a bit annoying as args to functions are passed via registers and not on the stack like x86, so it's harder to guess what's valid and what's just a trashed/leftover register value. The only thing I have discovered thus far is that there is data at CMsgBotWorldState index 9 in the protobuf. Not sure what it is yet, but looks like a pointer to another structure. Regarding signatures at this point I'm pretty sure: Which begs the question of how do we set actions. |
Any updates from your two RE guys? |
nope :( |
One thing that i noticed was interesting (and annoying!) is that the worldstate is being send out as:
|
I don't believe you set the console parameter I remember Chris Carollo saying at one time that if two "players" (one dire, one radiant) did an action affecting the same target at the same time (meaning in the same frame) it would be randomly decided which one gets applied first rather than always giving preference to Radiant (i.e., a spell being cast on a target that is activating BKB at the same time). I don't see how his statement would be true if your above message always stood true (unless... actions are 'invoked' but not resolved until a step #5 sync step or something). |
Finally, I did dig some more in late December and found that there is an index 9 in the protobuf that has a value. It is a pointer to something (you can modify the protobuf to have a value here: example: And print it in |
This Issue/Post is mostly for tracking things tried. Below compiles and doesn't crash, but doesn't take an action.
What I put in my Act()
What I see in dotaservice:
The text was updated successfully, but these errors were encountered: