Fixed The Console Command "GRID" is broken

[Monster Iestyn]

Having recently discovered what the console command GRID actually does in SRB2 through finding where it's used in the source code, I decided to try it out for myself... (I'm assuming this command is supposed to be like snapping Things to a particular grid size in SRB2DB, except within SRB2 itself, using Objectplace mode.)

To my disappointment, I soon found out how seemingly broken it is:

(With "GRID 1" set - compare the x and y positions shown in the objectplace hud to the x and y positions shown in the console message text)

These two examples are hardly ridiculous compared to what you get if you decide to randomly place Things anywhere around a map, whatever the value after "GRID" is set to. Even changing your Z position affects the position the chosen Thing is spawned in. =V


(tl;dr: SRB2 nearly always seems to place Things in Objectplace mode anywhere but near where you intend to place the chosen Thing Type, if GRID is set to anything but 0)

 

[Callum]

I don't think this command is ever likely to be fixed.

 

[Shadow Hog]

I don't see why not. Seems like it'd be a simple enough to debug.

 

[pastel]

Probably the same reason as this.

 

[Fawfulfan]

If it's useless and you aren't going to fix it, are you at least going to get rid of it for 2.1? There are all kinds of useless development tools in there, at least half of which aren't any real use to development, and it only serves to make the Wiki list of console commands longer.

 

[Callum]

I don't see why not. Seems like it'd be a simple enough to debug.

I guess so, but first I need to know what this command is actually supposed to do, since this topic and the Wiki both have kinda ambiguous explanations. :P Because of this, I'm doubting the usefulness of the command.

 

[Shadow Hog]

Well, my assumption is that you specify a "grid size", and then whenever you place an object in objectplace, it'll snap to the closest grid node (eg: grid size of 64, you place one at (356, 224, 48), it's moved to (384, 256, 64) - all the closest relevant multiples of 64, rounding up at the midpoint). Probably best used with intervals of 8-64, really.

From the looks of things, though, it's stuck at 4096, which is woefully inaccurate.

 

[SSNTails]

Well, my assumption is that you specify a "grid size", and then whenever you place an object in objectplace, it'll snap to the closest grid node (eg: grid size of 64, you place one at (356, 224, 48), it's moved to (384, 256, 64) - all the closest relevant multiples of 64, rounding up at the midpoint). Probably best used with intervals of 8-64, really.

You are correct, sir.

The original reason OBJECTPLACE was even invented was so that you could 'JOHNNYFUNCODE' and collaborate placing THINGs in a map via netgame.

---------- Post added at 11:42 PM ---------- Previous post was at 11:38 PM ----------

Oh yeah, and to place the stuff for NiGHTS mode. Man, that would have been frustrating otherwise.

 

[Ezer'Arch]

(I know it's a bit off-topic, since the relevant topic was locked before I post anything there, so I'm going to post here.)

There are all kinds of useless development tools in there(...)

Speaking of "useless" development tools...

Yeah, it's AutoMap working in the 2nd largest SRB2 map: ERZ2.

But, how did I get it working if any map larger than DSZ1 just shows a little point in the middle of screen? I merely zoomed in.

When you start a map and enter the AutoMap, it'll somewhat try to display entire map on the screen at the 1st time. If the map is really large, the AutoMap breaks, and we just say "baw, it's broken" and exit it. But, if the AutoMap tries to display only 30,000 FU-wide area of the map, the tool will work fine. My idea is simply to limit the AutoMap zoom-out in about 30,000 FU range and no one will whine about it anymore.

(Plus, I'd say someone already discovered that it's possible to fix the AutoMap by same "workaround" and implemented it in his little toy.)

 

[Monster Iestyn]

From the looks of things, though, it's stuck at 4096, which is woefully inaccurate.

Not neccessarily - even changing the z position can change the x and y coordinates the object spawned at, IIRC.