Jump to content
SubSpace Forum Network

Recommended Posts

Posted

* I asterbrushed some 'roids (one sweep). Did undo and still had myself 30 roids. Only the big ones, though.

* Also, the small roids are exactly the same, so why bother even having two options.

* Bad label - fixed

* Delete with delete key after using magic wand -> undo does nothing.

Posted

Also to mention that the bottom portion of the grid at resolutions as high as 1920x1440 (maybe it begins to happen at 1600x1200) are not drawn at all. I played around with my window by increasing/decreasing the heighth of the window while being zoomed out completely. It's almost like part of the grid is tilted and there's a maximum visibility making the bottom portion completely unrendered.

 

I was also thinking that the radius the spray brush emits tiles/objects is too small, maybe make something to define its cubic radius?

 

Another one, I think the spray can sprayed too many tiles/objects too quickly making it just a 'random generator for a given area' instead of a real spray tool where it 'fades' in from no tiles to filled tiles if you catch my drift. :\

Posted
* Also, the small roids are exactly the same, so why bother even having two options.
Actually, they use a different graphic file (over#.bm2), and if they are all the same, their animation is synchronized and its kind of redundant, having the second one adds some diversity in the animations.

Plus, a mapper could use one of the 2 types of asteroid for something else by changing its animation, then he wouldnt want that type of asteroid to be sprayed with the airbrush

 

 

It's almost like part of the grid is tilted and there's a maximum visibility making the bottom portion completely unrendered.

well, if you're zoomed out completely with that kind of resolution, the whole 1024x1024 map should fit in your view, so maybe the lines that were not drawn just didn't need to because they were out of the map?

Check the coordinates where the grid lines arent drawn, and try taking a screenshot too... It's hard for us to debug high-resolution issues since both our computers cant have such a high resolution

 

I was also thinking that the radius the spray brush emits tiles/objects is too small, maybe make something to define its cubic radius?

 

Another one, I think the spray can sprayed too many tiles/objects too quickly making it just a 'random generator for a given area' instead of a real spray tool where it 'fades' in from no tiles to filled tiles if you catch my drift. :\

You can use the line width to change the size of the spray

However, we will slowly add more tool options to every tool, and eventually you will be able to define the airbrush size accurately, maybe even change the shape (square, circle).

Another setting of the airbrush will be the "density", so you will be able to adjust the rate at which tiles are sprayed

Posted

No it's not. I'm on a 1920x1440 resolution and I can see it just fine. Any lower resolution should infact see it better. The point is that when it's window heighth or width is adjusted at high resolutions, it will have rendering glitches of the grid.

 

If you don't understand the point of the image and what I'm trying to show, you're wasting time.

Posted

i think he was saying that the image was too small to see what is actually happening

and check for updates, see if your problem is fixed with 1.2.66 please

Posted
i think he was saying that the image was too small to see what is actually happening

and check for updates

O_o

 

Look at that animation. In that animation, look at the south part of the grid. Notice how each time the heighth of the window is decrease what it does to the south part of the grid. Don't you see the grid disappearing?

 

Anyway, I shouldn't attempt to assume anymore, as I could easily be wrong. The image isn't anywhere near small enough to not see the grid draw distance problem.

 

As for v1.2.66 fixing it: Nope. Look and learn. blum.gif

http://www.hlrse.net/Qwerty/anim_dcme_bug2.gif

In this one, each frame I am increasing the width of the DCME window. Look what happens to the grid each time I do that. ;o

 

To do the following bug you have to select a few tiles, like the little room you see in the animation. I move it somewhere, then I use middle click to move the view around. After doing that, I just move the selected tiles around.

http://www.hlrse.net/Qwerty/anim_dcme_bug3.gif

 

This animation I have to move my select atleast 1 tile, then I can use my middle click (clicking my scroll wheel) and on the radar it'll move the drawn object at a diagonal offset each time I click it. Look carefully at the radar.

http://www.hlrse.net/Qwerty/anim_dcme_bug4.gif

 

This screenshot also illustrates something, infact another thing also came to my attention. First I will begin with the usual - look at the radar. The red square shows where my camera is. You obviously don't see anything passing through this selected room behind it. This is again performed with the last bug (above this paragraph; previous animation).

http://www.hlrse.net/Qwerty/dcme_middleclick_bug.gif

 

The other thing that came to my attention - the Wall tiles. I have the eraser selected as my secondary, and one of the walltiles as my primary - I have a base or room made from a walltileset... If I delete part of the wall, it won't automatically fix/adjust those tiles properly.

 

When I flip or rotate an object that was made with walltiles, it doesn't fix itself either, like the previous screenshot given shows.

Posted
http://www.hlrse.net/Qwerty/anim_dcme_bug2.gif

In this one, each frame I am increasing the width of the DCME window. Look what happens to the grid each time I do that. ;o

hm ok.. . the part to the right is normal I guess, since it is beyond the 1024 limit... but the grid shrinks up... thats weird ; but I might know what the problem is now, ill check later

 

Anyway, I shouldn't attempt to assume anymore, as I could easily be wrong. The image isn't anywhere near small enough to not see the grid draw distance problem.
true, but it's too small to see anything else blum.gif anyways...

 

To do the following bug you have to select a few tiles, like the little room you see in the animation. I move it somewhere, then I use middle click to move the view around. After doing that, I just move the selected tiles around.

http://www.hlrse.net/Qwerty/anim_dcme_bug3.gif

I don't get it.. they just.. move around? what's wrong?

 

The other thing that came to my attention - the Wall tiles. I have the eraser selected as my secondary, and one of the walltiles as my primary - I have a base or room made from a walltileset... If I delete part of the wall, it won't automatically fix/adjust those tiles properly.

 

When I flip or rotate an object that was made with walltiles, it doesn't fix itself either, like the previous screenshot given shows.

True, but you can repair them easily using "Convert to walltiles", with the "Redraw walltiles" option , or with switch/replace

To have it repair them automatically, we'd have to tag each tile to see if its a walltile or not i guess... for now it just sets the correct tilenr according to what is around it... and making them always adjust could give problems with some tiles you do not want to be walltiled.. hm

Posted
I don't get it.. they just.. move around? what's wrong?
Look at the radar - it's not in the correct location because I move the camera around with my middle click. If I hadn't middle clicked in the first place it wouldn't be in the wrong location in the radar.

 

If you continuously middle click on the selected objection after you move it atleast one tile, you'll notice that in the radar your object is moving when you aren't even actually moving it. It will usually more north east (diagonally) like 1 to 2 pixels.

 

You should be able to accomplish this trick on any resolution, if not, I guess it's a high resolution bug.

 

true, but it's too small to see anything else tongue.gif anyways...
You aren't sopossed to see full blown detail of the shiny buttons and the beautiful text, "File" and "Options," also to mention the window !@#$%^&*le. If I would have included a giant 1920x1440 image, it might have a large file size and would be more difficult to see two things at once two of the bug reports might require. I have resized it as small as needed, where you can still see the objects on the grid and in the radar. If you need help, use the Magnifying gl!@#$%^&* tool Windows XP comes with. blum.gif
Posted

Meh. You do know that it'll highlight in white the borders of the map (even when zoomed out)? I think after the white, no more of the grid should be rendered. For example - none of this stuff. blum.gif

http://www.hlrse.net/Qwerty/dcme_nogridhere.gif

 

Also I found another bug. ;) I tried to replace this one tile in my maze (which takes up the whole map perfectly) with walltiles, only the first row of tiles of the maze was replaced with my walltiles and I also got this error.

