Home » SIRTECH CLASSICS » Jagged Alliance: Unfinished Business » Vanilla Modding » Organization and Progression Suggestion
| Organization and Progression Suggestion[message #101748]
|
Wed, 18 August 2004 03:11 
|
|
 KIA |
 |
Messages:92
Registered:November 2002
Location: Virginia (USA) |
|
|
Hello, all! I've seen some wonderful knowledge, talent and enthusiasm exhibited here. We have very experienced project managers and smart, sharp programmers. But there is a high degree of chaos with programmers making their mods as they see fit and no real overarching organization or plan which I can detect. Surely someone (a manager?) can come up with a proposed list of waypoints, milestones or sub-projects which need attention? Similarly, someone ought to be able to come up with a list of specs for mods, i.e. the proposed mod must be a) well documented internally, b) uninstallable, c) verifiable and tested, and d) be adjustable, i.e. on/off from the config menu. (I think mods which have or aim for Linux compatability should be listed as a definite plus right now, but should not be mandatory - for the main project. That can be tweaked later.) From there, someone else (Bearpit?) can post a topic of individual mods which have been completed in compliance with specs and are ready for public beta and comment. As these become more established and solid, a second phase, incorporation into a new v 3.0 exe could be considered, but it seems somewhat distant right now. I think the only thing which can be done at this point is to establish the standards and start collecting properly crafted mods for user review. Thoughts?
Report message to a moderator
|
Corporal 1st Class
|
|
|
|
|
|
| Re: Organization and Progression Suggestion[message #101750]
|
Wed, 18 August 2004 21:18 
|
|
| Bearpit |
 |
Messages:1068
Registered:August 2001
Location: Sydney Australia. |
|
|
It seems to be the cart before the horse syndrome.
There is no point researching & making possible all manner of enhancements unless those creating mods have a use for them.
Best that could happen is individual players tweaking existing mods to their liking.
There are several considerations revolving around any proposed major enhancement ... mainly playtesting to sort bugs out & overall balance plus side effects on other areas ... finance, number of items dropped, overall difficulty, rate of progress towards objectives etc.
Examples:
1. Alter SAM site position & area coverage .... very nice to have & usefull.
2. Alter city positions & borders plus what constitutes the sectors where income is derived (mines) plus where militia can be trained.
Very nice to have but you would then need to alter patrol paths & orders - priorities for recapturing those newly positioned cities.
Care must be taken with Meduna Palace ... principal spawn point for patrols which is also linked to the Queens income .... more income more patrols. Once the spawn point is captured ... game over unless queen is still alive.
Some really usefull stuff you could develop
An ability to have a third vehicle ...
Can the helicopter be turned into a plane ??? meaning able to take off & land only at specified "airport" sectors.
This could make an island hopping scenario viable.
Is it possible to assign "cargo space" to vehicles. Maybe 6 - 8 large slots would do.
Is it possible to assign more sectors as hospitals similar to F8 at Cambria ... Chris pointed to those code areas in his Tweak Tweak thread.
Is it possible to assign all sectors as "normal" allowing helicopter - road - map interface travel ... including the meshed out ones currently at A4, A5, A16,E16, F16, J16, 16, L16, M14, M15, M16, N13, N14, N15, N16, O14, O15, O16, P14, P15, P16.
Can patrol logic & numbers be improved to have roving "hunter killer" elite squads follow then zero in on positions occupied by mercs.
Not just follow standard patrol paths.
All this sort of stuff would be valuable in designing new adventures from the ground up.
If in advance it's known these features are possible there is more scope for experimentation & deviation from a normal plod towards Meduna to kill baddie X scenario.
If any of the above can be safely implemented ... please let me know as there are possibilities of future mods coming your way in the not to distant future.
Techs with an ability to "get the job done" are valuable & their services may be required in the not too distant future.
Report message to a moderator
|
Sergeant Major
|
|
|
|
| Re: Organization and Progression Suggestion[message #101751]
|
Thu, 19 August 2004 02:28
|
|
| KIA |
|
Messages:92
Registered:November 2002
Location: Virginia (USA) |
|
|
These are excellent suggestions and points, Bearpit. They should be tagged and listed along with the other suggestions. A list of existing and potential mods is important because this is a purely voluntary enterprise. No modders can be forced or coerced into doing anything. But if someone can provide a structure and framework along with a list of potential projects, then they modders can see what types of things are suggested, try their hands at them and report back results. Successful mods can be posted, tried by users and rated for game enhancement.
Whether a big new exe can be compiled from the different sub-mods is a larger issue and much harder to decide. A series of polls or popularity surveys could be conducted with respect to the individual mods in order to determine which are the most useful, popular, etc. Mods which score above a certain percentage can be incorporated, lesser mods can be optional.
The alternative approach is to have several different, sometime conflicting, projects running simultaneously resulting in several different larger mods somewhere down the line. This is fine, but I think one mod which allows selective incorporation of lesser mods which can be turned on or off or selected at start is a better way to go.
Report message to a moderator
|
Corporal 1st Class
|
|
|
|
|
|
| Re: Organization and Progression Suggestion[message #101753]
|
Thu, 19 August 2004 06:04
|
|
| KIA |
|
Messages:92
Registered:November 2002
Location: Virginia (USA) |
|
|
 Ah, if only my stupid lottery ticket had won... I could rule the world... and hire Sir-Tech staff and the Mod Squad to implement JA3 properly... I'm not asking for as much as you suggest, actually. Let me explain.
As I see the forums and situation at present, there are many ideas, many working implementations (full auto bursts, 800x600, targeting, relocation of mines, relocation of sams, expansion of weapons, items with sub pockets, etc.) and absolutely no organization, pattern or methodology being applied to sort out the glorious mess. So work done by some modders is being replicated unnecessarily by others and there is feuding and bickering over the implementation methodology and so on. My thought was that if someone was hosting a forum for this, they could set standards for mods they would post and mods could be accumulated in one place over time for others to study, learn from, build on and so forth. In order for people to do that, the mod needs internal documentation which is distributed with the mod. So as a requirement for posting and hosting the mod, it should meet the standards. The general idea is that someday a general revision of the exe would be made to incorporate the best mods. Obviously the new exe would be aimed at the largest possible audience. But there will always be disagreement about what is a "good" mod and what is a "game breaker" so it only makes sense to plan for that eventuality, too. The sensible way to deal with the conflict is to allow the end-user to pick and choose what mods they want to use for their particular game. This means that programmers should plan in advance for their mod to be able to be turned off or deselected in some fashion. Again, this should be a criteria for hosting the mod. Mods which cannot be turned off, deselected or uninstalled will cause conflict down the line. While some people may want to use them anyway, they would not be officially hosted nor incorporated into the exe which is aimed at the broad audience for obvious reasons.
But maybe chaos and anarchy might spontaneously generate a triumphant work also. I somewhat doubt anything as complex and thorough as UC would ever be generated without organization and structure. So I offered my suggestion for a loose plan to advance JA2 modding. I haven't seen anything else so far...
Report message to a moderator
|
Corporal 1st Class
|
|
|
|
| Re: Organization and Progression Suggestion[message #101754]
|
Thu, 19 August 2004 07:58
|
|
| Batman |
 |
Messages:363
Registered:January 2001
Location: Gotham City |
|
|
I guess what's confusing me is your use of the word "mod". To me, MOD is when a modification is made to an existing game. If you are talking about source code changes, additions, corrections, then it is a different thing.
Then you talk about an EXE... To me, this is the final product compiled into an Executable Program. If you are talking about making such "Source Code Changes" as full auto bursts, 800x600, targeting, relocation of mines, relocation of sams, expansion of weapons, items with sub pockets, etc. Some of these are not easily "turned off"...
For example: Relocating Cities, Mines and SAMs would require a special editor to be included or incorporated in the game that would allow someone to alter the locations. Now we're talking about MODding the game.
I do apologize and I'm not trying to harass you, but I guess I don't understand the ultimate goal here...
Is it to allow MODding to continue? If so, then grab the source code and have at it...
"So work done by some modders is being replicated unnecessarily by others and there is feuding and bickering over the implementation methodology and so on."
I don't think working with the Source Code is unnecessary in any way. Every time I open the code I learn something new. I do agree with the feuding and bickering, everyone will think there code is the best... But then again, feuding and bickering will occur in MODding too... 
Report message to a moderator
|
|
|
|
|
|
|
| Re: Organization and Progression Suggestion[message #101756]
|
Sat, 21 August 2004 03:25
|
|
| KIA |
|
Messages:92
Registered:November 2002
Location: Virginia (USA) |
|
|
Batman: yes, my terminology has been imprecise. I have been using the term "mod" loosely to include any MODification of the code from the original. Whether it's an improvement, alteration, change, deletion or whatever, it modifies the "official" code. I guess some people think of a "mod" as a completed set of changes to the (big) game structure like weaponsets, tilesets, worldmaps, etc. But it's easiest to think of any mod in its smallest form as a change to any particular area of the code. For example, Chris C's recent revision of the sleep functions removing and debugging an unnecessary four hours of rest time is a great mod to that portion of the code and ought to be on the permanent list since he showed all of the lines and documented the causes and effects of the change. Further explanation: Think of all of the different items which have been corrected and generally accepted like the burst bug, Digicrab's aiming mod, Skyrider override mod, etc. As the different (small) mods are assembled over time, people can learn and grow and move up to larger mods which are more significant. People who want to design big game changes can then decide which (small) mods and changes they want to incorporate into their big set of changes (scenario mod).
Report message to a moderator
|
Corporal 1st Class
|
|
|
|
|
|
|
|
| Re: Organization and Progression Suggestion[message #101759]
|
Fri, 10 September 2004 07:23
|
|
| ebuck |
 |
Messages:123
Registered:August 2004
Location: Houston, TX |
|
|
Well, I've been reading the source code for JA2 for a week now...
All I can say is that it was specifically built to play the game. It's going to require a lot of house cleaning before any part of it is abstract enough to be deeply modd-able.
For example, you can slip in new intro screen pictures before entering a sector, but there's no sane way to do it without saving the modded intro screen over the original. This limits both the number of intro screens, and the modder's ability to handle intro screens that don't follow the established day/night pattern.
Now that we have the source code, we could add in "more of the same" to achive the goals, but modders are generally better at modding that programming, and programmers are generally better at programming than modding. I'd hate to close the doors to anyone who wasn't good at both.
I think we could benefit greatly in non-direct ways from focusing on KIA and pheloncab's suggestions. Bearpit is right too, options that aren't used won't be useful, but right now I'd say the scale tips toward code cleanup over option adding.
Batman makes a good point too. The MODDING portion of the work should exist independantly of the MODIFICATION portion of the work.
Modders need to focus on tweaking what they have. Modifiers need to give (both themselves and the modders) a sane framework to build on.
For example:
Modders want an airplane. They think the helicopter can be twisted into an airplane. It's one solution that might work right away.
Modifiers want an airplane. They can't stand the ad-hoc implementation of vechiles in the game. They want to make vechile handling generic so all vechiles are handled exactly the same, but each vechile responds differently to a movement command. It's a more involved solution which won't work right away, but when finished would allow both airplanes and helicopters to co-exist, and make adding in hovercraft / bicycles / trains trivial.
I know that I'm preaching to the choir here, so please forgive me for that. The real question is, can we organize the Modding ideas and the Modification ideas into two distinct camps for progress's sake?
Naturally, both camps will (and should) be peeking in on each other to help the other camp out.
Report message to a moderator
|
Sergeant
|
|
|
|
|
|
|
|
| Re: Organization and Progression Suggestion[message #101762]
|
Sun, 12 September 2004 02:05
|
|
| ebuck |
|
Messages:123
Registered:August 2004
Location: Houston, TX |
|
|
Just to summarize (from the modifier's point of view)
We need generic vechile code. This code will then be tweaked to the specifics of the vechile in question. For example, a jeep will find that rough terrain is impassible while the "foot" vechile will not. A plane will only allow boarding at airports, while a bicycle will allow boarding anywhere.
We need the ability to relocate special map areas. Not necessairly relocation during game play, but an easy hook to relocate hospitals, pharmacies, mines, sam sites, spawn points, whatever.
We need the ability to relocate cities, again not during game play, but for map designing.
Most of these needs revolve around the map. Odds are we will also have to overhaul the map to support the above.
There's other needs that seem to be somewhat independent of the map, they are things like:
An overhaul of healing.
An overhaul of repairing.
Item crafting / manipulation.
Story line stuff.
Different cut screens, etc.
Swapping out movies, etc.
Some of these needs have already been met by specialized editors, others cannot be met without rewriting the game engine.
I suggest (although I'm open for other opinions) that we concentrate our modifying efforts to the map related code. An alternative is to concentrate them on the Merc related code.
Report message to a moderator
|
Sergeant
|
|
|
|
|
|
| Re: Organization and Progression Suggestion[message #101764]
|
Sun, 12 September 2004 14:14
|
|
| Bearpit |
|
Messages:1068
Registered:August 2001
Location: Sydney Australia. |
|
|
Puma.
Quote: Just to summarize (from the modifier's point of view)
We need generic vechile code. This code will then be tweaked to the specifics of the vechile in question. For example, a jeep will find that rough terrain is impassible while the "foot" vechile will not. A plane will only allow boarding at airports, while a bicycle will allow boarding anywhere.
Sounds an ideal solution
We need the ability to relocate special map areas. Not necessairly relocation during game play, but an easy hook to relocate hospitals, pharmacies, mines, sam sites, spawn points, whatever.
Relocation for gameworld design purposes only. Being able to have extra SAM sites in addition to the present 4 ... NOT protected by militia would be very valuable. Also extra hospitals, patrol spawn points.
We need the ability to relocate cities, again not during game play, but for map designing.
Yes for design purposes only .... like Azraels road network utility.
Most of these needs revolve around the map. Odds are we will also have to overhaul the map to support the above.
What is badly needed is to make ALL sectors normal eliminating the presently meshed out unuseable "Other Country" ones.
There's other needs that seem to be somewhat independent of the map, they are things like:
An overhaul of healing.
Relocatable hospitals & penalties for mercs with low med skills
An overhaul of repairing.
Item crafting / manipulation.
Story line stuff.
Different cut screens, etc.
Batman - Azrael - Zephalo did a great job introducing extra characters into cutscenes, a first logical step. Primary objective is to remove the queen (slapping scenes) & provide a male ruler. Also should be a choice to replace some cut scene events with in game movies plus add extra cut scene triggers .... entering a certain sector, specific character dies, specific character steps onto Drassen helipad as possibilities.
Swapping out movies, etc.
Here you must be carefull about choice of codec for movies. Smacker - AVI was licensed by Sirtech so using that is OK.
Another very important enhancement is alternate endgame triggers.
1. A specific NPC steps onto Drassen helipad (or relocateable substitute) which triggers endgame instead of killing queen.
2. Can a system be created whereby certain NPCs can be coded with a "value" say 1-2 points each .... like something in PRO-EDIT or an external utility.
These NPCs when taken to Drassen helipad "add" their value to a progressive total which triggers the endgame when reaching say 15-20 as required.
After arriving they "vanish" like John & Mary.
With this system players could "rescue - escort" or "arrest" NPCs .... major characters are valued at 2 points, minor ones 1 point.
So the endgame becomes more quest completion oriented & replayability could be further enhanced by having NPCs positioned to appear in random sectors.
Further to your concerns.
Starting up money whilst a problem is not really much of one. It's very easy to have money available in the starting sector or handed over by an NPC.
You cant say a $35,000 stake is too much :wrysmiley:
Presently there is some uncertainty about immediate future plans but hopefully within a month I can get a new site able to host the CVS plus a development group set up.
Extra SAM sites & undefended airstrips.
Here's the logic.
Being able to place say 2 extra SAM sites "unable" to be defended by militia & having "undefended" airstrips suddenly gives designers enormous campaign creation advantages.
Part of the gameworld is rough scrub country only trafficable using a boat along a river .. replacing a road.
In an isolated area are players objectives ... a small 2 sector town with mine like Chitzena plus grass airstrip & SAM site nearby not able to be protected by militia.
Player must physically hold the airstip & SAM site to enable extraction of prisoners - hostages - casualties plus to guarantee incoming supplies - ammo - medical supplies - fuel for boat.
Once mision is complete player uses boat to move towards other locations. If enemy overrun the small recently captured town player can only use boat to recapture & train militia.
The helicopter is way too versatile to allow this type of gaming.
Report message to a moderator
|
Sergeant Major
|
|
|
|
| Re: Organization and Progression Suggestion[message #101765]
|
Mon, 13 September 2004 02:28
|
|
| Zap |
|
Messages:2
Registered:September 2004
Location: Florida |
|
|
There seems to be alot of confusion on what the general aim should be. We have our two terms of "Mod" and "Modification" but I think it should be something more like "Mod" and "Engine Rewrite."
It seems as if people want to have more of an engine rewrite in the vein of The Urquan Masters for Star Control 2, SCUMMVM for old LucasArts games, or even the multiple Doom ports . This is what I personally would like to see. There shouldn't be any problems for us to get support for something like this. The system that I was getting the idea of was something along the lines of SCUMMVM where you must own a copy of the game to get the data files from it. This would protect the project from any copyright infringements on artwork and such.
We have the source code so we can figure our how the data files are utilized. As for the constants, a ini file should work well. From reading about all of the bugs and errors that have cropped up, I think a new writting of the engine should be fine. Most of the original should be able to be kept intact.
If any of this doesn't help, the links to other open source projects should help.
Report message to a moderator
|
Civilian
|
|
|
|
|
|
|
|
| Re: Organization and Progression Suggestion[message #101768]
|
Tue, 14 September 2004 10:00
|
|
| KIA |
|
Messages:92
Registered:November 2002
Location: Virginia (USA) |
|
|
Good terminology clarifications and points here. One thing - if an engine rewrite is contemplated for vehicles, the defining features of vehicles should be valid enter point, valid exit point, number of passengers, terrain prohibited, travel speed over (terrain) or, in the case of air transport, travel speed over (all), fuel consumption, deterioration rate, repair difficulty, damage resistance (armor), cost, and quest triggers (if any) which make it available. These should all be customizable by modders, and some like quest triggers and cost would be optional, of course, but they should adequately define a vehicle for all gameplay purposes, yes?
Note here that valid exit points should be modified by an equipment check. For example, if mercs had parachutes, they should be able to airdrop into enemy-occupied sectors. Helicopters should allow mercs to fast-rope into pretty much any terrain, and if mercs have scuba gear or something like that, they could even deploy at sea and swim ashore.
Note also that prohibited terrain would permit development of many vehicle types such as boats (prohibited against land) or a Chevy Impala (prohibited against mountains, water, and swamp plus VERY slow offroad) or a tank (prohibited against water, swamp, slow in cities and mountains) or a helicopter (no terrain prohibited, merc drop off in any non-water sector, land in any open area).
Pretty complicated, I know, but if you don't ask, you don't get.
Report message to a moderator
|
Corporal 1st Class
|
|
|
|
| Re: Organization and Progression Suggestion[message #101769]
|
Wed, 15 September 2004 03:45
|
|
| ebuck |
|
Messages:123
Registered:August 2004
Location: Houston, TX |
|
|
KIA,
Good points, I'll have to muse over them a bit.
Valid entry points / exit points have two meanings to me, entry point of the vechile into the game, and entry point of the merc into the vechile.
Vechiles will probably be created at their entry point into the game.
Mercs will proabaly be able to board provided that they are in the same grid as the vechile, and the vechile is not moving.
Vechiles will probably exit the game by being destroyed.
Mercs will proabably have the option to exit the vechile at any time.
At first glance, I don't think an Merc exit scenario should be dependant on an equipment check. If you jump without a parachute, you're going to hit the ground hard. Consider it natural selection. Same goes for drowning at sea. Either way, it's not the vechile's responsibility to do such a check, perhaps it's the Merc's responsibility to complain, but I like the player's responsibility not to flash tenderize their squad.
So far, I'm considering a different movement cost per vechile for all interconnections between grids. It's the most flexible (modders start salivating) and it's totally independant on terrain (you can have two plains separated by a very hard to pass river (but canoes cross the river quickly)
Report message to a moderator
|
Sergeant
|
|
|
|
|
|
| Re: Organization and Progression Suggestion[message #101771]
|
Wed, 15 September 2004 06:20
|
|
| ebuck |
|
Messages:123
Registered:August 2004
Location: Houston, TX |
|
|
Bearpit,
Yes, I'm aware that you can always change an existing vechile into another by tweaking the values. (Modding)
But those kind of solutions won't ever really scale, first off, there's not enough vechiles to go around. Add a boat means lose a car, add a canoe means lose another car. Sooner or later, you run out of cars. Plus there's the chance that you don't notice a detail and your boat "discovers" that it can drive around the streets of Arluco. That's why a more generic vechile system will help. (Engine Rewrite)
Eventually, you'll have a flexible number of vechiles, each with thier own unique characteristics. It won't feel like overhauling a humvee to make it a train, it will feel more like defining a train outright, same goes for boats, planes, cars etc. Trains won't be able to drive on roads, but railroad tracks and roads can coexist on the same grid.
All vechiles interact directly with the map, that's why it's critical to get the interface between the vechile and the map defined in a way that's flexible (supports a wide variety of vechiles) yet isolates the vechile from the map so the map can be changed without rewriting vechile code.
Report message to a moderator
|
Sergeant
|
|
|
|
| Re: Organization and Progression Suggestion[message #101772]
|
Sat, 18 September 2004 02:05
|
|
| KIA |
|
Messages:92
Registered:November 2002
Location: Virginia (USA) |
|
|
The way I envisioned the term "Entry point" for vehicles is important. For example, even if a learjet is in the same square as a squad, if there is no landing strip, the squad has no way to enter the jet. If the squad is in the deep forest or a swamp, a helicopter could not land to pick them up... although it could use winching devices to haul them up, I guess. If the squad is on a riverside, but there is no port or dock, they'd need to swim to the boat to get aboard... with all of their gear. So valid enter/exit terrain for various vehicles would be important in a real-world implementation.
As always, if the complexity doesn't have a good return in gameplay value or it detracts from gameplay, it ought to be nixed. But if there's an engine rewrite, designing in the flexibility, whether it's used or not, would be good.
Report message to a moderator
|
Corporal 1st Class
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Organization and Progression Suggestion[message #101781]
|
Tue, 02 November 2004 06:52
|
|
| Jack D Ripper |
 |
Messages:31
Registered:September 2002
Location: The Woodlands, Texas |
|
|
Since, as Defrog said, the use of armor in an urban setting is difficult at best, prehaps there is a way to program the roving patrols incorporating armor to not appear within the boundries of a city.
Report message to a moderator
|
Private 1st Class
|
|
|
|
Goto Forum:
Current Time: Wed Jun 17 20:00:24 GMT+3 2026
Total time taken to generate the page: 1.56717 seconds
|
Blog
Search
Help
Members
Register
Login
Home
