Bak

You could probably come up with a better way to store the map than a huge array though; even simple RLE compression would usually drastically reduce the size.

http://209.197.106.133/19580222/rock/beatl...ComesTheSun.mid

Here you go: http://wiki.minegoboom.com/index.php/Liste...Per_Player_Data Let me know if there's parts that need clarification.

Definately. I'll write up a tutorial soon (most likely tomorrow). The basic idea behind controls, such as ones that involve the keyboard is the controls module: /** * tell the Controls modules you want a function to be called when a certain control is pressed, * down is true iff we want the function to be called when the key is pressed down, if it’s false it will be * called iff the key combo is lifted up. * * call this function in your handler for the CB_CONTROLSLOADED callback * * @param keyString the keyString cooresponding to the event, as defined in the settings (like "repel") * @param funcToCall the function to call when the event occurs, down = true iff we're pressing the key combination */ void (*regControlEvent)(const char* controlString, void (*funcToCall)(bool down, const char* controlString)); now controlString here is specified in a conf file (along with the actual buttons that are needed to be pressed) as in conf/modules/Controls.h: ;; This section defines what controls map to what actions ;;; for keyboard controls, use SDLK_ constants minus the SLDK_ when using them [Controls] ;;; all of the key bindings in the section ;;; the rest of the section will be in the form of ;;; <name> = <binding> where <name> is one of the ones in this list and <binding> is a list of keys (the SDLK_ constants without the SDLK_ part) ;;; these can include + to use multiple keys to active this command, as in "repel = LSHIFT + LCTRL, RSHIFT + LCTRL" Names = menu_toggle, menu_quit, menu_fps, specUp, specDown, specLeft, specRight, specFast, toggleCursor, chat_toggle, chat_left, chat_right, chat_ignore_modifier, chat_send_message, moveForward, moveBackward, turnLeft, turnRight, repel, burst, decoy, thor, brick, rocket, portal, gun, bomb, mine, stealth, cloak, xradar, antiwarp, playerlist change view, playerlist up, playerlist down ; from SpecMode module ;;; move up while spectating specUp = UP ;;; move down while spectating specDown = DOWN ;;; move left while spectating specLeft = LEFT ;;; move right while spectating specRight = RIGHT ;;; move quickly modifier for spectating, to be used in conjunction with specUp, specDown, specLeft, or specRight specFast = RSHIFT, LSHIFT ; from EscapeBox module ;;; toggle the escape menu menu_toggle = ESCAPE ;;; the quit key while the escape menu is active menu_quit = Q ... As for per player data, look at the do!@#$%^&*entation in Modules/PerPlayerData/PerPlayerData.h, I'll get a tutorial on this one too.

Yeah I have gotten it to compile under OSX and was working out some of the byte-ordering issues... It wasn't 100% when I stopped... kinda hard considering I have to borrow my roommates Mac to do it. I might get a Mac mini at some point.

priitk made the game, ekted made the front end

Thanks, we sure could use your help. Here's a simple module tutorial topic, post there with any questions you run into: http://forums.sscentral.com/index.php?showtopic=13168

you're right, ship 9 was messed up. here's a fixed shipman.conf (attached) also for full screen set Graphics:Fullscreen to 1 and it should work in full screen (conf/visual/graphics.conf) The next chance I'll get to work on this is after I graduate in mid-may. Shipman.conf

