Author Topic: Coming Soon  (Read 209923 times)

Takinalis

  • Boss
  • ****
  • Posts: 107
Re: Coming Soon
« Reply #380 on: June 30, 2015, 02:28:05 AM »
Um... hello, skyscraper logic people.... is everything OK? Not all of us can fly... I code some, but it's more like fitness with sprint active, not really super speed or SJ or anything...
Valkyrie Blade - Virtue Server

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Coming Soon
« Reply #381 on: June 30, 2015, 02:39:04 AM »
In effect, Paragon Chat is a peer-to-peer distributed virtual environment, with XMPP as the network layer.  The network layer has a server, but the virtual environment has no server.

Potentially it's even more "Euraka-y" than that. After all, the protocol itself is designed to be decentralized, with people on different servers seamlessly communicating with each other...

While the first version mostly assumes that everybody is on a single server together, multi-server federation was definitely kept in mind during development and much of the framework takes it into account, even if the frontend for it isn't finished. If you connect to a server with s2s enabled, with the help of some slash commands, you already can add a global friend with a JID on another domain, join a global channel that is on a different server, or switch the default conference service that is used for the zone broadcast and metadata channels, letting you /mapmove to a zone that is hosted on a server other than your own.

Eventually I'd like to see that not be such a manual process. Ideally you could log on and see your friend on another server is online, then click on them (or be invited) and seamlessly transition into their reality without having to type a bunch of commands to do it. However those are ideas just floating around in my head, and there's a lot of work to do before we're ready to even begin moving in that direction.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Coming Soon
« Reply #382 on: June 30, 2015, 03:03:44 AM »
I have some plans for future versions to actually reduce the update frequency to the metadata channel, perhaps to 5 seconds at the most, while simultaneously implementing limited multicasting of more frequent updates to characters who are actually close to you, similar to how local chat works. Perhaps eventually shift toward a timecoded history stream to replay in between absolute updates, which is very similar to how the game itself achieves its extremely fluid motion even in laggy conditions.

That might actually require a plugin.

Although thinking about it a bit more, perhaps you could implement something purely client-side with voxel-based microzones.  You divide up Atlas into cubes a hundred feet on a side, and whatever cube you are standing in you subscribe to that subchannel - Atlas.32.12.1, say, and also every adjacent cube.  That way, no matter where in your cube you are, even if you are right at an edge, you are guaranteed to be subscribed to the correct subzones which contain action at least 100 feet away.  You then send rapid updates to those 27 subchannels, and infrequent updates to a global AtlasRoot channel.  Whenever you cross a block boundary, you announce that on the global channel so everyone else knows something interesting boundary-wise just happened, with hysteresis to prevent flapping on the boundary.

I'm not certain, but maybe nested roster groups could be used for backward compatibility, where by default clients would subscribe to all zones of a particular name pattern, like Atlas_XX_[blank] rather than just Atlas_XX (i.e. Atlas_23).  Then when microzones were deployed, older clients would subscribe to all of them, while modern clients would subscribe only to the most local ones.

Just thinking out loud: steal/discard/set_on_fire as desired.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Coming Soon
« Reply #383 on: June 30, 2015, 03:11:34 AM »
Potentially it's even more "Euraka-y" than that. After all, the protocol itself is designed to be decentralized, with people on different servers seamlessly communicating with each other...

While the first version mostly assumes that everybody is on a single server together, multi-server federation was definitely kept in mind during development and much of the framework takes it into account, even if the frontend for it isn't finished. If you connect to a server with s2s enabled, with the help of some slash commands, you already can add a global friend with a JID on another domain, join a global channel that is on a different server, or switch the default conference service that is used for the zone broadcast and metadata channels, letting you /mapmove to a zone that is hosted on a server other than your own.

Eventually I'd like to see that not be such a manual process. Ideally you could log on and see your friend on another server is online, then click on them (or be invited) and seamlessly transition into their reality without having to type a bunch of commands to do it. However those are ideas just floating around in my head, and there's a lot of work to do before we're ready to even begin moving in that direction.

When I wrote my "how to make a decentralized MMO no one could shut down" article on the official game forums, this idea of having local servers run a game, but federated to other servers you could transfer to like alternate reality shards was one of the core concepts of the design.  Although this is not the game, and there is not quite yet a built-in local server as such, it seems to be moseying in that general direction.  The notion that federated chat could form the underlying basis of the whole thing is really the quantum leap I needed to shown; it makes perfect sense in retrospect, but it didn't occur to me until actually presented.  Once presented, it seemed like one of those things so obvious you kick yourself for not realizing it sooner.

