Have you considered cutting out the financial system completely, and switching over to a shadow economy based on user donations? This way, it is impossible to be sued.

_________________

I have considered it, I've considered putting up a project on patreon. but the chans really put me off that, you know "will of the fuckheads" and all, and the fuckheads have spoken and said patreon links are cancer.

I could take donations directly to my paypal, but I don't quite like paypal any more after thier recent nazi shenanigans with north carolina.

_________________

Link

_________________

lol now that's the way to start your morning.

today I will be without net at work as I will take my other computer, this one has a broken left mouse button and all my files for dev stuff are on the other one.

gonna try and make an offline chat (I'd make it online but I'd need net for that)

_________________

Is this the thread about that roommate that scratched your good cookware but then we found out you just had poor eyesight and were wrong but nobody cared and we all just went on a tirade about how he didn't deserve to keep his bones and how we needed to harvest his organs/bones for orphans which was just crude innuendo about tires?

Look, I have heartburn and heartache and blue hair dye under my fingernails which I trimmed with a box cutter before giving up on going to a party where I probably would have turned down casual sex with some girl barely old enough to drink because I'm a stupid fuck that still believes in romance despite all the evidence and life-lessons to the contrary and a coworker's house warming party is the wrong place.

nah, this thread is about me making an MMO video-game. the verysame game I talked to you about server hosting for when I finish it.

_________________

Oh, yeah, cool. Why not host the source code on one of those collaborative sites like github or whatever where we all download free software for shit like downloading pixiv galleries and boorus of porn?

I'll be working on something like that soon enough, myself, not the MMO, though, that's your slice of cake.

I think it'll end up on there eventually.

I'll be releasing it with a really relaxed license and simple usury policy.

pretty much it's free to use it for anything except if it violates or encroaches on the intellectual properties of something else already known to be in dev or existence. this being under two articles 1: that you don't claim ownership of or take credit for the original files or any edits there of. and 2: if your game is commercial you must pay me $1 per paying player per year.

thats why it's code named project bane, because it will be the bane of the modern MMO market what with everyone making cheap knock-offs and parody versions of all the cheesy lame-o MMOs out there and mass releases of MMOs and games just like when flash started getting popular and we raped the internet.

this is my goal.

progress:

mouse script 2.0 cumpleated. it is superior in all ways to the original mouse script I was using and gets rid of a large array of bugs.

Chat Test: Offline chat is a partial success. anything typed into the textbox is saved to an external file then loaded from that file into a new text object. I need to stop that object from dispearing when a new message is posted so I can move it with the scroll bar that I need to program, and I need to make the text box clear itself after use (I know how to do this).

after that, I need to make the shit online and put in basic user name instancing, cause we need to know who the fuck said wat. To make it online I merely need to make a chat server that sorts all the messages and routes them to whoever is in that proximity etc. then instead of saving messages directly to a file I will send them over the net to the server and back again, on retrieval the text object will spawn and load the text from the message. simple shite really.

once that shit is done who knows what I'll do.

_________________

so I'm banned from a forum where one of my threads is, https://www.cohtitan.com/forum/index.php?topic=9895.100

As you can see a question has come up and been answered correctly, but I have not given any confirmation.

I would like to reply "yes it's solo, but I'm happy to accept helpers as and when they want to help, I'm willing to give basic tutorials and test files for reference as well so people can see what I'm working with that I could use help on at that particular moment. I am unable to reply in person as I am banned from titan (what looks like permanently), but the project continues in several locations such as http://blenderartists.org/forum/showthr ... ost3043584"

any help in transferring that message over tot here would be appreciated.

_________________

I'm gonna plop this here because; because.

because linear algrebra is fucking retarded and treats something simple like a single number angle as a vector based rotation matrix, and all game software works off of linear algebra;

a simple bounce script is relatively hard to accomplish unless you have an equation or algorithm to use to do the math for you rather than fucking around trying to find the angle then do the math then convert the angle to a rotation matrix. yeah, "no".

So a simple thing; angle in = angle out, is what we are looking for. to get that the algorithm is;

rotation of the face of the thing the object is going to hit +(the difference between the angle the object is traveling and the angle of the face of the object it will hit) = out angle

so if the angle of a wall is 90 degrees and the angle our object is traveling is 0 degrees it will be 90+90= 180 (it will fire back where it came from) where as if the angle of the wall is 90 degrees and the angle the object is traveling is 10 degrees it will be 90+(10 - 90=-80)= 90--80=170 which is exactly the original object's angle in the other direction.

