SRB2 Doom Builder
- Thread starter Oogaland
- Start date
-
- Tags
- srb2 v2.1.x
- Status
Blitzzo
It's Mr. Computer!
Here's my main gripe about gamepads:
"I need to aim my cursor over that super tiny object! Oops, I didn't go over it! I need to align myself and try again! Oops, I moved past it, I gotta move back over it again! Oops, I did it again! Oops, I moved the joystick just a touch and I aimed too far! Oops! I moved it a touch the other way and I still went too far!"
"I need to aim my cursor over that super tiny object! Oops, I didn't go over it! I need to align myself and try again! Oops, I moved past it, I gotta move back over it again! Oops, I did it again! Oops, I moved the joystick just a touch and I aimed too far! Oops! I moved it a touch the other way and I still went too far!"
If you just want to switch map, there's an option for it on the File menu (Sonict suggested it a while back). If you mean adding the ability to have multiple maps open at once, then... probably not. It would be nice, but there's a whole lot of stuff that depends on there only being one map open at a time, most notably the renderer and the saving routine.Roboashura said:
BlazingPhoenix
AAAAAAAAAAAAA
Add the ability to make custom unlockables in the MAINCFG lump...(if you can add that into SRB2 already that is...)
r16
New build: http://homepages.inf.ed.ac.uk/s0569864/builder_srb2-r16.zip. As ever, keep backups of your WADs, and don't overwrite FOFPresets.cfg and ColourSchemes.cfg unless you're sure you want to. Changes since last time:
Some of these merit further explanation:
That covers everything worthy of note, I think. If you happened to download this directly from my site shortly after midnight BST, you'll probably find that the colour for zero-height linedefs is something weird. Redownloading should fix it. Failing that, you can set the colour manually in the config dialogue.
EDIT: The changelog in the zip is outdated. I'll fix it... some time. Also, I meant to mention earlier that SRB2DB seems to work in Wine if you feed it a native OLEAUT32.DLL from Win98. NTish ones might work, possibly.
New build: http://homepages.inf.ed.ac.uk/s0569864/builder_srb2-r16.zip. As ever, keep backups of your WADs, and don't overwrite FOFPresets.cfg and ColourSchemes.cfg unless you're sure you want to. Changes since last time:
Code:
+ Deaf/multi text can now be customised. Updated game config accordingly.
! Texture selecter not invoked when preview in main window clicked in frame but
outside image.
+ Numerous very minor interface adjustments.
+ Scroll key. While held, mousing to the edge of the map causes it to scroll.
! Selected item info was wrong if the mouse was moved out of the map directly
from a highlighted item.
+ Linedefs whose floor heights are the same on both sides are drawn in a
different colour.
+ Linedefs which are impassable due to delimiting a sector with equal floor
and ceiling heights are drawn in the impassable colour.
! Rewrote the control sector positioning algorithm in an attempt to quell its
bugginess.
+ Control sector positioning hint object.
! Fixed a problem with custom deaf/multi text.
! Selected item info not shown immediately after mode change.
! Selections could be messed up internally (leading to crashes) when linedefs
merged while in sector mode.
+ Grid-snapping can be toggled in the time-honoured fashion while drawing lines.
+ Holding Ctrl while drawing a line constrains it to a multiple of 45-degrees
from the source vertex.
! Changing ceiling flats from the main window actually changed the floor flat...
+ Merged in Doom Builder 1.68 (except for the flat/texture mixing changes, which
don't apply to SRB2 anyway).
+ Cleaned up the linedef/sector specials display a little.
! Concurrent linedefs weren't merged when pasting following a flip.
+ Added some defaults for config options and keyboard shortcuts that had been
added in the past.Some of these merit further explanation:
The Changelog said:
The first of these can allow you to see the structure of your level a little more easily. If you prefer the old behaviour, you can set this new colour to the same as a that of a normal two-sided line in the Configuration dialogue. The second can't yet be disabled, which is really why I'm bringing this up: lines which you can't cross since they abut a zero-height sector (e.g. the inside border of the thok barrier) are now drawn in the impassable colour. I'm not sure how well this will be received. Opinions/rants are welcome, as always. I intend to allow this behaviour to be toggled at some point in the future.The Changelog said:
Similar to the 3D Mode Start object, this is inserted in the manner of a Thing, and will act as the starting point for the algorithm that searches for free space in which to create a control sector. The direction of the object tells the algorithm in which direction to look.The Changelog said:
The real, honest-to-goodness Doom Builder has recently been updated by CodeImp. I've merged the changes, which are enumerated at http://www.doombuilder.com/builder_changes.php, into the SRB2 branch. They're mostly little things, with one or two more substantial new features.The Changelog said:
That covers everything worthy of note, I think. If you happened to download this directly from my site shortly after midnight BST, you'll probably find that the colour for zero-height linedefs is something weird. Redownloading should fix it. Failing that, you can set the colour manually in the config dialogue.
EDIT: The changelog in the zip is outdated. I'll fix it... some time. Also, I meant to mention earlier that SRB2DB seems to work in Wine if you feed it a native OLEAUT32.DLL from Win98. NTish ones might work, possibly.
BlazingPhoenix
AAAAAAAAAAAAA
Re: r16
....*IDEA*, why not ask CodeImp to put the SRB2 version of DB on his site? It'd be like another host I guess...
about time that he finally updated it too.Oogaland said:
....*IDEA*, why not ask CodeImp to put the SRB2 version of DB on his site? It'd be like another host I guess...
...I doubt that will happen.
Sorry for the double post but when you change a texture through the main window, the main window never updates. Instead, it looks as if you never changed the textures at all until you deselect them and select them again. I found that to be heavily annoying at first.
Suggestion: Color the lines of a sector which are tagged to an FOF or any other sort of linedef action. I found out that sectors which were used only for FOF with no other changes were marked in the zero difference color. I found this both annoying and useful. Annoying because the color the zero difference linedefs were made it hard to tell the FOF was even there and useful because when I set zero difference linedef colors to a much brighter color, I could tell it was an FOF immediately without having to remember or check. Thing is, I'd like to keep my zero difference linedef color to a dark color. So I think coloring tagged sectors without having to hover over the linedef that it's tagged to would be a great idea, whether it's colored always or only when you hover over it. (Both of which is good.)
EDIT: Okay, I kept trying to use the texture changing in the main window thing and I found a whole slew of new bugs. 1) Sometimes certain textures won't change. I had a linedef with a front upper texture a back upper and lower texture. I attempted to remove the upper front texture, change the upper back texture then remove the lower back texture and lower back texture refused to change. Further more, when I changed it the old fashioned way, it labeled the texture as "Missing" when in reality, there didn't need to be a texture there at all... 2) Selecting a lot of linedefs and attempting to change the texture sometimes doesn't change all of them. I haven't found any pattern to that yet. 3) Trying to change a linedef's texture too much will result in the linedef unselecting completely...but you can't tell because linedefs are still red (or selected) and the detail display never changes, though you can't interact with it at all. It's only noticable when you hover your mouse over one of the linedefs, that's when all the lines "appear" unselected and the detail display changes. Your last texture change isn't saved either when that happens. It appears to be connected to the first bug mnetioned in this edit.
Another final thing: DB keeps pestering you about the Control Sector Hint Thing being outside the map when most of the time, it should be outside the map. Not really a bug but it's quite annoying.
By the way, I can't say for sure about this but one time, I tried making a sector normally, but DB ended up reversing the sidedef pointers. For instance, the one linedef had it's front sidedef pointing to sector 31 and it's back one pointing to 33 but the pointers were saying that the front one was pointing to 33 and visa versa. I only did this once and haven't been able to recreate it but it was very strange nonetheless...
'NOTHER EDIT: Alright, another suggestion: Redesign the testing config for SRB2. For instance you could specify what map type a certain map is in the Map Options (Which of course could be saved in the DBS file) and when you test your map through the test key/button in DB, it'll use that map type you specified to determine which parameters to start SRB2 with so you'll always test your map in the correct gametype. This way there's no testing maps in Single Player and such. You could even have force keys where you could force a certain test mode regardless of the map type specified. Example: One key tests the current map in Match while another tests it in Single Player and another tests in CTF. I suppose you could also add check boxes, radio buttons and such in the test tab in the main configuration dialog box for options like music and sound settings, windowed mode, open gl, which skin you want to use, devmode, whatever you think would be handy for testing. You've made a launcher before so I assume this would be no big deal to implement but if you feel it's unnecessary then you don't have to put it in. ^_^;; I just think testing is a very, very important process of designing and building and it should be made as effortless as possible if you're going to be testing a lot.
EDIT: Yes...another edit.
The control sector hint thing fails. DB tried to follow it but puts the control sectors so close together that they OVERLAP with one another, and create a whole SLEW of problems. I had to spend a half an hour trying to fix the abomination it created. It makes the FOF dialog unusable.
EDITv4: Sigh...another edit. One thing I've noticed over the past year I've been using DB is that it has a very hard time distinguishing what sector is what. For instance...
Let's say the red sector is sector 1, the green one is sector 2 and the blue one is sector 3. Let's also say sector 1 isn't drawn yet so I draw it counterclock wise. DB gets confused with sector 1's linedefs merging with sector 2's linedef and thus, thinks that sector 1 is part of sector 2. This results in sector 1 sharing the same properties as sector 2, the linedef connecting the two sectors having wrong sector references and multiple "sector not closed" errors. Further more, no matter how I draw sector 1, sector 3 will be inside it. But DB does not fix sector 3's linedef references once sector 1 is drawn. Sector 3 still thinks it's part of the previous sector it's in, resulting in even worse unclosed sector errors. You see the problem here? It makes drawing sectors very hard when you're dealing with a lot already.
Furthermore, moving a sector inside another also does not fix the linedef references, making it impossible to put an existing sector inside another without having to edit the references yourself. Moving a sector next to another, trying to merge the linedefs of the two sectors, will also confuse DB and mix up more linedef references. I must say, DB has gotten quite buggy as of late...
Suggestion: Color the lines of a sector which are tagged to an FOF or any other sort of linedef action. I found out that sectors which were used only for FOF with no other changes were marked in the zero difference color. I found this both annoying and useful. Annoying because the color the zero difference linedefs were made it hard to tell the FOF was even there and useful because when I set zero difference linedef colors to a much brighter color, I could tell it was an FOF immediately without having to remember or check. Thing is, I'd like to keep my zero difference linedef color to a dark color. So I think coloring tagged sectors without having to hover over the linedef that it's tagged to would be a great idea, whether it's colored always or only when you hover over it. (Both of which is good.)
EDIT: Okay, I kept trying to use the texture changing in the main window thing and I found a whole slew of new bugs. 1) Sometimes certain textures won't change. I had a linedef with a front upper texture a back upper and lower texture. I attempted to remove the upper front texture, change the upper back texture then remove the lower back texture and lower back texture refused to change. Further more, when I changed it the old fashioned way, it labeled the texture as "Missing" when in reality, there didn't need to be a texture there at all... 2) Selecting a lot of linedefs and attempting to change the texture sometimes doesn't change all of them. I haven't found any pattern to that yet. 3) Trying to change a linedef's texture too much will result in the linedef unselecting completely...but you can't tell because linedefs are still red (or selected) and the detail display never changes, though you can't interact with it at all. It's only noticable when you hover your mouse over one of the linedefs, that's when all the lines "appear" unselected and the detail display changes. Your last texture change isn't saved either when that happens. It appears to be connected to the first bug mnetioned in this edit.
Another final thing: DB keeps pestering you about the Control Sector Hint Thing being outside the map when most of the time, it should be outside the map. Not really a bug but it's quite annoying.
By the way, I can't say for sure about this but one time, I tried making a sector normally, but DB ended up reversing the sidedef pointers. For instance, the one linedef had it's front sidedef pointing to sector 31 and it's back one pointing to 33 but the pointers were saying that the front one was pointing to 33 and visa versa. I only did this once and haven't been able to recreate it but it was very strange nonetheless...
'NOTHER EDIT: Alright, another suggestion: Redesign the testing config for SRB2. For instance you could specify what map type a certain map is in the Map Options (Which of course could be saved in the DBS file) and when you test your map through the test key/button in DB, it'll use that map type you specified to determine which parameters to start SRB2 with so you'll always test your map in the correct gametype. This way there's no testing maps in Single Player and such. You could even have force keys where you could force a certain test mode regardless of the map type specified. Example: One key tests the current map in Match while another tests it in Single Player and another tests in CTF. I suppose you could also add check boxes, radio buttons and such in the test tab in the main configuration dialog box for options like music and sound settings, windowed mode, open gl, which skin you want to use, devmode, whatever you think would be handy for testing. You've made a launcher before so I assume this would be no big deal to implement but if you feel it's unnecessary then you don't have to put it in. ^_^;; I just think testing is a very, very important process of designing and building and it should be made as effortless as possible if you're going to be testing a lot.
EDIT: Yes...another edit.
The control sector hint thing fails. DB tried to follow it but puts the control sectors so close together that they OVERLAP with one another, and create a whole SLEW of problems. I had to spend a half an hour trying to fix the abomination it created. It makes the FOF dialog unusable.
EDITv4: Sigh...another edit. One thing I've noticed over the past year I've been using DB is that it has a very hard time distinguishing what sector is what. For instance...
Let's say the red sector is sector 1, the green one is sector 2 and the blue one is sector 3. Let's also say sector 1 isn't drawn yet so I draw it counterclock wise. DB gets confused with sector 1's linedefs merging with sector 2's linedef and thus, thinks that sector 1 is part of sector 2. This results in sector 1 sharing the same properties as sector 2, the linedef connecting the two sectors having wrong sector references and multiple "sector not closed" errors. Further more, no matter how I draw sector 1, sector 3 will be inside it. But DB does not fix sector 3's linedef references once sector 1 is drawn. Sector 3 still thinks it's part of the previous sector it's in, resulting in even worse unclosed sector errors. You see the problem here? It makes drawing sectors very hard when you're dealing with a lot already.
Furthermore, moving a sector inside another also does not fix the linedef references, making it impossible to put an existing sector inside another without having to edit the references yourself. Moving a sector next to another, trying to merge the linedefs of the two sectors, will also confuse DB and mix up more linedef references. I must say, DB has gotten quite buggy as of late...
Bugs aplenty
Thanks for those bug reports/suggestions, JJames19119. One question: is your information bar running along the top or bottom of your map, or is it down one of the sides? The texture previews weren't being updated correctly when it was vertical (fixed for the next build), which might be the reason for your first problem. It could also be the cause of your second, although I've yet to investigate that. Thanks.
EDIT:
When drawing the magenta line, did you click on all the vertices A, B, C and D in turn, or did you move straight from vertex A to D? If the latter is the case, I can reproduce the problem; if the former, I'll have to look a little harder.
EDIT 2:
Thanks for those bug reports/suggestions, JJames19119. One question: is your information bar running along the top or bottom of your map, or is it down one of the sides? The texture previews weren't being updated correctly when it was vertical (fixed for the next build), which might be the reason for your first problem. It could also be the cause of your second, although I've yet to investigate that. Thanks.
Um... erm... *hides*JJames19119 said:
EDIT:
When drawing the magenta line, did you click on all the vertices A, B, C and D in turn, or did you move straight from vertex A to D? If the latter is the case, I can reproduce the problem; if the former, I'll have to look a little harder.
EDIT 2:
Sorry about that. It'll be fixed in the next build. For the meantime, adding this line to Builder.cfg should solve the problem:Cy-Chan said:
Code:
show3dsechighlight = 1;BlazingPhoenix
AAAAAAAAAAAAA
This is the strangest, most annoying thing I've ever encountered: When I draw a sector in a different area, sometimes it'll count some lines in a different sector as part of the sector I just drew, what's all this about?
Re: Bugs aplenty
Indeed my information bar is running across the side so I guess that ends that. :P
I clicked on all four vertices in order because I know from experience DB doesn't stitch vertices going straight from point A to point B if there are other vertices in the path.
Indeed my information bar is running across the side so I guess that ends that. :P
Oogaland said:
When drawing the magenta line, did you click on all the vertices A, B, C and D in turn, or did you move straight from vertex A to D? If the latter is the case, I can reproduce the problem; if the former, I'll have to look a little harder.
I clicked on all four vertices in order because I know from experience DB doesn't stitch vertices going straight from point A to point B if there are other vertices in the path.
Left click. I don't believe I've ever actually closed a sector with a right click, what does that do? o_o
It creates all the linedefs you've drawn, but doesn't create a new sector, and doesn't adjust the sector references on existing sidedefs. I haven't the faintest idea why anyone would ever want to do that, though. I mention it because closing with a right-click in the example you described also leads to the detailed symptoms. It's possible that the no-new-sector code is being called mistakenly for whatever reason. Anyway, thanks; I'll go and see whether I can find out what's going wrong.JJames19119 said:
What I'm reporting is likely a suggestion more than a bug but SRB2DB doesn't notify you that a linedef is missing textures when a ceiling with the flat F_SKY1 is covering it. While this is normal behaviour in DB, in SRB2, F_SKY1 is more or less an "invisible" flat, so any linedefs the sky ceiling is covering is still visible, making the Hall of Mirrors effect pop up when you don't set proper textures. What would be nice is if DB told you that you needed a texture on a linedef even if it's being covered by a ceiling with the flat F_SKY1. This makes it to where you can avoid the hall of mirrors effect more efficiently.
- Status