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 :)
|
 |
|

Board Index

|
 |
#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
|
 |
 |
|

Board Index

|
 |