No progress today... well none really. Had a big event at work, added to my 3 hours less sleep the last 2 days due to car issues and I wasn't coherent enough to be productive.

I did add some better messages while the games are loading, so you can see progress and stuff (I will eventually multithread much of that) and made a few architectural decisions (counters will be in 1 big file per race, not hundreds of little files). I was working on dynamically changing render order of units within a hex, when my brain gave up.

Plus, Ted looks like he is about to do his turn, which could impact dev time as I get a C8V shoved up my rear to help loosen me up for the B10 next turn.

By Ted Fay (Catwhoeatsphoto) on Wednesday, March 06, 2013 - 10:37 am: Edit

LOL, that's funny.

By Eric Smith (Badsyntax) on Wednesday, March 06, 2013 - 02:11 pm: Edit

Not to the person WITHOUT the battleship :P

By Eric Smith (Badsyntax) on Thursday, March 07, 2013 - 08:19 am: Edit

A little progress last night, mostly due to entering in all the Early Beginnings Andromedan variants, as well as all my own variants (they are marked separately, and of course all unpublished).

But after playing with queues, stacks, and all manners of sorted lists, I figured out the simple process of render order, where you can move a unit to the front or back of the list. I was trying to be too complicated I think. Oh well, fixed now.

Next is moving units around the map. I can find which unit the mouse is over simply enough (by using the render order and location/size of the counter) but I'm not real confident it'll work smoothly yet. We'll see.

Next will be cut/paste. This is really easy, I can do it in under an hour, but need stuff on the map first

I moved the 15,000 counters I have currently supporting this to my local hard drive, decreasing load time on my machine from about 13 seconds, to 5. Many of those images are duplicates, or the old copies, or unofficial, so it is probably closer to 3000 used. Though it'll take a while, I want each race to have a single large PNG with all their counters in it. This will speed up load times a LOT, save memory, and I think be a better solution in the long run. Not sure when I'll do this, but I am making it a requirement before an alpha gets released due to the amount of files I'd be sending testers (all 2.5 of you who actually emailed me).

Ted made a couple booboos on his economy form that I noticed (honestly I think this is the first time I really looked at them), as I have errors on nearly all of mine. But it got me thinking again about the economy sheet. I want to integrate this in with DFE, though I think it'll be a big project as I'll have to have some rules implemented, mostly construction based, and have lots of questions that I'd need answered much faster than typical responses so it wouldn't stop development. We'll see on this, I can easily push it back until DFE is much farther along.

If anybody is any good at pixel graphics, I made these:
Fed CA
Fed CA Crippled
which are used to make counters for the Federation CA type ships. Anyway, if you want to give it a try, load them in paint and see if you can make all the hulls for a specific race. The Andromedan's need redone to be a bit smaller, the early years stuff for all races either needs done, or in the case of the Feds, needs more colors. All the Omega races will need them too, and I have nothing at all now. Any time I spend making these directly cuts into time working on DFE, so if you wanna see DFE and can spare a few minutes here and there, knock out a race, at least the uncrippled ones.

By Shawn Hantke (Shantke) on Thursday, March 07, 2013 - 02:12 pm: Edit

I really like how the crippled one is all beat to heck.

By Eric Smith (Badsyntax) on Saturday, March 09, 2013 - 12:20 am: Edit

Ok, a bit of progress today, then I got bored with it and am moving to something else for the evening.

I have counter selection done, as well as movement. However, I still need some marker on the selected counters so you know what you picked up. I'm guessing I'll just draw little boxes on the corners, or perhaps draw a major border around the counter to show its selected. This should be easy to do, just got bored tonight.

I also need the little rectangle showing the destination of the "picked up" markers. This is a bit harder. If I knew what I was doing, it'd be done in 5 minutes, since I don't it'll be 100 different compiles and executions before I come across the right x/y/zoom/matrix coordinate sorta system.

