Cross-Platform Editor for Conquests now available! 1.51

[Blue Monkey]

It's not clear from the op or the post with the terrain instructions if the limitations in 0.73 are now corrected.

• Can rivers be placed?
• Can forests/jungles be placed?
• Marshes?
• Are the other standard Firaxis terrains stable?

I'm ready to start detailed work on the map for the Asoka scenario. Basics were done with bmp2bic. These are the main things I'll be doing. If the answers are positive I'd like to give the map editing features of this program a workout.

 

[Quintillus]

It's not clear from the op or the post with the terrain instructions if the limitations in 0.73 are now corrected.

• Can rivers be placed?
• Can forests/jungles be placed?
• Marshes?
• Are the other standard Firaxis terrains stable?

I'm ready to start detailed work on the map for the Asoka scenario. Basics were done with bmp2bic. These are the main things I'll be doing. If the answers are positive I'd like to give the map editing features of this program a workout.

You're right, the first post is slightly out-of-date in that area. At this point, the map editor is fairly stable as long as you stick to the standard Firaxis limits (i.e., don't try to put jungle in deserts). Specifically:

• Can rivers be placed?

They can, although the method is somewhat different than in Firaxis's editor. In my editor, you select a tile, and then use NW/NE/SW/SE checkboxes to indicate where the river should go along the tile's borders. This will be slower than Firaxis's editor in some cases, but allows more precision control.

• Can forests/jungles be placed?

