Jump to content

eezstreet

Members
  • Posts

    5,207
  • Joined

  • Last visited

Everything posted by eezstreet

  1. This has been moved to JA++ forum You could start by following the second link in Raz0r's signature (this one)
  2. 16GB RAM is starting to show up as standard fare for a few games. I'd recommend that as your baseline if you're going to be playing Battlefront at all. Regarding dual-boot, the UEFI booting system from Win8 onwards makes it a bit more difficult to use dual booting. If you absolutely must have Win10, there are workarounds however.
  3. Excuse me for my ignorance, but what makes this model necessarily better for JA than what we already have?
  4. Okay, that's enough. We get it, @@Sovietskiy Partizan, you don't like MB2. But there's no reason to spew vitriol at them and call them retarded, idiotic or whatever when it isn't warranted. Warning issued.
  5. eezstreet

    Makermod on JA++

    This thread has been moved to the JA++ forum
  6. Your file has been approved. Thank you for the submission.
  7. Unable to reproduce it. Maybe try flushing your DNS cache? You can do this by entering in the command prompt: ipconfig /flushdns Are you getting this issue when clicking the download button, or is it shown on the download page itself? Try these two links: http://jkhub.org/files/go/aff34772b595ba563cbe2a8d84cee4ff/epvii-kylo-ren http://files.jkhub.org/jka/playermodels/KyloRenTFA.zip Which one of these two links works?
  8. I don't think that a script is the best way to proceed here, simply because you can't control where the spawns would be at. I think a better option would be to copy the BSP and make an ent-modded version of the map. This way you can place scripted elements like buttons to turn on/off spawning.
  9. Let's try and keep things civil folks. Don't want to have to lock this thread while it's the latest poll for only a couple more days.
  10. yes, rend2 will be able to render polygons
  11. That's very true. I mentioned Payday 2 before in this thread. It had almost 10 heists that didn't show up.
  12. You are right. We were having some FTP issues a while ago and I am updating the bar now that I have time. EDIT: Nope, FTP issues still prevailing. Looking into it, I swear.
  13. 4. You're correct. Even if it's at 999 they could still use force powers, they just regenerate 1 FP per second (999 milliseconds). The forceMax keyword (I believe. The Kyle NPC has this field set) dictates how much force power they have. So setting it to 0 should prevent them from using powers (other than Jump, which has special handling and doesn't drain their force power). But a better way is to just alter their ranks. 5. Yes. 6. rank doesn't affect drain, dark rage, protect or absorb usage. They affect all of those powers the same. Class on the other hand might have an effect. I can't remember all of that right now.
  14. Maybe you can cut down that process (by using a script) and make a bridge?
  15. You reminded me of something. I think someone made a portal gun mod. Whatever happened to that?
  16. I think it would make sense for the gunner's seat to be able to swivel 180 degrees, that way they can be able to crawl up into the pilot's position. Not necessarily fold, although that could be a thing. I imagine very little time is spent down there, so it doesn't need to be comfortable. For longer flights, there would need to be at least one bunk that can be fitted in a room behind the pilot's position. Also this is a really minor point, but how does one get off the ship? I don't plan on showing that, but maybe the entire nose piece (pink in your picture) is on a hinge, like X-wings are? I don't know. I don't remember those windows being on the original ship (?)
  17. Maybe @@ent can implement a command that makes the character say something. This is a commonly requested thing with video making I think.
  18. Random question: how are the settings/cvars for the mod internally documented? I think the process of moving cvars to HTML documentation could prove an interesting tool for other modmakers.
  19. I am glad you are diving in. You will find that the rabbit hole goes deep.
  20. This is an interesting idea. And it wouldn't be too hard to implement either. As for dead links, yeah, it is something that I need to examine closer. There were some internal hiccups a few weeks ago involving FTP and I'm not sure if I was able to get them resolved for me. And I still haven't implemented the Origin field. Pretend that I am not lazy and didn't just add it. Oh, and it will show up at the top of the contact field list. I'm on a phone, and reorganization involves dragging. Dragging is not mobile friendly. u_u will fix later.
  21. I only have time to skim this topic, but maybe not use a non POD data type (roll your own? Memory management is certainly a trial by fire) as replacement for vector. Problem is that vector is template type. But if you write your own then you won't have to worry about it. Use a macro instead of a template? I never really intended my post to be taken super literally though. It was mostly just pseudocode and ramblings :s apologies if that wasn't clear. Also please refrain from tagging lots of people in your posts, and/or tagging every post. As for reflecting the missiles, I believe the code is handled somewhere in g_missiles.c (pp). (I will try and hold back the urge to write some overengineered thought on this.)
  22. @@Avoozl this is false. Battlefront 1 and 2 used Pandemic's in-house engine, which was also used for games like Destroy All Humans and some other THQ titles. You can very clearly see the influence in the camera angles. I think the argument that an engine is deterministic of the game is quite unsound to say the least. Consider PAYDAY 2. Its engine (Diesel) was originally made for racing games on the PS2. Quite odd then that the game is a FPS/RPG, and driving mechanics were only just recently added. Also, how would you classify games made on general purpose engines, such as Unreal? Anyway, I will almost certainly not purchase it. I am far too busy with schoolwork. Plus I have a bad feeling in my gut that it will include microtransactions.
  23. It's not maintained and it's not a simple job to replace the JA weapons with the ones in the mod. You have to edit the GLMs and MD3s by hand for each one to replace texture paths. That is, if you mean to use those weapons. The way you word your question makes it sound like you're referring to the way the gun is held. You could try editing the cg_gunX, cg_gunY, and cg_gunZ cvars but they are cheat protected I think. PS I recommend the JA++ mod över JA+
  24. For JKG we didn't use two different STAT_ fields. Instead we kept two separate inventories on the client and server and kept them in sync. The server wasn't even aware of what was in your hotbar. (Technically this could open an exploit where you could get any weapon you wanted without actually buying it, but it wouldn't work properly as you wouldn't have ammo for it) Each weapon had a base ID and variation ID. Base being weapon type (pistols, carbines, rifles, shotguns, rocket launchers, concussion rifles, grenades, trip mines, deployable explosives, chemical weapons, lightsaber. Probably other categories, these are the only ones I remember) and variation being the specific type (so pistol -> DE-10 Blaster Pistol, concussion rifle -> Stouker Concussion Rifle, etc) I'm just saying that there's a lot of ways to design the net code. Also consider that you're in singleplayer. There's a lot of stuff you can get away with since this is true. Something like this appeals to me: class Weapon { public: Weapon(const char* filename) { /* Loads the file */ } virtual void Fire (bool bAltFire) = 0; virtual void Equip () = 0; protected: int fireTime; int primDamage; /* ... */ } struct gentity_t { ... std::vector <Weapon*> vOwnedWeapons; std::unordered_map <Weapon*, int> umAmmo; } There's a lot that can be said about the design of data types here, and even just a cursory glance over my code shows a few improvements that could be made. I guess what I'm trying to say is simple. This is not really an easy fix if you stay inside the mindset of changing the engine to suit your needs. You really ought to dive in and see how everything works.
  25. I think @@UniqueOne has the right idea here. The mapping format you have should be based on the content you intend to design with it in mind. I've done a little bit of research on the subject, and there's a few different systems: - Voxels (Minecraft). Grid based system with uniformly sized units, although players, creatures etc can be oriented on fractional units. Can also be said of tile systems like the ones in the original Fallout and Diablo. - Cell Structure (Skyrim). Maps within maps within maps... - BSP structure (Quake). Basic geometry which is rendered to the client with potentially visible sets (PVS) as opposed to distance based - Megatexture (Rage, parts of Quake 4). Geometry is mapped from a (freakishly giant) texture which is compressed. - Hybrid (Most UE engine games) - Procedural (No Man's Sky). Content which is generated on-the-fly and may or may not conform to any of these. Now of course you can use these with dynamic loading or generation procedures or you can keep it static. It doesn't really matter. I have probably left out a few things anyway. The problem is that you can't develop a catch-all system that encompasses all of these systems and have it work well. I think it should honestly be up to the modmaker to implement whatever mapping format they want to do. But certain improvements like the mapping system in Doom 3 seem feasible. I would honestly like to see the BSP code be cleaned up a bit and externalized in such a way that it can be replaced rather easily. But everything is organized in such a way that it's all interconnected.
×
×
  • Create New...