+- Renegade Projects Network Forums (https://forums.renegadeprojects.com)
+-- Forum: Modding (https://forums.renegadeprojects.com/forumdisplay.php?fid=3)
+--- Forum: Red Alert 2 & Yuri's Revenge Editing (https://forums.renegadeprojects.com/forumdisplay.php?fid=8)
+--- Thread: Single Player modding/mapping and the UMP (/showthread.php?tid=155)
Pages:
1
2
- Marshall - 15.01.2006
I am working on the next version of the UMP and am trying to sort out all the SP issues.
Whilst this has not been 100% confirmed, I am confident that IE #14 [modenc] is caused by setting DeploysInto/UndeploysInto on an infantry unit, and then modifying that infantry unit's entry in a subsequent override rules-set.
Thusly:
Example1:
rulesmd.ini > ENGINEER.DeploysInto=something
mpmwmd.ini > ENGINEER.TechLevel=-1
IE will occur in Mega Wealth mode.
Example2:
rulesmd.ini > ENGINEER.DeploysInto=something
mymap.yrm > ENGINEER.Strength=200
IE will occur when playing on <mymap.yrm>.
Example3:
mpbattlemd.ini > ENGINEER.DeploysInto=something
somemap.mpr > ENGINEER.Speed=2
IE will occur when playing Battle mode on <somemap.yrm>.
My first inclination is to only set the DeploysInto linking logic in multiplayer game mode files.
Unfortunately, there are probably several maps that modify the infantry in question (Dogs, Engineers, and, in Purple Alert, SEALs).
The single player maps could possibly be modified for the UMP (so that the linking issue is still fixed), as they are all being included anyway to fix other bugs.
If there is an abundance of multiplayer maps where infantry linking is impossible, then perhaps infantry-linking should be outlawed, or at least the modder will have to think carefully and make the user well aware of potential crashes on custom maps.
At the very least, mappers need to be implored not to modify those infantry that are frequently linked (Dogs/Engineers, although as I said, modders might link additional infantry units). Unfortunately that could curtail modmap moddability.
What the UMP instructs people to do should be the standard community practice.
DCoder is a good person to reflect on this, as is anyone working on single player mod/mapping, or indeed multiplayer mapping.
- DCoder - 15.01.2006
Marshall;date=Jan 15 2006, 02:08 PM;post=2213 Wrote:Example1:
rulesmd.ini > ENGINEER.DeploysInto=something
mpmwmd.ini > ENGINEER.TechLevel=-1
IE will occur in Mega Wealth mode.
Example2:
rulesmd.ini > ENGINEER.DeploysInto=something
mymap.yrm > ENGINEER.Strength=200
IE will occur when playing on mymap.yrm.
CannisRabidus (CR 1.8 changelog) Wrote:: Moved typeselect mods (can select both dogs and all 3 engineers as same type) to mp overrides to fix broken campaigns. Seems the game thinks more buildings exist when DeploysInto= is abused.
Marshall Wrote:My first inclination is to only set the DeploysInto linking logic in multiplayer game mode files.
Unfortunately, there are probably several maps that modify the infantry in question (Dogs, Engineers, and, in Purple Alert, SEALs).
The single player maps could possibly be modified for the UMP (so that the linking issue is still fixed), as they are all being included anyway to fix other bugs.
If there is an abundance of multiplayer maps where infantry linking is impossible, then perhaps infantry-linking should be outlawed, or at least the modder will have to think carefully and make the user well aware of potential crashes on custom maps.
At the very least, mappers need to be implored not to modify those infantry that are frequently linked (Dogs/Engineers, although as I said, modders might link additional infantry units). Unfortunately that could curtail modmap moddability.
What the UMP instructs people to do should be the standard community practice.
DCoder is a good person to reflect on this, as is anyone working on single player mod/mapping, or indeed multiplayer mapping.
My thinking is that Dogs should be side-exclusive, like the Amph Transports are in CannisRules. They can be visually differentiated also, so they can logically be treated as different units.
Engineers, on the other hand... Well, the main problem as I see it is allied engineers coming out of all destroyed ConYards. There really is no solution for this, short of using the Technician for that purpose, and making him significantly different from the Engineer...
As you see, my suggestions are really ways to avoid infantry linking rather than work around the problems it creates. That is my choice uless PD manages to track down this IE to something rules-fixable...
- Marshall - 15.01.2006
I agree that avoiding linking would be preferable to working around the problems it causes.
However:
Yuri not having a dog means he could potentially have two attack dog types (forget the land rush issues for now).
Does the AI ever build Yuri attack dogs? If not, then new attack dog types could be created that would never be subject to map modifications.
The technician as generic [doesn't have to have different properties] engineer would, IMO, be an acceptable compromise as that would mean only 1 missing link (however Yuri can, of course, mind-control enemy Engineers).
I think that avoiding linking (even if it means missing links) is the best option. That way, although there are some missing link issues, there will be no chance of IEs cropping up.
As such, linking will now be covered in the 'extras' section of the UMPDP and generally discouraged.
- DCoder - 16.01.2006
Yes, I believe that would be the best choice.
(Ouch, I just remembered I promised you a 'cleaned up' ini set last year... I'll get to it quickly.)
- Bobingabout - 16.01.2006
just on a sidenote, i give permission to include my re-coloured engineers in the UMP if you want to make them look different.
- Apollo - 16.01.2006
Just don't use the deploysinto= and yuri getting two dogs is ugh... custom engineers would be fine.
- Blade - 17.01.2006
In my own tests of using linking (which I rely on to achieve certain effects such as the american paradrop giving veteran GI's) I have never gotten any kind of IE in games where E1 is modified by mode or map. I run on XP in Win98 compatibility mode if you want to compare operating environments.
- Marshall - 17.01.2006
It's possible that the unit must have certain other properties if the error is to occur.
We have clearly seen the problem on Engineers.
I will need to further test my other linked units to see if the problem occurs.
Blade, have you tried to cause the error by linking Engineers?
I doubt the op env has much to do with it, although admittedly I'm running ME. What about you DCoder? And what were the specific circumstances of your IE w/ Engineers whilst converting the single player campaigns?
- DCoder - 17.01.2006
I'm running WXP with slipstreamed SP2.
My IE details:
Mission S02. IE occurs as soon as I attempt to scroll the screen to the area where the allied WF is, even if the area is shrouded and the mission has only started 5 seconds ago. It doesn't cause that IE anymore once I comment out the [DOG] section from the map. Take note that after my rulesmd tweaking the DOG in question is the soviet-exclusive version, so the AI (Allies) shouldn't be building it at all.
My thinking is this IE has something to do with the automatic object caching even without them being in the appropriate [xxxTypes] lists, like PrismType=ATESLA caches ATESLA as a BuildingType even without it being in the [BuildingTypes] list. Which agrees with Cannis' opinion. What exact combination of coding causes the IE, I do not know, but I am curious what was to happen if you defined a BuildingType [DOG] with TechLevel=11 and other anti-AI stuff. I will try to test this suggestion today.
Edit: Nevermind... not sure what I was thinking when I wrote that... Defining a second [DOG] and [ADOG] with TechLevel=11 does avoid the IE, but then again the TL=11 prevents the real dogs from being buildable in skirmish, plus there's no guarantee the game will assign the right [DOG] to the infantry and structure respectively... No go.
- magnet20 - 19.01.2006
It seems like the rp v 1.7 and 1.7b does not like ME very much. I have also had serious issues on ME, but not on my Windows 98 (I still cant run YR with rp 1.7-1.7b on ME).
- Marshall - 19.01.2006
That's as maybe, but this thread has nothing to do with the RP.
- Blade - 21.01.2006
I've just checked over my code and I put the links between E1 and my none buildable paradrop equivalent in the game mode file only so it wouldn't break maps unless played in that mode and so I've never noticed it.
- Marshall - 21.01.2006
That makes sense. It's unlikely that you will ever endounter a problem but if you played on a map that modified [E1] then you would get the error.
Because of this, the DP will discourage infantry linking.
I suppose one could make a clone of, say, [E1] and name it something 99% likely to be unique. Then make [E1] unbuildable by human players, and the clone buildable. Make the Allied Crew equal to the new unit, etc, etc. That should be pretty safe.
Not sure if that should be part of the core UMP fixes though as it's quite a bit of work. I think that's best for the Extras section.
- Blade - 22.01.2006
Thats pretty much what I'm going to do just to be on the safe side.
- Marshall - 22.01.2006
I plan on including the following document in the extras section of the UMP DP.
Any input regarding it is welcomed.
----------
Infantry Linking using DeploysInto/UndeploysInto (Engineers, Attack Dogs, etc)... and why you shouldn't do it
Infantry Linking is generally discouraged because it requires complex work-arounds for the problems it causes and also invites Internal Errors.
What is infantry linking?
When you press the 'select-all-of-type' button, all units of the same type as the one(s) you have currently selected will be selected as well. Infantry linking allows you to treat multiple infantry units as the same type, as far as select-all-of-type is concerned.
Normally, if you have a GI selected and you press the select-all-of-type button, all GIs on the screen that you own will be selected as well.
With infantry linking, you could end up having all GIs and all Navy SEALs selected too (and vice versa).
How does it work?
The Slave Miner is made up of two units; the vehicle form and the structure form.
The vehicle form has the flag DeploysInto=YAREFN, and the structure form has the flag UndeploysInto=SMIN to allow the unit to change from one thing to the other.
Part of the DeploysInto/UndeploysInto logic makes both unit types be treated as the same type by the select-all-of-type function.
Infantry cannot deploy (or undeploy) into another unit. But when you use the DeploysInto/UndeploysInto flags on an infantry, the select-all-of-type logic is still effected.
From the above example:
[E1]
DeploysInto=GHOST
Would mean that Navy SEALs (GHOST) would be selected as well as GIs (E1) with a GI originally selected.
However, it does not automatically work the other way around...
[GHOST]
DeploysInto=E1
...would be needed for that.
You can link up to three infantry units all to each other by using DeploysInto and UndeploysInto together.
However you must bear in mind that the logic also makes the game think that there are extra structures/vehicles in the game, with the IDs of the units you specify. This causes the problems that we will discuss shortly.
Why is it needed?
Each side has it's own Engineer. But when an Engineer emerges from a destroyed Construction Yard, it is always an Allied Engineer.
This means that when a Soviet player selects-all-of-type on an Engineer, they may not get all of their Engineers selected.
Further more, Yuri can mind-control Engineers and so Yuri players could potentially gain access to all three Engineer units.
Similarly, there are 4 Attack Dogs in the game. In Land Rush mode especially, the linking problem occurs when a player gains access to multiple Attack Dog types.
Finally, you might add side-specific versions of a new unit type - they are not normally all selected at the same time either.
Infantry linking can be quite useful to avoid this problem (and sometimes eliminate it entirely).
Why shouldn't we use it?
Because it can cause Internal Errors if not used 110% properly.
An Internal Error can be caused by setting DeploysInto/UndeploysInto on an infantry unit, and then modifying that infantry unit's entry in a subsequent override rules-set.
Thusly:
Example1:
rulesmd.ini > ENGINEER.DeploysInto=something
mpmwmd.ini > ENGINEER.TechLevel=-1
Internal Error will occur in Mega Wealth mode.
Example2:
rulesmd.ini > ENGINEER.DeploysInto=something
mymap.yrm > ENGINEER.Strength=200
Internal Error will occur when playing on <mymap.yrm>.
Example3:
mpbattlemd.ini > ENGINEER.DeploysInto=something
somemap.mpr > ENGINEER.Speed=2
Internal Error will occur when playing Battle mode on <somemap.yrm>.
The Internal Error occurs when a human player positions their battlefield view over an AI-controlled War Factory.
Note that the error may be caused by modifying the 'to' unit of a link, rather than modifying the 'from' unit. The exact details of the cause of the error are not yet established.
Because you have no control over what modifications any custom maps might include, it is very difficult (and even impossible on certain game modes/map filters) to guarantee that your mod will not be the cause of Internal Errors.
The disadvantages of missing infantry links are insignificant when compared to the huge disadvantage of an Internal Error occuring.
Previous versions of the UMP included infantry linking on the Engineers and Attack Dogs as part of the core fixes, however such 'fixes' have since been repealed.
There must be some way we can use this?
Well, yes there is.
A common example of two units that you may wish to link are two types of GI: A buildable one and a paradropped one.
1. Make a clone of [E1] and give it an ID that is 99% likely to be unique. Some sort of alphanumeric serial number that is truly random would be good. (Ideally, you want all of your custom units to have an ID that nobody else could possibly use in a map.)
All elements of a linked-infantry group should have totally unique IDs.
2. The original GI ([E1]) should be made unbuildable by human players. The only way I know of doing this is to give it a Prerequisite of a building that could never possibly exist on a custom map. This dummy building should be properly defined in your code and have a unique ID.
AI players ignore prerequisites and so will still be able to build the original GI.
3. Set AlliedCrew= to your GI clone.
I don't think the flags Pilot= and PParatrooper= are even parsed, but if they are then they might need to be changed.
4. Set AllowedToStartInMultiplayer=no on the original GI (and 'yes' on your GI clone).
Obviously the AI scripts can be left alone as the AI is unaffected.
It's quite a bit of work but it will allow you to use infantry linking 99% safely.
Two problems still remain though:
1. You can mind-control a unit from a computer-controlled player that will not be covered by the appropriate infantry links. (Presumably you could replace all occurrences of a unit with its clone, in <aimd.ini>, in order to avoid this problem.)
2. Any changes to the GI that are introduced by a mod-map will only apply to AI-built GIs, not to human-built GIs. (Again, if you made the appropriate modifications to <aimd.ini>, at least mod-map changes would not apply at all.)
If your mod supports the original single player campaigns then you will have another problem because some of the maps may modify the units that you are trying to link in this manner (for example, the Engineers). To overcome this, either you will have to NOT link the units in the campaigns (by only making the modifications in the appropriate game modes) or you will have to include a modified copy of the maps in question (in which case don't forget that all of the single player maps have already been bug-fixed by the UMP and are included in this Developer's Pack).
You should not attempt to make use of infantry linking unless you clearly understand every facet of this document.