Create a way for ships to be defined in raw text

[danbuis]

Likely JSON or something similar.

I want a plain text file so that the end users can easily make custom ships or make modifications if they want to experiment.

This will need to have everything represented on the card, AND a way to determine the hull zone geometry.

I don't really care how this gets done, as long as it is readable and easy to implement. In a prior implementation I used the distance along the side edge for where the lines hit, and a distance where the 2 front arcs met since those were all easy measurements.

The upcoming munificent AND the Onager have arcs that are actually narrower than the front edge of the base, so we will need a different way to indicate that without adding too much overhead.

[danbuis]

@Sobonis01 let me know if you need some guidance on this one.

When you think you have something reasonable I can teach you how to use this website to get it into the code base. That will be your intro to the wonderful world of git/github.

Do try to keep a lot of relevant discussion here in the appropriate issues, as these are persistant and will serve as documentation as we work on the project.

[Sobonis01]

So take everything on the card put it into a file which can be edited? Including the area and size and shape and arc. Would looking at vassal be helpful in this reguard? For me to learn how to write and object as a text doc.

[danbuis]

That's the gist of it.

Vassal will not be very helpful for this. Vassal is primarily a literal drag and drop sort of process. Rather than parsing a text file to create a CR90B it creates a CR90 token, which is a subtype of ship, and populates fields with values there.

The workflow here will be a Ship class/object will take in the type in the constructor, and grab the appropriate section from the text file. That section will be parsed and populate the fields.

Its a fairly subtle difference, but the biggest advantage of a text file vs setting variables in the classes/objects is that the end users can easily add in the ships from things like DAs shipyard and others. Secondarily it also provides us a single location for data when we need to change something.

Here is a link to my first attempt - https://github.com/danbuis/ArmadaAIEngine/blob/master/shipData Hullzones ended up being defined by where different points were in relation to the front. Since the ship is symmetrical I ended up creating a value for where each pair hit the side of the cardboard, and a value for where they met in the middle. This allowed me to create a set of accurate hullzones with 5 values (ship size, 2 middle intersections, and 2 outer intersections)

At the end of the day, as long as you can come up with a deterministic (always works the same) way to represent a ship, I don't much care what it is, as long as you can explain it so we can implement it.

[danbuis]

@Sobonis01 let's go ahead and pull the conversation back over here, where it is relevant to this issue.

After giving this some thought, I'm not wild about doing angles for 2 reasons. 1) Most of us don't have protractors laying around, and this is intended to allow people to insert custom ships into the game from things like DA's shipyard etc. (This is something you will likely run into once you get to ships that are newer than the 2016 ish ships on your spreadsheet) 2) I'm not sure at this moment how to create the actual hullzone shape on the ship based on the angle and where it is located. Right now my immediate goal is to create those triangles/trapezoids/home plate shapes that are the printed hull zones. I suppose we could make a massive shape from that angle and find the polygon resulting from the intersection of that massive shape and the cardboard base, but honestly I don't have any of that logic written in BBDGamesLibrary yet and wasn't planning to. I'm neck deep in offsets so we can actually create proper polygons for visualizing firing arc ranges etc.

Now, maybe you've already thought through some of those things, that's why we have discussion here, so everyone gets heard and can weigh in. I admit I don't have all the answers, but I do have a decent idea what BBDGamesLibrary geometry packages can and can't do right now.

Right now hullzones will need to be defined as a BBDPolygon, which takes in a set of points. So we need to be able to create a list of points that define the perimeter of a printed hull zone.

We need a shape of the printed HZ for things like LOS calculations and "is this HZ in arc?" sorts of questions.

[Sobonis01]

I dont really have an answer for number 2. As that is above what I know how to do atm. I did see in the code that you got the measuments for the hull sizes. For number one I was going to use a digital protractor and a scan of my Armada cards, or the models from Vassal, and measure out the angles that way. Tonight I can put everything together for one ship tonight less the arcs as as test. Then work on the arcs as I go along. Also we would have to find a way to put the diamond for LOS within the raw text file correct? So on the raw text, would I need to put in location of the dot? The example you gave me too look at has this code in them

FrontArcOffset 0 RearArcOffset 0 FrontArcConjunction 35.5 RearArcConjunction 35.5

I dont know what that means? Is a conjunction arch where 2 lines of a triangle meet? Its been over 20yrs since I did Geometry but I can learn it. Also the with Specials arcs like on the OSD we might need something different as we will have 2 overlaping firing arcs. Maybe for that one if we write it something like, Boolean stating is target in speical arc, yes = shoot out of arc 1 if no shoot out of arc 2.