I have a rubber band when you draw a box with the right button, but it doesn't select stuff underneath. This should be pretty easy, just get a generic range of hexes the band could be around, then go through the units within those hexes to see if they fall within the rubber band "box".

Lastly the cut/paste, which is super duper simple, only a few minutes, just want to get all the other movement/selection stuff done first.

Once I get those 4 little things done I have some cleanup to do, and moving the thousands of images over to just a dozen or so files, and it'll be ready for alpha. *Maybe* still on track for this weekend, depends on various real life events.

If there are any features ya'll would like to see (on top of extensively detailed unit counting), better chime in now before I make some architectural decisions that can't easily be reversed.

By Pete DiMitri (Petercool) on Saturday, March 09, 2013 - 09:47 am: Edit

I don't know all the features you have, but the obvious ones that come to mind are:

1 - ship pin count
2 - supply status
3 - economics and also keeping track of long-term capture for annexation.
4 - exhaustion
5 - strategic movement - keeping track of what counts.

By Eric Smith (Badsyntax) on Monday, March 11, 2013 - 10:21 am: Edit

Cool, thanks Pete, all of that will eventually be incorporated.

Weekend Update:

We had a big storm in Texas that knocked out our power like 6 times Saturday, throughout the day, so coding was just not going to happen

Sunday I worked on a few things. I do have the individual counter pickup/moving working great. I started working on the rubber band box (where you hold down the mouse button to draw a box around units to select them all) and ran into some annoying problems that I should be able to fix next session. So code wise I didn't get very far.

On top of that I found an design issue and I'll have to redesign a bit. Basically, when you move a unit and it ends up over a hex border, the hex border gets drawn OVER the counter. This is because when you move the mouse, it highlights the hex you are over, then when you enter a new hex it redraws the last hex you were in, overwriting any counters there. I know how to fix it, and it won't take long, but it does show that not everything always works as intended

Obviously I didn't get the cut/paste done (which requires all the movement/selection be done first) or the save/load.

I looked at VASSAL again, and again found it very lacking and cumbersome, just like nearly every Java app I've ever used.

I spent quite a bit of time going through Omega races adding some values and ensuring I have the list done. Kind of off-track, but I should be done this evening with it and shouldn't have to look back for a long time.

Now the biggie. Right now, I have 1 app that generates all the ship counters and use it for my online SIT. It works well, and is pretty quick. There are still a very few minor bugs but I can work around them. Anyway, It takes about 5 seconds for my app to currently load the maps, initial fleets, and data for about 1700 units, mostly due to loading all those little bitty counter images. So, in the release, the images will be created dynamically the first time you start the application and a single large PNG created, which will be used from then on. I think this will greatly increase load time. This function is also a dependency before any releases as I don't want to send anybody a zip file with thousands of little bitty images within it. I may increase the counter size from cyberboard just slightly, so all the counters fit better. This is fine as I can scale my hexes to any size I want quite easily.

FYI, right now this whole thing isn't but about 2200 lines of code. The EXE is 324k. The whole download package for F&E, with all scenarios, should only be a couple of megabytes.

I *really* need all the hulls drawn up so I can make the counters.... anyone?

By Andrew Bruno (Admeeral) on Monday, March 11, 2013 - 02:35 pm: Edit

I have a 64 pack of crayons... But no time for coloring.

Great progress Eric! Look forward to putzing with it.
Rock on!

By Eric Smith (Badsyntax) on Tuesday, March 12, 2013 - 12:56 am: Edit

Guess its all me then

Well, I finished adding all the races that actually existed, which included everything from omega and the Borak, to my SIT tonight. This way at least I have a full list of hulls that I'll need to make. I will probably just create a generic 1 per race as a placeholder until I get all of them knocked out.

Tomorrow, time permitting, I'll try to work on the code to dynamically create the counter file as needed. This isn't too hard to do actually, or maybe it is just that I've done stuff like that so often its easy for me.