Nyx Nought Nothing

  • New Efforts # 11,000!
  • Elite Boss
  • *****
  • Posts: 796
  • Ha!
Re: Coming Soon
« Reply #384 on: June 30, 2015, 03:24:02 AM »
i've been contemplating The BDLPSWDKS Effect quite a bit more often than usual for the past week. For some reason.
Huh.
So far so good. Onward and upward!

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Coming Soon
« Reply #385 on: June 30, 2015, 04:31:15 AM »
You divide up Atlas into cubes a hundred feet on a side, and whatever cube you are standing in you subscribe to that subchannel - Atlas.32.12.1, say, and also every adjacent cube.

Joining an xmpp room is a fairly heavyweight operation involving receiving presence for everyone in that room, so I don't think it would be a good idea to try something like that (not to mention I shudder thinking about looking at the server admin page for something like that). Possibly you could create them as 'blind' rooms with presence disabled, so you'd have to have some other room to coordinate them.

The path I'm considering leverages the same tech we're using for local chat: XEP-0033, aka XMPP multicasting. That XEP allows you to specify multiple recipients for a direct message, so you can send it to an arbitrary group of people and the server will take care of the details. It even works efficiently across server boundaries -- servers that support it will coordinate with each other to only send the message once across the s2s link even if it's going to multiple recipients on that server.

The downside is that the JID of each recipient has to be included in the outgoing message stanza, which could add a lot of overhead in crowded areas. I'll need to run some tests and see how much compression can mitigate that. I suspect it would still be less overhead than frequently joining and leaving rooms though.

Interestingly, the whole microzone idea is very similar to a design I've been working on for another other project with more intensive requirements than just chatting. I came up with it as a way to simultaneously accomplish the goal of a seamless world where zones would not necessarily have to run on separate servers, but also where a single zone could have geographical areas running on different hardware to mitigate extreme load. Think RWZ with a mothership raid running on one server, while the vanguard base happily sails along on a different one. The only difference is I've been calling them "chunks". It's not exactly a new idea, but surprisingly doesn't seem to be implemented to the logical extreme that I think it could be taken.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Coming Soon
« Reply #386 on: June 30, 2015, 04:52:13 AM »
Interestingly, the whole microzone idea is very similar to a design I've been working on for another other project with more intensive requirements than just chatting.

It would be ridiculous overkill for just chatting, but when you said "metadata channel" I assumed you were talking about situations where you needed to determine and leverage locality to handle more game-y effects than just chatting.  Perhaps I misunderstand what the metadata channel is used for.

Fifth

  • Underling
  • *
  • Posts: 16
Re: Coming Soon
« Reply #387 on: June 30, 2015, 05:40:19 AM »
I feel ashamed to think that after the demise of CoH I've neglected to return to titan network. Sure every few weeks my soul would pine for Paragon and Rogue Isles but, I would merely pop up the old Icon and play with costumes...and listen to the CoH soundtrack. I decided to check on the old CoH sites after such a binge and find that Icon has been made better and is still being worked on "O_O omgomgomgomg" was all I could manage while waiting for the new installer and now theirs a mysterious banner here. What could it mean?

I love you guys! You work so hard.  I love everyone who is active here, who kept true to CoH even after all this time. This is why we had the best MMO community that ever was or will be <3

Now making Titan my homepage so I don't miss a thing o-o

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Coming Soon
« Reply #388 on: June 30, 2015, 05:54:34 AM »
It would be ridiculous overkill for just chatting, but when you said "metadata channel" I assumed you were talking about situations where you needed to determine and leverage locality to handle more game-y effects than just chatting.  Perhaps I misunderstand what the metadata channel is used for.

The metadata channel is just used for position data. Each zone gets two XMPP rooms, one named after the zone that is its broadcast chat, and the other that the position data, and potentially other stuff in the future, is sent over. The metadata channel is hidden from searches by default, and PC tries to turn off conversation logging on it if the server supports that, since no real conversations happen over it.

The main reason for the split is so that normal XMPP clients can join broadcast chat without having to get a ton of apparently empty messages they don't care about.

benkenobi

  • Underling
  • *
  • Posts: 13
  • Nōlī turbāre circulōs meōs!