They can. Currently the editor does not limit you to only putting them on sensible tiles. But as long as you only put them on tiles that the Firaxis editor allows, you should be fine. I can probably add a limitation to "sensible" forest/jungle placements to 0.79 or 0.80 (not sure if I'll have a 0.79 before 0.80 or not).

Pine forests are not currently available, although any existing ones will display properly. They likely will be added in the future (along with snow-capped mountains). Also note that mountains in the jungles won't display with jungle on their sides in the editor, but they will in-game.

• Marshes?

Those also work, in the same manner as forests and jungles.

• Are the other standard Firaxis terrains stable?

As long as you stick to what Firaxis's editor allows in terms of not putting forests/jungles/marshes on terrains that they can't normally be on, the terrains are to the best of my knowledge stable. The last bug that I remember that could render a plain map unusable was fixed in version 0.71, according to my changelog. Subsequent versions have fixed bugs not directly related to painting terrain.

The only bug that I can think of right now with regards to standard map editing is that if you go to add a city, but click Cancel when you have the prompt to give the city a name, the map editor crashes. This will be fixed in the next version. The current workaround is that if you accidentally add a city, go ahead and give it a name and then delete the city.

-----------

There's some other graphical deficiencies, such as that river deltas don't show, that appear in the editor itself but not in-game. These are considered somewhat low priority since they don't affect the game and don't make it difficult to understand what's happening on the map.

At this point I am considering making the next version 0.80, with the map editor enabled by default to reflect its considerably more mature state than in the early 0.70's, and thus signifying that it's ready for standard use like the other tabs. I'd also like 0.80 to have several new features, though, so 0.79 may come before 0.80.

Landmark terrains are a work in progress. Currently, you can't add them to the map. That will probably be fixed in 0.80, but they still need some work around the edges. Since they can't be added now, they aren't a danger.

Also, if you plan on adding lots of buildings to lots of cities, version 0.80 may be of interest. Not to spoil too much here, of course .

I am curious to hear how horizontal mousewheel scrolling works on Macs. In the worst case, if it causes erratic scrolling, it can be disabled again in Settings. So far no one has reported back either way on whether it works on Macs. I'm also looking forward to hearing how the map editing goes in general. I've mostly been trying to get the editor to break, rather than editing realistic maps.

Despite it being fairly stable in regular editing, I still recommend testing in Civ3 fairly often to make sure the scenario is still working, and making backups. By default the program will auto-save a backup every 4 minutes, with up to 10 backup files, but both of those can be changed in Settings if you prefer a shorter interval or a longer trail of backups.

 

[Blue Monkey]

Thanks for the prompt and thorough reply. At this point we're only concerned with physical features. so the concerns about cities don't apply. Pine forests should be easy enough to add in later - they're not too extensive on the map. Looks like it's time to install the current version & give it a go.

 

[AlanH]

Feedback on the Mac version:

First, having played with this myself, serious congratulations on your map editing addition

Re. Horizontal scrolling:

I have a Magic Mouse, which uses a touch surface for "scroll wheel" operation. A swipe on the mouse pans the map in any direction, roughly according to your finger movement. But if I pan left or right from the centre of the map, it is quite difficult to avoid vertical panning at the same time. The software seems to be biased to moving the map on a diagonal from top left to bottom right.

Also, I notice that scrolling with the scroll bars is jumpy if you are used to a Mac's smooth scrolling, as the map moves in about 10 pixels increments. Scrolling with the mouse seems to move about 30 pixels at a time horizontally, so this is considerably more jerky.

It is usable, but my preference would be to use single pixel movement resolution during panning, both for mouse and scroll bar. You can always drag the scroll bar thumbs to move to a distant position on the map faster.

While testing the limit cases on map scrolling, I notice there is a redraw problem when you scroll to the right hand edge. The edge tiles are not drawn correctly, and their appearance changes when you scroll vertically at that edge. I also once saw the cultural border on tiles at the right edge of the screen not redrawn, even when near the centre of the map.

 

[Kyriakos]

Can you make a new thread particularly for your discoveries regarding barbarian cities? I think many people here are not aware of this, and would be very interested in it. Also i have not been following it all, so an update on that would really be great

 

[Quintillus]

Thanks for the prompt and thorough reply. At this point we're only concerned with physical features. so the concerns about cities don't apply. Pine forests should be easy enough to add in later - they're not too extensive on the map. Looks like it's time to install the current version & give it a go.

Cool. Keep us updated.

Feedback on the Mac version:

First, having played with this myself, serious congratulations on your map editing addition

Re. Horizontal scrolling:

I have a Magic Mouse, which uses a touch surface for "scroll wheel" operation. A swipe on the mouse pans the map in any direction, roughly according to your finger movement. But if I pan left or right from the centre of the map, it is quite difficult to avoid vertical panning at the same time. The software seems to be biased to moving the map on a diagonal from top left to bottom right.

Also, I notice that scrolling with the scroll bars is jumpy if you are used to a Mac's smooth scrolling, as the map moves in about 10 pixels increments. Scrolling with the mouse seems to move about 30 pixels at a time horizontally, so this is considerably more jerky.

It is usable, but my preference would be to use single pixel movement resolution during panning, both for mouse and scroll bar. You can always drag the scroll bar thumbs to move to a distant position on the map faster.

While testing the limit cases on map scrolling, I notice there is a redraw problem when you scroll to the right hand edge. The edge tiles are not drawn correctly, and their appearance changes when you scroll vertically at that edge. I also once saw the cultural border on tiles at the right edge of the screen not redrawn, even when near the centre of the map.

Thanks!

I was afraid there might be diagonal movements with horizontal scrolling. That's what the Linuxes I tried it with tended to do. It was kind of a hack to get it working in the first place, since I couldn't find a documented way to do it cleanly. I'll have to see if I can come up with a more reliable formula.

I'll have to see whether I can make scrolling smoother. By default Java did have it move one pixel at a time (maybe 3 with the mouse), but it was unbearably slow so I had to increase it. 10 pixels at a time sounds about right, as does 30 for the mouse. I've since improved the drawing - 0.79/0.80 will be noticeable cleaner in drawing than 0.78 - so I might be able to add smoother drawing (though it would probably be optional, in case it's too taxing for older computers). I also came up with an idea for faster drawing while on a plane recently, which could improve performance considerably if it works as it would in theory.

Performance is one of the limiting factors here. Moving 1 pixel 10 times will inevitably be more demanding than moving 10 pixels once, and already on big maps and resolutions it takes some horsepower to draw the map. It's also a factor that I'm using completely CPU-powered drawing, whereas recent versions of OSX probably use the GPU for faster, smoother, and fancier graphics (I know Windows Vista and later do). CPU-powered is probably better for old PowerBooks, but can't reach as high of top performance on computers. So, it probably will be improved, but I'm not sure what the upper limits will be.

The edge tile issues are ones I'm aware of but haven't fixed yet in part because they don't affect map editing. The "appearance changes when you scroll vertically at that edge" part is because I don't redraw anything where there are no tiles, so what used to be visible still is. The right-edge tiles drawing somewhat strangely is because I'm drawing the whole tile, rather than cutting it off as in Firaxis's editor. In some ways I think this is good, as it can be annoying when you have a city at the very edge of the map in Firaxis's editor and it's hard to see. But I may have overcorrected a bit, with the beaches being visible to the right of landmasses on the right. There's room for improvement in both aspects. For editing, though, if you try to do something with a part of the map on the right edge where there's no tile, you won't be able to.

The cultural borders issue sounds new to me. I'm a bit confused with where exactly this occurs - the right edge of the center? It sounds like it could be related to the right-side oddities, though I'm not sure. I know I also fixed a couple of cultural border updating issues earlier in the 0.7x series, so if it's an older 0.7x release it could have been fixed.

Can you make a new thread particularly for your discoveries regarding barbarian cities? I think many people here are not aware of this, and would be very interested in it. Also i have not been following it all, so an update on that would really be great

That's a good idea, although it's something I really need to explore a bit more and refresh myself on before I do that. As I recall, I may have gotten it to be stable in one situation and unstable in a whole bunch more.

 

[AlanH]

I was afraid there might be diagonal movements with horizontal scrolling. That's what the Linuxes I tried it with tended to do. It was kind of a hack to get it working in the first place, since I couldn't find a documented way to do it cleanly. I'll have to see if I can come up with a more reliable formula.

Let me know if I can help. I've some past experience of getting graphics to scroll smoothly on slow old hardware!

I'll have to see whether I can make scrolling smoother. By default Java did have it move one pixel at a time (maybe 3 with the mouse), but it was unbearably slow so I had to increase it. 10 pixels at a time sounds about right, as does 30 for the mouse. I've since improved the drawing - 0.79/0.80 will be noticeable cleaner in drawing than 0.78 - so I might be able to add smoother drawing (though it would probably be optional, in case it's too taxing for older computers). I also came up with an idea for faster drawing while on a plane recently, which could improve performance considerably if it works as it would in theory.

Performance is one of the limiting factors here. Moving 1 pixel 10 times will inevitably be more demanding than moving 10 pixels once, and already on big maps and resolutions it takes some horsepower to draw the map. It's also a factor that I'm using completely CPU-powered drawing, whereas recent versions of OSX probably use the GPU for faster, smoother, and fancier graphics (I know Windows Vista and later do). CPU-powered is probably better for old PowerBooks, but can't reach as high of top performance on computers. So, it probably will be improved, but I'm not sure what the upper limits will be.

I assume you are not redrawing the entire image each time it moves. You should only change the coordinates of the image, and redraw the new pixels that are exposed on one or two edges as you scroll, but I'm not familiar with the API that Java provides for this.

[snip]

The cultural borders issue sounds new to me. I'm a bit confused with where exactly this occurs - the right edge of the center? It sounds like it could be related to the right-side oddities, though I'm not sure. I know I also fixed a couple of cultural border updating issues earlier in the 0.7x series, so if it's an older 0.7x release it could have been fixed.

Right edge of the visible space, and it was on version 0.78, downloaded specifically to provide you feedback on horizontal Mac scrolling.

I only saw it once. I've tried to reproduce it so that I could provide a screen shot, and I've not been able to. I am beginning to think I was seeing an extreme case of a border hidden behind hills, though I thought at the time that I was able to restore the border by scrolling left/right to get it to redraw. Not a big deal, in any event.

 

[Blue Monkey]

Very quick first impressions. Only worked with it enough to make sure it installed correctly and that I could use it - maybe 15 minutes work so far.

• You're working toward a nicely intuitive interface. Kudos.
• The "brush" painting of terrain is a good feature. I definitely like some other things as well - like the fine control of rivers.
• I use a 2-button trackball so I don't really have horizontal scroll. If I use the scroll bars I do see the jitter. No unwanted diagonal movement at all.
• I still get the initial request for directory path every time i open the program. If i cancel then the program opens normally. The program itself finds the files just fine. Both Civ itself and all the files/folders used in creative work are on a different drive than the boot - maybe that is the cause.
• Some indication of tiles - a visual grid or a reference number on the tile itself would be useful in judging relative placement.
• Without a zoom it can be difficult to judge where to put terrain relative to the overall map. Wouldn't need multilevel. One level of zoom that puts a reasonable amount of map in view would be fine for most of my work. I'd actually prefer that to a minimap. I tend to zoom in & out while working - only use the minimap for jumping from one side of the map to the other. Something roughly like this level of difference:
  
  
  

I'll experiment with it more & report anything further. I have to say that without something like a zoom the utility is only practical for very fine adjustments while comparing to an overall screenshot open in another program. Bottom line though: what you've done is amazing & I can already see that the rules aspect of the editor will be of enormous benefit. I'm only offering what I hope is a very constructive critique of the map features.

Keep up the good work.

 

[Quintillus]

Sorry for the slow response - saw these on the 24th, but didn't get around to them then, and I've been working a lot since then, on real-world work. Now I'm on the adjustment back to a more normal, daytime-hours schedule.

Let me know if I can help. I've some past experience of getting graphics to scroll smoothly on slow old hardware!


I assume you are not redrawing the entire image each time it moves. You should only change the coordinates of the image, and redraw the new pixels that are exposed on one or two edges as you scroll, but I'm not familiar with the API that Java provides for this.


Right edge of the visible space, and it was on version 0.78, downloaded specifically to provide you feedback on horizontal Mac scrolling.

I only saw it once. I've tried to reproduce it so that I could provide a screen shot, and I've not been able to. I am beginning to think I was seeing an extreme case of a border hidden behind hills, though I thought at the time that I was able to restore the border by scrolling left/right to get it to redraw. Not a big deal, in any event.

I actually am currently redrawing the entire visible portion of the image each time it moves, which you're right, isn't a very efficient method. I wasn't familiar with the Java graphics APIs coming into this myself, and that emerged as the first reliable method I found for drawing the map, which I guess makes sense as it is necessary to draw it initially. Now that I'm more knowledgeable, and evaluate the API, there is a method that looks like it'll do what you describe. My initial tests show that changing the coordinates takes about 1/11th the time as redrawing the whole image. Redrawing edge tiles will add a bit to that, but it will still be significantly quicker.

I'll let you know how this progresses, but it appears that I will probably be able to rework this for significantly better performance. And with that, smoother scrolling probably will be possible. Initial forays are promising.

I'll keep an eye out for the cultural border issue.

Very quick first impressions. Only worked with it enough to make sure it installed correctly and that I could use it - maybe 15 minutes work so far.

• You're working toward a nicely intuitive interface. Kudos.
• The "brush" painting of terrain is a good feature. I definitely like some other things as well - like the fine control of rivers.
• I use a 2-button trackball so I don't really have horizontal scroll. If I use the scroll bars I do see the jitter. No unwanted diagonal movement at all.
• I still get the initial request for directory path every time i open the program. If i cancel then the program opens normally. The program itself finds the files just fine. Both Civ itself and all the files/folders used in creative work are on a different drive than the boot - maybe that is the cause.
• Some indication of tiles - a visual grid or a reference number on the tile itself would be useful in judging relative placement.
• Without a zoom it can be difficult to judge where to put terrain relative to the overall map. Wouldn't need multilevel. One level of zoom that puts a reasonable amount of map in view would be fine for most of my work. I'd actually prefer that to a minimap. I tend to zoom in & out while working - only use the minimap for jumping from one side of the map to the other. Something roughly like this level of difference:
  
  
  

I'll experiment with it more & report anything further. I have to say that without something like a zoom the utility is only practical for very fine adjustments while comparing to an overall screenshot open in another program. Bottom line though: what you've done is amazing & I can already see that the rules aspect of the editor will be of enormous benefit. I'm only offering what I hope is a very constructive critique of the map features.

Keep up the good work.

Thanks for the critique. That's some valueable feedback, and I wasn't aware of some of those things.

• You're working toward a nicely intuitive interface. Kudos.

Thanks! It pretty much came from thinking about what didn't seem as straightforward in Firaxis's as it could be, how it could be changed, and drawing it out on paper first.

[*]The "brush" painting of terrain is a good feature. I definitely like some other things as well - like the fine control of rivers.

I couldn't not have brush painting, since Firaxis's editor has it. I'd actually like to expand it to wider radiuses, like Firaxis's, and perhaps to "mesh" type terrains - you could have a "mesh" of two-thirds grassland and one-third plains, for instance. The rivers were inspired by my inability to reliably get rivers to draw as I wanted them to in Firaxis's editing.

[*]I use a 2-button trackball so I don't really have horizontal scroll. If I use the scroll bars I do see the jitter. No unwanted diagonal movement at all.

Sounds about as expected. The jitter should be lessened in 0.79, and much more so if I get smooth scrolling working.

[*]I still get the initial request for directory path every time i open the program. If i cancel then the program opens normally. The program itself finds the files just fine. Both Civ itself and all the files/folders used in creative work are on a different drive than the boot - maybe that is the cause.

That's odd. I'll have to see how Civ being on a separate drive works on my Linux VM, and see if it has a problem there. I have Civ installed on a different drive than boot on Windows, but Windows uses a different drive structure, so perhaps something's not working with that. If the Linux VM doesn't reveal anything, seeing what the civInstallDir line in your civ3editor.ini file (which should be in the same directory as the editor) says might help.

Are other preferences being saved, if changed?

[*]Some indication of tiles - a visual grid or a reference number on the tile itself would be useful in judging relative placement.

I agree. My initial attempt to draw the grid was put on hold due to not working reliably. However, earlier this month I added the ability to display city names directly on the map, and it would be fairly straightforward to add coordinates over tiles in addition to that (which could be turned on and off as desired). I could probably use more or less the same technique to get the grid to display.

[*]Without a zoom it can be difficult to judge where to put terrain relative to the overall map. Wouldn't need multilevel. One level of zoom that puts a reasonable amount of map in view would be fine for most of my work. I'd actually prefer that to a minimap. I tend to zoom in & out while working - only use the minimap for jumping from one side of the map to the other. Something roughly like this level of difference:

[/LIST][/QUOTE]

I'll look into zoomed-out options. It looks like Firaxis's editor basically draws a bigger window and then shrinks it to get a zoomed-out version. That's probably not the best method, but it might be a relatively quick one to add. I'll have to experiment a bit, after I finish currently halfway-there changes.

 

[Blue Monkey]

Please take all the time you need. As my drill sergeant used to say "I'm lazy - I do things right the first time".

Given the current limitations I will probably be doing another layer of the major work on this map in the Firaxis editor & just "playing around" with yours to compare.

Re: Opening Dialogue

The editor is in the path: Hulot/C3C Stuff/ConquestsEditor0.78(2)/Conquests Editor.jar . This is the directory path containing all files related to my scenario design work.
The game is in the path: Hulot/Civ III/ ...
While developing maps I sometimes work with biqs in the path: Hulot/C3C Stuff/scenario-named-folder/ biq etc ...
That last shouldn't affect the opening dialog - afaik - since the file is opened after that.

"Hulot" is the external hard drive's name. I notice that I've got "(2)" in the folder name. I think the launcher's name is changed as well: "QuintEditorLaunch" Maybe renaming is causing the problem?

This is the entire text of the civ3editor.ini :

openDir=/Volumes/Hulot/C3C Stuff
civInstallDir=/Volumes/Hulot/Civ III
debugLevel=info
numProcs=0
firstRun=true
nextAutosave=1
maxAutosaves=10
autoSaveInterval=240
fontChoice=Tahoma
confirmQuit=true
graphicsEnabled=true
horizontalScrolling=true

 

[Takhisis]

What happens if the fontChoice= line is edited? Does everything change there?

 

[AlanH]

I actually am currently redrawing the entire visible portion of the image each time it moves, which you're right, isn't a very efficient method. I wasn't familiar with the Java graphics APIs coming into this myself, and that emerged as the first reliable method I found for drawing the map, which I guess makes sense as it is necessary to draw it initially. Now that I'm more knowledgeable, and evaluate the API, there is a method that looks like it'll do what you describe. My initial tests show that changing the coordinates takes about 1/11th the time as redrawing the whole image. Redrawing edge tiles will add a bit to that, but it will still be significantly quicker.

With modern computer memory sizes, you don't even need to redraw the edges as you scroll, as you can draw the entire image at the start. Then just let the API scroll it across/down the view port. The API handles the masking that's required to hide the parts that are not in the window. For a very large map, this could make the initial drawing slow, but should speed up subsequent operations. You also need to be selective about which parts of the map you redraw when the user edits it, of course.

 

[Quintillus]

Please take all the time you need. As my drill sergeant used to say "I'm lazy - I do things right the first time".

Given the current limitations I will probably be doing another layer of the major work on this map in the Firaxis editor & just "playing around" with yours to compare.

Re: Opening Dialogue

The editor is in the path: Hulot/C3C Stuff/ConquestsEditor0.78(2)/Conquests Editor.jar . This is the directory path containing all files related to my scenario design work.
The game is in the path: Hulot/Civ III/ ...
While developing maps I sometimes work with biqs in the path: Hulot/C3C Stuff/scenario-named-folder/ biq etc ...
That last shouldn't affect the opening dialog - afaik - since the file is opened after that.

"Hulot" is the external hard drive's name. I notice that I've got "(2)" in the folder name. I think the launcher's name is changed as well: "QuintEditorLaunch" Maybe renaming is causing the problem?

This is the entire text of the civ3editor.ini :

At first glance nothing stands out as unusual, but I'll have to look at the code and maybe play around some in a *nix-based operating system to see how that might be throwing it off. I was concerned that perhaps the .ini file wasn't there at all, as that would cause the issue.

I don't think the (2) should cause a problem, and the launcher's name being different certainly shouldn't. The editor JAR file having a different name would affect it (if editing maps), but the launcher should be able to have any name you like, as long as it ends in .jar.

What happens if the fontChoice= line is edited? Does everything change there?

That controls which font is used within the editor. Along with Tahoma, Trebuchet MS and Arial seem to work decently consistently across platforms. I haven't tried changing it to something else using the config file - that would confuse the Settings window, but I don't know what else would happen.

Update: It works. In theory you should be able to set any font on your system that way, although some might not look real great in the editor. In practice, Times New Roman worked, Wingdings didn't for some reason.

With modern computer memory sizes, you don't even need to redraw the edges as you scroll, as you can draw the entire image at the start. Then just let the API scroll it across/down the view port. The API handles the masking that's required to hide the parts that are not in the window. For a very large map, this could make the initial drawing slow, but should speed up subsequent operations. You also need to be selective about which parts of the map you redraw when the user edits it, of course.

That sounds similar to how I was doing it initially. Perhaps I should revisit that approach. At the time, there were a few performance issues - one being the hugeness of the map affecting redraw speeds. But I may not have been using the API very well. I did start using source control before changing approachs, so going back might not be too bad.

Update: Took at look at my code from Oct, 2010, when I had this working for the first time and was letting the API take care of things. Didn't take long to see why it was slow. Not sure there's a silver bullet, though. Fun fact: the map was first minimally operational (drawing the base terrain) when version 0.57 was current. It took almost 6 more months to get it to the place that it was available to the world, at version 0.70.

 

[Quintillus]

It's been a few weeks since I've been able to work on this, and it looks like I won't be able to for the next few weeks, either, so I figured I probably ought to release what I did in January as version 0.79. That means there's a few in-progress features that aren't in this release.

Download here.

Changes:

• Added city names to the map editor
• Made the map scrolling better, as it no longer has white bars.
• Added scientific leader support.
• Fixed a bug that happened if you went to create a city, but then decided to not to after all.
• Slightly better spaceship support. Still kind of a work in progress.
• The building tab's Add/Remove options (on right-click) are no longer in the opposite order of all the other tabs.

If you really hate city names displaying on the map, you should keep using version 0.78 for now. They'll be turn-offable, but that hasn't been added yet. This feature kind of slipped in 0.79 by being sneaky, but I didn't have the heart to take it out.

The map scrolling isn't "smooth" yet, but it's less obviously not smooth. A smooth-scrolling map is in progress, but isn't complete yet.

Version 0.80 will have (at least several) of the in-progress features, but it will be awhile before it's ready - it probably won't be in March.

------

Also, for anyone curious, from what I've read about Apple's next operating system, Mountain Lion, there probably won't be any changes that affect this editor. The one potential tripping point if the Gatekeeper feature, but it looks like that probably won't affect Java applications, regardless of what setting it's set to. That might not turn out to be the case, but if not, it's something that can be dealt with at that time.

 

[Lee_Dailey]

howdy Quintillus,

kool, dude! thanks for this ... [*grin*]

take care,
lee

 

[Lee_Dailey]

howdy Quintillus,

i've noticed a few problems. [*grin*]

[1] with version 0.76
- go to the PLYR tab
- add a scout to player 1
- add a scout to player 2
- go back to player 1 and select "scout" from the unit list
- delete the "amount" [leave the field blank]
- switch to player 2
- switch to player 1 again

note that the "at least one of" list still shows the scout while there is NO amount listed. if you enter a zero the scout is removed as expected. i have not checked to see what would show up in the game.

[2] with version 0.79
- go to the PLYR tab
- in the "player information" section, click on player 1
- in the same section, click on any other player #
- in the same section, try to do a 3rd click on any player #

it seems that the 2nd click disables that list. you can re-enable that list by clicking on any other tab or any other item EXCEPT the "player #" items.

i presume it has something to do with code to support selecting more than one item, but that is a wildly uninformed guess on my part. [*grin*]

take care,
lee

 

[Quintillus]

howdy Quintillus,

i've noticed a few problems. [*grin*]

[1] with version 0.76
- go to the PLYR tab
- add a scout to player 1
- add a scout to player 2
- go back to player 1 and select "scout" from the unit list
- delete the "amount" [leave the field blank]
- switch to player 2
- switch to player 1 again

note that the "at least one of" list still shows the scout while there is NO amount listed. if you enter a zero the scout is removed as expected. i have not checked to see what would show up in the game.

[2] with version 0.79
- go to the PLYR tab
- in the "player information" section, click on player 1
- in the same section, click on any other player #
- in the same section, try to do a 3rd click on any player #

it seems that the 2nd click disables that list. you can re-enable that list by clicking on any other tab or any other item EXCEPT the "player #" items.

i presume it has something to do with code to support selecting more than one item, but that is a wildly uninformed guess on my part. [*grin*]

take care,
lee

I've figured out what's going on with the first one. It's basically caused by the program not doing well if you enter non-numbers where it expects a number. Normally it warns you with red text, but that doesn't help when nothing is displaying, and you could cause the same thing by typing in that Player 1 should have "bob" as the number of scouts, and then changing players despite the bright red text. I've fixed this particular case, but it can be tripped up in other places. I know what needs to be done to fix it across the program, though, so it should be fixed in 0.80.

The second one I couldn't get to happen without entering an invalid value (non-number where a number is expected) first. It shouldn't be possible to select multiple players, but entering invalid values can cause that to happen. In that case, the second click can indeed disable the list until you switch tabs. It looks like this will be fixed by the same fix to the first problem.

Thanks for the reports, particularly the steps to reproduce.

 

[Lee_Dailey]

howdy Quintillus,

thanks for the response, dude! [*grin*]

i have no idea why the STR for item #2 won't work for you. it's consistent for me. [*sigh ...*] still, i can see the possible relationship to item #1 and hope that the fix for one fixes two.

i'm looking forward to the next release ... [*grin*]

take care,
lee

 

[nick0515]

A bit late to the party, but thanks for making this Quintillus.

Since I'm strapped for time and this is quite a long thread can I just ask has this been tested much in Linux. I'm trying to make the transition away from windows and am using Ubuntu 11.10 for much of my computer use.

 

[Quintillus]

A bit late to the party, but thanks for making this Quintillus.

Since I'm strapped for time and this is quite a long thread can I just ask has this been tested much in Linux. I'm trying to make the transition away from windows and am using Ubuntu 11.10 for much of my computer use.

Sorry, I completely missed this when you posted it. I think I was AFCFC (Away From CFC) - I was definitely out of town that week.

For Linux testing, in short, I test it in Linux when I change something that I think might behave differently in Linux, which lately means when I change the way the map displays. When I make such a change, I'll make sure it works the same as Linux as on Windows. So, I test it enough that I can't think of any reason it wouldn't work the same, but it isn't nearly as rigorous as on Windows simply because most of the time I'm using the editor is when I'm developing it on Windows.

My Linux machine is a VM based on PCLinuxOS 2009, with KDE 3.5 - kind of old, but I don't use it much, so I haven't upgraded. I use the Sun Microsystems JVM, and haven't tested it to any appreciable degree with the OpenJDK (which comes with Ubuntu 11.10). Theoretically it shouldn't matter, but if you want the more-tested setup I'd recommend the Sun/Oracle JVM.