(Hopefully I'm not posting this topic on all boards simultaneously or something... )
Marathon Syndicate is dead and I decided to release two of my contributed maps as a mini-scenario for Rubicon X. (The third one isn't worth it). I missed the most recent evolutions in content creation technology & practices, so I'll use this thread to ask questions as they pop up. (Admins: feel free to move it if it should be in Editors, Emulators, Etcetera)
My first question: One map uses some additional (high-res) textures. What is more practical: releasing a scenario file and a plugin, or somehow merging the plugin into the scenario file (if this is even possible)?
Questions regarding the release of some Syndicate fragments
Question 2: Should I merge a patch into the map if it uses more textures than are present in the Rubicon shapes file?
They're not the best, although one is good and the other at least stands out in originality.
Well, it's better not to refer to external files in MML, so a plugin makes more sense for the hi-res textures. Embedded shapes patches override hi-res textures, so you'll have to put the shapes patch in the same plugin, and just hope users are smart enough to enable it when playing your levels.
I'll do that. I suppose there's no way to check, from within the level-specific lua, whether a plugin is enabled?
Also, is there a reason why you can't gather a network game with 1 player? It would be practical for testing lua scripts that behave different in cooperative games.
Also, is there a reason why you can't gather a network game with 1 player? It would be practical for testing lua scripts that behave different in cooperative games.
Aleph One used to have just such a testing mode, but we noticed many spots in the engine that check the number of players rather than the multiplayer flag. These led to crashes and places where the engine behaved differently in a "real" multiplayer game, negating the point. We disabled it because of the effort needed to bring it up to proper working order. Sorry.
Ah, Bungie
Ok, now I have a very silly problem: I can't find the A1 log file. My computer just doesn't contain any file with "log" in its name that was edited today. The pfhorums search tool claims it cannot find the word "log" anywhere. What's going on?
Edit: found it: ~/Library/Logs/Aleph One log.txt
I thought macs were good at searching...
Ok, now I have a very silly problem: I can't find the A1 log file. My computer just doesn't contain any file with "log" in its name that was edited today. The pfhorums search tool claims it cannot find the word "log" anywhere. What's going on?
Edit: found it: ~/Library/Logs/Aleph One log.txt
I thought macs were good at searching...
- PerseusSpartacus
- Mjolnir Mark IV
- Posts: 334
- Joined: Apr 30th '12, 05:03
- Location: Somewhere in the 19th Century...
Actually, I think the search engine doesn't check your Library, just stuff outside your library. Kind of strange, I'll admit, but that's just how it works.Drictelt wrote:Edit: found it: ~/Library/Logs/Aleph One log.txt
I thought macs were good at searching...
The wiki now lists the log-file locations as well. They were previously documented in the bug reporting guide, which is the most common reason to find the log, but not the only one.
FYI, the Console app (in /Applications/Utilities) is useful for finding log files on a Mac. In 10.8 at least, its sidebar shows you common locations including ~/Library/Logs. That doesn't excuse the default search behavior, but it can help you investigate.
FYI, the Console app (in /Applications/Utilities) is useful for finding log files on a Mac. In 10.8 at least, its sidebar shows you common locations including ~/Library/Logs. That doesn't excuse the default search behavior, but it can help you investigate.
Thanks, that's how I found it (by opening an unrelated log file), in spite of the search tool convincing me that it didn't exist.
- ellio7t
- Cyborg
- Posts: 271
- Joined: May 25th '08, 19:57
- Location: long beach, ca no, now I live in L.A.
- Contact:
You should see about getting as much of the scenario together as possible and releasing that. I remember there was a lot of work going on when I was involved with the project, albeit a shot time. I'm sure other team members would like to see what they worked on come out is some cohesive form.
My original plan was to release the first three levels (all mine) as they were, with the Syndicate story and all. But Goran didn't like the idea:
Since he created the most awesome parts of the Syndicate, I think we should respect that. However, you guys have my permission to integrate whatever I contributed into a future Syndicate release. Meanwhile, I'll release my own two levels with a seriously stripped-down storyline and with only the custom textures they use.Syndicate is dead for sure. Releasing it unfinished - I do not like. It is a bit of a mess as it is. I would like to keep its content hidden from public view, in case I ever come back or find a way to recycle it into a new project.
I could pretend to be a SUper hacker and "steal it" when in reality you simply released it for the good of the people.
Goran would never know.
Goran would never know.
Shocktart wrote:I could pretend to be a SUper hacker and "steal it" when in reality you simply released it for the good of the people. Goran would never know.
Between now and January.
Back on topic: I'm a bit confused as to how exporting shapes patches works in ShapeFusion. I found the following quote from TL at http://pfhorums.com/viewtopic.php?f=24& ... sion+patch:
Back on topic: I'm a bit confused as to how exporting shapes patches works in ShapeFusion. I found the following quote from TL at http://pfhorums.com/viewtopic.php?f=24& ... sion+patch:
So what I should do is: I open the modified shapes file, then select the original Rubicon shapes file as base file and then a patch is generated which is some sort of difference? (It will be a Rubicon scenario.)Treellama wrote:To generate a shapes patch, ShapeFusion will first prompt for a base shapes file. This is the file that the patch will be built against--i.e. the main shapes file the user will have loaded when they use your patch. For net games this will almost always be the standard Marathon Infinity shapes. After that it will prompt you for where to save the patch.
That's right. A shapes patch is just a list of differences from an original shapes file.
Yahaa, so far, everything works! These plugins are a good invention.
It seems however that Aleph One doesn't complain at all (not even in the log) when a closing slash is missing in Plugin.xml. It just silently ignores the entire plugin.
It seems however that Aleph One doesn't complain at all (not even in the log) when a closing slash is missing in Plugin.xml. It just silently ignores the entire plugin.
Does Atque have a log file? After I pick a location to save the merged map file, it just crashes.
Removing the slanted f in the Rubicon X f folder name doesn't help.
Edit: it does merge other scenarios, so I'm doing something wrong.
Edit2: After removing all .DS_Store files from the merge folder and its subfolders, Atque says "Merge succesful", but when I try to play the map, Aleph one says a system error occurred when trying to read from the file and Weland says:
Array index out of range: (see screenshot).
Removing the slanted f in the Rubicon X f folder name doesn't help.
Edit: it does merge other scenarios, so I'm doing something wrong.
Edit2: After removing all .DS_Store files from the merge folder and its subfolders, Atque says "Merge succesful", but when I try to play the map, Aleph one says a system error occurred when trying to read from the file and Weland says:
Array index out of range: (see screenshot).
I "solved" it: I was doing this on a FAT-32 partition. This time I copied the merge folder to a HFS+ partition, merged, saved the merge on HFS+, copied to FAT-32 and that works fine.
Conclusion: Atque + mac + Fat-32 = misery. I'm not even sure we should see this as a flaw of Atque, because mac + fat-32 is misery in itself.
Then why do I have a fat-32 partition? It seemed to be the least bad option for a common partition for dual booting OSX and Ubuntu. I suppose I will move my marathon activities to Linux then.
Oddly, the other scenario that I merged, worked perfectly on the fat-32 partition...
Conclusion: Atque + mac + Fat-32 = misery. I'm not even sure we should see this as a flaw of Atque, because mac + fat-32 is misery in itself.
Then why do I have a fat-32 partition? It seemed to be the least bad option for a common partition for dual booting OSX and Ubuntu. I suppose I will move my marathon activities to Linux then.
Oddly, the other scenario that I merged, worked perfectly on the fat-32 partition...
Hmm, Atque shouldn't care about .DS_Store files; I believe it will only merge files for which it recognizes the extensions.
I do know that merging the entire Rubicon scenario as it is will not work. Resource IDs 0-127 are reserved for system resources, and Atque can't merge them; but the Rubicon creators didn't bother to read the ResEdit reference, and use PICTs starting at 0 for terminals. So you can split it, but you can't merge it without remapping those IDs to valid numbers.
I do know that merging the entire Rubicon scenario as it is will not work. Resource IDs 0-127 are reserved for system resources, and Atque can't merge them; but the Rubicon creators didn't bother to read the ResEdit reference, and use PICTs starting at 0 for terminals. So you can split it, but you can't merge it without remapping those IDs to valid numbers.
No, it isn't that, because I was only using two pics: 00128.bmp and 00134.bmp