Dr Brain

Update: Set up my linux comp to run an ASSS server, and loaded the new modules onto it. Works: Loading and account creation Storing ?money command for both money and exp. /?grant Still left to test: /?give. ?grant's additions (like remote and local freq granting) /?grantexp (all targets) /?showmoney /?showexp /?money

Not gonna happen. Plain and simple.

I was thinking last night, and I realized that my caching scheme wont fix the bug it was implemented to fix. I think I'll ditch the scheme (as it only saves 1 query per quick login anyway) and use an online player check. If the same player name is found already online, copy his/her data to the new player's data. It's the simplest way to fix it. Siaon's method is way to complex and adds more problems that it fixes. Siaon's method also caches the ships, something that's impossible with the way my ships are per-arena.

I did some programming on the new new modules. About a month ago, I threw out what I had done up with siaon as totally unworkable and started again. Today I made some prototyping progress with it. Mostly just on hs_database. Created all the struct layouts, all the functions, filled in some of the simple functions. I put in a MySQL query in that should work, but it's still untested. I think I can take the money functions from my scrapped code and put it in these modules. That code is easily portable and I liked the way I had done it. I'd like to set up a test server on my linux computer and hook everything up for basic module testing. I've been periodicly compiling to remove all my syntax errors, but there may be logic errors building up during this, and I would like to clean them up first chance I get. My plan of attack is to complete the loading, unloading, and caching code. Then to add in money checking commands (or all the money commands), then test it all. When I get that to work, I can move on to the item, category, and store loading code. Siaon had a good idea about tracking where money comes from that I think I will implement. Should be easy to tack on after the fact (Though it does involve a DB layout change), so I'll do it right after I test the loading/unloading code.

Lol, some people just don't get it. Yesterday or the day before, some person asked me when the next reset was. Immediatly, half the zone population FREAKS. "OMG! They reset stuff here?" "I'm quitting!" you get the idea. So I say not soon, because I had no plans to reset. I then get about 5 PMs asking when I'm going to reset. >.< I get spammed in public chat asking why I have to reset. Ok, even if I had an exact date that I knew I was going to reset on, I would tell *no one*. Not even staff. Can you imagine the flashbang -*BAD WORD*-? That being said, we reset about every 3-4 months. It's been about... 3 months or so. While I do indeed have no plans for a reset, one in about a month will probably happen.

Seems that every rectangle is represented by 8 ASCII chars. 2 for each of the 4 rectangle properties in this order: X Y W H It seems that some sort of 0-1024 -> a-Z conversion is made. First, the input number is split into two numbers from 0-31. Then the numbers are converted into a-z (0 to 25) or A-Z (26+). I don't recall perfectly the conversion boundarys, so it's best not to take this post as reference material. The encode routine is found in region.c in the ASSS src directory.

I asked for a second opinion on this from Catid, and we eventually came up with a better solution for this interdiction module. Store the last good position packet for a player, and if we ever get one that's outside the interdiction area, warp them back to their previous location. There would have to be a function to disable interdiction before they legally warp out (Gates, Engines, Attaches). Turns out that this is a much easier module to write that my first idea.

Oh, btw, It's spelled "Avatar". Not that I should complain about spelling, but I figure I should give you a heads up.

Over the course of the next three weeks, I have school stuff that I will be taking care of. My free time that I can put toward subspace will be limited. To what degree, I don't yet know. Just an FYI.

Dumb. Hate to burst your bubble, but you aren't mature. Well, I guess I don't really hate to, but whatever.

404

Age means something. It's closely tied to maturity, much as some will deny this. We will do our very best to hire mature and capable individuals. That rules you, t2d, right out. Sorry. It also instantly rules many others out. Charcoal included. While I no longer control the hiring process, I do know what I look for in a moderator. Someone who asks for staff is probably going to be turned down. Only exception is when we ask for applications. Quite frequently, we have someone in mind when we ask for the apps, and ask them anyway when they don't submit one. I assume that's how Neru handled Fat Cat.

