doc flabby

I have problems with the CF lights as i can see the flicker in some of them- Have the same prob with normal floresents. Also dimmer switches don't work with CF The future in lighting is LEDs, vastly more efficent and produce much more natural light, CFs will disappear in a couple of years

Interesting ideas, but at this point not really looking at anti-cheat tech - Gotta have a game first to cheat in

http://forums.trenchwars.org/showpost.php?...amp;postcount=1

Whats to stop a rouge server faking the biller sending its own "special" bytes to the client. Biller: 1234 RougeServer: BillerBytes:0000 Client: hash(UserP!@#$%^&*0000) RougeServer: Accepts HASH login. Where is the danger you might ask? Well, if you have a short password its simple to bruteforce it. a 4 letter password only has 456976 combinations (!@#$%^&*uming a-z). However more worryingly the server could send specially crafted bytes to the client that maximize weaknesses of the hashing algo. Another issue is the server could save hashes and use them later, if and when the biller provides the same random bytes. These attacks are pretty theoritical, The biggest problem is it exposes the biller to direct DOS attacks and will use alot of bandwidth for the person running it. You might want to have a look at the UserDB service for STF. Its a more secure version of what you have described. In the design I have used, the user database is separated from all other billing functions. In order to authenticate a user the billing server passes on an RSA encrypted password to the zone. This is then forwarded to the biller which checks it agaisnt the userDB. This means anyone can run a billing network wilst still using a central userdb It uses RSA encryption, which is designed to never produces the same sting of bytes, even when the same password is encrypted. This means the only way a password can be stolen is by editiing the code of the USERDB to save unencrypted passwords to the database (it uses sha-512 as standard)

Give it a spin (needs some work but its pretty much there) http://forums.minegoboom.com/viewtopic.php?p=76761

It will be dependant on the opertating system API Windows/X/MAX OSX, but the actual libary is build into the exe. The version i am creating uses the gui. It is dependant on the windowing libary that comes with freepascal, however the libary itself is cross-platform. This libary, and dependant libaries are statically linked into the executable, so when distributing the exe, its already included as part of the exe. This leads to larger exe sizes but eliminates the need for external libaries to be distributed with the exe. When I post up the alpha it will be a bit more clear. I don't thinik i'm explaining it very well. There is a port for ncurses for windows somewhere as i was looking into it when I was starting this project.

hopefully should have something to show by the weekend. Its being written in free pascal, which is cross platform. Has build dependencies (like most programs do:P), but no run-time.

i hate to say this, is if this actually happens it risks creating more "carbon" than it saves, though the surge that will happen when everybody turns stuff back on, triggering backup generators to come online. Surges to the power grid are never good. If everyone turns of there lights the power stations still generate the same amount of power and produce the same amount of CO2. It takes about 4/5 hours to turn on/off a coal/gas powerstation. Nuclear is never turned off. So really what is the event going to achieve? very little. A far better thing would be to stop eating meat, or reduce our intake. The food we eat produces substantially more CO2 than anything else. Beef being one of the worst. Meat is one of the least efficient ways of fuelling a human. Exercise also produces CO2. So really we need to eat less, and do less. Driving by car powered by petrol produces less CO2 than a human walking the same distance powered by eating a big mac. Then again this whole "green" thing seems to be a good excuse to raise taxes

This is a similar conceptual problem STF is facing. this is how i see the order of processing. Arena -> Player -> Player Overrides However my idea has been to abstract the settings further, so all the settings are created from the file. rather than them being hardcoded. I've yet to work out how to achieve this however. Eg. Arena.settings Warbird-speed=100 Firebird-speed=200 Javelin-speed=300 These are sent the the client. It stores these in memory in some way. Then a module could alter these by something like. if(special area) { Override("Warbird-speed",400) //sends update to client } else { Reset("Warbird-speed") //sends update to client } It would mean that any setting could just be made up and alter. I am still getting caught up on how to stucture the settings file

I'll give it a go

Would it have to be written in C/C++ or could it not be written in another language that can be directly linked with C (e.g. free pascal) Pascal programs are statically linked so don't normally require any externals beyond operation specific ones.

define virgin. The word could mean anything. I'm a virgin in some ways, but not in others

As many of you may or may not know, i run the longest running backup directory server. I use a modded linux port of CATID's ddirserv. (it has been released to public) It launched in June 2006. Possible Server Downtime Unfortunately owing to the current way the exchange rates in europe are going, i am having to close the European server, as I can no longer afford to run it. This server was running the directory server. I have moved this to the America server (that hosts the PSS sites). You shouldn't notice any interruption in service provided the DNS updates go well.

you've completely misunderstood the point of this project, STF is about creating a new online world, its a new game. Inspired by subspace, but it will not be subspace. If you want to make subspace better, help discretion, that is the future for subspace in the short-medium term

As I have said in the other thread, I think that friction is a good idea, and definatly should be considered!

Friction was definatly worth meantioning, and bringing up. I would like to remind everyone that it is very important that to this project that we keep an open mind to all ideas, wherever and whoever they come from. That also means you must respect thoses ideas. The topic of the thread was only about ideas, which means no negativity (I don't want to hear the words SHOULDNT,CANT, MUST NOT) I have no patience for trash talk, personal attacks, aggressive posting, trolling, spamming and pointless arguements in this forum. Hopefully I have made myself clear.

Kinda offtopic, but i'm really happy to see this project progressing!!!

May I ask what the original loader is in the demo? I don't recall seeing any model files in there (stf-demo.zip). It was not in the first demo. MM posted in the wrong thread, the demo where I used the javelin, and has the model loader (loads lvl and ms3d, so far...) is from this thread http://www.ssforum.net/index.php?showtopic=18869

Playable Beta, Supporting at a minimul legacy subspace functionality is to schedualed to be released Jan 2009. Anything else = project failure.

Coincidentally I had recently textured my warbird model and made it look slightly better: http://toktok.sscentral.com/dump/wb3-tex.zip Although from experience I have a feeling if anyone opens that file they may not find any UV information (something to do with different versions of blender maybe). It's also resized to fit inside a 2x2 square in blender, which looking at my code may or not be length 100.0 in open gl. Thanks, but link not working now i just have to create/find a blender loader

Just to let everyone know, work is progressing on this project, the current priority is to design an effective settings system. there is unlikly to be much in the way of visual demos untill MAy/June. Alot of boring and tedious backend stuff needs to be sorted first.

first post

Thats because it IS the one from Thirdspace. I used it in the demo though the lack of anything else that was texture modeled being available to test with. The game will eventually (once more work is done) download all graphics from the zones it connects to, no artwork will be distributed with it. I'm happy to remove the javelin and use different models in future demos if you wish.