_________________

Well update: the chat is partially functional offline, a message typed will be sent out of the game and read from the exterior source then plopped into a message in the chat window. I'm working on message auto spacing and a scrolling bar which is partially functional as well, it's coming along nicely.

_________________

Lo and behold, I returneth from the veil of avalon. the veil is a place of great trials.

I had started another side project meant to test my abilities thus far, at first I ran into terrible problems because I realized that most games have some sort of UI (User Instancing), even a simple game will have some form of UI to handle when two or more somethings accidentally one something at the same exact time.

if that makes sense to you, then you're good to go.

however that's not to say that games cannot be made without UI, Zelda for example has no UI on any objects, you either intract with it or you don't because someone else already interacted with it and it's in 'hit and untouchable' mode, typically the first object to hit gets the hit. but that system sux octorocks because it means one attacker is denied their attack. this is not viable in most MMO utilizations. simply put you might have 100 people spamming attacks on one giant boss. that and for a chat system, a player might be receiving 800 different chat messages simultaneously (from system messages, to battle outcomes and rewards, zone messages and player spawned messages).

so for most games there needs to be some form of UI.

yeah? well UI is a bitch when trying to do it entirely in code. why? because there are 2 types of UI:

Basic UI: in basic UI, objects are told to wait their turn. Typically there are 60 turns in a second so this method is viable for online games. but what to do? how do you tell an object to wait? if you're doing it in code you're going to make it loop until something changed. but there in is the problem, looping too frequently will overload the recursion limit (a safety key put in by language devs so as not to allow you to crash your own computer!), so you're going to put in a sleep() to slow down the code so it doesn't overload so fast.

problem 1: sleep() will freeze your entire game until the wait period is over. Unless you put it in a thread.

problem 2: threading is dangerous to games and creates instability and bugs.

problem 3: once in a thread you need to import all your definitions again, and you can only use code which is for the language itself not the program you are working in. if your language is AS3 then you can't use any commands which are for flash objects, if your language is python you can't use any blender specific language.

that means the thread lacks a big part of user instancing in games: Communication.

how can the script know if a change happened in game if it can't access the game?

so you can't sleep the script. and you can't thread it.

Spoiler: show

most developers use a dictionary to solve the issue where users send their actions to a list/dictionary and the UI object reads them one at a time. however these games have random 'lost items' and attacks that are cast but ignored, lost messages that are never posted. yeah, you know the games I'm talking about (nigh all of the modern online games).

why? because it's a half ass fix that doesn't actually fix anything. the problem was that you might have multiple users sending messages to any given object at the exact same time, and that creates a conflict where only one user gets processed. By telling the users to all post their message in to one list or dictionary you are in effect just moving the conflict, instead of the object rejecting it; Only one user can write to the dictionary at a time.

only one user can write to any one object per frame.
only one user can write to any one object per frame.[period]
only one user can write to any one object per frame.[PERIOD]
only one user can write to any one object per frame.[PERIOD]
only one user can write to any one object per frame.[PERIOD]{it doesn't matter how you attempt to script it differently}
only one user can write to any one object per frame.PERIOD] ("['{nope, that, aint, going, to, work, moron}'}")+.mergedict("['{you, are, a, real, boner, head, aren't, you?}']")

merging dictionaries just means there were multiple dictionaries, if there was one dictionary per user then all you've done is moved the message conflict to the merger of the dictionaries. suddenly a whole dictionary or more is lost. and what does handling multiple resources into one resource take? UI.

congratufuckulations! now you've taken a simple UI and decided you need a UI to handle the UI, and the UI you've chosen just passes the conflict down to a different object.

and so that's when I crashed. I had a brain and ego crash and felt worthless. (as most online devs should feel according to their methods)

the fact is, in programming if something just got terribly complex; then you're doing it wrong. no exceptions.

if something gets so complex you have a meltdown when you realize that you've followed modern expert advice and are hypothetically right back where you started. then simplify that shit. start with small simple things and see how they can do the job.

in my case the main problem was that the script that needed to run until it saw a change; was not seeing the change even after the change had happened. because scripts run per frame, so they collect their frames' data and are ignorant to any instances created in later frames.