Moved.

Cya NiKe! We'll all miss ya.

I've had this idea for a while, but I haven't really written it out. Basicly, it's to have slightly modified settings for each day of the week, and then standard sets on the weekends. Or maybe do it with some other schedule. I don't know exactly how I should modify the settings, but here's an example: Sunday: Standard Monday: No private freqs Tuesday: 5x powerball reward Wednesday: Standard Thursday: Greens Friday: 1 hit kill bombs Saturday: Mega Jackpot

Add a two goal structure. Make goal entraces for updated goal structure. Make mining of the goal harder or less rewarding. Remove the few doors left over in the bases. Remove the spikes at the edges of the chains in most of the bases. Move the hyperspace gate sector labels to a place where the gate animation wont effect them. Perhaps change them to red and throw it over the hyperspace clouds.

Yes, that's the catapult displacement bug. Usually it's displacing them forward and backward of the ship, rather than off to the side.

There is a portal + hypertunnel bug in beta that will have to be addressed. People can warp through solid walls with it. Somehow, I will have to generate an antiwarp field in the hypertunnels. I can create a fake player called "(Hyperspace)" or something. Put it on its own freq, and then make it start broadcasting antiwarp packets. Only a few small problems. First off is that there is way to much ground to cover with a stationary position. And a moving player will not get everyone at the same time. So, that means that every player will have to see him in a different location. My first idea was to just put the antiwarper underneath every player, sort of like the subgame *mirror. Picano pointed out the problem with this early on: Bullets and bombs will hit him if he's on a different freq (and antiwarp doesn't work on the same freq). The only solution I can see to this is to give it a list of locations around the map to antiwarp from. It will choose the closest for each player, and if they are in a certain region, antiwarp from there. With enough points, there should be no gaps. So that the antiwarp dude doesn't show up, I can make him a UFO. So, while sligtly more complicated than the flag mover and antiwarp disabler, this module also depends on me figuring out how to generate region files.

This module must be completed before I'm willing to put beta into public 0. Again, the major hold up is my lack of knowlege in creating region definition files. Once I know the file layout, I can make a small java program to convert the map into a region file. After I get the actual file, I can make the mover module in less than an hour. It's a very very easy module to make. About as complicated as the antiwarp disabler (AKA not complicated).

This seems to be a very easy module to do. Once I figure out how to make regions, that is. In fact, that seems to be the only problem. Grelminar said he'd be gone for two weeks three weeks ago. And of course, there's really no one else who understands it. Get the net interface, register a C2S_SERVERPOSITION packet, and then check for an antiwarpdisable region. If they're in it, send them an antiwarp disable packet. 100 lines of code max. Just have to figure out how to make a darn region out of the center area in beta.

I'm thinking of things to do with the goals. My first inclination is to remove goals from the arena all together, as balling doesn't really help flagging along. The best soloution is to create a powerball arena. It could be made very hyperspace-esque. An infantry Boom Ball X clone isn't impossible. Next best soloution is to have a two team powerball game in the public arena. Because beta will be going online before long, I will just talk about modifications for that map. Perhaps a goal structure with a dividing line in the center that seperates the two teams's goals? The two sides would be symetrical and the structure itself would have have to be put at the center line of the map for continuum to read the goal ownership properly. Goal entrances could be put at opposing sides of the center with the ball spawn equally spaced between them. A ball game would be nice. A steal points game is always fun. Maybe a small team reward per goal, and a big one per game. Only pub teams would be able to play. A private goal would only give the team reward and not effect the game score (unlike now).

This is a forum where I will post announcements and ideas. Replies are disabled for everyone except hyperspace staff. I'll add more "important info" here later.

And of course we have a hidden staff board now. So that's an extra 130 topics and 740 replies.

BANG!

I'll throw a wrench into the safe quickwinner's system today. I'll probably mess with some other settings while I'm at it.