Once I get the counter thing done, which will speed up dev time as I don't have to wait 5 seconds to compile (that is a long time when you do it a few times a minute sometimes), I'll then finish up the counter movement and selection.

Then I'll do save/load, which again, is pretty easy for now (it'll get more complex when I save EVERYTHING a ship does throughout its service life, but not that much, mostly just bigger data).

Then Alpha to the few people who have shown interest in helping test.

By Mike Curtis (Nashvillen) on Tuesday, March 12, 2013 - 09:25 am: Edit

Eric, I would love to help, but I have no artistic abilities. Not the one...

By Alan De Salvio (Alandwork) on Tuesday, March 12, 2013 - 03:23 pm: Edit

You could take the counter images from Cyberboard. Mr. Bergen did a great job.

By Eric Smith (Badsyntax) on Tuesday, March 12, 2013 - 05:16 pm: Edit

I have no artistic ability either, but this isn't art, these are 20 pixel counters. I jumped in, looked at how they were up close, and within 5 minutes I was able to make little circles and lines that are only a few pixels across to kinda sorta look like the hulls of the ships. Even all black is better than nothing ;)

I guess I'll eventually get to it, for now there will just be a LOT of counters without silhouettes on them.

Another "oops I forgot thing" I gotta fix before an alpha. Right now I grab all the SIT data from my local database, which you don't have access too. Oops! I'll take my raw data for it (3mb), zip it up (150k), and when the app loads it'll download the latest version and use that to populate sit data. An hour or so to knock all this out, mostly due to handling the ZIP. If I downloaded the 3mb raw data it'd be minutes to do. I should be able to knock it out tonight.

I made some updates to my online SIT, so you can sort by things like survey, X-Ship, BG/GL, or shock.

I just finished the code that will create counters upon loading the application, instead of needing thousands of them pre-rendered. This also has the benefit of making it easier to handle captured ships, as I can recolor them without needing to create counters for every possible situation. It will take maybe 30 seconds to load though as it does have to generate 1700 or so of them, and could take 2 minutes to load if you had every race (5000 entries) on a huge map. I may try to cache these in a big binary file locally later. I'll try to multithread this, which with 4 cores could decrease the time by 75%, or in my case, 32 cores could decrease it by up to 97%. This is not a prerequisite for the alpha though, nor the beta, but will be for the release. I could also generate these as needed, so it doesn't create them all at startup, but there would be slight lags sometimes if you opened a new fleet and none of the ships were created yet, but on the second loading the lag would be gone.

I may increase the size of the counters from Cyberboard to make them easier to read and allow more complicated counters (ships like the ACS, VDB , or old Fed CVAs can get a lot of stuff on them). I don't have any hard-coded hex sizes and my map can zoom in so a single hexagon is the entire screen, or the entire map fits on 1 screen, all dynamically.

Oh, and a thought... when you zoom in/out now I scale the counters accordingly. While this is fine for a few percent here and there, when counters are a quarter of the size you simply can't read anything on them and can barely tell what they are. So I was thinking I could keep the counters in the same scale until they no longer fit in a hex, then I could just put a colored box there, with a number representing whatever you choose (ship count, pin count, compot, etc). The number would go away if the zoom was too small to render them. So basically no counter will ever be scaled, just changed to something else when they get too small. What do ya'll think?

Code time for that change is minimal, less than an hour, probably under 15 min.

Oh, and I started with the Cyberboard counters, and they were indeed a good job that helped inspire me, but I am trying to get more diverse hulls, avoiding anti-aliasing, adding all unique hulls, and adding damaged sided graphics for *all* races. My Federation and Tholians are 100% generated from me FYI, and I think they look better. The Klingons are mine too, but a bit too big for CB graphics (I used scale images tho, so they are in scale with each other and the right proportions).

By Ken Kazinski (Kjkazinski) on Tuesday, March 12, 2013 - 08:13 pm: Edit

