Jump to content

Xhaleon

Members
  • Posts

    18
  • Joined

  • Last visited

Everything posted by Xhaleon

  1. Oh okay. So that's what it is. Guess I'll just have to uninstall them and go for the ones currently on the board. Thanks.
  2. I'm sort of having problems with this map pack, I think. There are several maps where there are these large portions of black impassable tiles that seem to take up all Z-levels but doesn't block vision (aside from making it very confusing). I have never modified nor added any map tiles, are there any other changes that could possibly affect them? I'm skimming backwards through this thread and it seems that there may be some fixes I need to download? I'm using V21 Stable, if that doesn't have any good fixes then I'll have to revert the map pack.
  3. Oh not again I missed the "min" and "max" attributes because they just so happened to be colored the same as my editor's background. Great, missing obvious stuff like this every time.
  4. Ah, right. Looks like sequipview.lua does it. Only thing now is to figure out how xywh is actually calculated...
  5. Which file controls the size of the soldier stat bars? The bars aren't dynamic and don't adapt to the min/max of soldier generation, so using 100+ AP as a standard causes the whole bar to be filled up all the time. It's one of those LUA script files, isn't it? If it is, I'm not sure which one does what.
  6. Question related to the topic: What does the "id" and "name" fields do in levelsetup_finalmission.xml? At first I thought each AI name was unique, but then I noticed that the Heavy Drone here shares a name with one of the Caesan leaders (AI 11). And then I thought that the ID of each unit had to do with what configuration they had (rank, role, race, etc), but then I see two groups of Andron Elite Assaults using different IDs. I would like to stuff the mission chock full of high-ranking and very-low-ranking aliens if possible. If the map can't support 40+ aliens, then eh...
  7. Welp, I found out exactly what caused the problem, and it was between chair and keyboard. I wanted to make small, medium and large ammo types, but I blindly attached _heavy to a laser cell and a plasma cell, both mistakes in two different files! Moral of the story: Quadruple check EVERYTHING, and take a piece of handwritten paper to write down things rather than flicking through five different Excel and Notepad++ windows. It will save you many headaches when you have easy comparisons on-hand. Nice to see Xenonauts be another great modular game, we really need more of those. dis gonna b gud
  8. Ho, so apparently what I did with the strings didn't seem to make a difference, still crashing on Lasers. However, setting everything on Unlimited has revealed something. The MAG weapon tab works just fine, the Singularity Cannon and the five MAG weapons are there plus the new ammo types and all of my sweet edited weapon images. Equipping those on a soldier works as expected. So that leaves Lasers and Plasmas. Both of these tabs crash when I get into them. So now what? Did I accidentally delete an entry for something on the lasers and plasmas? I'm pretty sure those don't have something extra in them, not like the Singularity Cannon in the MAG tab. Looks like I'll just have to keep digging and comparing with my backup files, maybe re-do my work from the ground up. I'll post here if I manage to solve it. Thanks for the help so far.
  9. Earlier on while the forum posting was down I thought of that myself, checking the research and manufacturing files. I realized that I forgot to unlock these new ammo items once the Laser/Plasma/MAG research is complete, and now those have been changed. I already added in their ManTech entries in manufactures.xml. Unfortunately my changes didn't have an effect and the game was still crashing on entering the Laser weapons tab. I am chasing a new lead. I added string names for the new ammunition items and have been using them this whole time. There was some strange issue about the string names and descriptions that I have encountered before; I once added in a name and full description for the Combat Shield (the normal game so far doesn't have one, the ingame tooltip just shows a raw ID of some sort) and the game crashed when entering the loadout screen. I don't understand what causes this, but I had to remove the shield's name and description cells in order to get it working again. I will try this method as soon as I can get back to the game. However, it would be better if I could find the root cause of this. Why does the Combat Shield have no name or description string, and why does the game crash when I add new entries to give the shield those strings? Is there one more file somewhere specifying which strings go with which item? Or is this something hardcoded? Gauddlike, thanks for the advice about setting those items as always Unlimited, that will definitely help.
  10. No, they are all only pointing to a single ammo type. _Small cells go in pistols, _Mediums for assault rifles, carbines and precision rifles, _Heavy cells for machineguns. I did this so that I could better fine tune weights, size and capacity for each weapon type, not let a single weapon have multiple properties.
  11. I'm trying to replace the three researched ammunition types for Laser, Plasma and MAG with three separate new ones for each. This was done to split them into small, medium and large sizes for different weapons. Problem is, I'm entering the base loadout screen and the game is crashing to desktop when I click on the Laser weapon tab. I know that this is probably due to some missing or misnamed item in the files I've made, but I can't figure out what. Since the debugger in this forum is for the ground combat only, it isn't helping. I know I've got the following down: 1. Create new entries in ammos.xml along with pointing them to the new images, 9 in total 2. New entries for them in strings.xml 3. Changing the entries in weapons.xml to point to the new ammunition types, vanilla ones are not referred to anymore 4. Same thing in weapons_gc.xml, but this shouldn't come into effect in the geoscape 5. Create entries in items.xml 6. Put the new ammo images into the weapons folder (and GUI folder, for that matter) There might be more problems I will stumble upon entering ground combat, but for now this geoscape issue is stumping me. Is there something hardcoded about these ammo types that prevents them from being messed with? Is there one more file that I need to modify to get the game to recognize them?
  12. Warning: I am running with my own personal tweaks and modifications, but little is changed about fire except for fire light radius, explosive fire start chance, and unit sight range. I'm not sure if you could call it a bug but since I don't see anyone complaining about grass and fires, it seems like it isn't a common occurrence. Basically, on a night mission I started out by firing a rocket onto an alien standing in the grass. This caused some fires to start and spread after a fairly lengthy pause. The thing about this case is that calculations for fire spread turn (after the alien phase) became longer and longer, if it wasn't pretty long from the start already. Near the end it got to the point where I was waiting for 10 minutes per turn before regaining control. I have started fires before at night and it wasn't anywhere near this bad, although in this particular map the fire was constantly spreading amongst the tall grass. I tried to look away from the fire tiles as I advanced towards the UFO to see if that would help, but during the few times that I did have sight of the fire I saw that just as the game was becoming responsive again, the fire tiles seemed to shift around multiple times in the very last second. Perhaps I tripped some bug that caused the fire spread code to go on a very long loop, or maybe that some fire tiles were dissipating and then re-ignited by nearby fire tiles over and over? I'm not sure how fire in this game is programmed. Also, as the turns went by and the fire spread even more, the animations of my soldiers started getting really choppy. If no one was moving though, looking and scrolling around the map was normal and smooth. In any case, the problem seems to only be excessive calculation times, as I was able to complete the mission eventually. I can provide a save file if needed.
  13. Can you access the store menu without a storeroom built? I've never actually tried that...
  14. Ah, just another request for Goldhawk: In future experimental and stable release updates, could you please put down a list of which files were changed from the last build? For mods and modders, the fast pace of the game updates requires constant reintegration and tweaks as new content gets added. The gameplay changes listed in the changelogs will hint as to which files were altered, but a changed-file-list would speed things up immensely. We can figure out the raw alterations ourselves; personally I keep a backup of every build's XML files so I can compare them with the latest ones. That way I can merge new official content into my modifications instead of re-doing everything from scratch the other way around. A file list for the changelog would be really appreciated.
  15. I see. Looks like this might cross into the realm of Suggestions, because that's a pretty big thing to be missing from alien variety. Lots of things you could buff on Androns while shackling them with tunnel vision, and the opposite for Sebillians too. Anyway thanks for the heads up that they use the general view angle.
  16. I tried searching the forums but I couldn't find anything on it. Maybe I was using the wrong search terms. Anyways, is there a way to set the view cone for each individual alien type? I know you can set each of the aliens' sight ranges in aiprops.xml, but I don't see any mention of the view cone angles other than the "general" LOSAngle tag in config.xml. I'd like to experiment with aliens that have vastly varying view ranges and FOVs myself. Unless, aliens don't actually use the view cone mechanic and always have 360 degree vision? It would be a bummer if that is true.
  17. All of which are more complicated, expensive and slower than simply flying there in a regular old plane and taking a local chopper in. I know Xenonauts is supposed to be really just an updated XCOM, but this is really weird and surreal to me. My suspension of disbelief is a little too small for this one. Besides, if taking a local military transport into the battle was a part of the game mechanic, one could make the Shrike even more useful than just being a bigger, faster dropship. Perhaps early on in the game with conventional vehicles, entering the combat zone is done offscreen and on-foot, meaning Xenonauts arrive in the middle of a road with no dropship to protect them. Once you get the Shrike, they enter the zone in the ship as normal and have some cover to work with. Would need to make new maps for that though. Oh well, since the dropships appear to be static parts of the map, this lore/gameplay thing could be easily modded-in in the future. Just something to consider.
  18. While it is too late to change core aspects of the game, I believe there is still a safe way to "fix" the one beef I have with the game's lore (and partially gameplay); the Charlie. Yes, it is 1979 and we don't have the fancy Skyranger anymore, but it is really more than a little silly that anyone would even try to modify a transport chopper in order to fly around the entire world and back. The Charlie in the game has twice the cruising speed compared to real world heavy transport choppers if the "500" value in the game files means exactly 500 kph, now that requires some crazy specs. That is to say nothing of the poor pilots who have to drive the thing with no chance of rest. Might I suggest that the Xenonaut transport lore be modified such that soldiers are transported from the base by a conventional fixed-wing plane instead, and the Chinook / Charlie / generic helicopter is what brings them from the airstrip to the combat zone. Perhaps the plane could be fluffed to be a very light transport modified to easily land on the shortest and most uneven landing strips. It doesn't really require the game mechanics to be changed, the same little green chopper icon just moves in a beeline to the target. And then the Shrike comes along and we can throw all of the previous problems out the window and just go with it being an indirect Skyranger expie.
×
×
  • Create New...