Re: Coming Soon
« Reply #389 on: June 30, 2015, 06:57:00 AM »
The metadata channel is just used for position data. Each zone gets two XMPP rooms, one named after the zone that is its broadcast chat, and the other that the position data, and potentially other stuff in the future, is sent over. The metadata channel is hidden from searches by default, and PC tries to turn off conversation logging on it if the server supports that, since no real conversations happen over it.

The main reason for the split is so that normal XMPP clients can join broadcast chat without having to get a ton of apparently empty messages they don't care about.

Ah, the tried and true. #WoWAddons lol :)
# Quantum Mechanics
(rand(0..1)) ? True : False;

Fifth

  • Underling
  • *
  • Posts: 16
Re: Coming Soon
« Reply #390 on: June 30, 2015, 07:49:46 AM »
Codewalker and team.

I don't have words that can adequately convey how grateful I am for this. I know it isn't the game but it's closer than we have come in two years and it is a phenomenal technical achievement.

Thank you!
This is my thoughts exactly
We have the best community ever. I may not post much , but i read these forums everyday. Thank you Codewalker , and others for your hard work and dedication.
best mmo community ever indeed <3 every one is either an asshole or secretly working for Nemesis on the other MMOs >.>
I've got a few costumes I saved back when the game was alive, and a few I've done in ICON that I really liked.

But, yes, definitely time to play around and make some more!
yup I even remade some of my old ones even thought I have the originals saved :)


Anyway, all my old friends from when this game was live are MIA, anyone want to be my friend when SOON is live? :)

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Coming Soon
« Reply #391 on: June 30, 2015, 08:18:05 AM »
The metadata channel is just used for position data. Each zone gets two XMPP rooms, one named after the zone that is its broadcast chat, and the other that the position data, and potentially other stuff in the future, is sent over. The metadata channel is hidden from searches by default, and PC tries to turn off conversation logging on it if the server supports that, since no real conversations happen over it.

The main reason for the split is so that normal XMPP clients can join broadcast chat without having to get a ton of apparently empty messages they don't care about.

Logical.  Hopefully soon I'll be testing SleekXMPP; I really hope that library works.  I would hate to have to write my own.  Although the moment I realized that any bot you write has to either have preprogrammed pathing/motion or have to read the mapfiles and do geometry and collision calculations...


Joshex

  • [citation needed]
  • Elite Boss
  • *****
  • Posts: 1,027
    • my talk page
Re: Coming Soon
« Reply #392 on: June 30, 2015, 08:57:55 PM »
Joshex, I dislike Java almost as much as I dislike Ecmascript (javascript to mortals).  However, if the industry wants it, then as a professional, I have to learn it if I want to keep food on the table.  Sticking to one language just gets you one thing, unemployed.

yeah, the other option is one a lot of people can't afford to do and I'd never suggest it; be a starving artist. It's what I do,  fight the fads I don't like regardless the cost to me. cause eventually I'll develop something my way and it won't work with java and if I make it cool enough people will use it, and then... I will have no use for java applicants now will I? and if it starts a fad then... hehe.. mwahahahaha! lets see their wonderful java get out of that one. /em evil

Although the moment I realized that any bot you write has to either have preprogrammed pathing/motion or have to read the mapfiles and do geometry and collision calculations...



At least you didn't just bluescreen because you forgot your memory was near full and opened a youtube video on how to stretch a shrunken wool sweater.  lost some graphical work.

this is why I wanted to write a timer system in python and blender. Much easier if you already have a 3D environment built for games doing these operations.

again, if you take the character Location that XMPP is sending as scripture then you don't need collision geometry. but for a race, you need a crosschecking system and that means something more complicated, either as you say "using movement prediction" or logging [keypresses, order pressed, and time pressed for], for the whole duration of the one second message wait, then send this data as one message when allowed and the server and other players update based on it. by the time they are done updating one second has passed and the next movement datapack is received. No lag, no rubber banding. it does require a "not received" message saying what movement number is missing and for the player to send that info back just in case the net has a hiccup and then there might be some lag and a necessary slowdown/speed up of processing movement data to resync.

How exactly do you think Codewalker got a generic XMPP server, that knows nothing about City of Heroes, to send messages between City of Heroes clients that make the game clients see each others' activity?  XMPP is just XML wrappers around data.  There's nothing you can't send.

