Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1351353 views, last view: 12/09/2021 06:35

This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.

   Board Index   

#861: ..

by Sparr on 06/11/2005 19:41

I think the documentation should be divided, like the four cube htm files but in a better way, into a reference and a tutorial section. I do not want to have to navigate through your 'tips' (no offense intended) when im looking for the syntax for a console command, but equally as important is that the pure reference version of the syntax wont help out someone new to the game.

This is something many documentation authors ignore, forget, or don't realize. A reference and a tutorial/howto serve completely different purposes, usually to exclusive audiences.

Having said that, I was considering working on the sauer docs as well, but I am not even going to try to start until there is some sort of moderate feature freeze. Editing is changing so much every week or two that the documentation becomes obsolete as fast as it's written.

reply to this message

#862: ..

by Sparr on 06/11/2005 20:53

good link. a wiki would probably be a good idea

reply to this message

#863: ..

by >driAn<. on 06/11/2005 21:01

Afaik pushplay already started on a manual. I'm not sure if a wiki is the best way to work on a sauer manual, Aard said something like "A programmer should write the manual" if I remember it correct.

reply to this message

#864: Manual

by pushplay on 06/11/2005 22:15

I'm working on it, hold your horses. I'm still sorting out all the commands and figuring out an ideal way to explain the oct tree structure to new mappers.

reply to this message

#865: Re: ..

by Pxtl on 06/11/2005 23:04, refers to #863

I agree about the problem with wikis - look at all the bizarre misconceptions about Sauer and Cube that pop up on the forum (I wont name any names) - imagine that in Wiki form.

reply to this message

#866: ..

by Sparr on 06/11/2005 23:06

wikis dont have to be completely unmoderated. there are at least 30 between this forum, IRC, and the snieb forum that i think could collaboratively maintain a very good wiki.

reply to this message

#867: wiki

by Aardappel_ on 06/11/2005 23:08

I am all for a wiki. it has always bothered me that there is so much information on these forums that is relatively inaccessible. If we could make the bundled documentation with sauer just an offline version of the wiki, that would be even better.

I can easily set up a wiki on cubeengine.com, even without sleepwalker's help. Infact, I have a test wiki up here:

http://strlen.com/wiki/

Why don't you all go try it out.

For now, we'll start with pushplay's work for the immidiate next releases, then work on that.

One issue is of course that we need some relatively active editors, to fix things in case we have "malicious" users.

reply to this message

#868: ..

by TOGoS_1u2kuhbui on 06/11/2005 23:33

Perhaps you should put a link to the wiki on the main page. There is another wiki that I started a wiki a long time ago (cube.xwikki.com), but it didn't get used much as nobody knew about it :P I'll see if I can start moving what little useful information there was over.

reply to this message

#869: Re: wiki

by Sparr on 06/12/2005 01:56, refers to #867

a wiki, hooray!

two problems:

1) no registration. i know, registration is "Bad", but youre going to get wiki spam if you dont require it. plus its nice to see who has been editing by something other than IP, so people dont want/need to sign their work

2) the ?binary thingie isnt working for cached images. my image on [edge spans] worked once, then died.

reply to this message

#870: Registration

by jean pierre on 06/12/2005 10:20, refers to #870

Are you talking about Sauer is gonna be ShareWare?

If yes then how much will it cost's?

Make the non open-sourced download freely and if people want it open-sourced they should pay for the download i feel its a good idea.

reply to this message

#871: Re: No spaces in filenames please :-)

by Pxtl on 06/12/2005 12:09, refers to #871

Ahh, don'cha love Linux? It slices, it dices, it makes julienne fries, but filenames with spaces still are a huge pain in the ass.

Note for all budding text parser programmers - spaces are not always the perfect delimiter.

reply to this message

#872: sauerbraten on mac os x

by absinth on 06/12/2005 14:21

hello all
with a few minor changes i've got current cvs sauerbraten to compile on mac os x (again) but it just crashes when running (log below). any idea where i could start debugging that?
thanks

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000a6c

