Is there anyway you could add randomly generated fortresses around the map so that we can use the siege weaponryi n singleplayer, also if this was capable make a mob that tries to defend the fortresses?
Both features are already in-game.
World gen has random towers with soldiers/siege engines, as well as larger fortresses that spawn occasionally in villages (all hostile). There are also smaller hostile bunkers that can spawn in the world, manned with a few soldiers to fight.
The RUINS mod, MCEdit and MCDungeons all have the same problem when it comes to supporting mod blocks - none of them have achieved it yet. Personally, I have stopped using mod blocks in most construction I intend to cut and paste because of this, and wouldnt have expected it to be in your scanner tool either. Its an almost impossible task.
By the way, has the config changed? I updated to 1.4.6 and now the random towers etc will not spawn with anything other than cannons. I've changed the fort to ballista turret - but havent seen one spawn yet, but the towers dont seem to havean entry in the config?
I patched in the two missing lines from the old config into the new, and now I have them spawning with ballistae turrets again.
I'll take a look at the config stuff for the next update. Forge changed a _ton_ of the config stuff behind the scenes, and I haven't really looked at it much in months. From a quick guess, I would say that where I was previously pre-declaring configs (to make them show up in the output file before being needed/used) is no longer functioning as it should. Probably only a few lines to fix it.
(I will be storing all structure templates as non- .java / .class files)
Preferred structure file type?
Human readable/editable outside of game (e.g. Ruins template files) (harder to parse, more prone to entry errors)
NBT Tagged format (editable outside game with any NBT editor?)(easy to parse, harder to edit but still fairly easy, robust vs. entry errors)
Binary (good luck reading outside of game)(easy to parse, no editing, immune to entry errors, corruptible if edited incorrectly).
(I'm leaning towards the NBTTagged format, but I may also opt to save things to a human-readable, probably compatible with Ruins formatting)(I will be contacting AtmomicStryker to see if it is okay that I use his template formatting/etc before I do)
I've also been looking over the Ruins source, and it appears that Atomic has a pretty decent system in place for his templates.
A few features I'm curious on whether I should support or not: (please be familliar with Ruins template if you answer these questions)
block randomization? (any block can be randomized)
block preservation features? (leave lava/water/plants if configured to)
Also, it might take a bit longer to get the MCEdit schematic import feature working--apparently MCEdit schematics are in some binary/encrypted format, and I will have to lookup specs on the format/ask Atmomic for his conversion code.
I have a bug when I play on lan with someone. I am not sure how to explain it so bare with me. I played single player and opened It up to lan. We went exploring and everything was found till I found a small hostile fortress. He didn't see it, for him there was a bunch of gravel floating In the air and the cannons were In weird places. We have the mod Installed on both computers and we don't have any other mods. I tried to post a picture but I couldn't figure out how. If their is any way to fix this it would be a big help. Thanks
Edit: Also if anyone knows what the crafting recipe for the siege workstation that would be a big help. The picture isnt showing up on the wiki page right now.
Quick question:
Human readable/editable outside of game (e.g. Ruins template files) (harder to parse, more prone to entry errors)
NBT Tagged format (editable outside game with any NBT editor?)(easy to parse, harder to edit but still fairly easy, robust vs. entry errors)
Binary (good luck reading outside of game)(easy to parse, no editing, immune to entry errors, corruptible if edited incorrectly).
Human readable or NBT/MCedit. I'm not sure what human-readable formatting method would be best (the current rectangle drawing system is even hard for me to comprehend, and I'm a 3d-graphics guy who's used to that kind of visualization), and having an editor for that format would be ideal (though if you're making it work with the in-game stuff, that'll be less important). I like the idea of being able to modify a file just by opening it up in a text editor though.
Perhaps a sideways look at it- might it be possible to store building information in image form? Select colors to represent different blocks/block types (maybe all blocks start at 50% saturation, 50% brightness, and the hue is the data value and modifications to the sat/bright values are special values) and each pixel is a block. Levels would need to be made distinct somehow, probably either a separate image, a layer, or a special color that flags that this is the second level; figuring out a flag for duplicate levels might also be good. That'd make the buildings human readable, keep the format small, and allow a plethora of visible editors to be used that already exist.
I spoke with AtomicStryker yesterday, and he has no issues with me including support for his template/formatting--so good news there.
As to my intended template format:
It will probably be very similar to the Ruins template format, but with support for a few more advanced feature specific to my mod (I will still include an exporter to convert to proper ruins template though). That template is _very_ human editable. When looking through it, you can pretty much 'see' what the building is, with a bit of imagination. Advanced features will include support for spawning soldiers, gates, and vehicles. Also, it looks like I will be supporting the full feature-set from ruins templates (including preservation and randomization features), but I will also be including special block-group/biome block selection features (make a building use diff. blocks if in a certain biome).
Made a decent bit of progress over the past few days, did the first test-compile on the new code, and first few-test runs. Got the item-code all sorted out (full tooltip support!), and the rest of the framework is starting to come together well. I may be able to get a testable version of the structure stuff out in the next week or so (if I can figure out what my own template format will be ).
Next Update/Release for Catapult_Mod will include:
Update for 1.4.7 (not really necessary--i think the 1.4.6 release works fine on x.7, but updated to newest forge)
Fix config options for structure vehicle and gate types for watchtowers and bunkers.
Changing the recruiting system to not need _pork chops_, but be able to use any type of food. it will be looking for a specific total food value.
Not sure when I will get this update out, as there is still a bit to clean up on it, and tons of testing.
... That template is _very_ human editable. When looking through it, you can pretty much 'see' what the building is...but I will also be including special block-group/biome block selection features (make a building use diff. blocks if in a certain biome).
Made a decent bit of progress over the past few days, did the first test-compile on the new code, and first few-test runs. Got the item-code all sorted out (full tooltip support!), and the rest of the framework is starting to come together well. I may be able to get a testable version of the structure stuff out in the next week or so (if I can figure out what my own template format will be ).
Next Update/Release for Catapult_Mod will include:
Update for 1.4.7 (not really necessary--i think the 1.4.6 release works fine on x.7, but updated to newest forge)
Fix config options for structure vehicle and gate types for watchtowers and bunkers.
Changing the recruiting system to not need _pork chops_, but be able to use any type of food. it will be looking for a specific total food value.
Not sure when I will get this update out, as there is still a bit to clean up on it, and tons of testing.
Will the update contain the structure improvements, or will that be a seperate thing? Anyway, sounds great, keep it up.
For the NPC aspect that is coming sometime after the structures, have you looked at Mine Colony? It used to be a mod where the NPC's did your bidding (harvesting, mining, etc.), and while it sounds like it had a clunky UI too IMO, it might be very similar to what you were hoping to do eventually.
Something that I've noticed I do not like is the whole 'soldiers consume food' (and really, all supplies; arrows are also a pain to supply) bit. It makes it so I need to spend all my time gathering food and putting it into carts for them. When/if NPC's are introduced that can work for me, that might change, but right now it's a pain (mostly because I need to put it into the carts or the soldiers won't get it, but also the sheer amount they require). Might be fine to dump that in favor of increasing their initial cost (and adding designated archers that come with non-user arrows), or giving them a food-upgrade/heal cost.
Edit: Have you seen the new stuff coming in the redstone update? Minecarts that do something, hoppers for moving goods around and into/out of chests, and some actual uses for the nether. Some of that will be very useful for dealing with gathering supplies for NPC's or for getting NPC's to do the gathering for us. Also, textures getting split up seems to me to be a boon (though their backwards way of rejoining them all up has me worried).
why is it that this mod always crashes. I had it a couple months ago, it crashed, Today, it crashed. Does this need some core or something?
It needs forge installed, which is linked somewhere in the first post or the wiki. If that's not the problem, you'll need to wait for Shadowmage to answer.
why is it that this mod always crashes. I had it a couple months ago, it crashed, Today, it crashed. Does this need some core or something?
Logs or it didn't happen.
Or more precisely...
Please provide crash logs, or there is nothing I can do about it.
I have not received any other complaints of crashes, so it is likely a setup or mod-conflict issue. However, if it turns out to be a real problem, I will do what I can to fix it in a timely manner.
I know, but their spawn system is what i like one dies another takes its place, makes spawning knights a lot easier,
Suggestion: Make the the people smarter give them like the wolfs brain or make them smarter they keep getting blown up and falling in wells around cities.
i have been looking for a anceint siege mod for the longest time, of and the arrow thingy should have explosive shot but that should only blow up on contact with and entity,(that would be historically accurrate as they could fire rocket arrows that had a forward facing charge the arrow would stick the enemy and the charge would burn and cause nasty damage to there flesh and bones)
there was also a handheld single shot vershion called a that looked honeycombs and was none reloadable(it also had a chance of blowing up)
I know, but their spawn system is what i like one dies another takes its place, makes spawning knights a lot easier,
Suggestion: Make the the people smarter give them like the wolfs brain or make them smarter they keep getting blown up and falling in wells around cities.
Define smarter?
Currently the soldier AI is far more advanced than a wolves, in every aspect. However, there are some issues that are (currently) out of my control. To respond directly to your comments--Pathing: they use the same pathing as vanilla entities--the MC pathing system. Hence, any problems vanilla entities experience will apply to soldiers as well (falling in things/off of cliffs, occasionally getting stuck). I'm looking into writing custom pathfinding, but need to do a few days/weeks worth of A* study before I can even begin. Getting blown up: I infer you mean they are getting destroyed by creepers? You can set their default targeting behavior in the config file--go in there and turn creepers off--problem solved, soldiers will no longer attack/target/be targeted by creepers (same can be done with any other vanilla mob, btw).
In the rewrite I'm thinking of going with a data-driven scripted AI, meaning the AI for each class of NPC will be customizable by the user through editing of script files. Its a ways out, but should both simplify the in-game soldier configuration and allow for greater customization to meet individual users'(servers/admins) likes/needs.
In other news:
rewritten structure system has been making great advances lately. I have the template sorted out, can scan in-game and export to template, and load templates in to be built in game. I have not worked on import/export of Ruins templates, but the systems are compatible at the core so it shouldn't be too difficult when I get to it. Need to work on supporting world-gen, as well as all of the advanced ruins-template features during world gen. I _might_ be able to get an alpha/test release out to a few select people (testers and long-time supporters) as soon as this weekend. This release will (likely) only cover basic scan, export, and creative-mode in-game building. It will be mostly for testing of readability and useability of the template as well as basic useability feedback.
If you would like to be included on the list for alpha-testing of the new version, please contact me via PM. (It won't be a _public_ release, but if you are truly interested in testing I could certainly use the help)
I'm still poking at updating the current version, changing the recruiting table a bit to use blind food-value instead of specific foods. I might try and merge in the new/updated structure code when I get it finished (as I really like the way it is turning out), but not sure how well that would really go over (lots of differences between code-bases, mostly in the low-level framework).
Currently the soldier AI is far more advanced than a wolves, in every aspect. However, there are some issues that are (currently) out of my control.
In the rewrite I'm thinking of going with a data-driven scripted AI, meaning the AI for each class of NPC will be customizable by the user through editing of script files. Its a ways out, but should both simplify the in-game soldier configuration and allow for greater customization to meet individual users'(servers/admins) likes/needs.
While I feel AI stuff can probably wait until after some of the other stuff (Buildings, Unit variation [archers mostly], weapon simplification/unification, tech tree, then AI), I have noticed that the AI soldiers have some quirks. They don't seem to interact well with mobs (or vis-versa) for one. Setting up a few more preset units might make their quirks disappear though. Just having it setup where archers exist and basically stay where you put them, soldiers go out and hunt mobs/enemies, siege engine operators stay on their engines, etc.; would make it seem like they were behaving better, if not completely properly.
While I feel AI stuff can probably wait until after some of the other stuff (Buildings, Unit variation [archers mostly], weapon simplification/unification, tech tree, then AI), I have noticed that the AI soldiers have some quirks. They don't seem to interact well with mobs (or vis-versa) for one. Setting up a few more preset units might make their quirks disappear though. Just having it setup where archers exist and basically stay where you put them, soldiers go out and hunt mobs/enemies, siege engine operators stay on their engines, etc.; would make it seem like they were behaving better, if not completely properly.
There are a few issues with mob interaction in the current AI. All vanilla mobs are hard-coded for what they are aggressive against, and I never looked fully into the hackey solutions to tell them to attack soldiers (and for some mobs isn't really possible).
Classes: There will be a much more dedicated class system coming for soldiers, with more limitations and fewer configuration options on the AI. Will make it much simpler to get the right soldier for the job (while still allowing for some customization within the classes, on a per-soldier basis). Currently I'm planning: commander(similar to current, can melee/ranged/drive--but is expensive), footsoldier (melee only), archer (mostly ranged, weak melee only if forced to), medic(heals), engineer(restock/repair), and driver (not sure what to call it, but a dedicated siege-engine driver---the other classes will not be able to drive siege engines<may allow training>). With the classes I can see some necessary changes to strategy and army composition--you will need the proper mix of each class to have a good force.
There are a few issues with mob interaction in the current AI. All vanilla mobs are hard-coded for what they are aggressive against, and I never looked fully into the hackey solutions to tell them to attack soldiers (and for some mobs isn't really possible).
Hmm... Is it possible to just replace the current mobs with mod-mobs who are hostile to your units? Or is that more work than just hijacking current code and adding a line referring to your guys? Having a hoard of opponents coming at your castle, or attacking their castle with a hoard of units, is one of the appeals here, and though vanilla mobs really aren't ideal for that, they are readily available. I'd love a situation where loads of vanilla mobs worked intelligently to try to destroy my fort/town while my soldiers try to defend it from them.
Classes: There will be a much more dedicated class system coming for soldiers, with more limitations and fewer configuration options on the AI. Will make it much simpler to get the right soldier for the job (while still allowing for some customization within the classes, on a per-soldier basis). Currently I'm planning: commander(similar to current, can melee/ranged/drive--but is expensive), footsoldier (melee only), archer (mostly ranged, weak melee only if forced to), medic(heals), engineer(restock/repair), and driver (not sure what to call it, but a dedicated siege-engine driver---the other classes will not be able to drive siege engines<may allow training>). With the classes I can see some necessary changes to strategy and army composition--you will need the proper mix of each class to have a good force.
Excellent as usual. I'd call the driver an engineer, but that's taken... maybe sapper? Also, would the engineer be responsible for carrying around goods and getting them from places other than chest-carts, or would that be another position/a future non-soldier position?
Shadowmage4513 i wana know if u can make it compatible for 1.4.7 cuz i just seen your mod on youtube and it look nice but i updated to 1.4.7, pls reply
Shadowmage4513 i wana know if u can make it compatible for 1.4.7 cuz i just seen your mod on youtube and it look nice but i updated to 1.4.7, pls reply
As far as I know it _should_ be compatible with 1.4.7, though I haven't personally tried (I don't think there were any obfuscation changes between 146 and 147--which is mostly what breaks mods).
Either way, the next update is being built on 1.4.7, so support will then if it isn't already working. When? As soon as I can quit working 12hr days and get back to major coding. If I forgo adding newly planned features I could have an update out just for 147 relatively quickly, but I would rather fix some things if I'm going to take the time to pack up a release.
I'm hoping for sooner rather than later..but no guarantees..... (perhaps this weekend, if I get some time?)
Both features are already in-game.
World gen has random towers with soldiers/siege engines, as well as larger fortresses that spawn occasionally in villages (all hostile). There are also smaller hostile bunkers that can spawn in the world, manned with a few soldiers to fight.
I'll take a look at the config stuff for the next update. Forge changed a _ton_ of the config stuff behind the scenes, and I haven't really looked at it much in months. From a quick guess, I would say that where I was previously pre-declaring configs (to make them show up in the output file before being needed/used) is no longer functioning as it should. Probably only a few lines to fix it.
(I will be storing all structure templates as non- .java / .class files)
Preferred structure file type?
Human readable/editable outside of game (e.g. Ruins template files) (harder to parse, more prone to entry errors)
NBT Tagged format (editable outside game with any NBT editor?)(easy to parse, harder to edit but still fairly easy, robust vs. entry errors)
Binary (good luck reading outside of game)(easy to parse, no editing, immune to entry errors, corruptible if edited incorrectly).
(I'm leaning towards the NBTTagged format, but I may also opt to save things to a human-readable, probably compatible with Ruins formatting)(I will be contacting AtmomicStryker to see if it is okay that I use his template formatting/etc before I do)
I've also been looking over the Ruins source, and it appears that Atomic has a pretty decent system in place for his templates.
A few features I'm curious on whether I should support or not: (please be familliar with Ruins template if you answer these questions)
block randomization? (any block can be randomized)
block preservation features? (leave lava/water/plants if configured to)
Also, it might take a bit longer to get the MCEdit schematic import feature working--apparently MCEdit schematics are in some binary/encrypted format, and I will have to lookup specs on the format/ask Atmomic for his conversion code.
Any other thoughts on compatibility?
Edit: Also if anyone knows what the crafting recipe for the siege workstation that would be a big help. The picture isnt showing up on the wiki page right now.Human readable or NBT/MCedit. I'm not sure what human-readable formatting method would be best (the current rectangle drawing system is even hard for me to comprehend, and I'm a 3d-graphics guy who's used to that kind of visualization), and having an editor for that format would be ideal (though if you're making it work with the in-game stuff, that'll be less important). I like the idea of being able to modify a file just by opening it up in a text editor though.
Perhaps a sideways look at it- might it be possible to store building information in image form? Select colors to represent different blocks/block types (maybe all blocks start at 50% saturation, 50% brightness, and the hue is the data value and modifications to the sat/bright values are special values) and each pixel is a block. Levels would need to be made distinct somehow, probably either a separate image, a layer, or a special color that flags that this is the second level; figuring out a flag for duplicate levels might also be good. That'd make the buildings human readable, keep the format small, and allow a plethora of visible editors to be used that already exist.
See the post for a Texture pack tutorial!
As to my intended template format:
It will probably be very similar to the Ruins template format, but with support for a few more advanced feature specific to my mod (I will still include an exporter to convert to proper ruins template though). That template is _very_ human editable. When looking through it, you can pretty much 'see' what the building is, with a bit of imagination. Advanced features will include support for spawning soldiers, gates, and vehicles. Also, it looks like I will be supporting the full feature-set from ruins templates (including preservation and randomization features), but I will also be including special block-group/biome block selection features (make a building use diff. blocks if in a certain biome).
Made a decent bit of progress over the past few days, did the first test-compile on the new code, and first few-test runs. Got the item-code all sorted out (full tooltip support!), and the rest of the framework is starting to come together well. I may be able to get a testable version of the structure stuff out in the next week or so (if I can figure out what my own template format will be ).
Next Update/Release for Catapult_Mod will include:
Update for 1.4.7 (not really necessary--i think the 1.4.6 release works fine on x.7, but updated to newest forge)
Fix config options for structure vehicle and gate types for watchtowers and bunkers.
Changing the recruiting system to not need _pork chops_, but be able to use any type of food. it will be looking for a specific total food value.
Not sure when I will get this update out, as there is still a bit to clean up on it, and tons of testing.
off the topic while f-ing around on the i found this
http://www.minecraftforum.net/topic/472937-125castle-defendersv25-improved-mages/
Sounds good.
Yay!
Will the update contain the structure improvements, or will that be a seperate thing? Anyway, sounds great, keep it up.
For the NPC aspect that is coming sometime after the structures, have you looked at Mine Colony? It used to be a mod where the NPC's did your bidding (harvesting, mining, etc.), and while it sounds like it had a clunky UI too IMO, it might be very similar to what you were hoping to do eventually.
Something that I've noticed I do not like is the whole 'soldiers consume food' (and really, all supplies; arrows are also a pain to supply) bit. It makes it so I need to spend all my time gathering food and putting it into carts for them. When/if NPC's are introduced that can work for me, that might change, but right now it's a pain (mostly because I need to put it into the carts or the soldiers won't get it, but also the sheer amount they require). Might be fine to dump that in favor of increasing their initial cost (and adding designated archers that come with non-user arrows), or giving them a food-upgrade/heal cost.
Edit: Have you seen the new stuff coming in the redstone update? Minecarts that do something, hoppers for moving goods around and into/out of chests, and some actual uses for the nether. Some of that will be very useful for dealing with gathering supplies for NPC's or for getting NPC's to do the gathering for us. Also, textures getting split up seems to me to be a boon (though their backwards way of rejoining them all up has me worried).
See the post for a Texture pack tutorial!
It needs forge installed, which is linked somewhere in the first post or the wiki. If that's not the problem, you'll need to wait for Shadowmage to answer.
See the post for a Texture pack tutorial!
Logs or it didn't happen.
Or more precisely...
Please provide crash logs, or there is nothing I can do about it.
I have not received any other complaints of crashes, so it is likely a setup or mod-conflict issue. However, if it turns out to be a real problem, I will do what I can to fix it in a timely manner.
I know, but their spawn system is what i like one dies another takes its place, makes spawning knights a lot easier,
Suggestion: Make the the people smarter give them like the wolfs brain or make them smarter they keep getting blown up and falling in wells around cities.
there was also a handheld single shot vershion called a that looked honeycombs and was none reloadable(it also had a chance of blowing up)
Define smarter?
Currently the soldier AI is far more advanced than a wolves, in every aspect. However, there are some issues that are (currently) out of my control. To respond directly to your comments--Pathing: they use the same pathing as vanilla entities--the MC pathing system. Hence, any problems vanilla entities experience will apply to soldiers as well (falling in things/off of cliffs, occasionally getting stuck). I'm looking into writing custom pathfinding, but need to do a few days/weeks worth of A* study before I can even begin. Getting blown up: I infer you mean they are getting destroyed by creepers? You can set their default targeting behavior in the config file--go in there and turn creepers off--problem solved, soldiers will no longer attack/target/be targeted by creepers (same can be done with any other vanilla mob, btw).
In the rewrite I'm thinking of going with a data-driven scripted AI, meaning the AI for each class of NPC will be customizable by the user through editing of script files. Its a ways out, but should both simplify the in-game soldier configuration and allow for greater customization to meet individual users'(servers/admins) likes/needs.
In other news:
rewritten structure system has been making great advances lately. I have the template sorted out, can scan in-game and export to template, and load templates in to be built in game. I have not worked on import/export of Ruins templates, but the systems are compatible at the core so it shouldn't be too difficult when I get to it. Need to work on supporting world-gen, as well as all of the advanced ruins-template features during world gen. I _might_ be able to get an alpha/test release out to a few select people (testers and long-time supporters) as soon as this weekend. This release will (likely) only cover basic scan, export, and creative-mode in-game building. It will be mostly for testing of readability and useability of the template as well as basic useability feedback.
If you would like to be included on the list for alpha-testing of the new version, please contact me via PM. (It won't be a _public_ release, but if you are truly interested in testing I could certainly use the help)
I'm still poking at updating the current version, changing the recruiting table a bit to use blind food-value instead of specific foods. I might try and merge in the new/updated structure code when I get it finished (as I really like the way it is turning out), but not sure how well that would really go over (lots of differences between code-bases, mostly in the low-level framework).
While I feel AI stuff can probably wait until after some of the other stuff (Buildings, Unit variation [archers mostly], weapon simplification/unification, tech tree, then AI), I have noticed that the AI soldiers have some quirks. They don't seem to interact well with mobs (or vis-versa) for one. Setting up a few more preset units might make their quirks disappear though. Just having it setup where archers exist and basically stay where you put them, soldiers go out and hunt mobs/enemies, siege engine operators stay on their engines, etc.; would make it seem like they were behaving better, if not completely properly.
See the post for a Texture pack tutorial!
There are a few issues with mob interaction in the current AI. All vanilla mobs are hard-coded for what they are aggressive against, and I never looked fully into the hackey solutions to tell them to attack soldiers (and for some mobs isn't really possible).
Classes: There will be a much more dedicated class system coming for soldiers, with more limitations and fewer configuration options on the AI. Will make it much simpler to get the right soldier for the job (while still allowing for some customization within the classes, on a per-soldier basis). Currently I'm planning: commander(similar to current, can melee/ranged/drive--but is expensive), footsoldier (melee only), archer (mostly ranged, weak melee only if forced to), medic(heals), engineer(restock/repair), and driver (not sure what to call it, but a dedicated siege-engine driver---the other classes will not be able to drive siege engines<may allow training>). With the classes I can see some necessary changes to strategy and army composition--you will need the proper mix of each class to have a good force.
Hmm... Is it possible to just replace the current mobs with mod-mobs who are hostile to your units? Or is that more work than just hijacking current code and adding a line referring to your guys? Having a hoard of opponents coming at your castle, or attacking their castle with a hoard of units, is one of the appeals here, and though vanilla mobs really aren't ideal for that, they are readily available. I'd love a situation where loads of vanilla mobs worked intelligently to try to destroy my fort/town while my soldiers try to defend it from them.
Excellent as usual. I'd call the driver an engineer, but that's taken... maybe sapper? Also, would the engineer be responsible for carrying around goods and getting them from places other than chest-carts, or would that be another position/a future non-soldier position?
Also, PM'd
See the post for a Texture pack tutorial!
As far as I know it _should_ be compatible with 1.4.7, though I haven't personally tried (I don't think there were any obfuscation changes between 146 and 147--which is mostly what breaks mods).
Either way, the next update is being built on 1.4.7, so support will then if it isn't already working. When? As soon as I can quit working 12hr days and get back to major coding. If I forgo adding newly planned features I could have an update out just for 147 relatively quickly, but I would rather fix some things if I'm going to take the time to pack up a release.
I'm hoping for sooner rather than later..but no guarantees..... (perhaps this weekend, if I get some time?)