JUICE

[treellama]

JUICE doesn't send anything. Aleph One will send the color table, but, like shapes files have always worked, it will only use the first CLUT in the collection for wall textures.

[$lave]

Ok, sorry I meant after using JUICe does Aleph one send the colour table as well as new bitmaps, thanks.

[screamingfool]

JUICE doesn't send anything. Aleph One will send the color table, but, like shapes files have always worked, it will only use the first CLUT in the collection for wall textures.

Ok, sorry I meant after using JUICe does Aleph one send the colour table as well as new bitmaps, thanks.

nice reading comprehension

[logan]

JUICE v1.1.1 is ready for action. The new version of Aleph One should be released very soon, and we've been given the go-ahead to get JUICE rolling out the door. Mappers, in preparation for embedded shapes in A1, visit one of these links to get the new JUICE:

• Simplici7y
• Sourceforge Project

I must thank you for putting this on simplici7y instead of just sourceforge.
(for some reason sourceforge crashes my old outdated juiceless, lochless, generally anything worth crapping on computer)

[irons]

You're welcome. The Sourceforge project is really there so that Watts and I have access to a development collaboration tool called Subversion. This lets use update our source code really easily. Some secondary reasons for registering on SF are things like bug reports (people basically ignore that interface, and we haven't gotten any bugs in there yet) and feature requests (1 and counting!!). We figured S7 was a better place to put the stuff for the everyday user.

[irons]

At long last, I'm implementing a merging system into JUICE. So far, I've only been able to confirm merging of map files, but I just added hypothetical support for merging shapes patches in, as well. Physics files won't be hard at all; lucky for us, the format of those files is just an extension to the chunk-based map format. I'll have to add a reader for physfiles, but once that's done, merging those will also be a piece of cake. I've checked out the terminal chunk format, and it's a whole wad more complicated than I thought. Instead of just embedding the terminal text file, we have to compile it into something ugly. So, merging terminals and resource forks (generally considered to be things only scenario developers do) is a long way off.

The merge setup will follow the old Forge convention: JUICE looks for Forge's unmerged map format in all files that start with N[number] or L[number]. New is the shapes patch convention, which is the same, but with S[number] at the beginning.

So, ideally, you'd have a directory set up like so:

L00.Boring Level Name
N01.Tinklefarm
S00.Boring Level Name
S01.Tinklefarm

and JUICE takes care of the rest. I'm not sure how Forge did things, but if you instead named N01 to be N01.Boring Level Name, the Boring Level Name shapes patch would go into that level instead of the Tinklefarm patch.

With this setup, you can operate on a directory that already has a project started in Forge. Or, for those of us who don't have Forge and/or a system capable of running it, you can use Smithy to the same effect. For now, this only works on unmerged maps produced by those two programs; a single-level map file made by, say, Obed, Pfhorte, or Pfhorge will not work. I will probably change this later if people have a need for it.

All we need to do in order to roll a new release is to add a merge function into the GUI.

For those who are following JUICE with some interest in the behind-the-scenes stuff, I also updated the backend so that it uses a much easier calculation method for the map files; it was this new method that allowed JUICE to add merging. Anyone who is using JUICE in a project (for example, HogePiyo's J-viewer) should check Revision 59 out of Subversion. Don't get anything newer, yet--Revision 60 has the new merge code and things are pretty messy.

So anyway, I'm pretty excited about this. I'll announce the release of JUICE 1.2.0 when we have it running.

[Bobwithkeycard]

way to go, man. Am I also gonna be able to merge secret pr0n files and pirated dvd's into my maps? you know..to hide it from the feds + the gf?

[localwarming]

Am I also gonna be able to merge secret pr0n files... to hide it from the feds

What kind of nutjob porn are you looking at?

[Bobwithkeycard]

dude, I was kidding..stop taking the thread off-topic

[localwarming]

dude, I was kidding..stop taking the thread off-topic

I was playing along, but couldn't think of a way to convey it that would be obvious in text.

Also, JUICE.

[irons]

We decided, as a last-minute thing, to add JUICE conversion scripts as objects that are acted upon during the merge process. This way, you can have a file J00.Level (a script) that will convert L00.Level's textures. So in a larger project (for example, if the CTF pack Magenta Filter had been started after JUICE and the JUICE merge process) it is now possible to cut down on the time spent editing each level for these kinds of things. Taking the Magenta Filter example a little further:

1) Edit levels in Forge.
2) Make sure JUICE scripts and flag shapes patches are in the merge directory
3) Use JUICE to merge everything together; now, levels have both texture sets and include flag patches

Then there's nothing to reverse when you decide to change a level later--just go through the JUICE merge when you're done.

I'm now in the testing phase of level, patch, and script merging. If it seems to work out well enough, a release will come in the next day or two.

[Bobwithkeycard]

[..]a release will come in the next day or two.

And you said you wanted to do it in the long run

[HogePiyo]

BTW, I've put some additional codes into downloaded JUICE ver.1.1.1 while get JUICE into my program, 'Map Viewer J',
because of lacking a chunk,"EPNT"(endpoint).
The added codes were ...

• case sentence into 'src.backend.Level' class
• create EpntChunk,EpntEntry originally

and so on.

Considering to your continuing developing JUICE, my operating might cause confusion.
So would you let me join the JUICE project? I want to merge this addition to your own JUICE.

--
Next, I gonna do for the terminal chunk. a japanese friend requested me for the function or a new program which can edit and replace terminal text. He said that he want to localize the english native maps into Japanese.
if you've done to load terminal text, I'll wait for the next release or CVS nightly. If not, I gonna make the method and create that chunk/entry class.