Thread 0 Crashed:
0 libGL.dylib 0x92d9de7c glBindTexture + 48
1 macosx_client 0x00013e68 createtexture(int, int, int, void*, bool, bool) + 64 (crt.c:355)
2 macosx_client 0x00031be8 clearlights() + 164 (crt.c:355)
3 macosx_client 0x0001f328 empty_world(int, bool) + 588 (crt.c:355)
4 macosx_client 0x0000d46c SDL_main + 688 (crt.c:355)
5 macosx_client 0x00036654 -[SDLMain applicationDidFinishLaunching:] + 68 (SDLMain.m:246)
6 com.apple.Foundation 0x9287bbf8 _nsnote_callback + 180
7 com.apple.CoreFoundation 0x90771840 __CFXNotificationPost + 368
8 com.apple.CoreFoundation 0x90769964 _CFXNotificationPostNotification + 684
9 com.apple.Foundation 0x92866000 -[NSNotificationCenter postNotificationName:object:userInfo:] + 92
10 com.apple.AppKit 0x9362d620 -[NSApplication _postDidFinishNotification] + 112
11 com.apple.AppKit 0x9362d50c -[NSApplication _sendFinishLaunchingNotification] + 92
12 com.apple.AppKit 0x9362d054 -[NSApplication(NSAppleEventHandling) _handleAEOpen:] + 264
13 com.apple.AppKit 0x9362cbfc -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 92
14 com.apple.Foundation 0x9287cc04 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 380
15 com.apple.Foundation 0x9287ca64 _NSAppleEventManagerGenericHandler + 92
16 com.apple.AE 0x91450a40 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 208
17 com.apple.AE 0x914508dc dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 44
18 com.apple.AE 0x91450734 aeProcessAppleEvent + 284
19 com.apple.HIToolbox 0x931253e4 AEProcessAppleEvent + 60
20 com.apple.AppKit 0x9362b344 _DPSNextEvent + 800
21 com.apple.AppKit 0x9362ae68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116
22 com.apple.AppKit 0x936273cc -[NSApplication run] + 472
23 macosx_client 0x00036c4c main + 1232 (SDLMain.m:223)
24 macosx_client 0x00003090 _start + 344 (crt.c:272)
25 macosx_client 0x00002f34 start + 60

reply to this message

#873: Non-FPS game idea for Sauer

by Kagat0 on 06/12/2005 18:36

Just tried out the latest release of Sauerbraten. Excellent work guys!

I\'m not sure if I\'m in the right thread, but I want to get this idea off my chest. :) I feel the incredibly powerful and simple in-game editing capabilities of Sauerbraten ought to be exploited as part of a game mode, and I think I\'ve got an idea how it could be done.

Many years ago, there was a game called Archipelagos.

http://www.mobygames.com/game_group/sheet/gameGroupId,1273/

It was a non-violent \"3D\" puzzle game. You\'re in a world of islands, and your goal on each is to link an Obelisk to all of its power stones, by creating \"land bridges\" between them. However, there are evil trees (yes, trees) after you, and as they move toward you, they turn the earth blood red; if the ground beneath you turns to blood, you die. There are other nasties about as well, which devour the land around you.

The Sauerbraten engine seems like the ideal way to translate this game concept into true 3D. Here\'s my reinvention of the concept, along with some mockup pictures. (I\'ve put it on a web page rather than here, as I prattle on a bit):

http://users.on.net/~carpenter/download/dreamlands.html

What do people think?

reply to this message

#874: ..

by Sparr on 06/12/2005 19:03

nice idea. first obvious problem, if the vortex modifies geometry then youll have to recalculate lighting, which is slow. you would need a way to background it, and only apply geometry changes once the new lighting is ready.

reply to this message

#875: Re: No spaces in filenames please :-)

by eihrul on 06/12/2005 19:56, refers to #872

You do know that shells have autocompletion and/or you can escape spaces with the \ character, as opposed to quoting?

reply to this message

#876: ..

by Sparr on 06/12/2005 20:15

spaces are just as much problem in windows as in other evironments, windows just uses the stupid ABCDEF~#.ext schema.

reply to this message

#877: Re: No spaces in filenames please :-)

by Aardappel_ on 06/13/2005 01:09, refers to #871

these are very temp files... we should have better documentation soon.

reply to this message

#878: Documentation

by pushplay on 06/13/2005 04:07

I'm putting in several hours a day, it's just surprising the volume of work that has to go into it. I'll submit a wip sometime tonight.

reply to this message

#879: Re: Documentation

by Aardappel_ on 06/13/2005 04:09, refers to #878

excellent!

reply to this message

#880: ..

by RealNitro on 06/13/2005 12:08

http://cubeengine.xwiki.com/xwiki/bin/view/Main/WebHome

I don't know who created this wiki, but I came across it while doing a google search.

reply to this message

   Board Index