I look forward to using the next release. Hopefully soon.

By Eric Smith (Badsyntax) on Wednesday, March 13, 2013 - 12:59 pm: Edit

Well I've been tired as heck the last couple days, so coding just isn't happening very well. But, I have been working today a bit. Since not all my code always produces what was expected, here are some "oopsies" I thought looked funny when working on keeping counters the same size, while the map changes. This way you can zoom to a single hex is the entire screen, and move units between fleets and stuff more easily.

Oops #1
Oops #2, even worse!

Here is what the end result let you do:
Not so oops now

Still working on the whole movement/selection bit, its been a real pain and doesn't help that I suck with this part of the coding process.

I did fix the image thing. For now, when you start up a game for the first time, it'll create the counters on your local machine. This could take a minute or two, depending on your hardware. Once done, it'll be much faster next time when it loads the units (<5 seconds on my machine).. It'll probably be faster creating once I actually have all the hulls necessary.

Looks like Saturday it'll be 81 here in Dallas, so I may not get much coding in on such a beautiful weekend. However, if I can just get the movement/selection done to my satisfaction, I'll release a pre-alpha for testing before finishing the cut/paste and save/load parts, which are necessary for a full alpha.

The SIT will still be a lot of work too. I am trying to include everything you need to know about a unit when you view a unit. So things like if the ship can raid or not and which kinds, what rescue tug size it is, how many pods can a tug hold, how big the fighter squadrons are, how many EP it can carry, etc, etc, etc... all of those are stats that right now are often in separate parts of a rulebook, instead of at a quick glance when looking at a ship. I want DFE to show all that data, to help speed up play and reduce rulebook flipping, so it needs to be in the database. Often I find units that I'm just not sure of the values, and its pretty frustrating and very time consuming.

By Eric Smith (Badsyntax) on Wednesday, March 13, 2013 - 11:06 pm: Edit

Quick question, hopefully I can get a few answers...

Which style of ship silhouettes do you prefer?
#1. Look like the miniature
#2. Look like the SSD

By Richard B. Eitzen (Rbeitzen) on Thursday, March 14, 2013 - 02:14 am: Edit

I prefer that it look like the miniature.

By Andrew Bruno (Admeeral) on Thursday, March 14, 2013 - 10:35 am: Edit

Same.

By Ted Fay (Catwhoeatsphoto) on Thursday, March 14, 2013 - 10:59 am: Edit

the mini

By Eric Smith (Badsyntax) on Thursday, March 14, 2013 - 11:54 am: Edit

Ok, I'll use the mini or the ship silhouette from the books if available, but not the SSD.... thanks!

By Lawrence Bergen (Lar) on Thursday, March 14, 2013 - 12:07 pm: Edit

I am not sold on the size of the hexes needing to be that big. Nice for the room but screen size with CB at least only allows a limited portion of map view without scrolling UDLR to see more. Not saying good or bad...just different. I am going to have to see how this plays. Looking good though Eric keep banging away at it.

By Eric Smith (Badsyntax) on Thursday, March 14, 2013 - 12:27 pm: Edit

Thanks.... The thing is, this isn't Cyberboard, not in any way. I can zoom in to any scale. You can do 5% zoom, or 500% zoom, or any percentage inbetween. So, if you think the hexes are too big, zoom out a bit, the counters stay the same size. Eventually you can get it to exactly what CB is.

But, when you have a stack of 3 fleets and 6 other units in a hex, you can zoom all the way in to re-org your fleets and move stuff around, *without* creating a "move event" within the system. This way all those little wiggles and slight moves don't clog up the game turn files.

A technical rant, so if your not in IT in some form, skip the rest of this as you'll just get confused

