home home

downloads files

forum forum

docs docs

wiki wiki

faq faq

Cube & Cube 2 FORUM


Map Editing

by Goetzenzar on 01/05/2002 19:30, 4767 messages, last message: 10/18/2021 18:52, 2847055 views, last view: 12/09/2021 06:34

Welcome to the map editing saloon:
here u can post ur screens, maps, comments, questions and answers about mapediting, and meet other ppl for coop-sessions online :)

Go to first 20 messagesGo to previous 20 messages    Board Index    Go to next 20 messagesGo to last 20 messages

#3763: A matter of morals

by Person on 09/06/2008 04:35

Hey everyone, I recently got the platinum arts sandbox version of cube and found it to be enjoyable. I saw it too be some what limiting. I checked out what the engine it was based on and it said cube 2. I found myself here. I really like the engine but due to personal beliefs I don\'t wish to play an FPS in any way shape or form. Is there a way I can stop the engine from making my maps into FPS games?

reply to this message

#3764: Re: A matter of morals

by noerrorsfound_has_done_it_again on 09/06/2008 07:12, refers to #3763

There's really nothing wrong with pretending to shoot imaginary monsters, but believe whatever you want.

To answer your question, you can modify the source and recompile to disable the guns but you can't set it as a map option or server option to have no weapons.

reply to this message

#3765: Help

by sneak22 on 09/07/2008 21:07

How do i change it when you log on to Suberiou to my game name?

reply to this message

#3766: Texture Interpolation

by Jirtan on 09/13/2008 01:58

I\'ve noticed that some of my custom textures are handled poorly in Sauerbraten. When two edges are high in contrast, a visible blurring effect occurs where the colors on the opposite sides of the texture bleed into each-other. This makes the textures blend better when they are tiled, but when they aren\'t it looks terrible. Is there a .cfg option that deals with this?

Also, roughly how difficult would it be to update the engine to support animated textures (like .gifs)?

Thanks.

reply to this message

#3767: ctf

by samtrompet on 09/14/2008 11:12

does anybody know where you can find the flag for CPT in editing mode? And also, where can I find a stairs? I can only find a ladder, but do you have to make the stairs yourself or what? and just one more thing. I've read on a tutorial that you can make an arch (between two walls and the ceiling) just by pressing I and then typing "/arch 2", but it says "command unknown: arch". Wich command can I use for it?
Please somebody help me out with this problem, cause I've got some nice ideas for CPT maps :D
Cheers
sam

reply to this message

#3768: Crash problem doing a light calc on a large map

by dangerstripe_dan on 09/16/2008 01:08

I decided to take a short break from the Ktinga and build a Borg cube ship (not full size, obviously- it's only 10.5 million squares or so- figure about 160 "meters" on a side (1 "meter" = 1 default square size)

Every time I do a light calc now, the engine bombs out while computing normals, even if I set the light error to 15 and the light precision to 64.

When it crashes, I get a Win32 Exception with a memory range (probably not relevant), but also the following:

Vector <normal>:: vrealloc - tools.h [294]
addnormal - normal.cpp [50]
addnormals - normal.cpp [138]
addnormals - normal.cpp [99]
addnormals - normal.cpp [99]
addnormals - normal.cpp [99]
addnormals - normal

I am not a programmer, but I am suspicious that I have run into a hard limit on the number of lights (or the number of surfaces that can go through a light calc). I've probably a few thousand lights on this monster.

Anyone have any clue about this?

Thanks.

reply to this message

#3769: Re: Crash problem doing a light calc on a large map

by dangerstripe_dan on 09/16/2008 01:09, refers to #3768

Oh, one more thing (probably important)-

Latest CTF release (not from CVS), XP Pro sp3, dual Xeon workstation, 1.5 gig RAM, NVidia Quadro FX 1400 GPU.

Just to forestall anyone asking.

reply to this message

#3770: Re: Crash problem doing a light calc on a large map

by eihrul on 09/16/2008 03:24, refers to #3768

I'd have to be able to look at the map itself to tell you what's going on.

reply to this message

#3771: Re: Crash problem doing a light calc on a large map

by dangerstripe_dan on 09/16/2008 18:08, refers to #3770

Do you have a place for me to put it? It's 15.5 meg (and no custom textures- that's just the ogz file).