this meant that I could either thread and add things to a dictionary and pass the dictionary to the thread like a moron, or I could cause the code to exit itself back into the game logic and trigger the game logic to restart the script, where it checks to see if the change has happened and if not just goes back to the loop.

bingo. that was the solution, pages and pages of complexity solved by simply exiting the script and re-instancing on the next available frame to look for a change. no recursion limit, no threads, no sleep(), no dictionaries. that and my code is now much less than a page and as simple as fucking.

so how does that do UI?

Communication:

simple, each object does it's own UI, instead of a central server handling it all. a player makes a message (game, system, text or otherwise) and checks to see if the object it needs to send to is busy. If it is busy, exit, trigger self, recheck. if it's not busy notify it of your name exit, trigger self, loop till reply (because there's a chance you will not be first on the list) if no reply but object not in use it auto sends it's name again. the object everyone is waiting on pulls the first object off the list of senders and sends it's name back to it. that object is like "AWWW YEAH BITCH I'ms teh chosen one!" and says "hey bitch, my damage is OVAR 9000, FUCKING TAKE THAT SHIT YOU WHINY HO!" and the object is like "oh Fuck.. yeah.. I gotta take it.." *object kills itself* *object sends message to all objects* "I's d3d [OBJECTNAME] k!113d m3h, [OBJECTNAME] spwn j00r reward"

and so on and so forth. that is how UI should be handled. if the object is not defeated then it sets it's WAIT value to FALSE and gets names of the next users and repeats the process. and so on and so on.

that is basic UI

Advanced UI: Aww fuck yeah j00 hoe, you knows this shit was cumming.

Whats the difference between Basic UI and Advanced UI? Advanced UI compares all users messages during a set time or set number of frames and groups them one at a time while users during that time wait. it groups them by things like 'Attack casting time' (the length of the battle animation before it hits) compared to 'time received' lumping all the damage that will hit at the same time into one value and tell all those objects to begin their battle anims in order. then doing the same for any differently timed groups during that time frame then moving on to the next time frame's messages.

so the only difference is that messages are sorted and grouped by given constraints such as time.

master these 2 UI systems and you can do just about anything.

_________________

Simply mediate writes and queue them as needed. A mediator user accepts write commands and organizes them into a single write or write queue as needed to prevent conflicts and performs the writes on behalf of the users. The only tricky part is scripting the algorithm to determine which writes can be combined and which writes must be queued.

then the conflict comes when 2 objects simultaneously attempt to write to the mediator. The problem is still there it just moved to another object/user.

I talked about that in the spoiler section, it's why random items are lost when attempting to transfer them to something like say a shop, and why sometimes your attack doesn't hit anything but expires, or why sometimes rarely your message is not received by the game and you get no error.

it's rare because it depends on frames, there are 60 frames per second the chance that any two or more given players will make requests of the same object at the same 1/60th of a second seems rather absurd and obscure, but leave players at it for long enough and you'd be surprised.

I scripted the UI yesterday, it works but it's not looping enough, that's ok though because I can trigger it with more communication when the requested object is done handling a user it'll send a message to all objects "Next!" which will trigger the code again, because right now the code only loops 2 times then cuts off probably due to a logic brick and code timing conflict.

_________________

The mediator needs to have a queued input that's asynchronous to the frame rate of the rest of the thing.

I'm using the Source engine as an example here but here goes nothing.

The FPS of the program is about states of the database. The database can be anything, all programs can be logically reduced to manipulating bits in a database. Each frame the program attempts to sanity check the database; this is the purpose of frames. Impossible data or anything not passing the sanity check (even if it's not impossible) throw an error; error handling then decides how much of a problem that is. The mediator would need to be a thread on its own only being asked or only giving output once per frame. It would need to receive input on a buffer or otherwise spooled input. Think stdout or any string concatenation.

Source uses server and client FPS very differently. On the server side the FPS determines how many times per second the server solidifies the data into a state of the game. On the client side the FPS determines how many times the data in the client is used to calculate the geometry sent to the discrete graphics processor. It sounds like the problem you're having is basically that the game is using a blocking code that's not threaded and this code handles the data once per frame. I don't know the shape of your data but if the data you want to manipulate needs to be more multitasking friendly I suggest moving that data to a place where it can have manipulations queued using if_not_changed_since frame count/time stamp checks and on fail retry loops, or using a handler that performs this function and optionally combines manipulations that don't conflict using a lookup table or bitmap of allowed and compatible changes, queuing the rest as needed.