[danbuis]

I'm not worried about specifcs on the second one right now, as in I don't care about code. How would you do it drawing it on paper? We might be able to do some trig and such, but it could get a bit hairy. Idk yet

I'm not opposed to a digital protractor. That is a fine approach for ships in vassal. We can make a different workflow for non-vassal ships later. The tricky part with angles is defining where the angle sits, because not all angles meet at the center, and not all angles meet at the same point. We could conceivable do angle of the front, angle of the rear, where the apex of them sit, and build the rest from there. Maybe.

FrontArcOffset 0 How far from the front corner does the hull zone line hit the cardboard edge RearArcOffset 0 How far from the rear corner does the hull zone line hit the cardboard edge FrontArcConjunction 35.5 How far from the front of the ship do the front hull zone lines meet RearArcConjunction 35.5 How far from the rear of the ship do the rear hull zone lines meet

This made building hull zones super easy as I could make the front arc of every ship by defining the following points (-SMALL_BASE_WIDTH/2, SMALL_BASE_LENGTH/2 - FrontArcOffset) Where the hull zone line meets the left edge (-SMALL_BASE_WIDTH/2, SMALL_BASE_LENGTH/2) Front left corner (SMALL_BASE_WIDTH/2, SMALL_BASE_LENGTH/2) Front right corner (SMALL_BASE_WIDTH/2, SMALL_BASE_LENGTH/2 - FrontArcOffset) Where the hull zone line meets the right edge (0, SMALL_BASE_LENGTH/2 - FrontArcConjunction) Where the two front hull zone edges meet

In the case of the nebB or transport where the arcs go to the corners the 1st and 2nd points are effectively the same.

[danbuis]

Oh, if you want to adopt something like the above, feel free to make variables that you feel would be more descriptive. Offset and conjunction are drafting ish type terms, and probably not normal words.

[danbuis]

Feel free to toss a boolean or something in to the arc definition if you'd like for when we eventually incorporate the OSD. Honestly that is so far ahead right now that I'm not super worried about it. You could also assign names to the arcs and we could work things that way. ie somthing like {HullZone: { Name : Front VARIOUS GEOMETRY THINGS __}
}

Could also make it easier to make the SSD as well

[Sobonis01]

Had to make this on notepad

Gladiator 1 Faction Empire Size Small Points 56 Hull 5 Defense token Br RD Ev Command 2 Squad 2 Eng 3 Nav chart Speed 1 = 2 Speed 2 = 1 1 Speed 3 = 0 1 1 Front Arc RRKK Side Arc KKKK Rear Arc RK Anti Squadron B Upgrade Title Officers Gunnery Support Ordnance Front Arc 72.5 Apex 35 Side Arc 110 Apex -40 Rear Arc 67.5 Apex 45

Still working on the Arcs I used a calculator program to find the apex of each arc, assuming 2 legs of the triangle are the same.
I might going off into non sense land and this is useless, but I wont know unless I ask try.

[danbuis]

What does apex mean here? I realize ive been using that word amd not really explaining it. My usage definitely is different that yours here.

[Sobonis01]

I thought apex meant this

In an isosceles triangle, the apex is the vertex where the two sides of equal length meet, opposite the unequal third side.

I used this to find it

https://www.easycalculation.com/analytical/apex-angle-isosceles-triangle.php

[danbuis]

Cool, turns out we are using it the same, im just communicating poorly.

For the front and rear arcs the angle on your spreadsheet IS the value of the apex angle. I still need to know WHERE the the point created by the apex angle is.

[danbuis]

Could you also put a weird char like a ~ or a | between the label(key) and the quantity(value)

That will make it easy to parse each line into key, value.

camelCaseing the name of each line would also be nice so that when we retrieve a value we can do something that looks like a standard java variable. ie ship.attributeDict.get("hullValue")

[danbuis]

Lets also do shipName~Gladiator 1 or an equivalent instead of just gladiator1 so that we remain consistant with [key][weird middle char][value]

[Sobonis01]

Ships as Raw.txt

So what I did was change what we had talked about. If we can find out the point meets with trig that is cool or we can go back to the offset as well.

Waiting for my brother to reply

[danbuis]

Either angles and the location of the center of the angle OR the offsets is fine with me. I've got logic tested and ready to use from the backend library at this point.

A few questions about the coordinates used above... With the acclamator, vertex O at coordinates (249, 250).... What do those mean? Is (0,0) the front left corner of the ship, or of the window of the on screen protractor?

Either way that will need to get translated/corrected to the same scale as the values we have for the game constants for ship sizes (ie into millimeters) for those coordinates to be useful.