EDIT: added the version of downloaded JUICE

[treellama]

a japanese friend requested me for the function or a new program which can edit and replace terminal text. He said that he want to localize the english native maps into Japanese.

This is possible right now, to a limited degree, correct? You can change the font to a Japanese one, and use the old Mac OS Japanese character set.

Some day we should render terminals using SDL_TTF and Unicode, then you could have all the possible kanji available for rendering. I think this might require changing the way terminals are stored, though!

Unfortunately, you will never be able to use Japanese characters on the metaserver; but I don't know many Japanese that play on there. marin and NEC PC user come to mind.

[irons]

Considering to your continuing developing JUICE, my operating might cause confusion.
So would you let me join the JUICE project? I want to merge this addition to your own JUICE.

If you give me your sourceforge.net username, I will add you to the project. I was waiting to do EPNT because some maps have PNTS instead. After your EPNT goes into our subversion, we can learn what we need to do in order to work together.

Next, I gonna do for the terminal chunk. a japanese friend requested me for the function or a new program which can edit and replace terminal text. He said that he want to localize the english native maps into Japanese.
if you've done to load terminal text, I'll wait for the next release or CVS nightly. If not, I gonna make the method and create that chunk/entry class.

I added some support for the terminal chunk, but I found out that it was hard to compile terminals. If you want to try adding full support, you are welcome to do it. Right now, the TermChunk only holds binary data from the terminal chunk, and there is no entry. I think you will see this more easily in the source code.

I'm excited to have a new member of the JUICE project! Please give me your username soon!

[HogePiyo]

This is possible right now, to a limited degree, correct? You can change the font to a Japanese one, and use the old Mac OS Japanese character set.

Some day we should render terminals using SDL_TTF and Unicode, then you could have all the possible kanji available for rendering. I think this might require changing the way terminals are stored, though!

Unfortunately, you will never be able to use Japanese characters on the metaserver; but I don't know many Japanese that play on there. marin and NEC PC user come to mind.

well, the problem of 'Rendering font' was already resolved in AlephOneJP project in marathon group of sourceforge.jp.

what I wanna do is to replace just the text data in Map chunks. Almost all the maps are written in English, so he wants to translate into Japanese.

If you give me your sourceforge.net username, I will add you to the project. I was waiting to do EPNT because some maps have PNTS instead. After your EPNT goes into our subversion, we can learn what we need to do in order to work together.
I added some support for the terminal chunk, but I found out that it was hard to compile terminals. If you want to try adding full support, you are welcome to do it. Right now, the TermChunk only holds binary data from the terminal chunk, and there is no entry. I think you will see this more easily in the source code.

I'm excited to have a new member of the JUICE project! Please give me your username soon!

>souceforge.net username
My username is 'hogepiyo', and sent the message for you. please check it out.
I just have a user account of SourceForge."JP". so created "NET" account quickly

> PNTS
I didn't consider that. And no idea to deal with the map contains PNTS. In the mean time, I'll add the EPNT entry codes.

>compile terminals
that is also my point to resolve.

>terminal chunk into text and entries
I'll try to equip the methods by refering AlephOne's source codes in this weekend.

[treellama]

well, the problem of 'Rendering font' was already resolved in AlephOneJP project in marathon group of sourceforge.jp.

There's no reason to have two different Aleph One projects, though. Is there?

[Bobwithkeycard]

hmmm, AlephOneJp Project..interesting. Does it have any other nice features that aren't in the official AlephOne?

[treellama]

Why don't you download it and try it?

[Bobwithkeycard]

come on, are you kidding? There could be lots of differences that aren't visible on first or second sight. I am merely interested whether the main intention behind AlephOneJp is custom language support or if there's more to it.
What better way is there to ask the most prominent Japanese Marathon coder...who's also participating in this thread and who always has a friendly answer.
It certainly beats trying to look at ReadMes whose language I do not speak.

[irons]

From my visits to the Japanese IRC channel, I have the impression that their version supports some form of B&B.

[treellama]

come on, are you kidding? There could be lots of differences that aren't visible on first or second sight. I am merely interested whether the main intention behind AlephOneJp is custom language support or if there's more to it.
What better way is there to ask the most prominent Japanese Marathon coder...who's also participating in this thread and who always has a friendly answer.
It certainly beats trying to look at ReadMes whose language I do not speak.

Hey, what's with the attitude? It's not *my* fault you don't speak Japanese!

[Bobwithkeycard]

heh, nice one, irons

sorry treellama, your inquiry sounded like attitude towards me, apparently a misunderstanding. And now to more JUICY things...

[screamingfool]

as a layman i dont know if this makes any sense but how hard/valuable would it be to change the way terminals are coded and stored to make it easier to make terminals, edit them in merged maps, add pictures without resedit, and possibly translate as you were saying earlier?

[irons]

The coded and stored part has nothing to do with how easy it is to make or edit terminals; a good translator or GUI will help you with that (not that I'm capable of writing either). I don't know what HogePiyo plans for the terminal compiler, but if he doesn't make a WYSIWIG-style editor, I'm sure someone can create one that runs as a standalone program and spits out a plain-text file like the ones used by Forge. After that, JUICE ought to be able to swap a new terminal into a level or merge it with a batch of files.

Pictures are possible without using Resedit: in the Windows 95 version of Marathon 2, they actually stored pictures in extra levels at the end of the map file. I'd actually rather learn this method than tangle with resource forks, but I'm not sure if it would be a good idea.