You know, I literally handed you a solution that works, and the first thing you did was to counter-propose an idea that requires modifying the client code, point out problems with the suggestion that don't exist, and then made a statement about blender that's irrelevant to Paragon Chat. Then decide the problem is too complicated to solve directly. I handed you a solution that works.
You are your own worst enemy. The reason why I'm so confident the approach I gave you will work is because its a trivial modification of how generalized boundary collision detection works in practically every three dimensional computer game ever written ever that contains continuous motion. You compute the path the object will take based on its velocity or motion vector within the interval, and determine if that vector intersects with a boundary surface. If it does, you hit it and you normally calculate the intersection and stop the object there. Its something I learned in the 1980s, and the technique shows up again and again in gaming, simulation, and basic computer graphics.
It might actually be faster to write it, than convince you that it works. I would rather you write it, because it sounds like something you're interested in. But if you keep overthinking the problem, you will never get beyond listing all the ways it won't work. Eventually, someone else will do it, and leave you in a position only to comment on how your solution would have been so much better. Which literally no one will care about.
Codewalker could have PMed me about this great idea to use XMPP to connect game clients, and we could have discussed all the ways that wouldn't have worked for years. It still doesn't execute powers. It still can't execute mission content. It can't emulate NPC AI. Its not as fast as the game was. Its a good thing Codewalker ran out of F-s to give about any of that, isn't it?
Write the software. After you see it run, or not run as the case may be, then improve it. Don't fall into the trap of constantly cheating yourself out of the experience you need to ever get remotely good at this. You do not miracle yourself into being good at this by thinking about it abstractly. First you get good at it, then you start thinking about it abstractly. After actually making things work first.
Write the software. Or don't. I sent a canoe, I sent a boat, and finally I sent a helicopter. You decide.
Note to mods: If I type "Codewalker doesn't give a $-t" the forum pancakes that. If I say "Codewalker ran out of f---s to give" it apparently passes that through. Is that because "$-t" is abused more, or because the forum software literally knows Codewalker ran out of F-s back in 2013?
I took your solution, and mulled it over, yes I know I'm my own worst enemy, I like to think out new and interesting ways of doing things, and if those ways all fail then I go the normal course. I know that's bad, means it's hard to learn from other people's research outcomes, because typically the research errors are not wide spread info.
your thing will work, I just want to see if anything else might work better suited to this condition of one second message intervals especially in the future for 5 second message intervals.
Blender; now that I know the message format, blender and python can send this easily, so, the bot I would make is to route player location info to my blender program, then mimic the PC client and send the outcomes through the network to said account. I work in blender, because it's already a 3D environment and has the freedom of a timer and custom collision rules..
Collisions, I was going to handle them in blender because though the location of the gates is known in PC, there is no inherent timer, I'd have to call that outside of the application. typically the timer and gate collision should be in the same program for easier communication.
I'm not talking about changing the client, I'm talking about using blender for everything and sending results back to the client.
Last method: blender's player cube will spawn trajectory lines (similar to calculating velocity and orientation) in fact the outcome is exactly the same, EXCEPT that it will spawn + and - trajectory lines at each message location interval. Bend Trigger Priority: if the player's cube is seen hitting a gate in order, trigger it for that player. if one forward trajectory line and one reverse trajectory line both Cross at a gate then the gate was hit. Add time error percent cones at the ends of each trajectory line, if those both collide with the gate assume collision was true.
Or just do it your way cause setting an object in motion at a certain velocity and orientation from the last message then jumping to the next spot and seeing if at any point the player crossed the gate is easier.
I'll do it your way first. I'll make the last method I mentioned here as well after, then see which one is better at dealing with time lagged location info. the winner works, no biases on my part.
I can make the blender program(s) in an afternoon (though probably not till after the 10th.) especially seeing as we know gate locations from paragon wiki (and if not, We have Icon, thankyou codewalker!). then.. I will.. have to use java to make a few loops of what-dos, it would be handy to know the official messages the CoX client needs to start the race and spawn a timer window, same for gate collision and same for the finish line and results window. I will store things in that format for easy reading.
as for now, back to work on school things for the deadlines.
