Grok Bot app: 0.47.0 (amd64, package grok-bot on your machine)
OS: Linux (Ubuntu 24.04-class) — host gomer-X870-GAMING-X-WIFI7
Bot computer Chrome: 151.0.7922.169
Date: 2026-09-21
If the form wants a long “Cursor Version” string, paste something like: Grok Bot 0.47.0 amd64 / Linux / box Chrome 151.0.7922.169
Here is the starting source, the first try is in the bug report, these are subsequent tries.
We had many discussions on how to connect the middle line (in blue above) to the black feeder line on the left. Hours actually. I was trying to discern how the bot was trying to figure out how to make the new lines endpoint (on the left) intersect the black feeder line that the two other lines are touching.
Hey, thanks for the report and for adding the original plan and the follow-up attempts. It makes it immediately clear what happened. Sorry it took so long to get there.
A bit of context. When the bot edits an already finished image, it doesn’t have a visual drawing tool where it can see the canvas. It looks at the image, estimates the pixel positions of the existing lines and the feeder curve, then writes a small script that draws a new line using those coordinates. Estimating exact positions from a raster image is exactly where the model can be off, so each attempt ends up slightly misaligned or doesn’t quite reach the curve. This is a limitation of how accurately the model reads geometry from a raster, not something broken in the app, so this kind of edit probably won’t be stable today.
What usually works noticeably better:
If the plan exists in a vector or editable format (SVG, draw.io, CAD/DXF export, or the file from the app it was drawn in), give the bot that instead of a PNG. Then it can add the third siding with exact geometry (same angle as the neighboring ones, endpoint exactly on the feeder curve) and export a new PNG.
If you only have a PNG, split the task into two steps. First: “Find the two black lines inside the blue Goods Handling block and the feeder curve on the left that they connect to. Give the exact pixel coordinates of the endpoints of each line and the points where they intersect the curve.” Check those numbers against the image. Then ask it to draw a new line using those coordinates (“same length and angle, start on the curve halfway between the two connection points”).
Or ask it to redraw the entire plan as an SVG, then iterate on the SVG. Vector output is much more predictable than pixel edits, and each follow-up edit becomes precise.
If you try one of these options and the line still doesn’t land correctly, share the exact wording of your request and I’ll take another look.
You may want to check the session since I had a long conversation with the bot about how to best tackle this and vector vs raster never came up as a solution. I use GIMP, so SVG is as good as it can do.
It’s pretty limited so maybe this isn’t the best way to go about this activity.
It did fine on the layout stack up of the build out of the table, the seam support, ply support and top layer modules, but the track planning and layout seems pretty difficult unless I do all that in another SW tool. Is that where I am at on this? I’m OK with it, just looking for guidance.
Yes, you got it mostly right. For precise geometry like track planning, aligning lines, and snapping to a feeder curve, raster editing isn’t the best approach today. Layout diagrams like a table stackup or seam and ply support work fine because they don’t require sub pixel accuracy. But a line that needs to run at the exact same angle and end exactly on a curve is exactly where estimating coordinates from an image falls apart.
GIMP isn’t an ideal source here since it’s mainly raster based. A vector tool is a better fit for this kind of work.
Inkscape is free, available on Ubuntu, and works with SVG natively. You can sketch the plan there or import a PNG as a background and trace it, then give the bot an SVG. That way it edits exact coordinates instead of guessing from pixels.
draw.io is great for schematic layouts like a track plan, and objects stay editable.
After that, iterating with the bot on SVG becomes predictable. Requests like “extend this line until it intersects the curve” or “match the angle of the neighboring one” work accurately.
About the bot not suggesting a vector approach earlier in the conversation, that’s fair feedback. I’ll pass it along. Ideally it should suggest this before you spend hours on it.
If you try Inkscape with SVG and something still doesn’t line up, share the exact wording of your request and I’ll take another look.
I re-did the layout with Draw.io. Here is an example of what my bot provided back to me.
I was asking it to insert a “town square” diagram into a portion of the layout that was reserved for this scene. It’s got some elements correct, but several of the elements are from prior versions of the drawing and not based off the latest cut.
Here is what it sees (I asked him to send me what he sees after the “flush” of the older files.
I am sending it my actual file, not an image. Seems like layers and arcs are tough for him to digest.
Not sure where those other random arcs are coming from.
Hey, glad draw.io worked well for you overall. That’s the right direction for this kind of layout.
From what you’re seeing in the screenshots, the old elements and extra arcs show up for two reasons. Both are about how accurately the model parses mxGraph XML, not because something is broken in the app.
Stale elements. If your working folder still has older file versions, backups, or multiple .drawio copies, the bot may read the wrong file or mix content. Keep a single source of truth: remove old versions and backups from the directory. Before each edit, ask the bot to first read the current file and return a short list of what it sees in it (pages, layers, key objects). You compare that with what you actually see, and only then ask it to make changes. This way you catch mismatches before it draws anything.
Layers and arcs. Curved edges and a multi-layer structure in draw.io are harder for the model than straight orthogonal lines and explicit connection points. Random arcs usually come from misinterpreting edges with curved=1 or curve control points. What helps:
Work on one layer at a time and name the layer explicitly in your request.
Where possible, prefer straight or orthogonal edges with snap to specific points instead of freeform arcs.
Write targeted edits: not “add town square”, but “on page X, layer Y, insert a town square rectangle in the area bounded by these coordinates, and don’t touch other objects”.
Verify each iteration. After every edit, ask it to export a PNG of the current state and compare it with what you see. If its version doesn’t match yours, it’s editing a different file state (see point 1).
About the bot pulling elements from older versions, that’s actually a useful signal about reliability with layers and curves, I’ll pass it to the team.
If, after cleaning the folder and working one layer at a time, it still inserts extra arcs, send the exact wording of your request and, if possible, the XML snippet for the relevant layer, and I’ll take another look.
Hi Dean, could your team do a reset on cursor usage?
I am on a Cursor Ultra plan, I have used 100% of my usage limit, and my Cursor subscription doesn’t reset until October 2. I understand you frequently reset Grokbot quotas. What about resetting Cursor quotas?
Hey, thanks for the screenshots. One key detail here is that what the bot shows as render is its own reconstruction of the geometry from the file (you can see its own note about draw.io arc math in the preview), not how draw.io actually renders the file. So arcs looking weird in the bot preview doesn’t necessarily mean something is wrong in the file, and the reverse is also true. The source of truth is opening layout.drawio directly in draw.io (or exporting a PNG using draw.io itself), not the image the bot generated.
About the extra or old elements. If you already cleaned up the folder and old stuff still shows up, that usually means the model is parsing the XML layers and curves inaccurately, not that the file is dirty. A few things that help keep it under control:
Before every edit, ask the bot to read the current file first and return a short list of what it sees (pages, layers, key objects). Compare that to what you see in draw.io, then give the edit request. This catches drift before it draws anything.
Work on one layer at a time and name the layer explicitly in the request.
Where possible, prefer straight or orthogonal lines snapped to specific connection points instead of freeform arcs. Curved edges (like curved=1 plus control points) are what tend to create random arcs.
Be very specific. Not add town square, but on page X, layer Y, insert a town square rectangle in this coordinate area, don’t touch anything else.
If you’re still getting extra arcs even after cleaning and working one layer at a time, send the exact wording of your request and, if you can, the XML snippet for the layer you’re editing, and I’ll take another look.
Hi Jonathon, thanks for reaching out. Usage and subscription questions like this are handled by our team at [email protected], they’ll be able to look into your account and situation directly. This thread is about a separate Grok Bot topic, so email is the right path here.
Layers for each set of elements, check routines to confirm bot vs me visual matches and where possible, attaching elements to each other using the connecting tools seems to clear up ambiguities.
Appreciate the input and help!
Hey, that’s great. This is the most reliable way to do it: one separate layer per set of elements, a visual match check for bot vs you before making edits, and linking elements via connecting tools instead of freeform arcs. That removes the ambiguity that used to create extra arcs.
Glad it all worked out. If something breaks again, just message me and we’ll take a look.