Honestly offsets is probably a smidge easier, at least I think so, because people can toss a metric ruler onto their cardboards to get useful values and do less fiddly math for inputting custom ships.

From the perspective of programming things in, its going to be basically the same, as long as the angles and coordinates have a coordinate space with a reasonable scale and origin.

[danbuis]

Oh, work on some of your names for the values. You have 2 things named "Front Arc" I'd like those to have different maybe more descriptive names. Maybe Front_Armament or Front_Angle.

[Sobonis01]

So dumb question. To measure offsets I would take a ruler and measure the distances between the arcs and the edge of the card board? If so that is a lot easier. I agree I ran into a problem with the acclamator with measuring in degrees. Is the note pad doc ok for now?

[Sobonis01]

It’s all making sense about the arc offsets and conjecture arcs. Let me play around with it this week.

[danbuis]

Yeah. I think I just used a ruler and measured how far from the corner of the cardboard things hit.

Overall I'm satisfied with the structure of the notepad doc. I saw a few typos, but that can wait.

Next big step is to get you confortable with using github desktop to create a new branch so you can have a snapshot of the current code base to play with and upload the text document that way.

[Sobonis01]

I think I found out how to do the off sets

this is for a GSD let me know if this work, I put in the comment so anyone working on it other than me will know what I am taking about and it helps me out.

FrontArcOffset|8.7 //How far from the front corner does the hull zone line hit the cardboard edge// RearArcOffset|7.5 //How far from the rear corner does the hull zone line hit the cardboard edge// FrontArcConjunction|29.8 //How far from the front of the ship do the front hull zone lines meet// RearArcConjunction|32.1 //How far from the rear of the ship do the rear hull zone lines meet//

Also this one is for the CR 70 as well FrontArcOffset|15.1 //How far from the front corner does the hull zone line hit the cardboard edge// RearArcOffset|5.2 //How far from the rear corner does the hull zone line hit the cardboard edge// FrontArcConjunction|36.9 //How far from the front of the ship do the front hull zone lines meet// RearArcConjunction|26.3 //How far from the rear of the ship do the rear hull zone lines meet//

Let me know what you think if I got the offsets right I can start mass production

[danbuis]

I'm going to say go ahead and just do it. I think the conjunction values look suspect, but it will be easier to tell when we have something visual. I would expect the 2 conjunction values to sum up to 70 or so, since the arcs all meet in the middle, amd the small length is 70.

[Sobonis01]

I dont know if they will add up to 70. I did check the Vic 2 you listed as an example vs what I had. Your Vic 2 was 95.24, mine was 90.1 for the conjunctions. But we can talk about it on Tuesday, I will start loading them up.

[Sobonis01]

Reuploading it as I had a error in the Quaser Fire Carrier. Ships as Raw.txt

[danbuis]

Any chance we can get the type of ship in here too, ie quasar or cr90, in addition to the varient. That would make it a lot easier to match up the right image of the ship.

[Sobonis01]

I can do that, Also I think I should probably add in the upper grades part instead of just saying title, I should put CR90 title. Reason being that way we won’t have a Cr 90 flying around with a demolisher title. As right now every title it’s not specific to the ship. If I’m understanding programming right.

[danbuis]

That sounds reasonable. I had planned to put a restriction on the upgrade card object, but this works too. I can't come up with a compelling reason to use one over the other.

[Sobonis01]

Ships as Raw.txt

[danbuis]

At a quick glance at the above file, let's go ahead and add the keyword line to the OT ships, make it a keyword|None so that all ships have the same set of data.

One of the consulars has lowercase dice, it should probably be uppercase.

Tell me about the munificent front arc. I know that the front arc offset isn't 8mm from the front corner along the side edge, it hits the front edge.

[Sobonis01]

The munificent front arcs are odd. They have that middle section goes sideways down the middle.
So i measured the difference from where the arcs end to where touch the end of the card boards size. Otherwise I am not sure how to account for the Arc offset.

[danbuis]

RE: the muni arcs...

Huh, I didn't know that it also had the horizonal thing there too. Let me think on that.

We can always add extra fields that are only used for the Muni and are 0 elsewhere, like a sideways offset. So instead of having a front and rear conjunction, we also end up having a left and right one, describing how far from center the point is.

[Sobonis01]

On some of the ships as have the same idea but it is vertical. Which is why I included in there //there is a x gap between front and rear arc meeting//

[danbuis]

Yeah, I knew about the vertical one.

In the interest of time feel free to leave the munificent alone for now and we can address it in a specific issue.

I'll mark that conversation as resolved on the pull request.