I'm willing to work with this set-up, but so far I'm getting conflicting messages from everyone here on one key topic, which makes me take what codewalker said in reply as the correct answer, codewalker said even if you send other data (battle, timer, race, gates ETC.) to the client as an XML stanza it's not built to handle those so it will just ignore them, and codewalker doesn't have time to make it able to handle them.

I even confirmed it several times after in my own comments saying things like "Injecting just 'any' CoX server messages into an XML stanza designed in XMPP's messaging message composition format would not work according to Codewalker."

there needs to be a java plug-in on the client to handle that operation by parsing the message and looking for CoX message headers that Codewalker has not already included code for, then route the info to the COX client. right now it would either dump it in chat or just ignore it all together, that is what I gathered from what has been said.

if it's not movement/location data, animation/emote data, or a chat message, there is no support for it at present. from what I gather costumes are updated from player to player through the CoX client natively as I seem to remember that not being a server function.

We have motion, ability to see one another all costumed and animated, and ability to chat (and an ability to click doors and use single target zone transport). anything else is not currently supported and it may be a long time before it is. unless you want to write a plugin.

If I sent (mind you I don't know what City of heroes Gate collision (c) messages looked like so I'm just using words there):

Code: [Select]
<message type="groupchat" to="test1@server.nice.try/Nomad"
from="novapraetoria_meta@conference.server.nice.try/Conan the Librarian">
<u xmlns="xx:u" c="finishline.geo, 1:22:10, first place"   m=""/>
</message>

Paragon chat would currently raise a flag where it wonders " 'c' ? what is 'c'? Error Globaltype 'c=' is not defined"

if I did:

Code: [Select]
<message type="groupchat" to="test1@server.nice.try/Nomad"
from="novapraetoria_meta@conference.server.nice.try/Conan the Librarian">
<u xmlns="xx:u" p=-4742.7 40 -240.8" v="0 -0.6 0" o="0 -1.77 0"   m="finsihline.geo, 1:22:10, first place"/>
</message>

it would process it as a message block and would trigger Codewalker's function which looks for CoX game keywords that he has specified, this list would be read in an instant and no loops would be followed because their triggers don't match, the final trigger Else: would trigger and send:

Conan the Librarian: finishline.geo, 1:22:10, first place

to the game chat window. now while the player has received their result, the results window has not been called and any subsequent race finish text has not flashed on screen and the message including the finishline object was included. this seems stupid to worry over, it's just a topical thing right? wrong. what if you want to see the whole results window with scores from others?

Conan the Librarian: Superhero Wan, 1:22:10, first place, Supergal, 1:22:11, second place....... etc.

now again a topical thing, there's no window. but this message might be truncated by the message limit, or might be on multiple lines, and if the list is long you could end up missing chat messages from people as they are bumped off by the results.

best to keep data like this where it belongs, in it's own window, or chat tab, that's fine too and probably could be done. but why not call the window for nostalgia's sake? it's like the difference of between 1: me saying I'll show you the lost city of gold and showing you a real lost city of gold somewhere in peru and 2: me saying I'll show you the lost city of gold and showing you the sentence "the lost city of gold" on a piece of paper. yes it's still 'the lost city of gold' but not quite what you were expecting.

what if it's a long race with all the gates? gate collision messages in chat? next gate = messages in chat?. what about the timer? would kinda be annoying to receive your time in the chat window as a message once a second till you finish or till it hits a max time reset.