So I worked at match.com for 7 years. It is a pretty high-speed (and very political) company, with *huge* amounts of money, and *huge* amounts of SQL servers. I wrote a little multithreaded application that queried 1000 servers every minute and stored anywhere from 50 to 500 different pieces of information for each server so we could see graphs for the metrics. I tried using SQL at first, but it couldn't handle the 100K updates/minute. I mentioned this to our senior DBAs and their manager and got laughed at like I was an idiot. Even after I proved it they just couldn't believe that SQL couldn't handle the load of my little program. I tried MySQL and had the same and more issues. Anyway, I ended up using my own proprietary flat binary file data format, and it worked great. Not only was disk space reduced over 90% due to compression, but I could store information forever (a limitation of RRDTool/Cacti/PRTG that was in use before) and queries were *really* fast. I later eventually got SQL able to handle the updates through some batching and caching, but the storage size was huge compared to my own format, over 4x as much space with no compression, and REALLY slow queries, so I went back to a flat file.

Anyway, that being said my SIT database is in SQL. It is a bit easier in some respects than using flat files, and I do see the appeal.

Today I moved from using my SIT database, to the text file I have that gets imported to create that database (as its actually in excel). I converted the code so it went line by line in the file, instead of a SQL query that went record by record.

My initial load time, and time to create all the counters, went down about 20%. Once the counters were created, my load time went down about 25%.

So basically, I've said it before and will say it again, SQL performance sucks, but its versatility is awesome.

I may eventually creating a caching system for the SIT site, so it saves the dynamically generated forms if its a query somebody else did, that should speed up load time quite a bit... this assumes I finish DFE and get back to completing the SIT site though.

Back to tweaking my counter creation, so I can get back to finishing up movement/selection.

By Mike Curtis (Nashvillen) on Thursday, March 14, 2013 - 12:34 pm: Edit

Eric, with myself and Lar being GIS guys, we know caching is the way to go. Lots of time up front, but much more time saved later.

I am sure I am not telling you anything new, as you are light years beyond me, but for the others that may not know: The big thing about caching is making sure it is right before you cache, otherwise you have to cache each time you fix something!

By Eric Smith (Badsyntax) on Thursday, March 14, 2013 - 12:46 pm: Edit

I know what you mean, screwing up a cache creates all sorts of wacky issues. I'm not *too* worried about performance yet as I'm not even in alpha, but I'll eventually look at that kinda stuff more.

I'm kind of a GIS guy as a hobby. I have used arcgis, but find it makes me throw up in my mouth a little bit (though I still get their magazine).

But WAAAAAyyyyyy back, before google earth, I wrote my own google earth while in the Army for fun. I had 5m resolution data for the national training center, created it in 3D using directx, linked it to the army MILES tank-base laser tag system, and showed battles in 3D on a computer screen, as they were happening in real life out in the desert, giving people the ability to zoom to any tank on the battlefield and see what they saw. It was neato stuff, but as a lowly E4 at the time I had no clout to get any money out of it.

The SIT caches will just be local text files saved with the HTML output from creating a table. When a specific query is done, I'll just spit that file to the user instead of hitting SQL and building the tables programatically. The good news is that if it does get outta synch, or I do an update, I can just go delete those files and the first user will see a slightly longer load time as it does that first cache.

DFE will also cache the unit counters it creates, as well as the SIT data. However, on every load it'll hit the website to see if there is an update and download it (<180k now for all 5000+ units) and apply it. It'll then look at all the counters created, and if they have been updated in the SIT more recent than the file was created, it'll remake it. Captured counters, that have the split color scheme, will be created upon load though as I don't suspect there will ever be more than a handful, and saving 10+ captured color schemes for every capturable unit is madness.

By Mike Curtis (Nashvillen) on Thursday, March 14, 2013 - 01:47 pm: Edit

You didn't happen to run into an officer that was a Observer/Controller named Todd Curtis did you? I believe he was on scorpion team. This was back in the late 90's

Loved my tour of the facility from a Hummv. Wish I could have been there when training was going on, would have been fun to see from the side of the "god-gun".