Page 2 of 3

Posted: Thu May 24, 2007 4:55 pm
by Stij
Would this support importing models from, say, Wings3D? (sorry, I don't know crap about making maps :D)

Seems awesome though, very user-friendly.

Posted: Thu May 24, 2007 9:27 pm
by jude-
Wow, lots of replies. Thanks guys!

Tropican8, probably what'll happen is chunks of your map that you want mirrored can be grouped and then transformed as such.

TangenT, yup, groups, zones, and defines will be written to the bzw file as they are defined in the 3D scene.

Saturos, my current plan is to have a bzw file stored with the app's data (i.e. "userObjects.bzw") and a corresponding dialog that will allow users to select objects or groups they want to re-use later on in different maps, and save them to this file. The user will then be able to import them into future maps.

Mostly Harmless!, currently there is a text input field in the world options dialog that takes in an options string, but in the future there may be a completely separate dialog for configuring the options without knowing the options string syntax.

Tadd, CannonBallGuy, this is a great idea! I'll make sure to add that feature to the editor. Would making the hidden objects extremely transparent (but not invisible) work? This way, you can still know that they're there and where they are (i.e. making it easier to find them and make them opaque again).

Stij, I'll do my best to add wings3D support, but in the worst case scenario you'll still be able to export it to Wavefront .obj format and load it that way (I'll probably borrow BZFlag's .obj loader, if I can't get mine to work :)).

Posted: Thu May 24, 2007 10:35 pm
by CannonBallGuy
jude- wrote:Tadd, CannonBallGuy, this is a great idea! I'll make sure to add that feature to the editor. Would making the hidden objects extremely transparent (but not invisible) work? This way, you can still know that they're there and where they are (i.e. making it easier to find them and make them opaque again).
I was thinking along the lines of 10% Opacity.. or maybe just an outline.

Posted: Thu May 24, 2007 11:29 pm
by Peter
Maby in a section called "settings" your could edit the opacity, if it where to be a variable.

Posted: Fri May 25, 2007 10:21 am
by WarPig
This all looks awsome. Cannot wait! but, will it cost and if so how much?

Posted: Fri May 25, 2007 12:03 pm
by joevano
WarPig wrote:This all looks awsome. Cannot wait! but, will it cost and if so how much?
This is part of the project. There is no cost, ever...

Posted: Fri May 25, 2007 5:15 pm
by DTRemenak
WarPig wrote:This all looks awsome. Cannot wait! but, will it cost and if so how much?
Google is picking up the tab for this one.

http://code.google.com/soc/bzflag/appin ... 2C68E492DB

So no cost to you :)

Posted: Fri May 25, 2007 7:07 pm
by Winny
jude-: looking great so far, I can't wait. If your looking for someone to help with conceptual drawings or renders, let me know :)

Posted: Fri May 25, 2007 8:00 pm
by JeffM
the summer of code program will be paying Jude and 3 others to work on bzflag.

Read the wiki about the program, and the Google info. it will tell you how much each student gets paid.

Posted: Sat May 26, 2007 5:12 am
by Catoblepas
Hey yall, I was just wondering when this fine peice of software is gona be released?

Posted: Sat May 26, 2007 5:31 am
by Grace F
Well, the actual development doesn't start till the end of this month, I don't know how long it will take them though, I don't want to speak for them but I can only estimate that it will take about... 1 month? :?

Posted: Sat May 26, 2007 6:02 am
by Catoblepas
Well isnt that just perfetct!, I am going to spain for 5 months in 2 weeks :evil: :?
Well I will have somthing to look forward to :), Just one question, will you be able to add textures to you map from images.bzflag ? I don't know if you can use them from there or?....

Posted: Sat May 26, 2007 1:38 pm
by CannonBallGuy
"Google Summer of Code" suggests it would be done by September, right?
And believe it or not, the logical answer is the right one: http://code.google.com/support/bin/answ ... opic=10729

Posted: Sat May 26, 2007 5:10 pm
by jude-
Grace F, the project should take about three months to complete, maybe less. Betas and Release Candidates should be available sooner. The idea is to finish a stable 1.0 release by August 31st.

Catoblepas, you will be able to add your own textures to any object you want.

Posted: Wed May 30, 2007 5:01 am
by jude-
At the recommendation of my GSoC mentor, I've created a blog page for those who are interested to get up-to-date information on the project's development. I'll be posting at least weekly entries. It can be found at bzworkbench.wordpress.com

selectably not selectable

Posted: Wed May 30, 2007 5:27 am
by tadd
jude- wrote:Tadd, CannonBallGuy, this is a great idea! I'll make sure to add that feature to the editor. Would making the hidden objects extremely transparent (but not invisible) work? This way, you can still know that they're there and where they are (i.e. making it easier to find them and make them opaque again).
Being hidden has two purposes, one- you can see through them (adjustably translucent from 0 to ?100%? would be great!) and two - so you don't select them by accident.

