JUICE
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.
- screamingfool
- Mjolnir Mark IV
- Posts: 500
- Joined: Jul 19th '06, 22:10
- Contact:
Treellama wrote: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 wrote:Ok, sorry I meant after using JUICe does Aleph one send the colour table as well as new bitmaps, thanks.
nice reading comprehension
I must thank you for putting this on simplici7y instead of just sourceforge.irons wrote: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:Simplici7ySourceforge Project
(for some reason sourceforge crashes my old outdated juiceless, lochless, generally anything worth crapping on computer)
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.
underworld : simple fun netmaps // prahblum peack : simple rejected netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
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.
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.
underworld : simple fun netmaps // prahblum peack : simple rejected netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
- Bobwithkeycard
- Mjolnir Mark IV
- Posts: 490
- Joined: Feb 23rd '06, 16:31
- Location: AMS-Tower
- Contact:
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?
I bring my own plasma rifle to the house of pain
-
- Cyborg
- Posts: 231
- Joined: Jul 30th '07, 19:43
- Contact:
What kind of nutjob porn are you looking at?Bobwithkeycard wrote:Am I also gonna be able to merge secret pr0n files... to hide it from the feds
- Bobwithkeycard
- Mjolnir Mark IV
- Posts: 490
- Joined: Feb 23rd '06, 16:31
- Location: AMS-Tower
- Contact:
dude, I was kidding..stop taking the thread off-topic
I bring my own plasma rifle to the house of pain
-
- Cyborg
- Posts: 231
- Joined: Jul 30th '07, 19:43
- Contact:
I was playing along, but couldn't think of a way to convey it that would be obvious in text.Bobwithkeycard wrote:dude, I was kidding..stop taking the thread off-topic
Also, JUICE.
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.
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.
underworld : simple fun netmaps // prahblum peack : simple rejected netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
- Bobwithkeycard
- Mjolnir Mark IV
- Posts: 490
- Joined: Feb 23rd '06, 16:31
- Location: AMS-Tower
- Contact:
And you said you wanted to do it in the long runirons wrote:[..]a release will come in the next day or two.
I bring my own plasma rifle to the house of pain
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' classcreate EpntChunk,EpntEntry originallyand 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
because of lacking a chunk,"EPNT"(endpoint).
The added codes were ...case sentence into 'src.backend.Level' classcreate EpntChunk,EpntEntry originallyand 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
Last edited by HogePiyo on Nov 28th '07, 13:43, edited 1 time in total.
SourceForge.net Project
-JUICE ( Released from irons )
-Map Editor One J ( in progress )
-Terminal Editor One J ( in progress )
-Physics Editor One J ( latest version downloadable from FileBall)
-------------------
SourceForge.jp Releases
-Map Viewer One
-Physics Editor One
-Map Demerger One
-------------------
My web site
[HogePiyo's Tools Download Page]|
-------------------
avator image from : http://source.bungie.org/content/content_c...avid_Simon.html
-JUICE ( Released from irons )
-Map Editor One J ( in progress )
-Terminal Editor One J ( in progress )
-Physics Editor One J ( latest version downloadable from FileBall)
-------------------
SourceForge.jp Releases
-Map Viewer One
-Physics Editor One
-Map Demerger One
-------------------
My web site
[HogePiyo's Tools Download Page]|
-------------------
avator image from : http://source.bungie.org/content/content_c...avid_Simon.html
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.HogePiyo wrote: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.
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.
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.HogePiyo wrote: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.
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.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'm excited to have a new member of the JUICE project! Please give me your username soon!
underworld : simple fun netmaps // prahblum peack : simple rejected netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
well, the problem of 'Rendering font' was already resolved in AlephOneJP project in marathon group of sourceforge.jp.Treellama wrote: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.
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.
>souceforge.net usernameirons wrote: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!
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.
SourceForge.net Project
-JUICE ( Released from irons )
-Map Editor One J ( in progress )
-Terminal Editor One J ( in progress )
-Physics Editor One J ( latest version downloadable from FileBall)
-------------------
SourceForge.jp Releases
-Map Viewer One
-Physics Editor One
-Map Demerger One
-------------------
My web site
[HogePiyo's Tools Download Page]|
-------------------
avator image from : http://source.bungie.org/content/content_c...avid_Simon.html
-JUICE ( Released from irons )
-Map Editor One J ( in progress )
-Terminal Editor One J ( in progress )
-Physics Editor One J ( latest version downloadable from FileBall)
-------------------
SourceForge.jp Releases
-Map Viewer One
-Physics Editor One
-Map Demerger One
-------------------
My web site
[HogePiyo's Tools Download Page]|
-------------------
avator image from : http://source.bungie.org/content/content_c...avid_Simon.html
There's no reason to have two different Aleph One projects, though. Is there?HogePiyo wrote:well, the problem of 'Rendering font' was already resolved in AlephOneJP project in marathon group of sourceforge.jp.
- Bobwithkeycard
- Mjolnir Mark IV
- Posts: 490
- Joined: Feb 23rd '06, 16:31
- Location: AMS-Tower
- Contact:
hmmm, AlephOneJp Project..interesting. Does it have any other nice features that aren't in the official AlephOne?
I bring my own plasma rifle to the house of pain
Why don't you download it and try it?
- Bobwithkeycard
- Mjolnir Mark IV
- Posts: 490
- Joined: Feb 23rd '06, 16:31
- Location: AMS-Tower
- Contact:
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.
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.
I bring my own plasma rifle to the house of pain
From my visits to the Japanese IRC channel, I have the impression that their version supports some form of B&B.
underworld : simple fun netmaps // prahblum peack : simple rejected netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
Hey, what's with the attitude? It's not *my* fault you don't speak Japanese!Bobwithkeycard wrote: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.
- Bobwithkeycard
- Mjolnir Mark IV
- Posts: 490
- Joined: Feb 23rd '06, 16:31
- Location: AMS-Tower
- Contact:
heh, nice one, irons
sorry treellama, your inquiry sounded like attitude towards me, apparently a misunderstanding. And now to more JUICY things...
sorry treellama, your inquiry sounded like attitude towards me, apparently a misunderstanding. And now to more JUICY things...
I bring my own plasma rifle to the house of pain
- screamingfool
- Mjolnir Mark IV
- Posts: 500
- Joined: Jul 19th '06, 22:10
- Contact:
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?
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.
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.
underworld : simple fun netmaps // prahblum peack : simple rejected netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps
azure dreams : simple horrible netmaps // v6.0!!!: thomas mann's greatest hits : simple simple netmaps