I don't want to post it on quadropolis until it's ready for release.

reply to this message

#3772: Re: Crash problem doing a light calc on a large map

by eihrul on 09/16/2008 19:06, refers to #3771

You could try emailing it to me, although who knows if gmail would allow the file through.

reply to this message

#3773: Re: Crash problem doing a light calc on a large map

by eihrul on 09/17/2008 02:44, refers to #3771

It would seem your computer simply ran out of memory because you have used a rather insane amount of cubes. :)

reply to this message

#3774: Re: Crash problem doing a light calc on a large map

by dangerstripe_dan on 09/17/2008 18:50, refers to #3773

I upgraded from 1.5 gig of RAM to 3 gig and had the same problem in the same place. At the time of the crash, I was watching my memory utilization and never passed 65%. Sauerbraten didn't even hit the 2 gig 32 bit windows program space limit.

reply to this message

#3775: Re: Crash problem doing a light calc on a large map

by eihrul on 09/17/2008 21:51, refers to #3774

Well, after a certain point, the OS is refusing to allocate sections of memory of the required size, and this is what is causing the crash.

reply to this message

#3776: Re: Crash problem doing a light calc on a large map

by dangerstripe_dan on 09/18/2008 16:25, refers to #3775

Would a different OS make a difference to that? E.g., could this work on a Linux workstation instead of a Windows workstation?

reply to this message

#3777: Re: Crash problem doing a light calc on a large map

by eihrul on 09/18/2008 21:33, refers to #3776

Dunno, it ran out of memory on my Linux box too. :)

reply to this message

#3778: Re: Crash problem doing a light calc on a large map

by eihrul on 09/18/2008 22:12, refers to #3777

A temporary workaround for you might be to try setting "/lerpsubdiv 0" before you do your calclight. This will degrade the quality of the normals a bit, but it seems to save just enough memory for me to let it squeak by to the rest of the calclight.

reply to this message

#3779: Re: Crash problem doing a light calc on a large map

by eihrul on 09/18/2008 23:44, refers to #3777

Or if you can run from Sauer CVS, I just added some code to compress the normals, so that it doesn't have to allocate quite as much memory now.

reply to this message

#3780: skybox

by Johnny_Cash on 09/20/2008 14:38

hi guys,
im having trouble loading skyboxes
it says
"could not load XXXX_up.jpg"
and so on
can anyone help?

reply to this message

#3781: Re: Crash problem doing a light calc on a large map

by dangerstripe_dan on 09/22/2008 20:08, refers to #3779

I pulled the latest EXE from the CVS and had the system crash on me again, but in a much later spot in computing normals (about 75% of the way through instead of 5%), even after rebuilding the map to have fewer lights (well, somewhat fewer- maybe 10% less lighting) and using the lerpsubdiv 0 command prior to the calc light. It also doesn't give me the vrealoc error I had earlier- I just get a crash with a memory address.

Is there any other way to reduce memory requirements for lighting (besides deleting more lights?) e.g., I am using a light precious of 64; would 128 help? What about changing the light error?

Thanks.

reply to this message

#3782: Re: Crash problem doing a light calc on a large map

by eihrul on 09/23/2008 03:11, refers to #3781

Hmm, it worked fine for me on Linux. Maybe Windows is just good dealing with large amounts of memory for this?

Making lightprecision coarser will help with the later lightmap generation step, but it won't reduce the amount of normals generated via the normal generation step. The only way to reduce the normals was by way of that "lerpsubdiv" variable.

Dunno what to tell you in the end other than that. Maybe scale down the ship and reduce some of the repetitive elements of the map. I think you could still keep the feel of the map that way without necessarily going quite for such precision of layout.

reply to this message

Go to first 20 messagesGo to previous 20 messages    Board Index    Go to next 20 messagesGo to last 20 messages


Post a Message

Username

Email

Subject

Body

2 times 8 =


content by Aardappel & eihrul © 2001-2021
website by SleepwalkR © 2001-2021
42368273 visitors requested 58075535 pages
page created in 0.066 seconds using 9 queries
hosted by Boost Digital