Yeah, the physics module works by updating a particle's position and velocity after a number of milliseconds elapse. First, after we check what tile the particle is entering and find that it's a slanted tile, we check if it's coming from the left or bottom (using the tile in your figure). Then if it's not we have to check where the collision with the diagonal line occurs exactly. We put both the formula for the diagonal line in the tile into the cooresponding line equations (y=mx+b, remember from pre-algebra?). Note that we can only do this if the slope exists (m = dy/dx, so if dx = 0 m doesn't exist, this cooresponds to a particle moving straight up or down). If the slope doesn't exist, we can just plug the x value from the particle line into the equation for the diagonal line to get the y coordinate of the intersection. so, for example let's assume our tile is located at the origin in quadrent I. the equation for the diagonal line, in pixels, is y=(-1)x+16. Let's say a particle is moving straight down at x = 3. Putting 3 in for x we get y=(-1)(3)+16 which simplifies to 13. So now we know the collosion occurs at (3,13), which is actually a point on the diagonal. If the slope does exist, meaning the particle isn't traveling straight up/down, we have to find the collision of the two lines. so in our example the tile line is y=(-1)x+16. Let's say a particle is moving normal to the diagonal tile surface. So let's say the equation for the particle is y=(1)x-2. We can find where the intersection is by setting the two equations equal to one another and solving for x, then pluging x into either equation and getting y out. so (-1)x+16=(1)x-2, use algebra to get -2x=-18, x=9. Now we can plug x=9 to either equation to get the y coordinate. 9-2=y, y=7, so the collision is at (9,7). Now we do a check to make sure this point is actually in the tile (the two lines may intersect outside of the tile, in which case we can safely ignore the particle as it passes through the passable part of this tile). Indeed 9,7 is within our 16x16 tile size, so we now just have to move the particle to it. We get the distance from the original particle position and 9,7 using the pythagorean theorm. We can then use the velocity and distance to solve for time elapsed (v=d/t, t=d/v). If this time is less than the number of milliseconds we're advancing the particle, just advance it without bouncing, if not, subtract this time from the time to advance the particle, change the positon to 9,7, change the velocity as you described(incoming angle should equal outgoing angle, you can compute angle of particle from velocity and arctan), and go back to the begining of the physics loop to see if it his another tile during this update.

that's definately on the todo list, I play hockey zone in continuum so it would help us a lot.

nice, definately some good ideas I'll use. Some of the things, like encrpyting server files, would probably be impossible with an open source client. The conf files are nothing to be afraid of. They're like .ini files, interpretted settings. I think the fact that they're so many settings that you can change (and soon the server will be able to change), is a huge plus for customizability.\ You seem to like the winrar .dat files for a lot of things... any specific reason? Is there an open source library that you know of that I could use to read/write from these sorts of files easily?

what format did they come in (is there a tutorial somewhere for them)?

ASSS sorta does that where you can have multiple modules in one dll, but in my experience I often want to change a single module, so I think it's easier to just replace the file then either change modules.conf or recompile all the modules in the .dll. If more people express this concern, I'll consider it more. What names would you suggest?

STP is subspace transfer protocol, which is unimplemented currently (I relized I needed to back up and implement the profile stuff first). remove settings.conf from the server's required file list (should be in arenas/(default)/arena.conf if I remember right, there isn't much doc on the server portion, unfortunately. you should be able to connect to the server after this and chat with continuum clients that are conneted.

great! did you run through the image example?( http://wiki.minegoboom.com/index.php/Discr...splaying_Images ). The Chat stuff is in the Chat module (look in chat.h). If it still confuses you post and I'll make a tutorial for Chat... if not, you make one If you mean the kill-like messages, those are in the Flash Module, if you just want text anywere, the Text module can do that. let me know

hmm, what do you suggest I do differently?

You can do it in Discretion by not including a position change in a wormhole's StatusModification.

It can connect to a modified ASSS server (which is up on the webpage), but chat only for now (and file transfers if you're clever).

The way I see it work is that you put any trusted public keys in a key directory, which by default comes with just my key. When a server sends you a module, it checks to see if the public key is in your keys directory, if not the module is rejected, no prompt just a message saying the module is not trusted and may be malicious. You could of course disable this with a setting for testing modules and such. We will probably need an extra precaution perhaps the first time a key is used give a scary message to make sure they know that accepting a signature from a malicious party could result in windows being deleted or even the signature of a nonmalicious but careless party which releases buggy code should be treated as an equal threat to security. Anyone could make their own key, which is a good thing. Say I decide to disappear and only come back once every 2 years. In order to continue development, another trusted party could take over and start signing modules. As for Java using too much memory, that will be dependent on the quality of the module used. If server owners code them poorly and users get a poor experience they'll stop playing that particular zone.

Witchie: here's an addition tutorial for simple functionality: http://wiki.minegoboom.com/index.php/Discr...splaying_Images

yeah death+ is a cool cat. anyways, the digital signature thing would use public / private key encryption. I (or a trusted party) has a private key which I can encrypt a hash of the .dll or .so file. Then, anyone can use the public key to check the signed hash versus the actual hash executing code from the module. For more on digital signatures you can read up on wikipedia: http://en.wikipedia.org/wiki/Digital_signature Version checking will have to be done to make sure everyone's using the version of the module that the server expects. If there's some bug in a module that may compromise your computer, I could even use the private signing key to issue a recall on a module version so that your copy of Discretion will prevent servers from making you use the compromised version of the module. I actually haven't been successful with getting a java virtual machine to run out of a C/C++ program... although I have used JNI before. I think java's speed will suffice for things that occur on the order of seconds or even tenths of seconds. We'll see what happens when we actually implement it, but if that doesn't work I could make a simple safe scripting language for Discretion that would get the job done.

how did they work?

What's left in DCME after you get the LVZ stuff in?

Here's the reply about cheating I gave in the comments section... let me know what part you want me to elaborate on: Also, parts of the game may have to be slightly changed... for example it wouldn't be hard to drop a portal and then detect client side when you're about to die and instead warp to where the portal is at the last splitsecond. For things like this I think we could have a delay between when you press insert and when you actually warp... so like you'd press insert and 0.5 seconds later it would warp you... of course that would be a setting so if a server owner didn't think it was a problem they could use a delay of 0. In some sense, any time you're running arbitrary code on your machine whoever wrote that code could do anything they want. I've kicked a few ideas around my head about this. One thing you could do is have digitially signed modules such that if the server is sending you a required module, it must be digitally signed with a trusted key before it loads into Discretion. You could have a directory with all the digital signatures that you accept such that if the owner of the signature pulls a Priitk and disappears, some other trusted person / group of people could take over. Another option is to use Java .class files to interface with Discretion run through a virtual machine with a Security Manager that allows you to do nothing (think of the permissions Java applets are given when you run them through your web browser). This way you could interface with the Discretion interfaces to display images and react to keypresses, but not do silly things like delete files off your harddrive. Both options could be used with performance sensitive code being signed and written in C/C++, and individual server specific modules written in unsigned Java. As for client-side calculations and game manipulations, the only thing we can do is provide any benefitional ones to all the players with Discretion so that people are on a fair playing field. I'm skeptical as to how benefitial these will actually be, as I think given resonable settings a human can outplay an AI hands down. I mean currently with Continuum you can have things like prox squares (for hockey zone) and lines showing you where you're aiming by changing your ship graphics, but they don't seem to make much, if any, of a difference (at least in my experience).

Alright, in this topic I will attempt to help you make a module. Making a module is easy pie once you know what to do, so let's get to it. Windows with MSVC: First step: make a new VS.net C++ Project. 1. File -> New Projectw 2. Win32 Console Project 3. Give your project a name ("TestModule" in the picture) 4. Press Ok http://img.photobucket.com/albums/v622/bak2007/disc_module1.png 5. Click on application settings on the left 6. Click DLL from the list of radio buttons 7. Press the Empty Project checkbox 8. Press Finish http://img.photobucket.com/albums/v622/bak2007/disc_module2.png 9. File -> Add New Item 10. Select C++ Source File (.cpp) 11. Name your source file ("testmodule.cpp" in the picture) 12. Press Open http://img.photobucket.com/albums/v622/bak2007/disc_module3.png 13. Paste the following code into your source file // Sample Discretion Module Source File #include "Module.h" void* getClassInstance(void* _mm, LoadMode lm) { if (lm == LOADMODE_Init) printf("Test Module Initialized\n"); return 0; } extern "C" { EXPORT void* getInstance(void* mm, LoadMode lm) { return getClassInstance(mm,lm); } } 14. Right Click your project in the Solution Explorer and go to Properties (You can also access this through the Project Menu, Project -> Properties) http://img.photobucket.com/albums/v622/bak2007/disc_module4.png 15. In the properties window, from the drop down menu select "All Configurations" 16. Select C++, General from the tree view on the left 17. Type the directory to the Modules directory (the one with Module.h in it, not the one with only .dlls!) that comes with the full version of Discretion in the Additional Include Directory property ("E:/client/modules" in the picture) 18. Press Ok http://img.photobucket.com/albums/v622/bak2007/disc_module5.png 19. Go to Buld -> Build ("TestModule" in the pictue) http://img.photobucket.com/albums/v622/bak2007/disc_module6.png If all goes well, you code should compile and a .dll should be produced that is a Discretion module! Now let's put the module into Discretion to see it at work. 20. Copy the produced .dll into your Discretion executable's Module folder (the one with the .dlls in it, not the one with Module.h in it). http://img.photobucket.com/albums/v622/bak2007/disc_module7.png 21. Edit conf/MAIN.CONF with a program such as Notepad 22. Add the name of your dll to the Modules::Names setting (it's a comma seperated list of module names, order doesn't matter) 23. Save the file http://img.photobucket.com/albums/v622/bak2007/disc_module8.png 24. Run Discretion, Select Practice Offline 25. Observe your modules initialization in the console window http://img.photobucket.com/albums/v622/bak2007/disc_module9.png Now you might say, rightfully so, that this module doesn't do anything. The way to do real things in Discretion is by using other modules. Want to react to user key presses? Use the KeyControls module. Want to display some images? Use the Graphics module. I'll gladly write additional tutorials for how to use each of these as needed. Tell me what you want to do and I'll write a tutorial with how to use the existing modules to accomplish what you want to do. Linux: Todo... let me know if you're interested in linux dev post here and I'll make a guide, although the makefile provides some hints.