now Codewalker does not have time to program more loops into Paragon chat to look for these keywords not on the client not on the server (it's not a priority). and obviously he's not gonna release it just yet and obviously he will probably never release the server except to key people. so the only other option is a plugin made and sent to him or a standalone which communicates with the server and a plugin for the client with a module and loop looking for the message type you wish to send and referencing what to do in the CoX client with that message data instead of just plopping it in chat.

besides this if I made a stand alone timer and gate server, I would also need a plugin to collect player location from the XMPP server and send it to my program, and a plugin to receive the timer info and gate collision info to route back to the player, then a plugin on ParagonChat to know what to do with it. It also sounds like this system actually doesn't send anything from server to player unless it's global info for everyone which poses the consideration that the timer and gate system would have to be on the player side where they calculate it themselves and send the results to the server. gosh oh lordy that would be abused.. SuccessfulTroll autoset to all recordable places with times of 00:00:00 through 00:00:10. plus it would need a plugin for the server to save this data.

ok head spinning, message end.

« Last Edit: June 30, 2015, 09:15:39 PM by Joshex »
There is always another way. But it might not work exactly like you may desire.

A wise old rabbit once told me "Never give-up!, Trust your instincts!" granted the advice at the time led me on a tripped-out voyage out of an asteroid belt, but hey it was more impressive than a bunch of rocks and space monkies.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Coming Soon
« Reply #393 on: June 30, 2015, 09:27:41 PM »
besides this if I made a stand alone timer and gate server, I would also need a plugin to collect player location from the XMPP server and send it to my program, and a plugin to receive the timer info and gate collision info to route back to the player, then a plugin on ParagonChat to know what to do with it.

Or, you could write a bot that just logged into the zone and sat there, watching all the players move around, since every player connected to the server gets position updates from everyone else via the XMPP server.  That's what the XMPP server is there to do: act as a broadcasting system that takes one player's position and chat messages and forwards them to everyone else (within the right zone and group and blah blah blah).  Then you figure out by hand where the starting line and finishing line are in map coordinates, and then whenever someone crosses the imaginary start line the bot says "Player X through the start gate" and whenever someone crosses the imaginary finish line the bot says "Player X through the finish line: time = TTTT."  The bot doesn't even need to move, figure out geometry, or do anything.  This is actually *easier* than making a bot that actually pretends to be a player.

Chances are, you'd need to do some calculations.  At time T, you'll be told that Player Alpha is at position X,Y,Z, and moving with velocity J,K,L.  At time T+1 you'll be told that Player Alpha is at position X',Y',Z' and moving with velocity J',K',L'.  If you draw a line from X,Y,Z to X',Y',Z' and that line intersects the starting plane of the race course, you detect that as a valid start.  You could also check the movement vectors to perform bounds and error checking: given that the velocity of the player during the interval of T/T+1 was between J,K,L and J',K',L', is the necessary velocity (X',Y',Z')-(X,Y,Z) within the reasonable bounds of [(J,K,L),(J',K',L')].

Quote
I'm willing to work with this set-up, but so far I'm getting conflicting messages from everyone here on one key topic, which makes me take what codewalker said in reply as the correct answer, codewalker said even if you send other data (battle, timer, race, gates ETC.) to the client as an XML stanza it's not built to handle those so it will just ignore them, and codewalker doesn't have time to make it able to handle them.

I even confirmed it several times after in my own comments saying things like "Injecting just 'any' CoX server messages into an XML stanza designed in XMPP's messaging message composition format would not work according to Codewalker."

there needs to be a java plug-in on the client to handle that operation by parsing the message and looking for CoX message headers that Codewalker has not already included code for, then route the info to the COX client. right now it would either dump it in chat or just ignore it all together, that is what I gathered from what has been said.

Not so much conflicting messages as the reasonable assumption that you're not likely to be able to do that faster than Codewalker, even if its your number one priority and its Codewalker's number 100 priority.  Sorry, but its the truth.  Prove me wrong and actually do it, and we'll all be wondering what took you so long.  I'm likely to be a hundred times faster than you at this, and I'm inclined to wait for Codewalker to do it.

Given that, what we're trying to tell you is that its better to try to get creative and innovative with what you have, than try to do things you're heavily underestimating the effort for and will likely give up on eventually.  As I point out above, there's lots you could do just with what you have, if you stop trying to swing for the fences and start practicing just getting on base.  You are throwing signals in all directions that you need to reduce your reach.  When you say things like "this is why I wanted to to write a timer system in python and blender. Much easier if you already have a 3D environment built for games doing these operations" people wonder if you know what exactly you're talking about.  I'm taking my timer code and sticking it right into my bot.  My bot has no idea what 3D graphics are, nor will it ever really need to know.  What it needs to know is where the ground is, so its not constantly floating in mid-air or chatting from under the pavement, and it sort of needs to know where the buildings are so it doesn't pass through them like a Scooby Doo ghost, although even that's strictly speaking optional.  A sky slope bot doesn't even need to know any of that in theory, because you could just find the correct places in Icon and /loc them, then hard code them into the bot.

Attempting what you're describing, I'm sorry to say I'd bet against you.  With a lot of money.  But actually making a bot that could do something with the ski slopes, your original idea itself, that might be something within your ability to accomplish, if you tackled the problem from the right direction.  You just need to simplify.  Get something done, rather than the perfect thing.  Refine from there.  I do that, everyone else that has commented does that, and Codewalker himself is doing that just to get Paragon Chat out to the people.  None of us swings for the fences like you seem to do.  Aim for something you can build on.  Aim to make a platform for better ideas.  Play the long game.

FloatingFatMan

  • An Offal
  • Elite Boss
  • *****
  • Posts: 1,178
  • Kheldian's Forever!
Re: Coming Soon
« Reply #394 on: June 30, 2015, 09:31:11 PM »
And never ever EVER lose sight of every decent programmers primary principle.

K.I.S.S.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Coming Soon
« Reply #395 on: June 30, 2015, 10:04:21 PM »
And never ever EVER lose sight of every decent programmers primary principle.

K.I.S.S.

Keyboard isn't so strong.

I kinda got upset with my logitech K350 a few months back.  It didn't end well.  For the K350.

FloatingFatMan

  • An Offal
  • Elite Boss
  • *****
  • Posts: 1,178
  • Kheldian's Forever!
Re: Coming Soon
« Reply #396 on: June 30, 2015, 10:12:42 PM »
Keyboard isn't so strong.

I kinda got upset with my logitech K350 a few months back.  It didn't end well.  For the K350.

Keep It Simple, Stupid! :p

One thing I learned years and years ago.  if it's taking you more than half a dozen lines of code to do something, you're probably doing it wrong.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Coming Soon
« Reply #397 on: June 30, 2015, 10:59:29 PM »
One thing I learned years and years ago.  if it's taking you more than half a dozen lines of code to do something, you're probably doing it wrong.

#include <stdio.h>
#include <stdlib.h>

main(int argc, char *argv[])
{
int loop;
for(loop=0;loop<52;loop++)


FloatingFatMan: Dammit, that's too long.  Start over, you worm.

#:: ::-| ::-| .-. :||-:: 0-| .-| ::||-| .:|-. :||
open(Q,$0);while(<Q>){if(/^#(.*)$/){for(split('-',$1)){$q=0;for(split){s/\|
/:.:/xg;s/:/../g;$Q=$_?length:$_;$q+=$q?$Q:$Q*20;}print chr($q);}}}print"\n";
#.: ::||-| .||-| :|||-| ::||-| ||-:: :|||-| .:|

FloatingFatMan: That's better.



(No, I did not write that evil, evil thing.  Credit Les Peters, apparently the Mephistoperles of perl).

Joshex

  • [citation needed]
  • Elite Boss
  • *****
  • Posts: 1,027
    • my talk page
Re: Coming Soon
« Reply #398 on: June 30, 2015, 11:52:11 PM »
Keep It Simple, Stupid! :p

One thing I learned years and years ago.  if it's taking you more than half a dozen lines of code to do something, you're probably doing it wrong.

or too dynamic, setting all definitions to variables and random number rolls so the game is in effect doing calculus in each operation and setting all names and other text data to input defined variables and finding ways to reference to those names that don't exist yet, yeah it's a headache, but then it's much more rewarding when it all ties together and works.

I do agree there is a certain length of code unique to each operation that defines if you did it right. my first python text-typing-box scripts were THE WRONG WAY. Wish it were as easy as in VB printscreen loc "" or color for the pixel, it's been so long since windows 3.1 when I first got a hold of it.

I got mah U key fixed after it was stuck for months and months. but in doing that the repair man fudged my power button, easy to turn on with a press at the right angle, hard to find that angle to hold it to turn off when I accidentally [something] and then bluescreen.

Or, you could write a bot that just logged into the zone and sat there, watching all the players move around, since every player connected to the server gets position updates from everyone else via the XMPP server.  That's what the XMPP server is there to do: act as a broadcasting system that takes one player's position and chat messages and forwards them to everyone else (within the right zone and group and blah blah blah).  Then you figure out by hand where the starting line and finishing line are in map coordinates, and then whenever someone crosses the imaginary start line the bot says "Player X through the start gate" and whenever someone crosses the imaginary finish line the bot says "Player X through the finish line: time = TTTT."  The bot doesn't even need to move, figure out geometry, or do anything.  This is actually *easier* than making a bot that actually pretends to be a player.

Chances are, you'd need to do some calculations.  At time T, you'll be told that Player Alpha is at position X,Y,Z, and moving with velocity J,K,L.  At time T+1 you'll be told that Player Alpha is at position X',Y',Z' and moving with velocity J',K',L'.  If you draw a line from X,Y,Z to X',Y',Z' and that line intersects the starting plane of the race course, you detect that as a valid start.  You could also check the movement vectors to perform bounds and error checking: given that the velocity of the player during the interval of T/T+1 was between J,K,L and J',K',L', is the necessary velocity (X',Y',Z')-(X,Y,Z) within the reasonable bounds of [(J,K,L),(J',K',L')].

Not so much conflicting messages as the reasonable assumption that you're not likely to be able to do that faster than Codewalker, even if its your number one priority and its Codewalker's number 100 priority.  Sorry, but its the truth.  Prove me wrong and actually do it, and we'll all be wondering what took you so long.  I'm likely to be a hundred times faster than you at this, and I'm inclined to wait for Codewalker to do it.

Given that, what we're trying to tell you is that its better to try to get creative and innovative with what you have, than try to do things you're heavily underestimating the effort for and will likely give up on eventually.  As I point out above, there's lots you could do just with what you have, if you stop trying to swing for the fences and start practicing just getting on base.  You are throwing signals in all directions that you need to reduce your reach.  When you say things like "this is why I wanted to to write a timer system in python and blender. Much easier if you already have a 3D environment built for games doing these operations" people wonder if you know what exactly you're talking about.  I'm taking my timer code and sticking it right into my bot.  My bot has no idea what 3D graphics are, nor will it ever really need to know.  What it needs to know is where the ground is, so its not constantly floating in mid-air or chatting from under the pavement, and it sort of needs to know where the buildings are so it doesn't pass through them like a Scooby Doo ghost, although even that's strictly speaking optional.  A sky slope bot doesn't even need to know any of that in theory, because you could just find the correct places in Icon and /loc them, then hard code them into the bot.

Attempting what you're describing, I'm sorry to say I'd bet against you.  With a lot of money.  But actually making a bot that could do something with the ski slopes, your original idea itself, that might be something within your ability to accomplish, if you tackled the problem from the right direction.  You just need to simplify.  Get something done, rather than the perfect thing.  Refine from there.  I do that, everyone else that has commented does that, and Codewalker himself is doing that just to get Paragon Chat out to the people.  None of us swings for the fences like you seem to do.  Aim for something you can build on.  Aim to make a platform for better ideas.  Play the long game.

I'll wait till it comes out, rather than actually going in and reworking all the server responses to client messages for CoX start-up, I just have to figure out how to get the values from a bot.

multiple ways to do trajectories at one second intervals, could rig a multipoint path to follow a character then when they touch a "start run" point drop one point per location message received (similar to Arcana's idea) then set the gates to be sensors which bool TRUE if the path touches them in the right order.  but then what if a player is really fast and the path at the next second misses one gate... would be handy to have all the location data the player did in between messages to draw a proper line. but without it... even velocity and orientation with location wont do the job perfectly but it's at least closer, but then I'd defintiely need geometry, setting a static or sensor object to move to a location or follow another object's motion is fine, just /NEVER/ under any circumstances make a non dynamic object have it's own motion or velocity! or it will fly away in an odd direction on startup. if it's not static, then it will fall with gravity, that's a sad fact of blender. then again the way around that is to make the motioned object Dynamic and parent it to a static empty so it can't fall, that may well be useful here to avoid map geometry.

might be better to actually do it a different way, get the player's starting loc (wait till you see "Begin your run"), put the start a short distance in front of the slop so people wont slide around while waiting. then after that simulate a perfect run at the player's velocity starting from the first point picked up, following a path to the 1 second point, if the next location message received puts the player within a controlled distance of that point assume they went through all the gates between there, return which gate is next and get the player's new loc and velocity offset the trajectory of the path by this amount and continue to the 2 second point at the player's new velocity ETC till finish.

meh even thats got too many flaws. must think out good set-up...
There is always another way. But it might not work exactly like you may desire.

A wise old rabbit once told me "Never give-up!, Trust your instincts!" granted the advice at the time led me on a tripped-out voyage out of an asteroid belt, but hey it was more impressive than a bunch of rocks and space monkies.

Takinalis

  • Boss
  • ****
  • Posts: 107
Re: Coming Soon
« Reply #399 on: July 01, 2015, 01:13:43 AM »
Just realized... we're still talking about the ski slope! Man, I really need to buy a hat! All this stuff keeps going over my head!  :o
Valkyrie Blade - Virtue Server