So we want the simulated terrain to have targets ?

We want static and mobile targets... yes ?

we want the simulab coding team to provide us with a tool to make object placement as easy and intuitive as it can be ?

Well its not fair of us to just want want want.

We have to provide help, direction, guidance.... we can't sit back and wait for something 'perfect' to come along and if it doesn't critic it to perfection.... It's cheap of us and Paul and the simulab team if WE expect them to work with us deserve more.

So WE want functionality... well design it !

How ?

Draw a GUI....it doesn't have to be 'electronic'... draw it on a piece of paper, it just has to be clear, and scan it.

You've seen how doing the other GUI's has made it clear what functionality is wanted...so let's do the same for the tools we need and not leave it to guess work.

Over to you guys.

Simon.

Dang, I just posted a reply to Peril over at TW. It concerned Yak's 'Scenario Designer.' I found it pretty easy to use, its GUI was reasonably well thought out. I'd say it'd be a great starting point for discussion. Let me find a computer that will still open it....

That's right Clipper, if there's something that we think worked from a dev tool somewhere else then let's use it...cherry pick the best we've seen and if its possible improve on it.

I'd like to see a tool that allow me to build a rail network.. or a sea convoy system of ships constantly embarking and disembarking.

Simon

Yak's SD was a buggy piece of shit. Let's be honest. Intentions might have been good, but at the end of the day, it was easier to edit a .txt file than to use that "program". At least Wordpad wasn't very likely to crash suddenly for no apparent reason and take three hours of your hard work with it.

Also, the need to have to create these stupid "packs" hampered SD. If your terrain can load in-game in TW, then the SD should be able to also help you create a scenario on said terrain. BASTA. END OF STORY. You shouldn't need to create special files just for SD that Targetware itself wouldn't need to load the scenario. All that's doing is making the user work harder to make up for the design deficiencies of the tool.

I'll give credit to SD for presenting the "blanks" of info to fill in in a nice, eye-friendly format... but I never really got to use it that much because I couldn't even get it to load a viable, working terrain, and wasn't about to jump through the hoops to provide it with highly specialized overhead graphic images it needed to get to a vantage point necessary to detail an airfield. Again, with a little familiarity with any .scn file, you could find the blanks and easily populate them.

I wrote a tutorial for doing Targetware scenarios "the hard(er) way" that, IMO, had more utility than SD.
=========================================

Best tools I've seen for scenario design are in IL-2. It has a few quirks, too, and could be improved upon to make it more user friendly... but at least you could SEE where you were placing an item. (WYSIWYG is VERY important, if not indispensible in making a tool usable for "Joe Sim-Fan" and not just a paid coding professional team member).

The tool needs WORKING zoom that allows you to position an object within a few meters at worst. It needs to give you graphic tools to plot/schedule travel routes for moving forces, convoys or mission routes. Drop-down menus that allow you to select objects (not making you route through twelve levels of subdirectories to find an object or a file). And, well-designed pop up forms that allow you to write briefings, mission orders, and all the other information that the players will need "at their fingertips" before they start the mission. And, following that, the same easy-to-access menus and forms to create the rules, point schedules, and other game engine stuff to run the contest, report to players and administrators on the results, and to allow multiple scenarios to link to a greater campaign.

It's really not rocket science in this regard. As Simon is seeing it correctly, it's a matter of just "doing it RIGHT" and not designing it from the "code geek" perspective, where they accept that it's going to be buggy and harder to use than it ought to be.

It's got to be accessible to your average gamer/sim fan. That's TASK #1.

Brake checkkkkkk....full stop!

Terrain, campaign (ie scenario), aircraft import/fixing/tweaking, FM'ng, etc etc work will be handled with one GUI built on the NetBeans rock solid platform. No separate tools...

We need to get Paul over here to fill in the blanks!

Quote by: Stiglr

Yak's SD was a buggy piece of shit. Let's be honest. Intentions might have been good, but at the end of the day, it was easier to edit a .txt file than to use that "program". At least Wordpad wasn't very likely to crash suddenly for no apparent reason and take three hours of your hard work with it.

First off, we're not concerned with any buggyness in a previous piece of software but its interface. However, I will say that I never had the trouble you experienced, Stiglr. Maybe the OS X version was much more stable? It was a little quirky and some scratch-built characteristics but it crashed on me on me maybe three times ever and I really put it through the paces. I wrote a bunch of scenarios and never once had to resort to a text editor. But be that as it may...

I liked the GUI and found it a snap to use. Zoom in or out of the map, from down to airfield up to the whole theater. Button to show or hide enemy targets,units, limit of engagement etc.. Select objects, targets, planes, ships etc. from drop down menus and place them. Buttons to set waves, formation, compass orientation of spawn points.

But the interface will be dependent on how we design the simulation of air combat. Scenario Designer designed, well, scenarios. A well written scenario was a pleasure. But even the best ones became repetitive after a time.

You all are probably way ahead of me on this.. I'll just sit back and listen.

That's correct Clipper it's not about a previous tools 'buggyness' but about the functionality that we could incorporate.

I never could get it to work on OSX... so go figure.

Kev... Ok netbeans... but surely that's the backend so it'll still need a front end design which will determine the backend... ie what windows, capabilites, buttons etc that we need... and we're doing everything in netbeans, then we'd want separate tabs across the top for static object, mobile object, spawn object placement, weather, timetables...... not to mention some campaign controls..

If we have an idea what we want to do in each tab then we're well on the way to getting what we want.

We have to remove the vagueness out of "We want a tool............."

Simon

Still works fine for me on my old G4. Here's a screen shot to make a wish list from:

Did the screenshot not work Clip?

Quote by: mekgp

Did the screenshot not work Clip?

I can see it fine? It's a .tiff file...

Small update on the technological side of the coin: i spent 3 days experimenting with different setups of the terrain and vehicle editor setup and changed the development plan. The toolset will be based on the same technology as the GUI part: XML descriptions of the visuals with glue code written in JavaScript working directly with the backend. This way i can ensure the simplest setup and the simplest way the changes being applied on the backend code. The gui part will also profit from this approach.

Bitter statement to pinpoint once again: the team has until now only ONE programmer. This means: single issue/feature is implemented at the time. Multiple features might be developed at the same time but of course much slower.

More about the terrain tool set:
1. Is platform independent, supported on Windows, Linux and MacOS (the native libraries involved here are available for all 3 OS types)
2. Native executables for Windows and Linux
3. In version uno the editor will feature 2 windows: the primary editor with all the tools and 3d preview window.

Quote by: Clipper

Quote by: mekgp

Did the screenshot not work Clip?

I can see it fine? It's a .tiff file...

Hey Clip...I re-linked that image to a .jpg of the same one. For some reason it wasn't showing on Firefox or Explorer browsers for a few people. <shrug> <shrug>

Ok here's my initial thoughts scribled on paper..

I'd like to see a parent/child relationship when it comes to object terrain placement. Such that we add the objects then build them up into groups, and then use these groups inside other groups and so on..


I want to add all the objects into a database with various meta data information attached..


And then I want to be able to put these objects or groups into a placement entry which contains their x y z.


Well that's my first stab.
I know there are bit's missing... such as relative XYZ or Global and modifying existing entries.

Not a bad start.

You do need a rotation/facing input for individual objects.