Great stuff here

[vitz3]

Hi all!

This is more a message for the devs since I couldn't find a contact page.

Great work on the game! I couldn't fathom the amount of work that went into this and I appreciate it, fantastic stuff really. The textures in particular are quite impressive. I've only just started getting into the game but I was taken aback from the quality.

Cheers from Canada

[WeirdoYYY]

Hi all!

This is more a message for the devs since I couldn't find a contact page.

Great work on the game! I couldn't fathom the amount of work that went into this and I appreciate it, fantastic stuff really. The textures in particular are quite impressive. I've only just started getting into the game but I was taken aback from the quality.

Cheers from Canada

They definitely know their shit. Lots of work put into it and seeing it develop over a long period of time is exciting. So much cool stuff can be done with the Aleph One engine that the previous one couldn't do. (Now if only we can make scenario creation slightly easier. )

Oi oi oi from Canada as well.

[Crater Creator]

They definitely know their shit. Lots of work put into it and seeing it develop over a long period of time is exciting. So much cool stuff can be done with the Aleph One engine that the previous one couldn't do. (Now if only we can make scenario creation slightly easier. )

I don't mean to single out your negative criticism, but in what ways do you find scenario creation difficult? I've worked with a lot of different engines and I struggle to see parts of the Aleph One workflow that are majorly lacking. Even visual mode can be streamlined to be about as efficient as it is in Forge.

[WeirdoYYY]

They definitely know their shit. Lots of work put into it and seeing it develop over a long period of time is exciting. So much cool stuff can be done with the Aleph One engine that the previous one couldn't do. (Now if only we can make scenario creation slightly easier. )

I don't mean to single out your negative criticism, but in what ways do you find scenario creation difficult? I've worked with a lot of different engines and I struggle to see parts of the Aleph One workflow that are majorly lacking. Even visual mode can be streamlined to be about as efficient as it is in Forge.

I have a post about it on the editors section. Maybe I'm just not used to it but I find with all the hi res and scripting features of today, it's a bit more difficult than before. Lots more variables to work with. How do you get visual mode to be streamlined to work as efficient as forge?

[goran]

If you can ignore the extra time it takes to switch between draw mode and visual mode, the new combo of tools are much better than forge.

The tools in weland are identical to forge's. Identical or better. Some tools have been improved upon. There are no polygons limits . Forge is limited to 1024.

Visualmodelua has no limits. Forge visual mode has "view crosses too many transparent lines error" and "too long viewing distance error". These two errors/limits are difficult/annoying to work with.
´
Imo, the new advantages outweighs the switch time.

[WeirdoYYY]

If you can ignore the extra time it takes to switch between draw mode and visual mode, the new combo of tools are much better than forge.

The tools in weland are identical to forge's. Identical or better. Some tools have been improved upon. There are no polygons limits . Forge is limited to 1024.

Visualmodelua has no limits. Forge visual mode has "view crosses too many transparent lines error" and "too long viewing distance error". These two errors/limits are difficult/annoying to work with.
´
Imo, the new advantages outweighs the switch time.

The visual limits are annoying yeah but I guess I'm used to em.

[Crater Creator]

How do you get visual mode to be streamlined to work as efficient as forge?

It requires some extra setup.

When you call .save level MyLevelName.sceA in visualmode.lua, Aleph One puts it in ~/Library/Application Support/AlephOne. This is awful, because in OS X 10.7 and later you can't even access ~/Library without running a terminal command. That much you can fix if you open terminal and run "chflags nohidden ~/Library/".

With that taken care of, my workaround has been to make an alias in my Aleph One folder (the one with the executable) that points to ~/Library/Application Support/AlephOne, and a second alias in that folder that points back to the first. With that second alias created, when you go to Preferences->Environment->Map, you can select maps directly from the library, where Aleph One saves them. That means while using visual mode, you can write over the very map you're editing, which in turn means you can click Begin New Game and continue texturing where you left off.

In addition, you can open the level in the library in Weland. You can leave Aleph One open while you make edits in Weland. Then save from Weland, and next time you Begin New Game in Aleph One you'll see your changes. Each time you .save level from Aleph One I believe you'll need to re-open the level in Weland.

But the gist of this is, if you set things up thusly you can do both draw mode and visual mode type edits on a level without having to close Weland or Aleph One, without having to move files, and without having to switch filepaths while you do it.

I suppose since a non-developer can't change where .save level saves, the ultimate simplification is to move ALL Aleph One files into Application Support, and run the game from there. It wouldn't be my first choice, but it would get what I want: to have all my maps and other game data files in one place.

[treellama]

FWIW you can access ~/Library by holding the option key down when selecting the Go menu. You can also access it in save dialogs by typing command-shift-G and then typing in ~/Library. Also, I think Weland's non-native file dialogs show it.

[Pfhorrest]

If I may ask -- and this has probably been asked before -- since both Weland and Aleph One are open source and even maintained by the same person, why can't Weland just use Aleph One's own rendering code for its own internal visual mode? Or perhaps have some hook in Aleph One that allows another program to send it environment data and start a new game (doesn't the Linux version already do something like that on startup?), so Weland can just send the map it's working on and visualmodelua to Aleph One for visual editing? (If Aleph One is limited to writing data to it's own Application Support folder that makes sending saved changes back a pain, but why must it be thus limited?)

[treellama]

Aleph One's renderer is not yet modular enough for internal use in other programs--not to mention that Weland and Aleph One use two completely different languages and UI toolkits. The reason there isn't better external integration between the two is because the current implementation was sufficient for my own needs. There's no technical reason they couldn't be integrated better.

Aleph One is limited to saving data to its own Application Support folder on the Mac by the OS X sandbox, which only allows writing to files outside of the app container when authorized by the user through native file dialogs, which Aleph One doesn't use.

[glue]

When you call .save level MyLevelName.sceA in visualmode.lua, Aleph One puts it in ~/Library/Application Support/AlephOne. This is awful, because in OS X 10.7 and later you can't even access ~/Library without running a terminal command. That much you can fix if you open terminal and run "chflags nohidden ~/Library/".

Crater Creator's full thread just saved some sanity as I could not find the path where Visual Mode was saving the map as it was an invisible file: this is a Lion OS X change. Thanks!!! Now if I just have to get this Visual Mode interface down.