Matrix Games Forums

If I may chime in with this analogy; I feel that that there have been far too few steps taken period, and the ones that were selected are far too ambiguous when there are far more obvious ones needed. Any 'improvement' that requires a disable function absolutely has to be considered questionable at least. From where I'm sitting, considering my requests and the effort I've placed in communicating them, Ralph appears easily diverted when faced with daunting challenges, preferring to create and fulfill his own less challenging requests in lieu. Something tells me Ralph may be more capable than he is available, though the result is the same. That being said, it doesn't take very much to make us all 'lovey-dovey' again. Usually action/progress provides the impetus for communication. Thus these periods of no communication open the door to negative speculation. There are those that seem to act out of the fear that Ralph will get angry and quit. After the progress I've seen over the period he's been with Matrix, I'm no longer in that camp.

ORIGINAL: macgregor
Thus these periods of no communication open the door to negative speculation.

Well said, but honestly, has there actually been negative specualtion?

There are however questions that arise from this non-communication.

[:D][:D][:D][:D]

So giving an option to enable or disable something is bad??? Isn't some of what is being asked for that very thing? The ability to control how the game performs is a good thing, not bad.

ORIGINAL: Telumar

ORIGINAL: macgregor
Thus these periods of no communication open the door to negative speculation.

Well said, but honestly, has there actually been negative specualtion?

There are however questions that arise from this non-communication.

It probably doesn't help that the usual means of communicating with the oracle seems to be through Curtis.

ORIGINAL: Panama

[:D][:D][:D][:D]

So giving an option to enable or disable something is bad??? Isn't some of what is being asked for that very thing? The ability to control how the game performs is a good thing, not bad.

If Ralph had fixed something that was clearly not working, there would be no need to revert to the way it didn't work. What he's done is work on things that were already apparently working pretty well or there would be no need to make it optional.

And what if what was changed was something that made scenarios unusable without the option of reverting to the old method? Or what if someone didn't like the new graphics? He didn't just fix broken things. He did new things that some may or may not want to use.

ORIGINAL: Panama

And what if what was changed was something that made scenarios unusable without the option of reverting to the old method? Or what if someone didn't like the new graphics? He didn't just fix broken things. He did new things that some may or may not want to use.

If you still want to play a scenario with the 'old method', it must have worked pretty good, no?

That 'logic' is not worth a reply. I'm outta here. [8|]

ORIGINAL: Panama

That 'logic' is not worth a reply. I'm outta here. [8|]

Have it your way.

...

I make the point that if which scenario you play is more important than playing with the 'improvements' that these 'improvements' that have been made are probably not that big of a deal, and this is the response I get?

ORIGINAL: Panama


What has been said time and again is to make everything already in the game available to the scenario designers so they may vary effects during a scenario.

I might add that making the editor, or the process of editing scenarios, more user friendly should be a priority, too. TOAW has (always) and still does live from user created scenarios. This is one of its strengths and should be worked out. From my own work i know how cumbersome the editor still is. How painfull it is to do a bigger map. (Deep respect to those that did the FitE and Europe at 20km (various scenarios) maps! [&o])

ORIGINAL: Telumar

ORIGINAL: Panama


What has been said time and again is to make everything already in the game available to the scenario designers so they may vary effects during a scenario.

I might add that making the editor, or the process of editing scenarios, more user friendly should be a priority, too. TOAW has (always) and still does live from user created scenarios. This is one of its strengths and should be worked out. From my own work i know how cumbersome the editor still is. How painfull it is to do a bigger map. (Deep respect to those that did the FitE and Europe at 20km (various scenarios) maps! [&o])

Hear hear. At the moment, I'm bogged down trying to figure out why some event won't fire.

Never mind the details: this sort of thing is routine. We could certainly use more debugging tools when it comes to doing battle with the event editor.

Then there's the force editor. Often one has to cut back and forth between the force editor and the deployment editor -- and God help you if the units you're dealing with are far down a long list in the force editor. You'll have to scroll all the way back down each time.

In the event editor, once you're on a particular 'page,' you go back to that page whenever you reopen the event editor in a particular session.

Thank God for that. Couldn't the same thing happen in the force editor?

Finally, one thing I have to keep checking for is that I haven't duplicated any unit name. Currently, I keep a scenario dump available and search it. This works, but it's a tad cumbersome. How about just high-lighting any duplicate unit names? After all, they're going to have to get dealt with before the scenario will run -- and this is just the sort of thing computers are good at.

Hot keys for the map and forces editors would be nice of course. Could use the same ones with differing functions depending on what was open. Get kind of tired click click clicking.

And a bottomless beer keg would help ease the pain.

I thought (or better: dreamed [8|]) of a complete rebuilt of the scenario editor. Seperating the editor from the game. Using some Windows API/Menues/GUI instead of the TOAW like GUI. Like most games - where the editor is an extra executable.

Import images directly as a map, the designer could assign terrain types to certain colours (or colour ranges) and or defined areas (which could be drawn) on the map. Or simply import an image file as an overlay/layer to create your map upon. Own layers could be added, one could contain rails and roads, others cities etc, just for the comfort of editing. When the scenario or the map is saved it would be combined into a "one layer" TOAW map.. a design file could be retained that contains the original image and layers.
...ok maybe i got carried away, don't know if this can be done for IV. Time wise i mean. Coded it could be, if it is (considered) worth the effort is the question..

I'm dreaming about the TOAW Beachhead. Thanks for reminding me.

Let me ask one question -- one which I would really like to see directly answered.

How much trouble would it be -- actually -- to allow supply units to function as they used to under the new system? To simply add 25% of the base supply to all hexes within the full supply radius of the supply unit?

... please remain on the line, your call is very important to us ...

"Deleted"

ORIGINAL: Telumar
I thought (or better: dreamed [8|]) of a complete rebuilt of the scenario editor. Seperating the editor from the game. Using some Windows API/Menues/GUI instead of the TOAW like GUI. Like most games - where the editor is an extra executable.

Import images directly as a map, the designer could assign terrain types to certain colours (or colour ranges) and or defined areas (which could be drawn) on the map. Or simply import an image file as an overlay/layer to create your map upon. Own layers could be added, one could contain rails and roads, others cities etc, just for the comfort of editing. When the scenario or the map is saved it would be combined into a "one layer" TOAW map.. a design file could be retained that contains the original image and layers.
...ok maybe i got carried away, don't know if this can be done for IV. Time wise i mean. Coded it could be, if it is (considered) worth the effort is the question..

The short answer is that is remarkably like what I've been thinking about (except for the layers).

Scenarios can now be saved as XML and edited as XML and loaded. That isn't an accident, it is so that I can look at creating the editor as a stand-alone product, possibly before the next game. Portions (except for possibly the map drawing portion/graphics) might be released as open source. It's all speculation at this point, but the editor is very complicated and opening it up to have other people work on it seems like a good idea to me. It would also let me look at the user interface code more closely and how to write it using modern tools.

I've also thought about allowing a 'map overlay' of a jpeg where you can set the opacity and use it as a design aid.

All this is a ways off still, but I've thought about doing something like that.