http://www.hlrse.net/Qwerty/dcme_mazetile.gif

 

Part of the grid isn't rendered (again, the maze takes up the entire map leaving 3x1024x2 tiles extra (amazing eh?).

http://www.hlrse.net/Qwerty/dcme_gridagain.gif

Posted
the grid problem is because a width value has been used where a height should be there
Yeah that's what I thought.. did you fix it?

 

 

Meh. You do know that it'll highlight in white the borders of the map (even when zoomed out)? I think after the white, no more of the grid should be rendered. For example - none of this stuff. blum.gif

http://www.hlrse.net/Qwerty/dcme_nogridhere.gif

 

Also I found another bug. ;) I tried to replace this one tile in my maze (which takes up the whole map perfectly) with walltiles, only the first row of tiles of the maze was replaced with my walltiles and I also got this error.

http://www.hlrse.net/Qwerty/dcme_mazetile.gif

 

Part of the grid isn't rendered (again, the maze takes up the entire map leaving 3x1024x2 tiles extra (amazing eh?).

http://www.hlrse.net/Qwerty/dcme_gridagain.gif

First bug should be fixed with what Drake just said

Second bug... you were using 1.2.66 ? If so, I'll take a look ; else, I fixed some of these errors with 1.2.66

... oh nvm I think I know what the problem is... there was a tile at (1023,0) right? If the problem is what I think it is, it will be easily fixed

Third bug = First bug = probably fixed by now

 

(we should include the version in frmGeneral's !@#$%^&*le ; Drake Continuum Map Editor version major.minor.revision [Map name] )

 

and i'm thinking about recoding the entire walltiles stuff... i made them kinda quickly, and i made them just to be able to draw walltiles at first, then added stuff to them to work with conversion, switch, etc., but i had to add all these like.. separatly.. so the code is kinda spaghetti-like now... now that I know what I need to have for walltiles, i have ideas to code them cleanly... and it would avoid bugs as the one you just mentionned...

Posted
First bug should be fixed with what Drake just said
It isn't. The 'first' (dcme_nogridhere.gif) and 'third' (dcme_gridagain.gif) in v1.2.66 aren't fixed.

 

grid fixed
Not sure if you are referring to the same thing?

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...