metadata and foreign data

Posted: Wed May 30, 2007 5:33 am
by tadd
A really nice way to save the output file would be to create a regulation BZW file, but surround all of the BZWorkbench generated data with metadata. Any data that is NOT normal for a BZW file is saved IN the BZW file but surrounded by #### DO NOT CHANGE ### notes.

Now, if somebody were to take a BZWorkbench file and import some new data, like converted 3D graphics program output, when the next time BZWorkbench wants to import it, it can figure out what IS and IS NOT BZWorkbench created portions. It can put the foreign data in a special place so the next time the BZWorkbench file is saved, the foreign data survives. It would be also cool if BZWorkbench could make a stab at interpreting the foreign data for display or even editing it, but doing so might make BZWorkbench incompatable with future versions of BZFlag, i.e. not forward-compatable.

Another good thing for putting the metadata in the BZW file is that you only have to move one data file when backing up the work, you have only one to send via email to the server op, or to somebody else working on the map, and it is possible to cut and paste the BZWorkbench output using a normal text editor.

Thanks for the great work coordinating (and writing) this project.

Tadd

Re: metadata and foreign data

Posted: Wed May 30, 2007 6:14 am
by jude-
tadd wrote:A really nice way to save the output file would be to create a regulation BZW file, but surround all of the BZWorkbench generated data with metadata. Any data that is NOT normal for a BZW file is saved IN the BZW file but surrounded by #### DO NOT CHANGE ### notes.

Now, if somebody were to take a BZWorkbench file and import some new data, like converted 3D graphics program output, when the next time BZWorkbench wants to import it, it can figure out what IS and IS NOT BZWorkbench created portions. It can put the foreign data in a special place so the next time the BZWorkbench file is saved, the foreign data survives. It would be also cool if BZWorkbench could make a stab at interpreting the foreign data for display or even editing it, but doing so might make BZWorkbench incompatable with future versions of BZFlag, i.e. not forward-compatable.

Another good thing for putting the metadata in the BZW file is that you only have to move one data file when backing up the work, you have only one to send via email to the server op, or to somebody else working on the map, and it is possible to cut and paste the BZWorkbench output using a normal text editor.
Another excellent idea! I'll add it to the project spec.

Posted: Fri Jun 08, 2007 2:10 pm
by Catoblepas
:idea:

How about having a library of textures already in the map editor?
That would make things alot easyer.

Posted: Sat Jun 09, 2007 2:41 am
by Macrosoft
looks like it will turn out to be great...i would try to make useful stuff too, but i suck at C++

Posted: Sat Jun 09, 2007 3:11 am
by sniper1234
I have a quick question- what estimated time do u think this version will be finished. Looking at it, it looks great. Umm since I am a noob at making maps-maybe u can do it anywhere. Can u while making the map do a flag arragment!

Posted: Sat Jun 09, 2007 3:36 am
by Winny
sniper1234
Seriously dude, did you read anything in this thread? Your question has been answered a few times already. Instead of creating a non-needed post, why not just read the thread? :--)

CBG wrote:"Google Summer of Code" suggests it would be done by September, right?
And believe it or not, the logical answer is the right one: http://code.google.com/support/bin/answ ... opic=10729
Google Summer of Code wrote: August 20: Students upload code to code.google.com/hosting; mentors begin final evaluations; students begin final program evaluations

August 31: Final evaluation deadline; Google begins issuing student and mentoring organization payments

Posted: Sat Jun 09, 2007 3:39 am
by Hannibal
sniper1234 wrote:I have a quick question- what estimated time do u think this version will be finished. Looking at it, it looks great. Umm since I am a noob at making maps-maybe u can do it anywhere. Can u while making the map do a flag arragment!
Did you read anything other people have posted?

http://www.u.arizona.edu/~jnelson/bzworkbench.html for things you can do in the program to-be
jude- wrote:the project should take about three months to complete, maybe less. Betas and Release Candidates should be available sooner. The idea is to finish a stable 1.0 release by August 31st.

Posted: Sat Jun 09, 2007 9:45 am
by Peter
How long do you think it would take to complete making a map?
Would it make it a shorter or longer process?

Posted: Sat Jun 09, 2007 11:45 am
by joevano
PETER wrote:How long do you think it would take to complete making a map?
Would it make it a shorter or longer process?
It would depend on the map... if it were all 1.0 features, I would expect it to be somewhat similar, bt maybe slightly faster. But when adding 2.0 features I would imagine it would be shorter, because you wouldn't have to do any editing by hand.